Professional Improvement

To develop myself within my profession, I have started performing regular lessons learned reviews of my own performance using the 5 Why's methodology. Whenever I detect a problem with my work, (eg. taking longer than estimate, or faulty work), or when I encounter above average success, I perform a lessons learned to identify the behaviour that lead to the success or failure.

Implemented Improvements

Symptom Action Taken
Submitting poor code for code review, or worse, checking in poor code. Also passing poor code when performing code reviews. Started maintaining a code review checklist, updating with lessons learned.
Missing or extraneous content on functional specs. Started maintaining a functional specification checklist, updating with lessons learned.
I had spent a whole afternoon trying to find the source of a compile error. It turned out to be my library path pointed to a directory that didn't exist. My library path environment variable is set when I source out an environment from a script that is auto-generated by the script that creates wip branches. I knew the value needed to be changed, and I changed it, but I didn't know that re-sourcing the environment would not update the library path environment variable. Modified the auto-generated source script to validate the directory when setting. It also asks whether to use the a default setting (the one that I use 90% of the time), rather than just automatically using the setting that it had been using (the one that I use only 10% of the time). April 15, 2008
I was spending too long running down avenues of diagnosis that turned out to be fruitless. Created an alias to set a timer. When I notice that I'm getting stuck, I start the timer. When the timer goes off, if my current approach has gotten me nowhere so far, I either switch my direction of attack, get a second set of eyes, or, if possible, put off the task until I can come back fresh. April 15, 2008
When committing code to trunk, missed a number of files and accidentally committed files of unknown status (which subversion interpreted as a request to delete them). The script I had been using to assist in checking code was designed for our previous revision control system, not subversion, although it worked well in 90% of the cases. I modified that script to work with svn status, rather than the previous method which caused the missing files. This script automatically filters out files of unknown status. (See Subversion File Management Tool.) April 21, 2008
I was getting stuck on debugging sometime because of an assumption I had made earlier, but didn't document. Added an empty Risks and Assumptions list to my issue template. February 11, 2009
I was sometimes not reading the issue carefully enough sometimes before plowing in. Added fields to fill in before starting an issue to my issue template to force me to get the most vital information and to read the issue carefully before starting. February 12, 2009
I was running into issues debugging code by left over debugging code from previous issues polluting the results. Added an check box for cleaning up code before finishing an issue to my issue template. February 12, 2009
Estimating work for repetitive issue types was taking too long. Although this isn't my own solution, the company I work for started putting the task break-down and estimates into our design docs, then moved design docs to a common repository. This allows me to quickly find similar issues and base my work on them rather than re-inventing the wheel. February 23, 2009
Got lost during debugging sometimes, forgetting what I've checked and what code I've already looked at. Added sections to my issue template for Hypotheses and Next Actions, each containing check lists so I know what I've ruled out, what I've already checked. February 23, 2009
Assumptions and stop-gaps found their way into my check-ins. Further leveraged the Assumptions and Risks section in my issue template by adding a check box in the flow to verify that all assumptions and risks have either been verified or documented. April 2, 2009
I was requiring multiple compiles to get all the variable names correct. Also, labels, database and table names, and other text the compiler won't catch were causing bugs in my code. Learned the word completion feature in Vim. May 1, 2009

Potential Improvements

  • Find ways to reduce distractions from others. Identify specific distractions and minimize them.
  • Identify a methodology for approaching an unfamiliar code base. (Needs specifics.)
    • Find a good code to UML tool. (Umbrello does only one header file at a time.)
    • Find a better way to ask code experts if my understanding of their code is correct. Prevent being blindsided in the High Level Design review meetings by the code expert.
    • Develop a framework/toolset for tracing through code (complete with file names, classes, line #'s, calls, etc…) to speed debugging.
  • Identify my own distracting bad habits and coping mechanism then replace them with positive habits, or brace them.
  • Find ways to mitigate selective perception.
  • Develop professional humility. (Needs specifics.)
  • Implement automated self check-ups to determine if I am on-track to complete my tasks for the month.
  • Get some sort of lint tool for the languages I'm using.
  • Learn to capture thoughts that lead to sloppy habits. Good habits make great programmers. Once identified, add to code review checklist as a question. Find a more preemptive way.
  • Learn how to deal with internal and external distractions. (Feb 23, 2009)
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License