If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.
Albert Einstein
I’ve had the opportunity to mentor quite a few junior software engineers, and by far the #1 piece of advice I give is simple: slow down, spend more time thinking than writing code
I first heard “slow is smooth, smooth is fast” on the baseball field; I wanted to play shortstop, and I look up to players like Javier Baez who make fielding a ground ball look like ballet. If you’re not a baseball fan, think of any movement-based activity — dancing, gymnastics, or even crochet — and picture someone great at that activity. The one thing they all have in common is their movements are incredibly smooth.
In my experience, the same principle applies to technical fields: you’ll build better solutions to complex problems if you spend more time thinking than you do building. Go slow to move fast.
Stop Coding, Start Engineering
Fortunately, I quickly realized I wasn’t destined for baseball greatness. As I started my education and then career in aerospace engineering, I learned the value of deep thinking early on. One of my professors highlighted this in a lecture, and it has stuck with me ever since: the best people in technical fields typically develop the best problem-solving skills coupled with field-specific knowledge and the ability to work in a team. Solving complex technical problems in elegant, reliable ways requires deep thinking. And the more brains you have working on a problem, the better solutions you’ll develop.
In the software world, I think of this as coding vs. engineering.
Coders are folks capable of writing code. You can give them a task, that inevitable TODO list app, and they’ll get it built. Think back to your first Hello World program: you were a coder.
Engineers are problem solvers. They can take an ill-structured problem (one without one clear “correct” solution) and develop an elegant solution through a combination of personal problem-solving ability and teamwork.
Spend More Time Thinking Than Coding
One simple key to developing engineering skills is to spend more time thinking than you do coding. Slow down! When given something to work on, even if you’re told exactly what and how to build a particular feature, take the time to step back and think. Brainstorm as many ways as possible to solve the problem. Ideally, loop in a teammate and get their ideas.
Unfortunately, even though Agile and Scrum principles dictate that the team themselves are best capable of determining how to get work done, many organizations still practice a top-down, dictatorial style of engineering.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Agile Principle #5
For most organizations, this is shortsighted. Do you want to create a team of people capable of taking direct orders from that one brilliant engineering lead (who is going to retire or move on at some point), or do you want to create a systemic approach and team capable of working together to solve complex problems for your customers?
Draw, Diagram
Humans learn incredibly well in a spatial context, so take time to draw things out. I recommend using a tool like Miro to diagram complex problems (it’s also great for things like customer journey mapping, basic wireframing, etc.).
System architecture is one of the best use cases for diagramming, but even if you’re building a new front-end feature that has some complexity, give it a try.
[ Side note: ByteByteGo is a great way to learn the basics of a wide variety of software system architecture ]
Imagine trying to explain, in writing, what the diagram above depicts. It’s possible, and often even a requirement, to do so, but a picture is worth a thousand words as they say. Our brains process visual representations differently than textual representations. A diagram gives you a 10,000-foot view of your problem at a glance.
The Real World Has Deadlines
We all have deadlines, and we’re not trying to discover the laws of nature like Einstein was. We’re building software and competing in a marketplace. If you’re at an established company building highly technical B2B software, you’ll probably be given more leeway to spend time thinking than you would at a B2C sales-driven startup.
Regardless, use the time available to you to do more thinking upfront. I think you’ll not only discover that you write better software but also do so faster than you’ve done in the past.
Top comments (0)