"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."- Abraham Maslow, 1966
Here, within the Lift Development team, we’re the most successful when we don’t do our jobs. Confusing? That’s probably because it’s a counter-intuitive way of working. Just imagine hiring a carpenter to not hammer nails or cracking an egg to not cook it.
As developers, we write code to support the greater project and to either solve a problem or create value. Code is what makes your domain name become a website. It puts the site in your browser, it pulls the data out of the database and so much more. It’s the tool we use and in a lot of ways, writing code is part of our identity. It's the core of every digital project, because code is what puts things on the internet.
If our job is to write code and someone gives us a problem to solve, it’s pretty easy to start imagining all the code we could write to make that happen. We do this all the time. We hire people at Lift who are the best at their craft—Our developers are among the best in their field, and to them, writing code is easy (though some of the problems we have to solve are not).
Every line of code potentially contains a bug, so the more you write, the greater the quantity of bugs. Simple math. The only way to be 100% certain there are no bugs is to write no code. Obviously, this isn’t very practical so let’s just say this is a theoretical goal, shall we? The challenging part of this is that we have to write code to fix a bug and therefore we’re adding more bugs by fixing them. Sometimes there are bugs that hide other worse bugs and fixing one reveals more than you bargained for.
There are a few viable strategies. First, we can use well-tested third-party libraries, APIs and other external sources of code (basically offload the bugs to someone else). If we choose badly though, we could end up with more and worse bugs.
Another option is to do more planning so that we work out the issues before we even start writing code. A good code plan can save a project a lot of trouble. We could also use other methods to solve the problem and sometimes we need to put code aside. Perhaps you can solve the problem with a pen and paper, an email, a picture, or a spreadsheet. That extra code you need to eliminate these sorts of things might not be worth it. Self-discipline is key. Stepping back and thinking before we write or actively trying to reduce the code as much as possible is a great way to increase the efficiency of a project.
A carpenter is so much more than a “hammerer”, a developer is so much more than a coder
In our world, where often better is more, not less, it’s challenging to go against the flow, to be the zen master who says volumes with just a few thoughtful words. An elite chef doesn’t use more ingredients, but rather executes them in a highly strategic way. It takes practice, training and discipline to write less, to be a 10% developer (not a 10x developer).
While it’s impossible to get away from writing code, it’s a worthy goal. It’s probably going to happen in the future anyway. In a lot of ways it feels wrong to be a developer and not write code, but the job we have is to solve problems and create value and if there’s a smart way to do that without writing a line, we should pursue it.