As throwaway2016a alludes to, title should be changed to "The Types of Software Engineers"
Types of Engineers
21–30 of 82 posts
Re: Types of Engineers
#22No. 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, ...
Re: Types of Engineers
#23Sorry 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…
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.
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.
Re: Types of Engineers
#24All 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.
Re: Types of Engineers
#25No. Stop putting people in boxes. People don't fit into boxes. They're people, not rats.
Also rats don't like to be in boxes. You meant cats.
Re: Types of Engineers
#26As an Under-Engineer, I enjoy writing code like this:
for (i=0;iRe: Types of Engineers
#27What a load of *.
This post was under engineered.
Re: Types of Engineers
#28No. 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, ...
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.
Re: Types of Engineers
#29Earlier quoted context omitted.
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.
Re: Types of Engineers
#30From 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 wil…
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.