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.
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.
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?