Types of Engineers(omar.io) |
Types of Engineers(omar.io) |
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?
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.
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.
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.
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."
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.
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.
Nonsense.
> 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.
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).
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.
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.
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...
Maybe saying the same thing over and over again has merit to nail in the idea but eventually it becomes stale.
for (i=0;i<n;i++) {
printf("Please enter the %d%s array item\n",i,i==1?"st":"th");
scanf("%lf",d+i);
}smart & eager, smart & lazy, stupid & lazy, stupid & eager
stupid & eager does the worst damage and smart & eager doesn't exist (;
A mid-level engineer who only just discovered Design Patterns. So, a first or second year university student is a mid level engineer?
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.
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.
(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.
>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?
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.
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.
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.
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."
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 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 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.
You can certainly categorise people as well as rats. Some are faster / slower, (not-)curious, low/high-energy, ...
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.
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.
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?
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...
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.
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.
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.
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 :)
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?