From programmer to engineer

From programmer to engineer

I image that all engineers start life as a programmer, and most grow into engineers (and for those that don’t - that’s OK - there are plenty of brilliant programmers who are very happy to carry on they way they are).

So, what is the difference?

For those that mutate into an engineer, what exactly is the difference?

(I realise that a lot of what follows is a personal interpretation, and that, in the real world, these lines are not clearly delineated.)

Programmers think about the code, the functions they write, the database, and the user interface. They’ll be taking into consideration the right algorithm for the job at hand.

Engineers start to think about maintainability, how their code will be deployed (and that deployment process itself). Reliability, scalability and resilience need to be taken into account.

Thinking about the data, preferably sooner rather than later - what data will they have to work with, what quality is that data, what does the data flow look like, and what will that data end up as (and where). Thinking about a problem from the view point of the data generally ends up with a much better engineered solution.

Engineers should be thinking about quality at every point in their process (and thinking about the data first makes this even more valuable). I am not a believer in separating engineering and quality functions within a tech department, educating engineers as to quality, and getting them to own it as part of what they do is a much more sustainable long term solution, and results in better engineers.

What can make the growth start

• Environment - other engineers, processes CI/CD play a large role in providing role models and the space and environment for programmers to start thinking about more than just the programming.
• Engineers having to own their code in production adds to that impetus.
• Getting everyone involved in architectural decisions. Encouraging engineers to be involved in the design of the bigger picture will start to widen their horizons, and the things they think about when approaching a new project or task.
• Taking that a step further - giving engineers the agency to define as much about a solution as possible can only be a good thing. Ownership from the start of a project (or new feature) - defining the problem, designing the solution, implementing it, deploying it and then owning and looking after it in production.

Putting it all together

None of the topics mentioned above are of the sort that can be injected into someone’s head with the push of a button. The job of the engineering leadership (senior engineers, engineering managers and the CTO) is provide the right environment and actively encourage the behaviours that develop these qualities.

Notes and quotes

Scott Hanselman: Systems Thinking as important as ever for new coders

I told this young person to try not to focus on the syntax of C# and the details of the .NET Framework, and rather to think about the problems that it solves and the system around it.