Agile Zone is brought to you in partnership with:

Dave Fecak has served as the President and Founder of the Philadelphia Area Java Users' Group since 2000. He is an active blogger on software engineering career topics at http://jobtipsforgeeks.com, and author of Job Tips For GEEKS: The Job Search ebook (http://jobtipsforgeeksbook.com) Professionally, Dave has been a recruiter and consultant for 15 years helping startup and early growth firms to hire software engineers (primarily focused on Java/JVM, Python, Ruby, functional languages, and mobile). Dave is a DZone MVB and is not an employee of DZone and has posted 72 posts at DZone. You can read more from them at their website. View Full User Profile

The Engineer’s Engineer

06.03.2013
| 12887 views |
  • submit to reddit

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.

  • Lack of zealotry – Even though they want to use the best tools, they understand that their weapon of choice might not be appropriate in all situations.  This group knows there are no silver bullets, and laugh when others get overly religious about the new hotness.  Technology and new products excite them, but they are unlikely to get a tattoo of the latest JavaScript library.

  • 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.

Published at DZone with permission of Dave Fecak, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sat, 2013/06/08 - 5:40am

You nailed it on this one.

Almost all my questions in my last interview were about how I would be constrained.  I could care less about the maturity of their software development process or their technical skills.  I just don't want to be blocked.  Hire good people and let 'em run.

Your resume is more important than your salary history.  Never be afraid to take a job at the same or lower pay when it offers more freedom, or new challenges, or acquiring new skills, or it lets you escape an environment that you know is not healthy or not a good fit for you.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.