Software engineering unfortunately has an all-encompassing stereotype/stigma everyone tends to get placed in. Now my best, and most empathetic, approach to describing this stereotype would just be an engineer that gets things done. This description can range from less than stellar code to get a project/MVP out the door, to ignoring common functionality insurance that is test coverage. While stereotypes do come from a true place, there is often more nuance. Software engineers are no different.
Not all places where software engineers exist are the same. The pace, adherence to quality, and fundamental importance in particular areas are not the same. Keeping this in mind is important because it can be a good indicator of the success a potential team addition will do in your org. So now that we have a baseline understanding of the importance, let’s look at the different types!
The Code Churner
Starting off, let’s get right into the stereotype we started with. The code churner is a type of engineer that you would bring on when you want to get things done. It may not be 100% on par with best practices, have optimal test coverage, or be the most reusable, but it gets done. In short, this type of engineer builds with the philosophy that the end always justifies the means.
While there are products and organizations where this would be detrimental, you’d be surprised at how many have this as the preferred approach. To be blunt, the majority of the industry leans this way. Startups, marketing agencies, development studios, and Fortune 500 companies alike all can easily be identified as needing this type of engineer based on where they are in their trajectory.
The Mindful Coder
Similar to the code churner, this type of engineer is very much capable of getting things done in a timely manner. However, a mindful coder is someone that has enough experience to learn from their mistakes or those of their team. This type of engineer sees the drastic problems building things only in a 1:1 approach causes, and will proactively avoid them to the best of their abilities.
This type of engineer is great to have at early-stage startups beginning to transition into solid-sized organizations and enterprise-level organizations with lots of tech debt and legacy spaghetti code. They’re great for these areas because their mindset is close enough to the code churner as to where they can read that type of code well, while also being able to identify the simple layers of reusability and infrastructure possible.
The Architect
For engineers that lean more this way, things are more procedural and by the book. Best practices are not only encouraged, but strictly adhered to. This is so because in this group you’ve probably seen multiple horror stories and/or had to deal with the consequences of poorly made decisions in the early stages of codebases.
Engineers of this group have to be mindful of the organizations and teams they join. Not every company is in a place where this degree of cleanliness is required or even understood. So it’s best to focus on working in organizations focusing on scalability, building for the future instead of the moment, and understand that those in this group take longer to understand less than stellar code because it’s not the way you’re accustomed to writing.
In Closing
Knowing the type of engineer you are, and the best fit for a potential team is critical for everyone’s success. There is no one size fits all type of idealogy that works here. Engineers need to have synergy with the mentality of others on their team, and the appropriate attitude and culture around the methodology around the building process to succeed. Understand this, and then hit the ground running to be the best of your abilities.