What Makes a Great Software Engineer (Dissertation) (2016) [pdf]

We certainly know what makes bad developers:

* 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.

* decision anxiety - agree

* 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

Bad management can easily incentivize all of those things, with the possible exception of neglecting assertion criteria.

Not always insisting upon measuring is not the same thing as an inability to measure when it would actually help.

People tend to preference their bias because they cannot execute more objectively and then frame that against a collection of logical fallacies and other nonsense as justifications and equivocations.

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.

>who said this is something that is necessary at all stages?

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.

> * preference towards bias

I do prefer those things I'm biased towards.

It's interesting how your list contains points that are almost duplicates of each other:

- 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

I also like the things you're biased towards. :)

Decision anxiety, measuring things, and a preference toward bias are basically all you need to skewer anyone who has a different opinion than you. If they want more data they are anxious if you want more data they rush to an opinion.. Then they are either wasting your time with measurements when the project is done or not taking improvement seriously.

Also I've never known anyone who has no bias. Even if such people existed, it's not a given that they would make the best decisions. I would imagine the best decisions are made by those who have a good set of preferences and opinions based on experience.

All those are traits of subservient people that non-technical managers like

Nonsense. Just be honest that you have either evidence or a hypothesis. If you are in charge make an arbitrary decision or defer to the person that is in charge. Everything else is posturing by people that cannot perform, typically due to an irrational fear or some face saving silliness.

There's certainly many dimensions along these lines that if you don't think about them in relation to the type of software development you are doing, and what you have done, you will take a long time to improve.. But this being the model for all software development (such that all others are bad) strikes me as a missing chapter from printf.

https://ferd.ca/the-little-printf.html

Sure there are always edge cases and unknowns. Additionally we each have a limited capacity for condition variability. All of that can be qualified away by people who have prior experience. By prior experience I don't mean ample work history (vague), but people who have participated in a given scenario in the past (highly specific).

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.

That was a good read. I appreciate you sharing!