The Engineer’s Engineer
Lately I’ve seen quite a few requests for advice from younger programmers, asking questions either directly to me or in public forums about a career decision they are being faced with that is causing some level of stress. Reddit’s r/cscareerquestions is a hotbed for this type of activity, and you might see the occasional similar post on Hacker News. After 15 years in business, I’m quite comfortabel providing insight on the potential benefits and drawbacks of say, taking a job doing mostly Python versus a position exclusively using a rarely seen proprietary language and platform, or accepting a pure technical management position versus staying more hands-on.
Generally, I want to tell all these people the same thing. If you really enjoy the work and want to be successful in the business for a long time, you should try to make decisions, think like, and become an engineer’s engineer.
I know quite a few people I’d describe as an engineer’s engineer, and most of them have some gray hairs or are young but sound like a throwback to times past. Fortunately, some less experienced developers are benefitting from being able to work alongside someone in this category, who are more often that not open to mentoring and showing the way. As a recruiter I look at and treat these engineers like gold, as they are the types that any of my clients would want to hire – plus they tend to teach me new stuff in every conversation.
Who is the engineer’s engineer?
- Utility player – In baseball, it wasn’t uncommon in the early years for players to play several positions. Specialization has happened in baseball to the point where there are now pitchers who only pitch in the 9th inning. Similarly, software development shops are now often filled with segmented roles for build engineers, dev ops, QA, architects, performance engineers, database developers, etc. The engineer’s engineer is a utility player that can jump in almost anywhere, and doesn’t see the demarcation as a boundary that cannot be crossed. Little is considered beyond the scope, and they will not want to silo themselves into a singular function.
- Initiative – If they see something that is broken, they fix it. Will automating a task make our lives easier? If so, let’s do it, and only ask permission when absolutely necessary. This requires some level of autonomy.
- Technical integrity – By this I mean that an engineer’s engineer will have some opinions about decisions being made (if this person isn’t calling the shots) and will make that opinion known when there is disagreement. Instead of just saying an idea is bad, an alternate solution will be given. This is the desire to do things correctly over taking short cuts, which is likely to conflict with the business at times.
- Can’t be bought with money or title – This group will never take a job purely based on salary or rate, and are driven by the ability to solve interesting problems and work with a strong team. Job title means absolutely nothing. In my experience, most engineers factor money heavily in job decisions and sacrifice a better career move or additional job satisfaction for what amounts to a difference of $2.00 an hour. If you’ve chosen a job based on a 5K salary difference, this is you.
- Sharing - The engineer’s engineer wants to share, whether it be information on how and why they arrived at a particular solution, their favorite tools, or anecdotes about past projects. This is based on a combination of pride in their work and interest in teaching others. Open source is often a part of this equation, where there is a desire to share your solution for the outside world to see and use.
- No limitations - The engineer’s engineer doesn’t want to have the toolset options defined and thrives in an environment where they have autonomy over what will be on their machine. Having a company mandated IDE or OS will be a turn-off, as will any roadmap listing few acceptable tech options. Heavy bureaucracy, regulation, or barriers to being able to solve problems are an issue. The shop ideally will be engineering-friendly.
- No personality conflict, less ego – Of course, many strong programmers (and some weak ones) have quite a bit of ego about what they do. The engineer’s engineer does not come across as overly self-important, and can be more humble than those much less-skilled. This group isn’t alway the most friendly or popular person on the team, but is never the most hated.
- Movement – This group wants things to be progressively moving forward with few delays. Low latency in their process and little downtime at work.
- Has the back of team members – Solidarity among other engineers is their goal, and they tend to stay above or away from the drama of interoffice politics. They are there to solve technical problems, and have no interest in gossip or attacks on others.
- Know that they are not their code – These people can separate a technical criticism from a personal attack.
- Doesn’t need to be a leader – They are often more happy when they are not in charge, and are not instinctively driven to tell others what to do.
Note: In thinking about and doing some mid-article research for this piece, I came across Paul Graham’s 2004 piece Great Hackers which identifies some of the same traits listed here as being shared with hackers. The hackers he describes should share the workplace desires and drive as the engineer’s engineer, but may not always have the same personality or behavioral traits.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)