When I first started at the county, I would be called into an office. Someone would say “write a program to do the following…”. I would type up my notes, confirm the request and start coding. I’d post the program on some server and people would use it.
Then management changed. Management created a Dev, test, and production servers and added additional instructions. “Post to Dev and test it. Then post to Test and have the customer test it. When customers have finished testing, then post to production.”
Then management added a code repository, and added more instructions. “For each program. Make sure there is a develop branch, a test branch, and a main branch. Keep the branches aligned with the code on the servers. “
Then they gave us Jira a program to keep track of tasks, and added more instructions. “Each task, should be treated as a separate coding task. A task has a few status codes: new. In progress, in testing, ready to deploy, closed(there’s a few others as well). You musk keep the ticket status in sync with your progress on the coding, through to delivery.
Later “create a code repository branch for each ticket. Create a pull request to have someone review the code changes, give them a day to review, then merge the changes into the develop branch”
Then more instructions. “You do not have programming access to the test or production database. Rather you create a ticket for the dba to change those databases. You must also coordinate the release of an update with your customers, preferably release on Wed evening or Wed afternoon”
Each of the added tasks are fairly simply. But here’s what it looks like if you arranged the work into a checklist.
- Changes Jira ticket from “new” to “in progress”
- Create a branch.
- On your programming editor, change to the new branch
- 1: Do your programming changes.
- Test your code changes locally.
- Commit / push / create code review
- Merge to develop
- Deploy to development web server
- Test on development server
- Create pull request from develop to test branch
- Merge to test
- Submit dB change request (if necessary) to update test database
- Post to Test web server
- Test Test website
- Change Jira status from in progress to in testing
- Update documentation.
- Notify uat team to start testing changes
- If problems found. Return status to in progress, return to step 1:
- When testing is complete, change status to ready to deploy
- Schedule a release time
- Create pull request from test to main branch
- Submit and schedule a dB change request (if nessesary) to update production data base
- Merge to production
- At release time, update website and data base.
- Quick safe smoke test
- Close Jira ticket
Wow that’s a lot of work to do with for one programming assignment! Realistically it is probably right, but maybe I spent a lot of my career taking shortcuts, maybe shortcuts on shortcuts.
On thing you dont see are items that would be included for other people. For example maybe before the task goes to me, it would had gone to a business analyst so that requirements could be better documented. I have to say, while these processes should already be in place, maybe they are not, or maybe they keep track of their own work in different ways. This is a document of how I keep track of my work.
But As you can see, making a simple programming change takes a lot of work. The items in bold were what I used to do (maybe a few more should be bold)
This bullet list is typical and possibly realistic of the steps you need to do of you are a programmer working in the kind of environment I work in (which I perceive to be fairly typical)
And this list of steps is the same (except for the do your programming changes) each time you make a change to an application. Generally, you learn the above process, but it’s petty brittle and mistakes happen.
What I do, is for each task assigned to me. I will make a copy of the bullet list (above or at least a similar one) into a document associated with this task. (Or Lately for most of these tasks, into the body area of the jira ticket)
Then as I work on the task, I’ll mark off bullets as they are done. (I’ll put a date and the word ‘done’ or ‘skipped’ next to each task bullet). Most items only take a moment but it’s easy to get distracted and to lose your place, and then mistakes start. Sometimes I’ll add other non essential data and additional reminders as well.
Working the checklists have forced me to work the process in the same order and I have found it to help produce quality consistent results.
I’ll stop working on the programming tasks for a number of reasons including interuptions, meetings, or a blocker like waiting for a pull request to be processed, or a OPS ticket to be processed. At the end of the programming section, I’ll usually move the checklist items I’ve completed out of the list. (In the Word document, it will go above the ticket todo list. In a Jira ticket, it will be added to a comment, we’re I’ll summarize the work completed in the session, and past in the completed checklist items.)
For me, for now. This is the basic task list for a programming ticket. Over time new requirements are added and dropped. So over time, the list will grow or shrink.
I am not proposing you use the above checklist. But, What I am suggesting is that, if possible, you assemble a generalized checklist for the common tasks you perform and then attempt to stick with it in a consistent manner with each task you preform.
In theory, A business analyst will review this checklist. Probably come up with a procedure guide. The procedure guide is good, because it gives instructions to the newbie. But for me as long as the check list matches to the procedure guide, I find more utility in the checklist.
Pro’s of a copy of the checklist per task
- You keep track of where you are in each task
- You can add reminders to the checklist more easily
- If you are interupted a log, this will reduce the chances of a mistake when you finally get back to the task you are working on.
Con’s
- Appears Excessive?
Computerization of the checklist.
So far I’ve made 3 attempts
The data dictionary
- The data dictionary has a task management system, and for each task there is a primitive subtask system. It has a function to load from a template so I can pick programmer task and it would drop in 20-25 subtasks. When you were done with a subtasks, when you check it off. It gets removed from the list and added to the task notes.
- The program had one major flaw, while you could add additional subtasks, You couldn't sort the new subtask to where you needed it to be.
The Word document
When the office switched to Jira, I lost the subtask capability and moved to a Word document.
This is what was doing at the beginning of 2025. I have a giant Word document. When I start a Jira task I add a task number, and then I add a copy of the checklist with a header ‘TODO’. When I eventually do this task I go to the location in the Word document, and continue to work through that task’ checklist. At the end of the section, I’ll drag the completed tasks to another section ‘Completed on YYYY/MM/DD’.
One big advantages are I can add notes to an item on a checklist and I can easily add additional items to the list.
The Jira Ticket
I heard a rumor that people would like more visibility to the status of my work clearly enough, so I made a change to my work process. Rather than copy the task list to a Word document, I copy the task list to the bottom of the body of the ticket description.
I perform the usual routine, as I work through items on the list I’ll record a date and either ‘done’ or ‘skipped’. Sometimes I’ll include pertinent notes. At the end of the ticket programming session, I’ll move the completed subtasks and associated notes to the to a comment, which include a summary of work completed for that section.