I'm a software engineer who spends work hours thinking about products, users, and how to make things that matter. After hours, I live my life. I stay up to date with the world around me. I work with my hands—wood, leather, garden soil. This is where those worlds meet. Sometimes a hobby teaches me something about my day job. Sometimes my product instincts change how I approach a craft. The lines cross more often than you'd expect. And this series of posts will be about that bi-directional influence.
One of my favourite comedians is Kat Williams. And one of my fourth jokes he told tells a story about his son wanting a new Xbox. Instead, Kat convinced him to buy a used Nintendo console with two controllers and like 20 used games. His reasoning stuck with me for quite some time because it fits exactly how I think about product decisions in my engineering role.
He said multiple things in a matter of 2 minutes that changed how I see my work. Let me break down a few of them.
Daddy Can Do This All Day Every Day, No Problem
Kat said this about buying an Xbox for 199.99$. He had the money. He could do it. But he advised his son not to.
This sounded very close for engineers. We get asked to build things all the time. Use new frameworks. Add big fancy features. Complex architectures. My answer is often yes I can if that's the only choice. I can do it every day, all day. But that is not the question.
The real question is whether we should. A Product Manager mindset asks what outcome we are trying to reach. Is this the fastest path? Does this solve the actual problem? Or am I just showing off technical skills while wasting time?
I have said no to tasks I could easily complete. I once (or twice?) harmed my own bi-yearly performance review because I sounded "against the change" when it came to adding a new unnecessary fancy dependency to our stack. Not because I could not do them. Because I had a better idea for that time and effort. The best use of engineering power is not saying yes to everything. It is choosing the right thing to say yes to.
It Only Comes With 2 Demo Games and One Controller
Kat said the Xbox was a trap. Buy the base unit, then pay for every game. It comes with one controller. Daddy can't play with you. Your friends can't play with you. Buy another controller.
This happens in software too. A tool sounds free until you add the plugins. An API seems cheap until usage spikes. A microservice architecture starts simple but needs monitoring, logging, deployment pipelines, and five more services just to talk to each other.
These are hidden costs. Nobody shows them on day one. By the time you see them, you are already locked in. Migration takes months. Rewriting takes longer. Now you cannot go back.
A P.M. decision asks what comes in the box before you sign the contract. What are the real limits? What do I pay later that I ignore now?
20 Games That Other Kids Have Already Opened and Played With To Make Sure It Is Fun
Kat explained why the Nintendo was better. It came with like 20 games other kids had already tested. You knew they worked. You knew they were enjoyable.
Software has the same lesson. Some love shiny new tools. The latest library. The newest cloud service. The framework everyone is talking about. But who has really tested them yet in production? Nobody knows if they hold up under our pressure and our specific uses.
A P.M. decision looks for the games that already came with the system. Use patterns that work. Copy what others have learned. Solve the problem with code that has been proven before.
This does not mean staying old forever. It means being smart about when to risk. I would rather ship a boring feature that works than build something cool that crashes.
We Got Like 300 Dollars Leftover
If Kat's son chose the Nintendo over the Xbox, the saved money stayed in Kat's pocket. They could go across the country and have all the ice cream and nuggets they want! The point was not about saving cash. It was about having resources for other things.
In engineering we call this technical debt or opportunity cost. Every hour spent building unnecessary complexity is an hour taken from solving real user problems. Every server running unused features is budget gone from hiring someone new. Every bug in unfinished code slows down the next sprint.
Making a P.M. decision means looking at what you save when you choose simple over flashy. That saved time becomes freedom. Freedom to try real experiments. Freedom to pay down tech debt. Freedom to have fun building the next thing that actually matters.
Sometimes the smartest engineering move is doing less work.
The Bottom Line
Kat Williams taught his kid something bigger than video games. He taught him to look past the hype and the peer pressure. To value proof over promise. To keep resources for what matters.
Same applies to my work as an engineer. I can say yes to every request. I can build every feature. But a product mindset changes the question from can I to should I.
Make a P.M. decision. Choose the used game. Save the money. Keep the resources. Build what proves valuable over time.
No comments:
Post a Comment