First Principles — Issue #49
Every smart person I know loves solving hard problems.
They play with Rubik's cubes.
They perk up when something goes wrong.
They are eager to understand complex ideas.
In general – They are attracted to complexity.
Many people get uncomfortable burning their brain power to think hard.
Smart people get more discomfort from the idea of never understanding
So they persist.
It's a compounding effect that sets people apart as time goes on.
With the trade-off of a more anxious life – smart people are constantly hungry to understand.
But there is danger in knowledge.
Unregulated knowledge breeds wasted energy.
Sometimes things can be simple. However, people who accumulate tons of knowledge are dying to use it. This causes them to make complex problems out of something simple. They are trying to make the situation into what they wish it was.
A complicated problem.
When they needed to build a fly swatter, they were dying to use their knowledge of how to build a bazooka. The result? More harm than good.
For the deep thinkers and over-achievers in my audience:
This newsletter is about avoiding that trap.
Every time I learn a new technology I get excited: "That's so cool! I wonder how I can use that?"
This has served me a ton in life, but it has also bit me in the ass.
Instead of thinking about the problem at hand and working my way up to a solution.
I think of what I know and work my way down to a solution.
99 times out of 100 this results in tons of bloat.
You get excited about using one aspect of technology and don't consider the overhead. You can end up turning a 4-hour task into a 3-day task.
This helps you learn a ton at the beginning of your career, but one day it will no longer serve you. Early on the extra effort of implementing difficult tech was worth the growth. Eventually, after you know enough, the goal isn't growth. The goal is to build great solutions.
You are armed with tons of knowledge and need to accept that 9 times out of 10 the simplest tech is the best answer.
The only advantage of expanding the width of your knowledge is that in rare situations where you have an unusual problem: There will be more tools at your disposal.
Catch yourself next time you are working down from tech. Work up from the problem.
What is the "Simplest Viable Solution"
The goal is a solution where you can not remove or reduce a single part without it being dysfunctional. If you can remove or reduce any part of the solution and still have a functioning system – do it. Keep the ultimate goal in mind, but don't build more than you need.
Reduce until the solution you have is as simple as possible but no simpler.
As you work on more projects, you learn a lot.
You'll remember what worked well before and what you think might be important for new projects. But it's good to think about whether you really need to worry about these things for your current project.
For example, maybe once you had to make a database that let lots of different admins log in because having just one login in the .env file wasn't enough. But if you're just starting with a basic version of your project, do you need to make that big login system right now?
t might be better to focus on the main parts of your project first and think about adding more complex things later when they're really needed.
Another important thing to remember is that your past experiences can create biases or a kind of mindset that makes you think about problems in a certain way.
These biases are like a shield; they protect you from problems you've faced before. But sometimes, these shields can be too big or the wrong kind for a new problem. Just because something was a problem in the past doesn't mean it will be a problem in your new project.
Humans do this all the time:
- A girl doesn't trust a new boyfriend because the last one isn't trustworthy.
- A kid doesn't eat anything green because the green stuff they have eaten so far is gross.
- An engineer doesn't ever use a technology because it bit them in the ass when they used it for the wrong solution.
Knowing about these biases can help you make simpler and better solutions. You don't always need to use big, complicated fixes if they don't fit the new problem you're working on. Sometimes, the simplest solution is the best one.
Engineers try to think ahead and plan for everything.
They dream about creating a solution, putting their code out there, and having it work perfectly and handle lots of users forever. But this isn't reasonable.
Rather than trying to make the whole system right now, think about what is absolutely necessary.
You can grow, improve, or add to it later.
Don't start by building out the ideal system. Start by creating the best foundation for that system. Build something solid that you can make even better over time.
Consider that your "ideal" solution is probably not even close to what the actual solution will be.
Give yourself the flexibility to adapt and improve as your project grows.
The best systems start as simple as possible and become great through iterative improvements.
Don't start with "How can I build the best system".
Start with "How can I build a great foundation for the best system?"
______________________________________
Thank you for reading this week's newsletter.
I appreciate all of you who read to the end.
How I can help you:
Book A Coaching Call ☎️
Free Course 📚
Email Me 💌
Until next week 👋
Newsletter for Software Engineers. Teaching how to solve career and life problems with first principles thinking. One email. Once a week.
First Principles — Issue #52 How To Be The Person People Hate There is an advantage to being liked. People want to be around you more, they think of you first when opportunities come up, and you gain leverage by making people feel good. I know that sounds sociopathic to say it that way, but it's true. Goodness, good energy, and being a team player is just as beneficial to you as it is to the entire team. It's a mutualistic relationship. On the other hand... Being an asshole causes the...
Keep It Simple — Issue #52 3 No-Code Tools That Don't Suck When I started programming in I remember my teacher said:"Coding will be mostly drag and drop in 10 years" I think his claim was fair, but it didn't go as deep as any of us thought it would. The"drag and drop" code platforms are useful for a handful of things, but the full no-code movement never really caught on. For the most part – people still code. However, I have come across some tools that change the way I approach solving...
Keep It Simple — Issue #41 The Truth About Motivation Coding is Hard. Anything worth it is hard. You might love the idea of doing hard things, but you should ask yourself why you want to do it. Do you find it fun?Do you want the money?Do you want your parents' approval? It might all seem the same, but motivations make all the difference in how your accomplishments feel. For most of my life, I chased opportunities for the wrong reasons. The common reasons people would expect you to pursue...