Types of Engineers(omar.io)
omar.io
Types of Engineers
http://omar.io/2017/01/10/the-types-of-engineers.html
81 comments
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.
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!"
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.
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.
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.
Slow Romero style coders can be sawed 10x faster than other normal ones.
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.
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.
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.
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.
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."
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."
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.
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.
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.
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.
Sloppy or Serious: I have to agree with that. The attitude of the person in that case would dominate their work quality.
However I think you are being overly cynical about the 'Senior Web Engineer' bit.
True, you can make it far by faking it. Very far in some cases. But number of times I have run into developers that only landed the job because of the habit you describe, I can count on one hand. Was there a particular event that shaded your world view so?
True, you can make it far by faking it. Very far in some cases. But number of times I have run into developers that only landed the job because of the habit you describe, I can count on one hand. Was there a particular event that shaded your world view so?
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."
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."
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.
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.
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.
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.
Sorry just to be clear I didn't meant to criticize your article, it's just one example of a general cultural tendency that I was somewhat unhappy about.
As an Electrical P.E., it didn't bother me per se; but it is interesting to consider all the different ways engineer is used in English.
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.
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.
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.
Velocity? How is that a software term?
It's a pretty well known term in agile software development.
It is also a pretty well known term in other fields, and was long before agile software development came around.
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?
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?
Then the title should be changed.
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.
So if he had simply titled the piece "Types of Software Engineers" you would be happy?
That is exactly what is being said.
It's just unfortunate he's distracting from discussing the content of the post to make a pedantic point that recurs on HN ad nauseam despite fostering no interesting discussion.
It happens. As you said, it happens recurringly. Generalizations can be an issue for a lot of people in a variety of topics, and his comment outlines his hope/a reason against people continuing the trend of generalizing engineers. Even if it is just the title. There's nothing wrong with more specificity.
He even apologizes for going slightly meta and off-topic. If anything, complaining about this point distracts from post content and fosters even less interesting discussion.
He even apologizes for going slightly meta and off-topic. If anything, complaining about this point distracts from post content and fosters even less interesting discussion.
If you're apologizing for being meta and off topic you could also just save your comment for when it's on topic.
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.
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.
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.
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.
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.
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.
This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .
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.
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 are so many internal and external factors that go into solving a problem.
> 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.
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...
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...
The linked article actually has very little in the way of substance.
What is "impact"?
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.
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.
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]
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).
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).
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.
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.
Modern git does store most blobs as deltas of other blobs, in the form of packfiles.
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.
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.
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...
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...
[deleted]
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.
Maybe saying the same thing over and over again has merit to nail in the idea but eventually it becomes stale.
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 certainly categorise people as well as rats. Some are faster / slower, (not-)curious, low/high-energy, ...
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.
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.
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.
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.
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.
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.
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.
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
That isn't what I was talking about but it was an interesting choice of words :)
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 :)
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.
The difference is that all rats are rats, whereas all people are not rats.
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);
}There's nothing in this world quite like entering the 2th array item :P
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 (;
smart & eager, smart & lazy, stupid & lazy, stupid & eager
stupid & eager does the worst damage and smart & eager doesn't exist (;
> 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?
A mid-level engineer who only just discovered Design Patterns. So, a first or second year university student is a mid level engineer?
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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?
>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?
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.
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.
That's two opposite incentives.
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?
are under-engineers just another word for Morlock?
As throwaway2016a alludes to, title should be changed to "The Types of Software Engineers"
I second that, the title is misleading.
What a load of *.
This post was under engineered.
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?