Find a Process That Works for You

Once you’ve mastered your tools, the next thing to focus on is your own process for producing software. Every programmer approaches software development differently, and what works for some people may not work for others. There are several development methodologies and ways to solve problems, but I’m going to share a process with you that I’ve found works for a lot of programmers. It’s simple and straightforward, and it helps you stay focused on the important thing—delivering working software. So, here’s the process:

Make it work, make it right, make it fast.

That’s a quote from Kent Beck, the creator of extreme programming and one of the original signatories of the Agile Manifesto. Kent has shaped programming in many ways, and this technique will hopefully shape the way you approach programming. Following this simple pattern will help you manage the complexity of your own solutions and prevent you from trying to do too much all at once.

Let’s dive into it a little more.

Make It Work

When you first set out to write new code for a feature or bug fix, you should be fully focused on proving the problem can be solved. Without this step, nothing else matters, so you should always value a working solution, even if it’s messy, over something clever that doesn’t compile.

​important​ You are allowed to violate principles of good software design in this phase because your only goal is to make things work and work repeatedly.

This phase of software development can be compared to writing the first draft of an essay, so it’s okay to have ugly and messy code while you’re working towards a solution. You don’t need to come up with good variable names or a good object-oriented design, and your code doesn’t need to be elegant. It’s completely fine to start out scripting a solution at first, if that makes it easier for you to focus on solving the problem.

Once you are able to compile your code and run it, and you have somewhat of a working solution to the problem you’re solving, save your progress. Commit your changes to version control. Doing this will give you a good stopping point where you know you have a working solution. Now that you have at least something working, you can begin to refactor and improve upon the solution.

Make It Right

Once you have a solution that you’ve proven works repeatedly, it’s time to move on to the next phase, which is to make it right.

To follow the essay comparison, this would be the revision phase. Here you should focus on improving the design, reliability, and readability of your code. This is where you refactor the code you just wrote—clean up your naming conventions, introduce abstractions and interfaces to aid in extensibility, and add tests. Make sure to cover all your edge cases and remove any hard-coded values you may have used in the first phase.

Your goal is to clean up the code so that when you return to it in the future you’ll be able to understand what it’s doing and easily change it if needed. There may be other programmers on your team that could be extending it in the future, so keep that audience in mind when refactoring and documenting.

Your code should be bulletproof at the end of this phase. You should be confident in your solution and comfortable shipping this code to production.

Make It Fast

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.Donald Knuth, The Art of Computer Programming

This last step, which happens to be the hardest, is to improve the performance of your solution by making it fast. The reason it’s the hardest step isn’t necessarily because performance gains can be hard to come by, but because it can often be hard to find the time or resources in order to properly improve the performance of your solution.

After you’ve finished the “make it right” step, your code should technically be ready for production. You should be able to ship it and move on to the next feature or bug fix that provides value for your customers. And this is what makes the “make it fast” step so difficult, because you may be able to provide more overall value by ignoring this step completely and working on a new ticket.

In some cases, shaving a few milliseconds off the run time for your solution may not be the best use of your time, because that’s not what’s adding the most value for your customer. It’s a good idea to communicate with your manager before starting this step, because they may have other projects that take priority over optimizing your solution.

In the end, your goal is to provide software solutions that provide value to your customers, so it’s important to be aware of how much time you’re spending on performance optimizations. Most of the time, “good enough” will be fine to satisfy the requirements so you can move on to the next project coming down the pipeline.