Types of Engineers

http://omar.io/2017/01/10/the-types-of-engineers.html

by winterweather • 10 years ago

116 78 10 years ago

This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .

jcizzle• 10 years ago

You'll have to forgive the author for not going into every variable in human beings. Perhaps the purpose of the post was to give people a scaffolding to start developing their own thoughts on the matter? Maybe you have a post you'd like to share that takes others to the next level of understanding that you have?

badloginagain2• 10 years ago

Seems a pretty naïve description of Engineering types. Not only is there no data to back this up, but it makes it seem like hard divisions: I can anecdotally tell you about junior engineers who over-engineer in the wrong areas, or experienced engineers who `under-engineer` due to time|pressure|issue-critical requirements.

Nonsense.

okhudeira6• 10 years ago

Author here. Your point is valid. I do try to make this clear in this portion:

However, an over-engineer can sometimes perform like an under-engineer or an engineer. Underperformance and overperformance could be influenced by a number of factors including work environment, context, intellectual horsepower, and even personal life.

I personally continue to write under-engineered and over-engineered code because there are so many internal and external factors that go into solving a problem.

collyw• 10 years ago

Almost everything in tech is a trade off. Usually between Fast, good & cheap.

In saying that there certainly was some accuracy in my career between under engineering early on, then over engineering later. Nowadays I usually get a good balance (though it often depends how the problem is communicated).

js8• 10 years ago

Actually, engineering is all about trade offs. Good engineering is to understand the trade you are making, and be consistent with it, and playing to its strengths.

For example, Linus Torvalds is an excellent engineer. So in the Linux kernel, he understood the trade off between modularity and simplicity/performance. That's why he did not choose microkernel architecture. He also understood that device drivers often require weird changes due to hardware evolution, that's why he decided against having too many abstraction layers in drivers (which would be better according to DRY rule).

Similarly, in Git, he decided not to use delta format to store changes. This takes more disk space (which is cheap today), but gives improved performance. Again, he understood the trade off, and concluded that performance is more valuable than disk space saved.

thealfreds• 10 years ago

Eh, it's pretty much the same stuff over and over again that gets posted here when people try to categorize engineers into types.

Maybe saying the same thing over and over again has merit to nail in the idea but eventually it becomes stale.

throwaway2016a2• 10 years ago

Sorry ahead of time for going slightly meta and off topic. I am a software engineer myself but...

I find the fact that this blog refers to software engineering practices as if they apply to all engineering disciplines to be a little jarring and best and misleading at worst.

I wouldn't expect a mechanical engineering blog to have an article "Types of Engineers" that only discusses mechanical engineering.

I refuse to not call software an engineering discipline (I believe it is or at least strives to be) but even so I make sure to quantify my statements by putting the word "software" in-front of "engineer."

okhudeira6• 10 years ago

Author here.

I won't get into whether or not it's fair to call call "developers" "engineers", but I do make the distinction in the first paragraph that the article refers to software engineers. In addition, velocity, bug count, and lines of code are all software terms. I can't imagine anyone thinking this is referring to any other type of engineering.

deliriousferret• 10 years ago

Velocity? How is that a software term?

akvadrako5• 10 years ago

Then the title should be changed.

JorgeGT• 10 years ago

Note that other types of engineers write code: CAD, CFD, FEM, etc. We don't develop software products, but we write code to pursue our goals.

ritchiea3• 10 years ago

So if he had simply titled the piece "Types of Software Engineers" you would be happy?

paulddraper2• 10 years ago

That is exactly what is being said.

throwaway2016a2• 10 years ago

Yes

nialo• 10 years ago

I was a mechanical engineer for five years, now in software:

The way programmers tend to default "engineer" to meaning "software engineer" bothers me sometimes too. On the other hand, I wouldn't be surprised by a mechanical engineering blog doing the same thing. We all focus on our little corners of the world, and if software has it worse than mechanical it's just because mechanical engineers are forced to work with other disciplines more often. I'm pretty sure I've seen over- and under- engineers in mechanical work too, it's the same all over.

For whatever it's worth re: "engineering discipline", my feeling is that the parts of software engineering that really need to take their work very seriously mostly do. For example, the occasional articles on the NASA software that went into the space shuttle. On the flip side, if the mechanical engineers I worked with could build/test/release new designs the way software engineers can we would have been as sloppy and more. The reason physical things are more carefully designed is just that the edit/compile/test cycle is so much longer and more expensive, not that one is a "serious engineering discipline" and the other isn't.

eeZah7Ux3• 10 years ago

Indeed people can be "serious" or sloppy with everything.

Yet, software engineering doesn't require a degree and no minimum bar on both depth and breadth of knowledge required.

The jobspecs for "senior web engineer" with 3 years of Stack Overflow copypasting experience are an example.

asdfjaflswjafs2• 10 years ago

I feel the exact same way. I am electrical engineer by training. When I first moved to San Francisco, I would answer "yes" every time someone would ask "are you an engineer" but I quickly learned that when people said "engineer" 99% of the time they meant software engineers. I quickly became used to saying "no i'm not an engineer, at least not a software engineer."

To me, it's a fairly myopic culture. One of my friends, who has a Ph.D. in civil engineering and is a professor at Stanford has to do the same thing "oh no I'm not an engineer in the way you meant". It's insulting to all the other types of engineers out there (civil, mechanical, electrical, aeronautical, bme) who are somehow excluded from the definition engineer when you enter the Valley or software circles. No other engineering subtype abuses the language this way. It's even more mind boggling because no software engineer has a PE, which in some countries (not the US) is the only way you can call yourself an engineer.

As a whole, I think abusing the language is insulting to the diversity of engineers out there. While software engineering is probably the highest growth branch, that doesn't mean the other branches are just as relevant. In university, we never used the word engineering to mean just "electrical engineering", we actually used it when we were talking about the whole universe of engineers.

The funny thing is now that I've transitioned to software engineer, it feels good to be finally be able to say "Yes I'm an engineer."

okhudeira6• 10 years ago

Author here.

I had no idea that this is a sensitive topic. I personally have family members that are civil engineers and understand the difficulty with acquiring a PE. I went ahead and modified the title.

bavcyc2• 10 years ago

Texas and Florida have software engineer P.E. according to: https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...

I think there are a couple of states where you are not allowed (by law) to use engineer unless you are a P.E. but there are industrial exemptions, which muddy the waters. As compared to "Professional Engineer", which is don't use it if you don't have a license in the U.S. state where you are offering engineering services.

sidlls• 10 years ago

On the other hand I'd hesitate to call it a mature engineering discipline. It suffers from fad-following and shiny-bauble-chasing like no other engineering field I've ever worked with. It's a bit better outside the valley, but generally there is an amusing over-focus on academic trivia and minutiae from CS.

BigChiefSmokem• 10 years ago

From what I can tell almost everyone is an "over engineer". I fight this mindset in myself everyday. How many times have I seen interfaces and dependency injection and kinds of patterns used (besides MVC) on crappy little web sites that get re-written every 3 years anyway.

No we don't need an interface for something that is not a plug-in or will never be released as a stand-alone library! Coding for a future that will never happen is a fools game and none of the real bosses will care unless the UI or something more tangible (performance?) changes drastically.

andruby• 10 years ago

Finding the balance is one of the most difficult things in software. On the one hand there's YAGNI (You ain't gonna need it) which you described, and on the other end are "hacky" prototypes that take the most direct approach but often ignore edge cases and are hard to build upon.

bryanrasmussen2• 10 years ago

It does seem like there is a missing type, and it also seems like the type engineer is of course the good one and probably how the author likes to think of themselves. If I was to say the most obvious missing type: the settled engineer, won't try something out even though it could help them until it becomes absolutely a requirement.

This last type I've seen some places among people that were not necessarily under-engineers, but I really just want to add the type in because it balances out our types nicely that way.

lukaslalinsky• 10 years ago

I think this is because of the reasons mentioned in the article. From my experience, most software gets written by people who are not completely new to programming, but are not what I'd call senior either. Let's say it's their second or third bigger project. They are still very enthusiastic, they are able to write a ton of code, they are exploring new design patterns every day, etc. They also do not cost much more than complete beginners to hire. So they end up writing most software and that's why you see a lot of over engineered solutions.

Norfair• 10 years ago

No. Stop putting people in boxes. People don't fit into boxes. They're people, not rats.

akvadrako5• 10 years ago

I don't get it. If rats fit into boxes, surely people fit into bigger boxes?

You can certainly categorise people as well as rats. Some are faster / slower, (not-)curious, low/high-energy, ...

eeZah7Ux3• 10 years ago

Jokes aside, the article attributes characteristics and assigns blame to people based only on under/over designing.

It's well known that the same person can thrive with the right company/team/project/manager and produce good code and do terribly in the wrong one e.g. due to stress, and so on.

See https://en.wikipedia.org/wiki/Fundamental_attribution_error

Besides, it's a company responsibility to hire people that have the right skills, or train them, and don't reward careless work.

swalsh2• 10 years ago

It's a totally shallow classification. Slower and Faster are relative terms, curious is a relative thing, energy is a relative thing. The problem is that engineers create these generic "boxes", place their staff in it, and divvy out work/rewards/responsibilities based on it. It's just like designing an object oriented framework. Your original classes are probably not quite right.

The problem is your boxes are almost certainly overly generic. You might say Joe is just a slow developer, put him in that box and move on. Maybe you talk to Joe, and he doesn't quite tell you exactly why he's slow... he might not know why. You have to dig deeper into it. Maybe he has weaknesses he is afraid to tell. For example, he might be slow because he has 10 years of doing C++, and now he's on a Node.JS team. All his prior knowledge is nearly obsolete. Maybe he's slow because he's not interested in tech problems, instead he's more interested in learning the domain... so he's just not motivated to work fast. Maybe he's slow because he wants to move up in his career, but there's no clear path where that is possible. Maybe he's slow because he has a new born baby, and he doesn't sleep at night.

If you just put him in a box, you're not going to work to try and find his strengths, and play to them, you're not going to work with him to find solutions. It is YOUR job as manager to learn what makes up your team as individuals, and to help them grow. If you just put him in a "box" you're going to call him weak, and your team will work at a crippled pace.

gdulli• 10 years ago

You can (possibly) categorize a person on a given single dimension in isolation at a time. But a person in the real world is the sum of countless dimensions, and the subset of dimensions that factor into a given decision or interaction is complex and fluid and effectively unpredictable.

user59944612• 10 years ago

The difference is that all rats are rats, whereas all people are not rats.

eeZah7Ux3• 10 years ago

Also rats don't like to be in boxes. You meant cats.

crpatino• 10 years ago

But then you'd never know if the cat is already inside of the box or not...

paulddraper2• 10 years ago

As throwaway2016a alludes to, title should be changed to "The Types of Software Engineers"

reves• 10 years ago

I second that, the title is misleading.

lotyrin• 10 years ago

All three of these categories are served by a product team that makes economical constraints explicit.

Too often business comes into the conversation with e.g. "We need a disaster recovery system" and no figures on desired RPO or RTO, no figures for what a minute's worth of business data, or a minute's worth of business activity costs or expected incidence or duration of outages from which even the True Engineer could derive suct figures. Too many organizations, when an individual engineering contributor starts asking questions about these business figures put on a face as if a dog started speaking to them instead of having answers.

It's somehow not seen as inevitable that we, in this vacuum of evidence, reach for all we have -- assumptions based on individual personal prejudice, or just whatever seems easy/fun/cool to implement.

Why should I do the effective thing when I don't get a bonus when the solution works, but I do get overtime pay (or reduced feature load in the sprint) when it fails?

Why should I do the simple thing when I could do the thing that I can put on my resumé and hope I can be a member of a team that either doesn't have a role called "Business Analyst" (because isn't that everyone's job?), or has such a role that actually performs analysis instead of just being a mouthpiece for management.

Sure, a good engineering manager will know this is what has happened, and will push for business to consider the economics of potential solutions and facilitate the decision to implement the solution with the lowest expected costs in the face of risks, but the common level of skill here, and all I've ever been privileged to work with can't process figures like these (everything is either unknown, a feeling, or - rarely - a single precise number, it is literally unthinkable to have a distribution of possible numbers or do maths on such figures), and won't notice their absence or seek them out.

okhudeira6• 10 years ago

Your points couldn't be more accurate. In any organization, the quality of the function that dictates the work to be done (be it Product Managers or Business Analysts) heavily impact the success of an engineer's work. Some organizations choose to remove this level of management [1], others have ensure only former engineers fill this role.

It's very important but broad topic. I chose to not explore it in the post because it deservers its own discussion.

[1] https://www.quora.com/Does-Stripe-have-product-managers-or-d...

donquichotte• 10 years ago

As an Under-Engineer, I enjoy writing code like this:

     for (i=0;i<n;i++) {
        printf("Please enter the %d%s array item\n",i,i==1?"st":"th");
        scanf("%lf",d+i);
     }

Jarwain3• 10 years ago

There's nothing in this world quite like entering the 2th array item :P

lavay• 10 years ago

What a load of *. This post was under engineered.

bryanrasmussen2• 10 years ago

are under-engineers just another word for Morlock?

Jarwain3• 10 years ago

Random thought:

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place.

What are HN's thoughts on a system that rewards developers that fix a lot of bugs, alongside rewarding devs that produce bug-free code?

user59944612• 10 years ago

That's two opposite incentives.

ser02• 10 years ago

I think a key metric that is often missed about developer contribution to a project is lines of code in production and life-span of committed code.

Although these metrics are also prone to manipulation as people reformat code to get their name on git blame, or write perfectly redundant code rather than improve on existing code.

CoolGuySteve• 10 years ago

This reads like a horoscope. I can tut-tut at the over engineers and under engineers while considering myself just right.

Anyone to the left or right of me on the spectrum will also think they're just right and I'm one of the former or latter. This recursive confirmation bias then sends the article straight to the front page.

This is the most smug article I've read on here in a long time. Why can't we just be professionals?

akvadrako5• 10 years ago

If you haven't been in the industry long you'll realise that actual professionals (without quotes) are no more than 10% of the workforce.

Not saying the article isn't written by a "professional", but it's not like it's a solved problem, how to get engineers to behave.

robohamburger2• 10 years ago

I think a far more useful way to divide up software engineers is by how good they are at gathering requirements/understanding the problem they have been tasked with.

That said, and this might be crazy... but sometimes it is nice to have people good at different things on your team :)

With a good lead you can have a person with overengineering leanings on your team and have it be a strength as long as you balance that with other ways of thinking.

Thimothy• 10 years ago

I find that the only acceptable way to divide engineers is with a chainsaw. It might get messy, and is hard to hunt them down especially if they are of the runner kind, but afterwards you get the satisfaction of a work well done.

Bahamut• 10 years ago

When I clicked the link, I was expecting a breakdown on aspects that engineers tend to excel at and what those types tend to be weak at. This article sorely disappoints at an opinionated breakdown with no way to extract it into a more objective measure.

gervase• 10 years ago

I believe it usually goes something like, "Everyone who drives slower than me is an idiot; everyone who drives faster than me is a maniac!"

okhudeira6• 10 years ago

Author here.

Your response is a bit over the top. I'm in no way criticizing anyone or placing myself above anyone. I've been a junior engineer and I've under-engineered. I've been a mid-level engineer and I've over-engineered. Only through feedback from senior engineers did I finally get to see code I wrote stand the test of time 2 years later with minimal to no change.

As I mentioned in the post, no matter how many years we've been doing this, we'll continue to over-engineer and under-engineer because software is hard. The article is meant to layout the mistakes I've learned from, and for engineering managers, our responsibility is to help those we manage avoid the pitfalls we ran into.

ensiferum• 10 years ago

The old tongue in cheek classification of SW Engineers is something like

smart & eager, smart & lazy, stupid & lazy, stupid & eager

stupid & eager does the worst damage and smart & eager doesn't exist (;

pow_pp_-1_v• 10 years ago

These classification may or may not make sense. But why group people into these arbitrary categories? We already have our own biases and prejudices that fairly or unfairly judgde people the moment we meet someone. Why add more?

zwieback• 10 years ago

Unlike what the article suggests, I was an over-engineer when I was junior but now (I hope) I'm closer to an engineer. Could be a personal thing for me but I often preach to the juniors that they shouldn't build "platforms", just solve the problem and see what emerges. That's difficult, though, because you have to solve the problem in a future-proof way, which I only learned after many years of practice.

catnaroek• 10 years ago

The idea that engineers are abstract thinkers is completely laughable. An abstract thinker wouldn't ask you to show them use cases or test cases. An abstract-minded programmer:

(0) Views a program as a relation between the initial and final states of a process controlled by it.

(1) Understands that the sheer size of this relation makes it impractical to reason about it by enumeration of its members.

(2) Develops calculational machinery to minimize the amount of intellectual effort required to establish that a program meets a specification.

Insanity3• 10 years ago

Mid-level engineers who recently discovered software design patterns tend to fall into this category.

A mid-level engineer who only just discovered Design Patterns. So, a first or second year university student is a mid level engineer?

true_religion• 10 years ago

Most first or second year students aren't going to be able implement cqrs or even find out about it. In my university design patterns were never taught formally as teachers were more interested in the research aspect of computer science.

Insanity3• 10 years ago

We had a course dedicated to design patterns in the third semester, a second course on them in the fourth semester, and in semester 6 you could optionally take another course on them.

On top of that, we always had suggested reading material which would be given at the start of a semester. I'm fairly sure, but not 100%, that design patterns were mentioned at the start of the second semester as suggested reading material but not yet mandatory (since we would see it the year thereafter).

But my memory is hazy on that, I know that I picked a book up on it early in university but it is possible that that was one that I found by reference from another book and not by the list of books from the university.

ser02• 10 years ago

In theory yes, in practice no. Generally speaking university students learn, prove-knowledge-of, then move on to the next course/subject.

University projects also tend to be much smaller in scope than any sort of realistic product that a company can be built on. Therefore, the level of technical debt created by under-engineering and the codebase comprehension learning-curve created by over-engineering is not something most university students have exposure to.

Therefore, I think the article's intent hints more at experience than knowledge. It is possible that once a graduate gets enough experience with an under-engineered project, a lightbulb moment will occur where they see how they can apply their university knowledge by refactoring everything to be more testable, scalable, etc. Depending on the opportunities offered, they may well choose to over-engineer their next task.

Given the theoretical and academic nature of most course work though, it's more likely that an over-engineered solution is inspired by a HN post than by someone recalling their university education.

Insanity3• 10 years ago

Good point! There is of course a difference between just studying for an exam and retaining the information long enough to pass the test, and actually retaining the information for a longer period and being able to apply the learned principles in bigger, industrial-scale projects.

Types of Engineers

Related Stories