🏄️ Developer Workflow

Updated at 2015-12-19 06:52

Write code as if you had to support it for the rest of your life.

This note is about professional software development from a single engineer point-of-view. This is related to productivity, estimates, team development and developers.

Developers must have self-discipline. Employers cannot force programmers to do a good job. In the most of cases, the employer cannot even tell if a developer is a good programmer or not. Only thing that matters is how you appear to the management and having the willpower to work and voice your ideas

Code should never be written on autopilot. Developer should think what they are doing from time to time. Is he repeating the same pattern over and over again? There might be a simpler way of doing the task in the current context or a way to generalize the implementation so that the pattern can be implemented in the design. Developers go to autopilot when they are tired or in a hurry.

Focus solving one problem at a time. Avoid getting derailed and fix unrelated stuff while working on that a task. Write a todo comment for the unrelated parts and fix them after the task.

Do everything in small bites. Many incremental changes are better than one massive change. Then, if something breaks, you can more easily check which of the change breaks it. Make sure all tests pass after each iteration.

Over-engineering is a curse. Don't build it until you've been asked for it. In the end you might have to maintain something that no one even wanted. Solve each problem as they are encountered, only handle error cases that you've noticed or know will happen. Don't speculate.

Focus on the task at hand. When you feel like "hmm, this might change later" or "OH! this might break if...", stop for a while to think. If the change is going to happed tomorrow, you may do it but any further than that, don't bother. Never fix non-validated problems. Writing code is easy, understanding other people's code is tiresome, focus on small and concise solutions.

If isn't broken, don't fix it. Push away your personal ego and preferences. Not even if you have some really neat new library you could use.

There are always multiple solutions for each problem. The first way that you come up with is highly unlikely the way it will look in two weeks. There are no best solutions, only best solutions for the given context and the context may change in the future.

The simplest solution is usually the best solution. Reduce the amount of moving parts as much as you can.

  • Faster to implement and change later as it will change anyway.
  • Easier to understand and reduces cognitive overhead for others.
  • Easier to maintain and less parts that might break by an update.
  • Has no drawbacks if you keep everything neatly encapsulated.

Technical debt. When you have the options to "do it quick" and "do it right", choose "do it just right enough". Do it so that it does just minimally what it's supposed to do while allowing changing it later. This is an important characteristic of great engineers. More about this in code complexity notes.

Pragmatism over perfection. Code is just a mean to an end. Code itself is unimportant, understand cost and value of your work. Remain objective of you own work; are you using your time on the right battles? Don't design systems around edge cases, build the most common scenario first. Care less, care appropriately.

Your ultimate target is to generate money for somebody or something. Clean code is not your goal. Working software is not your goal. Programs you write can be beautiful, but that is not your goal. When you are professional developer, your goal is to generate revenue or reduce costs. But this should involve writing clean code (maintenance) and making working software (correctness); and having fun while doing it.

Avoid writing code when you are tired. Only thing worse than no progress is bad code that you will need to fix in the future. Go get some sleep and try again later.

If you cannot reproduce a bug, you cannot fix it. Set a trap for it and log all related variables. And don't blame the hardware, framework or others, it's usually your own fault.

Crash early. If a caller tries to use a sound file as texture, do not make any tricks, just crash and give a message. 90% of the time it is a development mistake and can be fixed in minutes. But if you let it go through, it might build into a huge bug.

Avoid the temptation to rewrite everything. Reuse as much code you can, no matter how ugly the code is. Throwing away old code always means you are potentially throwing away really well tested code.

Developers must understand:

  • How to use the Internet to get answers for most of their programming problems. There is no point in reinventing the wheel.
  • How to use command shells, especially how to create basic scripts. You should automate everything that can be automated.
  • How to use one general usage text editor really well. For example Notepad++, Sublime Text, TextMate, vim.
  • How to use an IDE for each language they work with. One IDE can be same IDE for multiple languages. For example PyCharm, PhpStorm, Visual Studio, RubyMine, Eclipse. And no, Sublime Text is not an IDE, even with the plugins you can install on it.

Think about your dev-prod environment balance. When setting up your development environment, there is always this balance of production-likeness and feedback loop time. Ideally you would like to have something that is close enough to production to replicate errors but also stays fast and sleek.