
Types of Engineers - winterweather
http://omar.io/2017/01/10/the-types-of-engineers.html
======
CoolGuySteve
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?

~~~
robohamburger
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
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.

~~~
robohamburger
Slow Romero style coders can be sawed 10x faster than other normal ones.

------
throwaway2016a
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."

~~~
okhudeira
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
Velocity? How is that a software term?

~~~
schwarzmx
It's a pretty well known term in agile software development.

~~~
cortesoft
It is also a pretty well known term in other fields, and was long before agile
software development came around.

~~~
shuntress
In this case, other context clues tell us that the article means 'velocity as
in software development'.

Agile, for example, is another general term that has a fairly specific meaning
in this context.

If you overhear someone in a park say "Oh, you guys are agile? What's your
average velocity?" would you assume they are talking about athletics or
software development?

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

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

~~~
badloginagain
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.

~~~
okhudeira
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.

~~~
badloginagain
I encourage you to keep writing, but it seems you need more research into
developer patterns if you want to contribute to an already highly discussed
topic.

For instance, last month this article[1] gave some seriously good insights to
developer checkin frequency based on hard data. It provides a lot more value
than the anecdotal, muddy definitions of over/under/engineer.

[1] - [https://blog.gitprime.com/check-in-frequency-and-codebase-
im...](https://blog.gitprime.com/check-in-frequency-and-codebase-impact-the-
surprising-correlation/)

~~~
okhudeira
I appreciate the feedback.

That's a very interesting article. However, it does seem suffer from the same
issues Joel outlined, namely, the measure of attributes of a commit can be
gamed and worked towards to achieve a "prolific" or "senior" status.

What the article you linked does reinforce is the value of iterative
development. As opposed to doing large infrequent commits, doing small bits of
work more frequently causes a success higher or "impact".

I would say that the article provides a data driven approach to justifying the
effectiveness of good iterative planning. However, it doesn't address whether
the commits of the "senior" engineer or the "prolific" engineer are of high
quality.

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

~~~
okhudeira
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...](https://www.quora.com/Does-Stripe-have-product-managers-or-do-
engineers-manage-the-products-themselves)

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

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

~~~
akvadrako
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, ...

~~~
swalsh
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.

~~~
akvadrako
I don't understand even the first paragraph in your argument. Are you saying
you can't pick some rats which are faster than some other rats?

Yes, it's relative - everything is relative - but what does that have to do
with shallow?

If you are looking for rats to win a race, clearly some rats will be much
better to use than others.

What you just wrote feels like a rant without a coherent basis.

~~~
swalsh
Your comment is unnecessarily combative, so i'm not going to further explain
myself. The issue with your line of reasoning is that your analogy doesn't
hold up. An engineering team building a product is not a rat race.

~~~
akvadrako
Maybe you are unaware, but the term "rat race" is a colloquial expression that
is used to describe the type of situation that many office workers are in:

[http://www.urbandictionary.com/define.php?term=rat%20race](http://www.urbandictionary.com/define.php?term=rat%20race)

That isn't what I was talking about but it was an interesting choice of words
:)

------
donquichotte
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);
         }

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

------
ensiferum
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 (;

------
Insanity
> 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?

~~~
ser0
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.

~~~
Insanity
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.

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

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

------
Jarwain
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?

~~~
ser0
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.

------
pow_pp_-1_v
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?

------
bryanrasmussen
are under-engineers just another word for Morlock?

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

~~~
reves
I second that, the title is misleading.

------
lavay
What a load of __*. This post was under engineered.

