I often talk to recruiters, hiring managers, people in the field and always hear about “love to code,” code katas, and being a code ninja. While coding is essential, I feel the software development industry has fallen out of balance with other more mature industries. There is a difference between engineering versus coding (development). Provided there are some inherent differences between software that does not exist in other sectors. (Being that software has a nearly fully automatable build and release cycle.)
Other industries do not have this; they need a clear distinction between architects, engineers, and manufacturing professionals. While it is not pure apples to apples, I wanted to portray my thoughts here. Steven
There is value in the separation of engineering from development in the software tech world. (I think it’s the future for large enterprise applications.) Let’s dig into the differences in engineering versus coding.
The difference between engineering versus coding
So what is the difference between a coder (or developer) and an engineer? Are they two different roles? Not necessarily.
Coders
A coder to me is someone who works specifically with the code, libraries, tools, and build systems. They become efficient at the focus and productivity in terms of showing the end product. They’ve already had a way realized to them by a team of professionals. This team will help define the research, set the rules, boundaries, decide the red lines, and “success.”
From there, the coder can identify and negotiate how long it will take them to accomplish the work based on the project plan. A coder will be more pragmatic with defined rules moving forward, and they should fulfill the project’s requirements.
Engineers
An engineer uses the knowledge and applies science to research the best solutions before they get built. Then they make a defined blueprint to be built. A sound engineer will work with a team of professionals to hammer out all the unknowns upfront. Their goal is to create a durable blueprint that will be passed off to others to hit the production line.
Engineering is less pragmatic; it is more of science combined with art. Often right and wrong designs are a bit more of a gray area. However, there are architecture and designs that are common tricks of the trade to utilize. These make patterns easier to be understood and built upon in a scalable and maintainable manner.
Once your blueprint is ready, you get it approved by a head architect overseeing the whole project area. They make sure no rules are being shortcutted, missed, and everyone should be going in the general direction.
Why it’s terrible to lump these into one role
I will use the example of building a house. I have an uncle that prepared the entire blueprint of a house he wanted to create. The blueprint was blessed by a professional architect, acquired all the materials for it, and he set off and built that thing over four-ish years. Then, he did basically what our software developers/coders do in projects today. He owned the whole pipeline from front to back, and it took him a while. He did it, though, and was capable of doing it all with his own two hands.
Now, what if I were to ask my uncle to build a skyscraper? Could he do it? Maybe, but it would not be realistic. So why do we run with this model for large projects across the industry? One could argue the code IS the blueprint. I disagree; code is the implementation and the final product (the house). The blueprint is the defined domain diagram, build systems, system integration, domain diagram, interfaces, documentation, expectations, look and feel, etc.
Overloading engineering know-how to the developer
Often the engineer may not have the specialization for all of the details surrounding a project. They’d need a support team for design, project management, and knowledge of dependency projects. The product of the engineer is a good blueprint for precisely what is being built. (As a bonus, this blueprint is self-documenting.) One would expect to pass this over the wall to another team. They will create it with a set timeline.
In the software developer role today, there is a lot that developers need to know. It is unruly, so it is so hard to find good developers who know all these tricks across this whole pipeline. How many people out there can build their own house? Here is a high-level article overviewing the top 10 things a software engineer should know. Reading through all of them, I agree with them all, but those top 10 things are so broad and general; each could have book series written about them.
Improving how we define our roles
What if we started defining our roles better to form clear and defined expectations of engineers and coders. There could be 1 or 2 engineers to a team of 4-5 coders for efficient team synergy. The goal would be for the engineers to research the best technologies, build systems, their features, and the best ways to design them. They also design how it will be architect-ed or fit into the architecture, document, and create the expected interfaces for it. These two roles only promote synergy and swim lanes on the overall project scope.
Heck, they could even be “test-driven” and stub out all the expected tests that the product must pass. From there, a team of coders will drive the blueprint to a product. Their whole goal is to review the ask and estimate how long it would take their team to build this thing as accurately as possible.
Today, our “combined role” engineering is a lot of art mixed in with programmatic coding. It is nigh impossible to make accurate predictions with so much scope. It is too much to perfect for most.
I am not saying it is impossible. I am sure some people are very knowledgeable about the material and area to make accurate predictions; it is not a realistic expectation.
Splitting the roles to better the skillsets of engineering and coding
We’ve mixed two roles too heavily in the field and expect everyone to be great at building a house from scratch. There is a lot of value in my mind in treating these defined roles differently in large scale projects. For creating a small home (small scoped project), sure; it can be done.
Some people can specialize in those little projects. However, that person may not scale well in large projects where there is a lot more to consider. (Like my uncle who built his house probably would not be the right choice for building a skyscraper.)
I hope my opinion on engineering versus coding resonates! Feel free to share your thoughts here. To read more of my views and opinions on the industry’s state, check out my other posts here.
