Aren't those two synonyms. No, they're not. A Software Engineer is the superset of a Programmer. Let's dive deep into how exactly they differ.
What's the difference
Well, a programmer is generally someone who's good at creating stuff through the means of code. When they get a specification to create something, they start writing code with a certain use case in mind. This is not much of a problem when you are working in smaller teams or building projects of your own. However, the moment you start working on projects where a good number of teammates are involved, you'll quickly find yourself under a big pile of code because to change one thing, 5 other things need to be modified.
A software engineer on the other hand, will question themself at each step of the process, ensuring that anything they change will be understood unambiguously by the next person who happens to encounter this change.
There are no steps set in stone that one could follow to transition from a programmer to software engineer, but one can inculcate the following qualities/habits that are often found in good software engineers.
Think solutions, not code
The most recurring mistake programmers do is immediately think in terms of code when presented with a problem. This approach does not scale well because there are a lot of black boxes at the early stages of any project. These black boxes might introduce features that could render your approach unusable.
Hence, it is crucial to think in terms of entities, their responsibilities and the flow of information between these entities.
Start small
To think solutions, start by approaching the most basic version of your problem. This will enable you to eliminate majority of the known and unknown variables alike from your solution.
Tackling your problem in isolation allows you to focus on the core components of the problem. Create a solution for this version then incrementally keep on increasing the set of requirements and rinse & repeat.
Docs come before code
The importance of documenting a solution before attempting it is arguably the most important step in developing a project. Practices like dry running approaches and writing pseudocode are worth the overhead that they bring to the table.
As any programming language has its own set of rules and limitations, changing documentation is so much easier than changing code.
So next time, before you jump straight to coding a solution, try writing the approach first and you might find issues early on that might have stayed hidden for weeks.
Note: This is an extension of the Rubber Duck Debugging technique.
Set goals
No, I'm not talking about setting up long term goals like a motivational speaker. Setting up goals in the short term means to just write your intent.
People don't realize that just writing down the next 3 steps that you want to take resolves so much of the indecisiveness and introduces a ton of clarity to an approach.
It does not matter if the approach you tried out failed. You just checkout off one method that you thought would've worked from the "approaches" list. Be willing to start with a clean slate and better understanding in case things go sideways.
Be your first reviewer
Always be critical of your solutions. Just because you wrote it, does not mean you should assume it would work in a certain way.
Think of cases where it could fail and be open to corrections from others. It is better if you spot your mistakes before anyone else. After all, who doesn't want to ship bugless products.
Choose your trade-offs
All decisions in software engineering and by extension in life come with benefits and trade-offs. You have to choose which trade-offs are you okay living with.
So, if you choose a particular technology to work with, be prepared to work around its limitations. If you choose an approach to solve a problem, get ready to meet some unexpected guests down the implementation road.
Well, that's all I have for you today. Implement these habits in your problem solving process and I'll see you later.
