61–70 of 82 posts
A mid-level engineer who only just discovered Design Patterns. So, a first or second year university student is a mid level engineer?
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, ...
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-…
Earlier quoted context omitted.
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, ...
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…
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.
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 coul…
> 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?
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 wil…
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…
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 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…
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.
Earlier quoted context omitted.
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).
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 req…