Engineers love innovation, shiny tools, and creative ways of solving problems. This is a good thing and a bad thing. It’s good because we do need new solutions to go forward, but it’s also a bad thing to risk stability, of both the product and the team, by changing an existing project too often.

So it’s up to us engineers to keep the balance. To help you make decisions, I’ve listed some of the biggest traps you should be looking out for during and after the development of a project, and how you can avoid them.

1. Stick to your stack

Before we start writing a single line of code, we have to decide which technologies we’re going to use. While using for example a promising new framework might seem like a great personal learning experience, our coworkers will also have to invest time to learn how to work with and even maintain it in the long run.

Additionally, new technologies often bring various risk that we might be unaware of because of our lack of experience with them. These can influence the development time, and even raise bigger problems like security or compatibility issues which might only become apparent after using it for a while.

So for every technical decision that has to be made, it has to be very clear what the added value would be compared to the impact on the planning and budget. Will our end users enjoy our product that much more if it’s built using the newest framework? How much more time are we going to need because we don’t know the pitfalls and risks associated with this new technology? Remember, the client pays you for your experience and knowledge, not to experiment and learn.

To avoid these problems, only add complementary technologies that expand the capabilities of your stack when necessary instead of constantly replacing major components. Why change a winning team anyway?

2. Code for your use case, not your re-use case

Don’t repeat yourself is probably one of the most misunderstood concepts of software development. While the idea is that you should only have a single source of truth for every piece of business logic, it has basically become a witch hunt for duplicate code, even code that lives in totally different parts of the application and serves different use cases.

As a result, engineers are constantly trying to come up with new abstractions to make their code re-usable for use cases that have nothing to do with each other from a business point of view, or even for potential use cases in the future that might never become a reality. This in itself takes some time, but the worst part comes down the road when it turns out that one of the use cases needs to be changed and the abstractions no longer make sense, so they have to be split up again.

Reducing the number of abstractions to the bare minimum not only saves time in the short term, it also makes the code easier to adapt to unforeseen future use cases.

3. Optimize for the right reasons

Traditionally we would try to optimize our code for either execution time or resource consumption. While it can be an exciting challenge to try to make a piece of code run more efficiently, these optimizations are often premature because technology has advanced so much that basic operations have become very cheap to run.

Humans on the other hand are pretty slow when it comes to code analysis, and it has been estimated that when programmers write new code, they actually spent over 90% of their time reading existing code. So to make things easier for each other, we should aim to optimize our code for readability and predictability first instead.

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

How we make time for the cool stuff at madewithlove

As we’re very aware of the risks involved when experimenting and trying out new technologies in a live application, we give our engineers the necessary time and freedom to do so outside of client projects. This way they can confidently use them on actual projects once they have thoroughly evaluated all the advantages and risks.

Everyone at madewithlove gets half a day every Friday to spend time on side projects, reading books and articles, and to generally improve themselves in some way. This gives everyone the freedom to gain experience with new technologies in a safe way, and then evaluate if they can be of use in our day-to-day projects.

We also often send engineers to conferences and workshops, so they can both gain knowledge from their peers and share their own knowledge in return with their own presentations.

This way we can offer our clients a stable and reliable product in an efficient way, while at the same time keeping up with the newest trends and solutions and feeding our passion for trying out new cool things.

More guides on coding principles and good practices