editione1.0.1
Updated August 7, 2023The first point to remember is that perfect software doesn’t exist. There will always be multiple ways to solve a programming problem, and each comes with its own trade-offs. Some may be faster or scale more efficiently, while others may be easier to read and understand, maintain, or extend. Rarely will there be a perfect solution to a problem because there will always be compromises that come with each option.
There’s a model of constraints called the Project Management Triangle that states that the quality of work for a given project is bound by three things: the budget, the deadline, and the scope of a project. While it’s possible for the project manager to trade between these constraints, they’re only able to optimize for two of the three. Programmers and engineering managers commonly refer to this model when they state that software can be good, fast, and cheap, but the catch is that you can only choose two.
Fast and cheap projects tend to produce lower-quality software
Fast and high-quality software will be expensive to produce
High-quality and cheap software will be slow to produce
Figure: Project Management Triangle.
There will be times when you’ll be forced to make trade-offs or cut corners in order to meet a deadline or keep a project under budget. It happens all the time in software development. The reality is that you have to accept that some code you ship to production may be sloppy, inefficient, or could be optimized better if you had more time.
Junior engineers tend to keep tweaking and fine-tuning a solution because they want their code to be clean and perfect, while senior engineers tend to have a better feel for when a piece of code is “good enough” to ship, and then they move on to the next task. If you look closely when reviewing pull requests from your coworkers, you’ll begin to notice code written by senior engineers often has a hint of inelegance to it. They understand that it’s not worth the time to optimize and fine-tune each and every algorithm, abstraction, or variable name.
Knowing when to ship “good enough” code is a skill that you’ll build over time, not something you can learn overnight. The more software you ship, the more you’ll understand where to focus your time and effort, and where you can write some quick and dirty code that gets the job done.
If you ever talk to a great programmer, you’ll find he knows his tools like an artist knows his paintbrushes.Bill Gates*
As programmers, we have thousands of tools available that help us perform our jobs, and choosing the right tool for the job can increase your productivity tenfold. But a lot of powerful tools go underutilized because the programmer doesn’t understand how to use them to their full potential.
Before you can truly be productive as a programmer, you need to develop a deep understanding of the tools at your disposal. You should strive to regularly add new tools to your toolbox, but with each new tool you add, be sure to take the time to learn its advantages and disadvantages so you can know when (and when not) to reach for it. No tool is perfect for all situations, so don’t fall victim to relying on just one tool because you’re comfortable with it. Every tool has its strengths and weaknesses, and a good programmer knows when it’s best to use each one. These are the tools with which you will build great things, but you can’t do that until you know them inside and out.