All Articles


As a software engineer myself and by being surrounded by engineers on a daily basis, I think we lose sight of the end goal of why we code. We code to solve a problem or scratch an itch, but at the end of the day there is a user at the other end, whether that be somebody a thousand miles away or even you, yourself.

We tend to fall in love with a solution and lose site of the problem. We sometimes create a falsified reality in which our code reflects. We then stand by our code blinded by the original intent. We then go deeper and deeper into that rabbit hole until we realize it is too late. The product on release day flops and forever flops. You pack your things and realize you should have been asking the hard questions up front. Now you realized you’ve wasted three months head down coding a solution you thought you would solve, but instead solve a make-believe problem. You tackled the problem at the wrong angle and as you got deeper and deeper entrenched in the code, it is harder to get out.

What should have been done was to receive feedback regularly and early on. Code is expensive, talking to a person is cheap. Think of why A/B testing is really cropping up, to validate ideas regularly and early on in order to know if the attack angle is correct. If not it is easy to correct in that case as A/B testing are small and incremental changes.

I appreciate great code, but after learning that falling in love with a solution is a downfall, I’ve grown a bigger appreciate for great product.

I’ve also learned that no matter what code base you are in whether that be Google or a small company, there will always be areas of hairy code that requires refactoring. Code is an evolving beast. It is not meant to be written once and shipped. The software is only as good as the people. It is meant to be maintained. As soon as the people leave the software dies. I’ve learned there is no such thing as perfect code. If there is and you are writing software for the modern world, the chances are that area of code is going to require refactoring in order to fit new use cases. I’ve come to accept hairy code. I don’t like it and avoid it at all cost, but I understand that this is a natural part of the software lifecycle as software grows as it should.

Realizing this, I’ve been drawn to the allure of great product from a user’s perspective. I’ve been drawn to the beauty of great product. I’ve grown to put into perspective a users point of view. At the end of the day users don’t give a shit about implementation (more so consumer products not technical products), they care about if you solved their problem. At the end of the day if the user is happy I’m happy. I’ve solved the problem with a solution that is the right solution.

Really this is just a rant of how I feel about when I build product. As a software engineer I think we get lost in the code and have a hard time empathizing with users. I still do it from time to time. It’s hard! It’s hard to get feedback since when problems are solved correctly, users don’t provide explicit positive feedback. When things go bad, they provide explicit bad feedback. It’s hard then to empathize with users as they tend to point out negatives only. You’ll get a few positives, but it’s mainly negatives. It’s hard to get that positive feedback loop in which you directly can connect to your users and really want to solve their problem.

I recommend reaching out to a few users of your and ask them of their opinion of your product. I guarantee that you will be surprised from their feedback. Once you hear how much it helped them, it’s an overwhelming feeling. You feel directly connected and can pinpoint exactly what you’ve created solved that problem. It’s super rewarding. It pays off. You realize then it’s the product that you’ve created creating this feeling. It wasn’t the fact that you’ve used the latest dev tools to get the job done. It wasn’t the fact that you’ve chosen JavaScript over ruby or ruby over Java. And of course some things are more performant than others, but looking at the big picture at the end of it all, the user doesn’t care how you solve the problem. In my opinion, it’s how you set out to solve that problem, tech stack is just one facet of that solution. I’m passionate about that.

Stay humble and never assume your solution is the solution user’s want. Avoid the rabbit hole and get feedback early and regularly.

Fall in love with the problem, not the solution.

I’m @steventsooo on Twitter. I would love to hear what you think!

Published 31 Aug 2015