What distinguishes great software engineers? (2019) [pdf]
faculty.washington.edu
What distinguishes great software engineers? (2019) [pdf]
1–10 of 174 posts
Re: What distinguishes great software engineers? (2019) [pdf]
#2I'm surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I've found many people, even engineers with a lot of experience, are terrible at this.
Re: What distinguishes great software engineers? (2019) [pdf]
#3Can't claim I read the entire thing, but I got down to methodology and must say it doesn't look particularly impressive. The study is a survey sent out strictly to Microsoft employees asking them how they rank a set of pre-defined criteria about what makes a great software engineer. That criteria includes things like "hard working", "honesty", "team player", "creates a safe haven" etc...
Obviously no Microsoft employee is going to say something like "Lazy liars who treat people like crap make great software engineers."
At the very least you'd expect a study to have a control group in order to filter out these useless questions. For example send a similarly worded survey to a group of grocery cashiers and ask them if they think attributes such as "Hard work, honesty, integrity, long term thinking, being a team player." make someone a great engineer.
My hypothesis is you'd end up getting similar answers from taxi drivers as you would from Microsoft employees and consequently that there isn't much value derived from this survey or their selection of participants.
Anyways, I'm by no means an expert and could be misjudging this research but frankly it looks to be beyond useless.
Re: What distinguishes great software engineers? (2019) [pdf]
#4I'm surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I've found many people, even engineers with a lot of experience, are terrible at this.
One place I worked said that you weren't allowed to make an estimate that was longer than three weeks. There are apparently studies showing that estimates longer than that tend to have much larger errors. So if it was going to be longer, we had to break it up into pieces until each piece was smaller than three weeks.
That could get tedious. On the other hand, we did do a lot better than normal at hitting our dates.
(I believe this shorter-than-three-weeks idea came from Extreme Programming, but I'm not quite certain of that.)
Re: What distinguishes great software engineers? (2019) [pdf]
#5I'm surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I've found many people, even engineers with a lot of experience, are terrible at this.
> An important part of their role is estimating how long a task will take to complete
Agile exists because a very large number of people dispute this.
Re: What distinguishes great software engineers? (2019) [pdf]
#6I'm surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I've found many people, even engineers with a lot of experience, are terrible at this.
One place I worked said that you weren't allowed to make an estimate that was longer than three weeks. There are apparently studies showing that estimates longer than that tend to have much larger errors. So if it was going to be longer, we had to break it up into pieces until each piece was smaller than three weeks. That could get tedious. On the other hand, we did do a lot better than normal at hitting our dates. (…
This is also why I like estimating tasks using the Fibonacci scale without a direct correlation to time.
In my teams, we generally set 8 points as something that would take an entire day. Every number after that jumps up in relatively large increments as they are more difficult to accurately determine
Re: What distinguishes great software engineers? (2019) [pdf]
#7I'm surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I've found many people, even engineers with a lot of experience, are terrible at this.
> An important part of their role is estimating how long a task will take to complete Agile exists because a very large number of people dispute this.
And then jumps through large hoops to hide that it's still asking people to estimate. Sure, it's not hours, it's "velocity" and "difficulty", and you don't estimate, you play "Fibonacci Poker".
But at the end of the day, the question "can we do this in the allotted amount of time" still gets asked and answered.
What agile got right is realizing that the error bars increase superlinearly with duration, and that scope isn't fixed - so frequent estimates with frequent course correction. But you're still estimating.
Re: What distinguishes great software engineers? (2019) [pdf]
#8OK, so I admit I just started with the abstract, but the first item listed is "writing good code". Umm, I would hope that is kinda part of the definition? I was actually looking for some valuable insight (e.g. how are great software engineers able to consistently write good code) but I didn't see it in this report.
Re: What distinguishes great software engineers? (2019) [pdf]
#9As other commenters have noted, this is a quite generic article with very little specific to software engineering. For a much more informative take on the same topic, read "Norris Numbers" by Lawrence Kesteloot:
https://www.teamten.com/lawrence/writings/norris-numbers.htm...
Re: What distinguishes great software engineers? (2019) [pdf]
#10Can't claim I read the entire thing, but I got down to methodology and must say it doesn't look particularly impressive. The study is a survey sent out strictly to Microsoft employees asking them how they rank a set of pre-defined criteria about what makes a great software engineer. That criteria includes things like "hard working", "honesty", "team player", "creates a safe haven" etc... Obviously no Microsoft employ…
Most academic software engineering “research” I’ve seen is pretty useless, especially these kinds of human factors studies. Questionnaires and interviews are usually too underpowered or specific to be statistically significant, and their terms are defined vaguely enough to draw any conclusions the authors want. Occasionally there is some interesting demographic information, but most of the papers I’ve read are usually glorified position papers under the guise of an empirical study.