Types of Engineers
omar.io
Types of Engineers
1–10 of 82 posts
Re: Types of Engineers
#2This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .
Re: Types of Engineers
#3This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .
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?
Re: Types of Engineers
#4This 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.
Re: Types of Engineers
#5This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .
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]
Re: Types of Engineers
#6Eh, 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.
Re: Types of Engineers
#7This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .
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).
Re: Types of Engineers
#8Sorry 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."
Re: Types of Engineers
#9This 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.
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.
Re: Types of Engineers
#10From 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.