Skip to content

Instantly share code, notes, and snippets.

@butterybread
Created May 29, 2017 12:41
Show Gist options
  • Save butterybread/825f5406f3d6456ff96b318bf3174525 to your computer and use it in GitHub Desktop.
Save butterybread/825f5406f3d6456ff96b318bf3174525 to your computer and use it in GitHub Desktop.
An article about developer discipline

Developer discipline

I believe the source of many bugs in code can be found in how much discipline a developer has.

When a developer builds a new feature in an existing codebase, there are many routes he can take. Each resulting in a different quality of code written. Usually when a new feature needs to be introduced, some code needs to be changed or refactored to allow for the new functionality.

The case of simplicity

If this developer wants to write the feature as fast as possible, he will write code until the requirements are met. But by adding new code, the codebase might not be so coherent as before. Some lines might be added or changed in existing functions resulting in that function having a different responsibility. Did the function name change? Is it still in the correct module? Should it by abstracted? When focussing on delivering a feature as fast as possible, who cares about code quality. Well you should. Definitely when you are maintaining that codebase for a few months. Why? Because code is read way more than it is written or changed. And within a few months, you no longer remember what you wrote, or why you wrote the code the way you did. The context that you had in your head at that time is gone. And if you wrote something complex, its going to take so much longer to get back into the context. Thats why its a good idea to, once you have a feature working, to revisit your code. Because know you have a working feature. You know how it works. You have a high level structure of the different components working togheter. Now you can improve that structure by making it as simple as possible.

Bug fixing (when you have

If a bug is hard to find or fix, a developer might become agitated or stressed. Debugging some code and not seeing where the bug resides is frustrating. So when the bug is finally discovered, he wants to fix is as fast as possible just to get it over with. His current context is colored with frustration. He wants to change context as soon as possible. But he can only switch to a different task once this bug is fixed. So when finding and fixing the bug. It is fixed in the fastest and easiest way. Not the best way. The best way might involve the refactoring some code and renaming some functions. But unfortunately, that is not what happens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment