DEV Community

Cover image for Evolution from Programmer to Software Engineer
Imran Khan
Imran Khan

Posted on • Updated on • Originally published at imrank.vercel.app

Evolution from Programmer to Software Engineer

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

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

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

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.

See you soon

Top comments (6)

Collapse
 
b1n4ry9h0s7 profile image
Nishanth Bhat

This was a very interesting post, Reminded me of my past self and how far I have come from being a programmer to a Software Engineer. The way I think about solving a problem has drastically changed between now and 5 years ago!, Enjoyed reading it!

Collapse
 
bernardbaker profile image
Bernard Baker

This is a good guide for anyone wanted to take on the responsibilities of a software engineer. I hope you go on to write many more. And never forget that's ideas and creativity make great programmer's and software engineers.

Collapse
 
brense profile image
Rense Bakker

Tbh there are hundreds of titles to describe the same thing in software land, all with varying degrees of overlap. Whether you think in code or properly analyse the business requirements and domain before you start building, is something that comes with seniority, more than job title imho. But I agree with your analysis that a good developer (just to throw in another term 😉), should be skilled in analysing the problem, as well as writing code.

Collapse
 
parzival_computer profile image
Parzival

Interesting, the difference isn't evident.

Collapse
 
glebsvechnikov profile image
Gleb Svechnikov

If you think in solutions, but not in code, are not you a solution engineer?

Collapse
 
robinamirbahar profile image
Robina

Good Job