17 ms·

Types of Engineers

116 points by winterweather 10y ago

zitterbewegung 10y ago
This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .
- jcizzle 10y 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?
  - deleted 10y ago
    [deleted]
- badloginagain 10y 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.
  - okhudeira 10y 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.
    - badloginagain 10y ago
      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-impact-the-surprising-correlation/ https://blog.gitprime.com/check-in-frequency-and-codebase-im...
      - Ace17 10y ago
        What is "impact"?
      - okhudeira 10y ago
        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.
      - random_rr 10y ago
        The linked article actually has very little in the way of substance.
- collyw 10y 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 10y 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.
    - dlubarov 10y ago
      Modern git does store most blobs as deltas of other blobs, in the form of packfiles.
thealfreds 10y 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.
throwaway2016a 10y 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."
- okhudeira 10y 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 10y ago
    Velocity? How is that a software term?
    - schwarzmx 10y ago
      It's a pretty well known term in agile software development.
      - cortesoft 10y ago
        It is also a pretty well known term in other fields, and was long before agile software development came around.
        shuntress 10y ago
        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 10y 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 10y 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.
- bryanrasmussen 10y 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 10y 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 10y ago
No. Stop putting people in boxes. People don't fit into boxes. They're people, not rats.
- akvadrako 10y 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, ...
  - user5994461 10y ago
    The difference is that all rats are rats, whereas all people are not rats.
  - eeZah7Ux 10y 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 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.
  - swalsh 10y 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.
paulddraper 10y ago
As throwaway2016a alludes to, title should be changed to "The Types of Software Engineers"
- reves 10y ago
  I second that, the title is misleading.
lotyrin 10y 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.
- okhudeira 10y 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-do-engineers-manage-the-products-themselves https://www.quora.com/Does-Stripe-have-product-managers-or-d...
donquichotte 10y 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); }
- Jarwain 10y ago
  There's nothing in this world quite like entering the 2th array item :P
lavay 10y ago
What a load of *. This post was under engineered.
bryanrasmussen 10y ago
are under-engineers just another word for Morlock?
Jarwain 10y 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?
- user5994461 10y ago
  That's two opposite incentives.
- ser0 10y 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 10y 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?
- akvadrako 10y 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.
- robohamburger 10y 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 10y 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.
    - robohamburger 10y ago
      Slow Romero style coders can be sawed 10x faster than other normal ones.
- Bahamut 10y ago
ensiferum 10y 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 (;
jbeja 10y ago
There is also the "simplistic", like the author.
pow_pp_-1_v 10y 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 10y 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 10y 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.
Insanity 10y 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 10y 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.
  - Insanity 10y 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.
- ser0 10y 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.

116 points by winterweather 10y ago

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

jcizzle 10y 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?
- deleted 10y ago
  [deleted]
badloginagain 10y 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.
- okhudeira 10y 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.
  - badloginagain 10y ago
    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-impact-the-surprising-correlation/ https://blog.gitprime.com/check-in-frequency-and-codebase-im...
    - Ace17 10y ago
      What is "impact"?
    - okhudeira 10y ago
      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.
    - random_rr 10y ago
      The linked article actually has very little in the way of substance.
collyw 10y 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 10y 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.
  - dlubarov 10y ago
    Modern git does store most blobs as deltas of other blobs, in the form of packfiles.

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

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

okhudeira 10y 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 10y ago
  Velocity? How is that a software term?
  - schwarzmx 10y ago
    It's a pretty well known term in agile software development.
    - cortesoft 10y ago
      It is also a pretty well known term in other fields, and was long before agile software development came around.
      - shuntress 10y ago
        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 10y 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 10y 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.
bryanrasmussen 10y 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 10y 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 10y ago

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

akvadrako 10y 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, ...
- user5994461 10y ago
  The difference is that all rats are rats, whereas all people are not rats.
- eeZah7Ux 10y 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 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.
- swalsh 10y 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.

paulddraper 10y ago

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

reves 10y ago
I second that, the title is misleading.

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

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

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

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

lavay 10y ago

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

bryanrasmussen 10y ago

are under-engineers just another word for Morlock?

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

user5994461 10y ago
That's two opposite incentives.
ser0 10y 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 10y 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?

akvadrako 10y 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.
robohamburger 10y 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 10y 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.
  - robohamburger 10y ago
    Slow Romero style coders can be sawed 10x faster than other normal ones.
Bahamut 10y ago

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

jbeja 10y ago

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

pow_pp_-1_v 10y 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 10y 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 10y 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.

Insanity 10y 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 10y 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.
- Insanity 10y 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.
ser0 10y 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.