Types of Engineers • Hacker News Board

Re: Types of Engineers

#41

Post by robohamburger » Wed, Jan 11, 2017, 5:08 PM UTC

CoolGuySteve wrote: post #35

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 profes…

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.

Re: Types of Engineers

#42

Post by badloginagain » Wed, Jan 11, 2017, 5:08 PM UTC

okhudeira wrote: post #9

badloginagain wrote: post #4

Earlier quoted context omitted.

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.

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…

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

Re: Types of Engineers

#43

Post by jbeja » Wed, Jan 11, 2017, 5:26 PM UTC

There is also the "simplistic", like the author.

Re: Types of Engineers

#44

Post by pow_pp_-1_v » Wed, Jan 11, 2017, 5:26 PM UTC

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?

Re: Types of Engineers

#45

Post by Bahamut » Wed, Jan 11, 2017, 5:39 PM UTC

CoolGuySteve wrote: post #35

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 profes…

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.

Re: Types of Engineers

#46

Post by swalsh » Wed, Jan 11, 2017, 5:47 PM UTC

akvadrako wrote: post #22

Norfair wrote: post #14

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

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

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.

Re: Types of Engineers

#47

Post by zwieback » Wed, Jan 11, 2017, 5:47 PM UTC

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.

Re: Types of Engineers

#48

Post by catnaroek » Wed, Jan 11, 2017, 5:47 PM UTC

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.

Re: Types of Engineers

#49

Post by asdfjaflswjafs » Wed, Jan 11, 2017, 6:05 PM UTC

throwaway2016a wrote: post #8

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 n…

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

Re: Types of Engineers

#50

Post by gdulli » Wed, Jan 11, 2017, 6:07 PM UTC

akvadrako wrote: post #22

Norfair wrote: post #14

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

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

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.