Problem Solving Approach
Problem Solving Approach
Problem Solving Approach
There is, however, a huge gap between the kind of step-by-step “happy path”
tutorials aimed at complete beginners and the complex engineering problems
you’ll be expected to solve as a professional. To become a professional software
engineer, you have to recognize that gap. You also have to develop the attitudes
and behaviors required to bridge it.
Hacking together pieces of code and just trying things to see if they work is a
behavior often seen in hobbyist programmers or beginners in the “explore
phase” of learning. To become a professional software engineer, you need to
graduate from the “hack and slash” mentality.
Code with intention, and take a deliberate and considered approach your work.
The following actions and behaviors will help you do that:
• Planning out your solution to a problem
• Considering the trade-offs of different solutions
• Accurately implementing your chosen solution
• Understanding the purpose of each line of code
Being a good software engineer isn’t about memorizing a bunch of syntax and
functions and then magically typing out a bunch of code that just works. It’s
about solving problems. Programming languages, frameworks, and libraries
are just tools you use to help solve the problem.
Problem solving is hard. To help you out you need a well-practiced, consistent
approach.
Work on developing a solid approach to solving problems. You’ll then be able to
tackle any problem by breaking it down and solving it logically and
systematically.
When learning a new language, tool, or framework, don’t spend lots of time
trying to memorize every single method or function, or an entire API. Instead
familiarize yourself with the documentation for that language or tool.
Learn to read and use technical documentation. Combine this ability with strong
mental models about fundamental programing concepts, and you’ll be able to
quickly pick up new tools and languages.
The combination of the two things is key. For example, if you have a solid
understanding of how a combustion engine works and know how to read
engine schematics, you can use those two things together to quickly start
working with any engine.
If instead you’ve memorized every single piece of one particular type of engine,
but without those other skills, then you’re limited to only working with that
type of engine.
The best developers and engineers don’t necessarily know the answers to
everything, what they do know is the underlying context for those answers and
how to find the specific details when they need them. Don’t aim to become a
‘React developer’ or a ‘Rails developer’, aim to become a software engineer who
can quickly adapt to work with any language, tool, or framework.
Don’t get overly attached to, or egotistical about, your code. Be prepared to
rethink, refactor, or even replace it entirely.
A big part of this is being able to accept feedback and criticism. The purpose
of that feedback is to help you improve your code; don’t take it personally.
Remember that you are not your code, and a criticism of or feedback about
your code isn’t a value judgment about you as a person.
Also remember that as a professional your code won’t be your code. The code
you’ll be working on won’t be for some personal pet project, but a collective
undertaking with a specific, shared objective. Thinking of parts of a codebase
in terms of individual ownership is problematic in a professional environment.
Summing it Up
In this article we’ve examined the difference between how hobbyist
programmers and professional software engineers approach working with
code. If you really want to launch a long-lasting career as a professional
software engineer then you need to adopt these professional attitudes and
behaviors. Let’s recap on what they are:
• Code with intention, taking a deliberate and considered approach your
work
• Develop a systematic and logical approach to solving problems
• Don’t treat debugging as a chore. Accept it as a normal part of software
development and use the opportunities it presents
• Learn how to read technical documentation, and combine this with strong
mental models to quickly pick up new languages and frameworks
• Don’t get attached to your code. Treat it as a practical solution to a
problem, not an artistic creation