As an engineer, I was always trying to build stuff based on cool patterns from books with animals on the cover, but most of the time it didn’t work out that well. We either moved slowly, or the code was so “cool” that it took quite some time to onboard new engineers.
It took me a while to understand that there’s no universal cookbook for such solutions, and sometimes they don’t even have to be fancy. Usually, the simpler it is, the better, but those might bite you in the ass at some point. If you have ever worked in a startup and you know the pace they usually operate, then it might ring a bell already.
The pressure is on
If you’re working on a simple one-time thing, then it’s fine; you don’t have to write perfect code for that. But what if it’s a new feature which is demanded by the client and now business nudges you to implement it asap? As an engineer, you’ll naturally try to come up with a nice solution and discuss it with your team. But then you also have tight deadlines on your tail, so what are you gonna do?
Best of both worlds
If you come up with a solution which is poorly implemented and not integrated into existing code well, then you’ll slow your future self and your team down. But if you work on a good solution, then you also risk losing the client. In most cases, you simply go with a simple solution which is in the middle-ground, it’s not bad but not perfect either.
My friend came up with a name for such implementations: “poor man’s solution” It resonated with me, inspiring this series, and now I decided to write a couple of articles on the problems we had to solve and the price we paid as time passed by. Let’s embrace the imperfection!
Stay tuned and see you in the next one!