Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Types of Engineers

omar.io

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Types of Engineers

#71

Post by asdfjaflswjafs »

okhudeira wrote: post #69
asdfjaflswjafs wrote: post #49

Earlier quoted context omitted.

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

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.

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.

Re: Types of Engineers

#72

Post by Thimothy »

robohamburger wrote: post #41
CoolGuySteve wrote: post #35

This reads like a horoscope. I can tut-tut at the over engineers and under engineers while considering myself just right . Anyone to the left or right of me on the spectrum will also think they're just right and I'm one of the former or latter. This recursive confirmation bias then sends the article straight to the front page. This is the most smug article I've read on here in a long time. Why can't we just be profes…

I think a far more useful way to divide up software engineers is by how good they are at gathering requirements/understanding the problem they have been tasked with. That said, and this might be crazy... but sometimes it is nice to have people good at different things on your team :) With a good lead you can have a person with overengineering leanings on your team and have it be a strength as long as you balance that…

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.

Re: Types of Engineers

#73

Post by swalsh »

akvadrako wrote: post #64
swalsh wrote: post #46

Earlier quoted context omitted.

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…

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.

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.

Re: Types of Engineers

#74

Post by akvadrako »

swalsh wrote: post #73
akvadrako wrote: post #64

Earlier quoted context omitted.

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.

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 :)

Re: Types of Engineers

#75

Post by Insanity »

true_religion wrote: post #66
Insanity wrote: post #61

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

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.

Re: Types of Engineers

#76

Post by ser0 »

Insanity wrote: post #61

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

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.

Re: Types of Engineers

#77

Post by ser0 »

Jarwain wrote: post #32

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

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.

Re: Types of Engineers

#78

Post by bavcyc »

asdfjaflswjafs wrote: post #49
throwaway2016a wrote: post #8

Sorry ahead of time for going slightly meta and off topic. I am a software engineer myself but... I find the fact that this blog refers to software engineering practices as if they apply to all engineering disciplines to be a little jarring and best and misleading at worst. I wouldn't expect a mechanical engineering blog to have an article "Types of Engineers" that only discusses mechanical engineering. I refuse to n…

I feel the exact same way. I am electrical engineer by training. When I first moved to San Francisco, I would answer "yes" every time someone would ask "are you an engineer" but I quickly learned that when people said "engineer" 99% of the time they meant software engineers. I quickly became used to saying "no i'm not an engineer, at least not a software engineer." To me, it's a fairly myopic culture. One of my frien…

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.

Re: Types of Engineers

#79

Post by bavcyc »

okhudeira wrote: post #69
asdfjaflswjafs wrote: post #49

Earlier quoted context omitted.

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

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.

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.

Re: Types of Engineers

#80

Post by robohamburger »

Thimothy wrote: post #72
robohamburger wrote: post #41

Earlier quoted context omitted.

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…

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.
Post reply on HN