(Most) Engineering is masturbation
Attention: This blog moved to my new Substack. Follow me there for updated content!
You, me, we’ve all been there. You have an amazing idea. You see the problem and can’t stop thinking about the solution. You know how to code—hell yeah you do. You’re a Senior Software Engineer. You ship high-quality code for a living, and maybe you even have a CS degree.
Your employer gave you a exceeds expectations score on your performance review. They pay you a generous salary plus equity for all the valuable contributions you bring to the company.
You wonder: If I can do that for someone else, imagine the things I can do for myself. You know frameworks and languages, testing and deploying. You are a swiss-army knife of software.
There is no bureaucracy around you to slow you down. No daily stand-ups, no JIRA tickets, no coffee chats, no endless meetings, no redundant code reviews, no micromanagement, no waiting for approvals, and no unnecessary documentation.
You have all the pieces of the puzzle. And if there is one missing, you rest assured that you can learn anything by yourself. That’s pretty much your job, right? Nothing can stop you from shipping your idea. You can already feel the high of real people using your product to solve their problems.
To me ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.
– Steve Jobs
I know how the story ends. The project is never released. Am I a magician? Do I have hidden cameras at your home spying on you? No, I’m just like you.
Have you ever asked yourself why does the story always end the same? The usual escapegoat is lack of motivation. I flagellate myself for long with the idea that I’m just lazy. If only I had the discipline to push through, everything would be different.
I opened my eyes now, and Tyler Durden is going to help me explaining you what I’ve seen.
This is your life, and it’s ending one minute at a time
From the book Fight Club:
Maybe self-improvement isn’t the answer, maybe self-destruction is the answer.
– Tyler Durden
I like the movie’s version better though. Let’s break this quote down:
Self-improvement is masturbation
Urban Dictionary defines mental masturbation as “Intellectual activity that serves no practical purpose”.
It’s the illusion of progress without real advancement, a feel-good distraction that accomplishes nothing meaningful.
It’s the path of least resistance: staying busy with something. But how often do you ask if that something is the most impactful thing you could be doing?
Cal Newport, a computer science professor and author, calls this Busyness as Proxy for Productivity:
In the absence of clear indicators of what it means to be productive and valuable in their jobs, many knowledge workers turn back toward an industrial indicator of productivity: doing lots of stuff in a visible manner.
– Cal Newport
You feel good because you’re working on it, not just slacking around. Sadly, the result is the same as doing nothing.
Now self-destruction…
What prevents us from shipping is what made us Senior Software Engineers. At some point, this becomes our identity. We must deprogram ourselves from this role. In product companies, product managers ensure we build the right thing, so engineers can focus on building the thing right.
In your solo venture, you wear all the hats. But your natural tendency will be to lean on your strongest skills.
For Tyler, pain is necessary for real progress. Letting go of your ego is crucial. If you want to succeed, you must become more than just an engineer.
How do we let go of our ego? We don’t work as engineers, we are engineers. We take pride in our craft — scalability, reliability, extensibility. The buzzword list goes on.
Let go of your ego and build. Start by creating something that, by your high standards, is… 💩
Build something that makes you feel ashamed. More than the bare minimum, and you’re wasting your time. Yes, the bare minimum is buggy, not mobile-friendly, hardcoded, and looks horrible. Code something that would make your coworkers laugh at you. They’re busy laughing while you’re busy shipping. You’ll laugh in the end.
Remember Pieter Levels
Pieter Levels blew my mind with his story of launching 12 startups in 12 months.
He ended up launching 8 startups that year. He first tested 5 project ideas he had, and once NomadList gained traction, he focused on it.
Pieter is a self-taught developer who uses the easiest, least glamorous tools like PHP and jQuery. He doesn’t need to unlearn a craft, which gives him a tremendous advantage over any engineer.
To build your idea, learn to code. Just Google: “How to make a website?” Business and coding is about learning how to figure things out yourself.
– Pieter Levels
My conclusion from listening to Pieter’s story is: Failing ain’t failing. Failing is not shipping.
I got ninety-nine problems but coding ain’t one
Wait a second, is this a free pass to hack, hard-code, and deploy untested code? No, this is a reminder that tech is a means to an end, which is always solving a problem. What counts is what works.
There are a gazillion tasks you could be working on. How do you know what to focus on? What is the most impactful problem you could be solving right now? At the beginning, the problem is always figuring out which problem that is.
The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.
– Eric Ries
Building the right thing instead of building the thing right
The Lean Startup methodology centers on validating ideas quickly and efficiently. The goal is to avoid wasting time and resources on features and products that don’t solve real problems for customers.
Successful startups are those that manage to iterate enough times before running out of resources.
– Eric Ries
Practical Steps to Build the Right Thing
- Define Your Hypotheses: Clearly state what you believe to be true about your product and market.
- Create the MVP: Build the simplest version of your product that can test your hypotheses.
- Collect Feedback: Release the MVP to a small group of users and gather their feedback.
- Analyze Results: Determine if your hypotheses are validated or if you need to pivot.
- Iterate: Use the insights gained to improve your product in small, manageable steps.
Focus on Validated Learning
Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects.
– Eric Ries
It’s about testing your hypotheses with real-world data. Instead of building a polished product from the start, you build just enough to test your ideas. This approach minimizes waste and ensures you’re solving the right problems.
Embracing the Pivot
A pivot is a fundamental change in your product or business model based on the feedback you receive. It’s not a sign of failure but a strategy for finding a viable product-market fit.
You test a hypothesis and realize you are were either right or wrong. Both ways you win. You should pivot as soon as you realize your current path isn’t leading to success.
Expect to pivot many times. That is not quitting or failing. It is adjusting, tuning, and improving.
Pivoting ain’t failing. Failing is not shipping.
Conclusions
What if you already know enough?
The education system prepared me to study hard and pass my exams with an A. The path to strong grades was clear: study harder and longer. There was a deadline for the exam, and whether I liked it or not, I would face the test and verify if I knew my shit or not.
Life doesn’t work like that when you’re building something for yourself. There’s no deadline, so it’s easy to keep adding features and fixing defects until… until what?
Pieter didn’t started a journey to learn how to code. There is no finish line for that. It’s very easy to fall into tutorial hell, a state of perpetual learning, going from one tutorial to another without putting acquired knowledge into practice.
How do I know if I already know enough? Pieter learnt what he needed to solve the problem in front of him. He wanted to add a feature to his project and learn just enough to solve that particular problem and move on to the next one.
Are you a consumer or a producer?
You have this urge to create something, that’s why you started a project in the first place. Maybe you haven’t started it, but you fidget with the idea constantly. You have been playing for the wrong team, the consumer team.
I’m constantly looking for something else to consume before I can finally produce. There is always another book I can read, another tutorial I can watch. I was taught to consume information as the way out of problems. That’s how it works in school and university. Whenever a new problem came up, I could always search for the answer.
But now, my time has come to act. To drop the script I’ve been following my entire life. My time to switch teams and become a producer.
Do you practice what you preach?
Maybe building isn’t the answer, maybe shipping is the answer.
– Pablo Musumeci
I do. Say hello to my first project: MapaMate. I’m a fanatic mate drinker and always struggled with running out of yerba while traveling.
Sure, you can buy yerba online, but waiting for delivery is a luxury you can’t afford on the go. So, I created a Google Sheet where anyone can add and edit store locations that sell yerba.
I felt like a lot of people face this problem, so I shared the MVP on Reddit. I also had a hypothesis on people willing to contribute places they know instead of me having to source them all.
The result? Absolutely no-one cared about my project and that made me feel… good. Why? Because I shipped a horrible website built with the fastest and worst Javascript I was able to produce to validate if anybody was interested.
I quickly validated my hypothesis and realized that investing more time on this would have been an absolute waste. I know now something I didn’t know until I shipped. It’s time to pivot.
Hungry for more?
This post is based on my personal struggles shipping combined with some amazing books I’ve read such as:
Comments