What Makes an Effective Engineer?

Strong technical skills alone do not make for a great engineer. Believe it or not, coding is not necessarily the most important thing that an engineer does. It takes great communication skills, people skills, drive, and initiative to make a truly successful engineer.

This is not to say that technical skills are unimportant. Of course you need to understand the technology, and you need a solid foundation in the principles of computer science. But this is merely a prerequisite for success, not the full requirement. Technical skills alone are insufficient for true success.

Great engineers don’t just point out problems and expect others to fix them, or worse, just ignore the problems and hope they go away. Rather, they dive in and investigate the problems themselves, even if it’s in someone else’s code. They’re not hung up on finger pointing or on getting credit; they are just interested in getting things done. You can call it initiative, or call it being conscientious – I prefer the fancy term “a bias for action.”

Also, in any decent sized organization engineers will not be working alone in a vacuum. They need to work as part of a team developing features and products, and the entire team needs to be on the same page. To some extent such coordination is the responsibility of the dev or project manager, but each team member’s ability to work well with their teammates contributes to the overall effort. This is what people talk of as ‘teamwork’.

When I talk about teamwork I’m also referring to sharing information. Does the person speak up and volunteer information when they should, or do they stay quiet and withhold key knowledge? Or do they instead talk too much and soak up everyone else’s time? Are they able to split up a task and coordinate work with another engineer? These are important considerations in judging a person’s teamwork skills.

In addition, engineers will often have to work with other people outside of the team. This may involve other technical teams as well as product managers, senior management, sales, etc. These may be less technical or non-technical people, and the way the engineers interact with them can spell success or failure for the project (not to mention the engineers’ careers).

The best engineers are able to communicate with non-technical people in a productive manner, explaining technical issues in a clear and simple manner that everyone can understand. They are able to distill a problem down to the essential points instead of getting bogged down in technical details. i.e., they can explain clearly what the issues mean to the decision makers so they can take meaningful action instead of ending up confused.

Hence to be truly successful an engineer needs to work as part of a team, not just within their immediate group but also within the entire organization. They need to communicate well and spread understanding beyond just the engineering organization. This kind of interaction and communication skill set is not taught in school, nor is it necessarily innate. It’s something that can be developed over time, but unfortunately one that some people either do not understand or refuse to pick up.

Does Your Company Need Rock Stars?

A lot of companies, if not most of them, think they need to hire rock stars. It’s perfectly legitimate to want to hire the best, but where do you make the cutoff? Many companies insist on hiring only the top 10%, or the top 5%, or even the top 1%. If all companies thought like this then it’s a wonder that most people get hired at all.

“The Mythical Man Month” is a seminal work in Software Project Management, written over 30 years ago. It contains many ideas, some of which are controversial, and some that are dated, but one that I like is that of a “Surgical Team.”

A surgical team is led by an experienced surgeon who is assisted by more junior surgeons, anesthesiologists, nurses, and other supporting personnel. Transposed to software development, this model means that an architect or other senior engineer works on the most critical portions (i.e., architecture & design) while others support the architect by working on supporting tasks (i.e., coding & testing).

This model is attractive because it requires only a few rock stars compared to supporting characters. If you only need 1 out of every 10 engineers to be rock stars, that makes hiring a lot easier. Of course, the proportion of rock stars in the developer population is probably a lot less than 10%, but perhaps for some teams you could substitute a medium level star instead. So instead of a top rock act, you might have a good cover band instead.

Finally, consider the possibility that you may not need rock stars at all. CRUD development is a favorite whipping boy of mine, perhaps unfairly. But the fact remains that there are a lot of projects out there that do not require rock star level talent. And if rock stars were to work on them, they might quickly become bored and disillusioned.

Boredom in this case may result not just because such projects don’t use leading edge technology. It may also be because those projects actually rely more on other skills, such as project management, internal marketing & selling skills, political negotiation, and people management. Those are not necessarily the skills that rock star engineers possess, yet they may be essential to the success in the organization.

Are You a Rock Star?

I sometimes like to say that many people think of themselves as rock stars when they are just roadies. And no, I don’t consider myself a rock star either.

“Rock Stars” are a phenomenon that is not unique to software development; politicians like Barak Obama are often called rock stars, as are some top professors, and even (gasp) rock musicians! If you are at the top of your profession, any profession, “Rock Star” seems to be the requisite title. But that’s not a title you can award yourself, alas. It has to be bestowed upon you by your peers.

Detecting a potential rock star in a job interview is very difficult. Just because someone can answer all the technical questions in an interview does not mean they are a star; it just means they are knowledgeable. And as to whether they can learn their job quickly and perform all the duties of that position to a standard that significantly exceeds expectations, that’s something that only time can reveal.

That doesn’t change the fact that a lot of people consider themselves to be rock stars. And certainly just about everyone considers themselves to be above average, just like the kids in Lake Wobegon. But of course that's statistically impossible, just as no more than say 10% can be stars, and no more than 2% can be superstars. And yes, I just pulled those numbers out of a hat – but I think I’m accurate to within an order of magnitude.

So how can you tell if you are truly a rock star? Here are some signs:

• Are people constantly coming to you for help or advice? (on technical matters, not just to shoot the breeze)
• Is your calendar filled with appointments, half of which you cannot attend? (technical and design discussions, not pointless BS meetings).
• Is your boss always giving you more work than you can handle? (and not just busywork)
• When a crisis occurs, are you the first one they ask to troubleshoot? The go-to person? (and not as the fall guy)

Any of these qualities could be meaningless on their own, but combined they might point to you being the next Mick Jagger -- or Keith Richards. But hopefully not Ron Woods.

If these things don’t happen to you, you can kid yourself all you like but you’re not a rock star. Alas, you might even be a great performer worthy of the title but stuck toiling away in obscurity – rock stars unfortunately don’t thrive in caves. You should learn to sell your achievements to others, or at least get a good promoter.

What Qualifies Someone as ‘Experienced’?

The term ‘experienced’ is a nebulous one. I call to mind former Democratic presidential candidate Hillary Clinton (no hate mail please), who claimed that she had “35 years of experience in government.” Which was strange, since I seem to recall that as of 2008 she had only served eight years in either elected or appointed office.

Likewise, just saying you have 5 years of .NET experience doesn’t make you an experienced .NET engineer. You might have spent all of those 5 years on CRUD apps moving controls around on WinForms. Not that there’s anything wrong with that, but that kind of work does not make for a well rounded .NET engineer.

To me, someone experienced with a technology has had enough depth and variety in assignments to have explored most of the features available in that technology. For instance, if you say you are experienced with.NET, does it mean .NET version 1.0? 1.1? 2.0? 3.0? 3.5? Have you used, or at least understand, collections? generics? multithreading? delegates and asynchronous I/O? garbage collection? If not, you can’t truly call yourself experienced in .NET.

Some may quibble that I’m using a trivia contest to the question of whether someone is experienced in a technology. However, there’s experience and then there’s experience. To me you’re only qualified as experienced if you can confidently discuss the technology in depth and apply it readily to problems. To do this you have to know the ins and outs of the technology, what it’s capable of, and what its limitations and weaknesses are.

Also just as important, if not more so, than the number of years with a technology is what you have done with it. Did you maintain an existing system and fix bugs? Play around with scripts? Or did you actually participate in specing out, building, releasing, and supporting an actual system? There is a huge difference between designing and coding up something from scratch versus just patching holes in it. You will most likely not be considered ‘experienced’ unless you have gone through at least one full development cycle, and preferably several.

What Makes for a Senior Engineer? An Architect?

At larger, more established companies an architect is typically a highly experienced engineer who has distinguished himself/herself during at least 15-20 years of work experience. At other companies, typically smaller, younger ones, the architects may be engineers in their 20s who developed the original systems, however good or bad those systems might be.

So obviously you cannot compare a 45 year old architect with a PhD who has worked at six companies to a 23-year old architect who wrote the first version of their company’s website using Perl and SQLite. The first architect is likely to have a wide breadth of experience in a variety of technologies and design approaches; the second architect will likely have superb in-depth knowledge of how his company’s site operates and the tweaks needed to keep it healthy. Both skillsets are important, but they are not equally transferable.

The same issues apply to the title “Senior Engineer”. An engineer may achieve that title through many years of experience, or because they just happen to be among the most senior members of a very young team. In both cases they are likely relied upon to provide leadership for the more junior engineers, which may be more important than the actual number of years they’ve been working. Still, giving a “Senior Engineer” title to an engineer with 2 years experience is somewhat of a silly game.

The bottom line? Do not place too much weight on titles. An architect or senior engineer at one company may have less experience than a junior engineer at another firm. Just remember that titles are relative, and a fancy-pants architect at one company may flounder at another company. It’s kind of like how someone who skis black diamond runs in the Midwest might get themselves in way over their head trying to do the same in Colorado.

Job Titles

I talked earlier about the term ‘IT’ being used in different contexts. This can be a problem because people often have different notions of what IT is. It can be a general term to describe the technical field, which is how I use it, or it can also refer to internal corporate IT departments. I tend to refer to such departments as ‘IS’ or ‘MIS’ rather than IT.

Similar confusion abounds when it comes to job titles. What exactly is the difference between a computer programmer vs. a software engineer vs. a developer? Or an analyst vs. a systems analyst vs. a programmer analyst?

To a large degree this is a game of semantics. In theory all people who write software should be considered software engineers, in the sense that engineers are people who apply scientific and technical knowledge to real world problems. However, in practice there are real distinctions between the various titles that can lead to differences in pay, prestige, and more than a bit of elitism.

A (business) analyst (or systems analyst) is commonly one who translates business needs into software requirements. This type of position exists mostly at internal IS organizations; software companies in comparison tend to have product managers who fill such roles. At any rate, analysts and product managers both tend to stay out of the purely technical realm, except perhaps for those designated as “programmer analysts”.

As for programmers vs. engineers, that distinction came about in large part due to the different educational programs that many universities provided. Students often had a choice between undertaking a computer science degree offered in a school of engineering versus a CS degree from a math or liberal arts college. If you undertook an engineering track, you were exposed to more hard sciences (think chemistry / physics / calculus); in comparison, the math/liberal arts curriculum was seen as a less hard core approach (think more ‘softer’ classes like English Lit.).

To some degree this is an unfair distinction between two very similar programs, but the distinction has still stuck in many people’s minds. So much so in fact that some people saw a ‘programmer’ title as being inferior to an engineer title. As a result, even people who did not have a true engineering degree started calling themselves “software engineers” just for the added prestige. Some saw that as a cheapening of the title, but others felt entitled to the designation due to the nature of their responsibilities.

As for the term ‘developer’, it gained popularity with the advent of the web when people who put together static HTML pages started being called web developers. Some of these people eventually moved on to write some Cold Fusion or PHP code, but the title of web developer stuck with them. Unfortunately this has led to the term becoming somewhat ghettoized in certain circles, such that a “web developer” is thought to be someone who doesn’t write any ‘real’ code, at least not in the classic O-O sense.

My point of view? Call yourself what you like – developer, engineer, programmer. I don’t care, as long as you produce results. But if pressed, I’ll use the term ‘developer’ to avoid the programmer / engineer title controversy.

Thankless Tech Jobs

I’ve mentioned working in a CRUD position at a cost center as a job you should avoid. But there are plenty of other jobs that are likely much worse than the one you’re in now. So the next time you feel tempted to tell your boss where to shove it, you may want to pause and thank your lucky stars you don’t have one of the tech jobs below.

IT Helpdesk – answering phones all day helping corporate lusers open Outlook or change their password is not my idea of a career.

Customer Support – Neck and neck with Helpdesk in terms of mindless work dealing with clueless people. Often a stepping stone to QA Analyst.

QA Analyst – Repetitively testing the same software day in and day out and pointing out problems is probably not what you had in mind when you spent four years to get your computer science degree.

System / Network Administrator – The only time you hear about them is when something is broken, and then it’s always seen as their fault.

Project Manager – Often a role where you have the responsibility to get things done but not the authority to get people to do the work. You need influencing skills, otherwise known as cajoling, begging, pleading, pestering, conniving, threatening, yelling, and bribing.

Game Developer – Working 80+ hour weeks is expected in this field, and the pay’s not even that great. If you like games, then play them; don’t throw away your youth making the game companies rich.

Junior Recruiter – Despite the negative feelings I may sometimes have for hungry junior recruiters, I fully understand it’s really a high-pressure sales position. Usually it’s sink or swim in the first 90 days. Their choices are to cold-call prospects who hang up on them or else get yelled at by the managing partner who sees them as dead weight.