* decision anxiety
* fear of writing original ideas, both natural language and code
* the inability to measure things
* preference towards bias
* cognitive conservatism
* inability to form assertion criteria
Real engineers proceed on the basis of evidence and in the absence of evidence make arbitrary original decisions as necessary to gather evidence.
* fear of writing original ideas, both natural language and code - agree
* the inability to measure things - who said this is something that is necessary at all stages? sometimes you just need it done. when you have 1000 people teams selling to enterprises, sure. If it is you and your buddies, no need to measure, necessarily.
* preference towards bias - Why? If it works, a good engineer won't go to the newest tech/framework. They will stay with their biased favorite.
* cognitive conservatism - Disagree. See previous comment
* inability to form assertion criteria - Not exactly sure what you mean, but if you mean to reason about code and state at various points, then I agree
https://web.archive.org/web/20170809055122id_/https://learni...
tl;dr They did a qualitative survey of what other people think makes a great software engineer at Microsoft.
Their take aways:
- The ability to learn is more important than any individual technical skill
- Making good decisions is rarely discussed in the software engineering literature, but it is critical to being a great software engineer
- Software engineering is a sociotechnical undertaking
- Delivering the code is often insufficient; complex contextual technical considerations abound.
It is a hard truth though that a lot of those personality traits lead to behaviours that are not aligned with small to medium enterprise (SME) needs, particularly ones that hire engineers and yet are not, at their core (in their couer) tech companies.
The big, great tech companies have their business units ride on the coat tails of great engineers and the engineers thrive in a stable maximum.
Great product companies can have great engineers fulfilling product needs, but the long term trend, without constant and frankly impossible levels org vigilance, will be for their engineering culture to devolve into mediocrity. SME product companies don’t stand a chance.
"Why the down votes?"
LLT, dis u?
The whole 'sociotechnical' part is gaping black hole for most new devs I meet, because it's not taught, and I don't know that schools know how to teach it.
Anyone have any internal processes (or resources) for helping newbs understand that side of the job?
But since you're asking, and it seems with more sincerity than your initial comment, I can offer my view.
First, though, I need to point out something about HN karma that's a bit different than reddit or elsewhere. I include this because it was a shock to me at first, and your account is new enough you may not have gotten used to it yet, either. And it's that nobody cares about how much karma anyone has. It's used as a basic filter for allowing downvotes and it's visible in someone's profile, but what I mean is that there isn't a lot of farming going on. At least, in general. Partly because it's so much work with little pay-off, I think. You can't get easy karma from a quick laugh or posting something controversial. You can't even be sure that a news item you post will get enough attention to try and get easy comment points from. The kinds of comments that would get easy karma on Reddit are more likely to get downvoted here, and maybe it's reactionary but I am pretty sure it's not personal. I like how you can't downvote any responding comments, even if you can downvote. Anyway, it's not a perfect system but I can say I stopped going to reddit when I came to appreciate the better parts of HN commentary.
One of the things that can trigger a lot of downvotes is criticism without substance. Even if it's a valid commentary on the society or politics involved. And, if it's a little off topic, that can trigger some downvotes too. It takes a real gem of a comment and good timing to get more than a few upvotes, and you never really know how many upvotes someone else's comment got unless they tell you. tbh some of my comments that I put a decent amount of time and thought into never got an upvote, but I'm rarely surprised at getting too many upvotes for a comment.
The audience here tends to favor original thought, and are easily dismissive of comments that are overly dismissive of the news post it is commenting on.
Tying this all back to the fine article, which I'll admit to not having read, but whose topic I can claim some of my own opinions on, because I've been fortunate enough to work with a range of talent there. I think one of the hallmarks of a great engineer is to have partitioned off the creation from the creator enough that they never take personal offense to any criticism of their design or their plan. Assuming mutual respect and fair communication (both which also are requirements, IMO). There's also all the actual technical bits but I think it's fair to say that a lot of what makes a great anything involves a mastery over communication and enough confidence in themselves not to take things personally.
And, maybe, you know, that also connects with your original comment. But I don't know if that has anything to do with your intention when posting it.
I like negative feedback.
I'm surprised you wrote all this. You, too, should like negative feedback. How else are you going to get gritty and competitive?
To be clear, some of my commentary was in response to a sibling comment of yours where you seemed to take the downvotes personally. I can't speak for all the cases, obviously, but my observation of HN is that the downvotes are usually a signal of "this comment doesn't apply to the topic or follow-up debate" and less so a signal of "bad idea" or "bad author.". Disagreement with an idea usually results in a thoughtful comment response, not a downvote.
I think the karma threshold for downvoting rights is useful here in that it gives everyone enough exposure to the guidelines before taking action on their own personal ranking objectives (and the HN guidelines are worth reading if you haven't yet -- https://news.ycombinator.com/newsguidelines.html). My best guess is that your downvoters considered your comment a dismissal of TFA, without any explanation for your flippancy.
I may have read to the bottom of too many HN posts but,, fortunately, no one is keeping score and they really don't get that long or too toxic. (thanks largely to the efforts of dang and the rest of the mods, I'm sure)
Your comment read to me like an attempt to energize and motivate. It didn't seem to have "substance". How does your comment help me improve my understanding of what compromises a good engineer? Instead it seems to suggest I shut down my mind, stop doing the work, and feel like I've already won before I've even started. Yet, improving as an engineer has come with a lot of work, challenging myself to get more specific, be concrete and appropriately detailed, as well as thinking through "but really... How would that work throughout the complete causal chain with no shortcuts?".
I won't claim there aren't downsides but there is a utility to the expectation. Hopefully you find ways it can help you grow.
The inability to measure things results in a lot of really bad output often in preference for emotional comfort. This and cognitive conservatism are the most clearly identifiable criteria of poor cognitive performance by people who are in over their heads. I saw this at every employer when I wrote JavaScript for a living.
The inability to form assertion criteria means a person has absolutely no idea how to qualify a decision logically.
In most of these people tend to do Y at much greater cost because they cannot do X. The most common answer to this is anxiety and then people twist themselves into knots to somehow qualify that anxiety in a way that makes sense to themselves.
understanding when you don't need to measure is important too. If you are just making a small 2d app as a hobby with no more than maybe 100 draw calls on hardware that exceeds that of a potato: I probably won't waste much time with optimization schemes and just crank something out.
But that same app may want to be kept as small as it feels so I would focus more on any assets being compressed.
> inability to form assertion criteria - Not exactly sure what you mean
I took it as testing. Unable to understand what you're trying to solve, frequency of usage for such functions/modules, the amount of reach your code will have (only used once in a small module? Code code that he core multiple layers up will rely on?) and not considering potential edge cases. More or less similar to what you said.
I do prefer those things I'm biased towards.
- fear of original ideas = cognitive conservatism = preference towards bias
And kind of opposites:
- decision anxiety = results from, or brings about, too much measuring
So, I guess those can be digested to say that engineers are:
- Innovative - Make informed decisions
https://www.svilendobrev.com/rabota/
starting from Organisational patterns, down. Skip anything there about design/ architecture/ math.
But: have in mind Conway's law - software-produced <=> organisation's-culture. So you can't dismiss entirely either of the two extremes of the socio-techical (human-machine) systems.
IMO, Winnie the Pooh has much more sociotechnical hints than CS university course.
You could take any five of those attributes, any five sections, cut and paste them into a blog, and it would be a nice but middling post. Five good things to be reminded of. Nice quotes.
Probably a good post for applying to lots of other jobs besides software engineering.
But a comprehensive list of 18 distinct attributes becomes more. The extremely tight intersection you get from all 18 personality constraints creates the clearest picture of a "great software engineer" that I have found yet.
Comprehensive coverage adds depth and clarity all its own. Bravo.
Curious to know this group's thoughts: Do you believe that passion is NECESSARY to be a "great" software engineer?
Or, perhaps, consider it in reverse. If you don't have passion, if you don't care about the software, if it's just a 9-to-5 job to you, how likely are you to do great work?
I don't think you have to have an obsessive, does-nothing-but-code-and-sleep kind of passion to be great, or at least moderately great. But you have to care about your craft, about the quality of the code you produce, or you won't produce anything approaching "great".
Also very much thought it was cool to know someone can nerd out on math and skateboard.
Also being a "great software engineer" doesn't get you money more than being "good at people" so ppl who are great are doing it for love .
Any leetcoders I have hired have turned out to be one trick ponies and actually aren't very creative or think from first principles. I have been in the industry for 21 years now and I know my opinion is shared by many others.
I also ponder what it means that u can graduate with a cs degree that essentially leet code companies don't trust, hence they test you. What does this say about the university system? I could see asking ppl from "lower tier" unis to take a test but applying leet code across thr board surely has to weed out really good candidates who are generally fast learners and are smart.
The problem space there comes from only two considerations. The first of which is a team where nobody has the required prior experience. In that case confidence drops in proportion to the increase of uncertainty, but that does not necessarily result in an increase of anxiety. Some people and/or work cultures are much better positioned than others to confront stress directly without distressing towards anxiety.
The second consideration is the collision between prior experience and evidence. In this case both the evidence and the prior experience must be considered and an alternate conclusion must be reached. That alternate conclusion is the definition of truth according to John Stuart Mills.
For more experienced engineers, I think about it as skill vs motivation. In theory one doesn't need motivation to do great work. In practice, I haven't seen great work from folks with high skill but low motivation.
My view of GSEs:
- Wiliness to test hypotheses, listen to others, seeks input and feedback, and maintain metrics to decide if various methods are or aren't working.
- Minimal ego.
- Curiosity about things at lower levels.
- Mastery of first principles and able to create data structures and algorithms optimized for specific, difficult problems.
- Ability to debug up and down the stack quickly.
- Concern for stability and usability by consumers of products and services maintained and delivered.
- Ability to teach and mentor.
- Ethical integrity refusing to compromise or exploit users for short-term business gain.
I'm sorry... but only interviewing engineers from one company makes this a complete joke. I stopped reading after I saw that.
I don't understand how anybody could take any conclusions here seriously when they're obviously so fundamentally biased.