Mentality Drives Technical Competency
Have you ever asked the question, “How do we help more developers be like Bill, so Bill doesn’t have to review every last piece of code put into the system?” Most likely, Bill is your best guy: He’s your tech lead, the alpha geek (and proud of it)! But pose this question to Bill and likely all you’re going to get is a big old ¯\_(ツ)_/¯ (shrug). The truth is, Bill might not know why he’s better at catching code errors or pitfalls than his peers, he just is. Therein lies the secret!
Many times, we look at technical competency from the perspective of language proficiency, framework experience, database chops, and other skills related directly to “what” developers do on a daily basis. I submit, however, that if you survey the landscape of developers at your company and mentally tap the ones that truly stand out, some of them may actually be considered behind their peers in this regard. So, how then have these folks been determined the “technical” leads? It is because they are better at the “why” aspect of software development.
For developers looking to improve in this area, I have compiled a list of questions to ask themselves as they do their jobs on a daily basis. It is by no means a complete list (producing such a list would be an impossible task). However, these questions are born from issues I’ve found to be common pitfalls for developers as I have reviewed code over the past decade. The goal of this list is for a developer to review code changes (the “what”) in context of a tech lead mentality (the “why”), using the questions here as a crutch until the questions become subconscious and automatic. When the mentalities are internalized, questions like these come naturally, and your developer will find herself at a whole new level in her career (regardless of not yet being able to dig into that latest Rails release!)
|
Situation (What?) |
Question |
Mentality (Why?) |
|
When determining the correct logic for code or a data query... |
Is there somewhere else in code that is already doing this (or something similar)? |
This is a HUGE time saver and risk mitigator! Most business logic we are implementing can be found in some shape or form elsewhere in the code base. Get good at determining the right text to search for in code (e.g., parts of variable, field, or function names) in order to find business logic you are looking for. |
|
When making any code fix... |
Is there other code that needs a similar fix? |
Something done wrong in one area of code is often done the same way in other areas of the same code base. |
|
When changing common code... |
Does my new generic code refer to feature-specific code that wouldn't be considered generic? |
Generic code referencing feature-specific code is often a circular dependency (because that same feature-specific code references the generic code) and should be avoided. In tightly coupled, monolithic code bases, you can often get away with this. However, it's a bad pattern to establish in your mind as acceptable because it doesn't transfer into modern architectures (e.g., modular environments like Drupal, SOA environments with REST services, etc.) |
|
When changing common code... |
What else is using this code, and am I changing or breaking any existing functionality? |
You don't want to unintentionally change (or worse, break) current functionality, so a code analysis must be done to ensure this doesn't happen. Ideally your changes are made in such a way that existing calls to the code you are changing maintain the previous functionality, unless you explicitly desire otherwise. |
|
When replicating a piece of functionality... |
Can I make this into a generic, reusable function instead of repeating it? |
Any amount of business logic, even just 2 or 3 lines, is almost always better in a reusable function. It makes that function more testable, both manually and via code unit tests. It also makes changes to that logic much easier to make in the future, as the change need only be made in one spot. |
|
When adding functionality to a user interface (UI)... |
Is the new functionality consistent with similar existing functionality within the application/page/site? |
When you are knee-deep in code, it can be easy to be oblivious to the cosmetics and user-friendliness of your new functionality. Before a new UI change can be considered complete, however, you must take a minute to switch hats to a (potentially untrained, non-technical) user and think about what that user would expect. Sometimes you may even need to step away from the computer a minute or two to transition your state of mind. |
|
When deleting code... |
Have I deleted all unused code previously referenced by what was deleted? |
It is often tempting to leave this extra code remain, as that requires less work and appears less risky. But that’s just being lazy and sloppy, trading short-term ease for a long-term tax on maintenance of the code base. Also, there is no need to keep code "in case it is needed in the future" because it can always be restored from source control history. |
|
When making an unintuitive code change... |
Will someone be confused by this change, either in code review or when looking back on it in the future? |
An unintuitive code change can lead to time wasted on code review or worse, someone undoing your change in the future. To mitigate these risks, comments in the code, on the code review, or both should be used. |
|
When updating code not directly related to the current task... |
Will my QA tester know to test this change? |
A test plan needs to involve all areas potentially affected by your changes. This includes functionality that may not have been directly changed, but uses common code that you did change. Remember, the QA person probably has no idea to test these areas unless you tell him! |
|
When adding peers to a code review... |
Have I first done the review (within the code review tool) myself? |
It's one thing to have diff'd the code before committing, but code review software often gives a different/fresh view of the changes that make unintentional changes or bugs way more obvious. Before having others spend (i.e., waste) their valuable time reporting to you on these obvious issues, your own "pre" review should catch and fix these items. |
|
When receiving a code review suggestion... |
Does this suggestion make sense? |
A code review suggestion is often based on limited analysis by the reviewer. You've spent hours/days in this code and the reviewer probably only minutes. Even if you consider the reviewer your superior, you should generally not implement changes just because "he said so." The suggestion should be analyzed in light of your current system knowledge and any additional analysis required in order to validate the suggestion prior to acting upon it. |
