Live data from Hacker News

What distinguishes great software engineers? (2019) [pdf]

faculty.washington.edu

31–40 of 174 posts

Re: What distinguishes great software engineers? (2019) [pdf]

#31
post #7
post #5

Earlier quoted context omitted.

> 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…

I have fond memories of spending days in planning meetings, arguing over whether a task was 2 points or 3. Totally pointless.

Re: What distinguishes great software engineers? (2019) [pdf]

#34

Earlier quoted context omitted.

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. (…

But then, you still have to connect all these 3-weeks-pieces together. And how long does that take? No we are back to the original, overall question...

The idea was that the three week pieces add up to the whole of the larger task. (Yeah, I know - only if you didn't miss anything. Take the time to think it through well enough that you don't do that. And what if you have things you don't know? Then you have to do a research project to find them out before you can give valid estimates.)

Re: What distinguishes great software engineers? (2019) [pdf]

#35
post #3

Can'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…

The paper may not offer insightful prescriptions for experienced engineers, but can work like this still be useful for informing future studies in a meaningful way? The authors repeatedly note the widespread inadequacies of the current research landscape. (To anyone familiar with the literature, is their assessment accurate?) In my eyes, the message is that the paper represents an incremental step in the direction of…

> The authors repeatedly note the widespread inadequacies of the current research landscape.

This is standard language in academic research papers. It is there to sell the importance of the research to the reader, in particular to journal editors or peers who review the article. It is mere puffery.

Re: What distinguishes great software engineers? (2019) [pdf]

#36

Earlier quoted context omitted.

But then, you still have to connect all these 3-weeks-pieces together. And how long does that take? No we are back to the original, overall question...

The idea was that the three week pieces add up to the whole of the larger task. (Yeah, I know - only if you didn't miss anything. Take the time to think it through well enough that you don't do that. And what if you have things you don't know? Then you have to do a research project to find them out before you can give valid estimates .)

"And what if you have things you don't know?" I usually find stuff out in the middle of work - a question comes up I don't have an answer for, and many times, no one else does either. In effect, no one can estimate it, but we didn't even know that up front. And... I've often hit things where the time to give an 'accurate' estimate takes more time than the actual work effort. Is that common in your "limit everything to 3 weeks" world?

Re: What distinguishes great software engineers? (2019) [pdf]

#37
post #6

Earlier quoted context omitted.

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

Interesting take, mind sharing how do you use fibonacci ? Thanks

https://www.youtube.com/watch?v=iZYSapFCg4A

Re: What distinguishes great software engineers? (2019) [pdf]

#39
post #9

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

I recommend reading that Norris Number article. It is very interesting in terms of describing walls you hit at various code sizes, and it matches my experience. I've been thinking in similar ways, although in "complexity" rather than lines of code.

I think the whole "10×" programmer debate makes more sense when considered in context of Norris Numbers. If the task is on one side of the complexity wall, both programmers perform roughly the same. But if the task is on the other side, one programmer will flounder around while the other will succeed, resulting in the fabled 10× performance.

Re: What distinguishes great software engineers? (2019) [pdf]

#40
post #3

Can'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 usuall…

What is your take on the DevOps DORA research? From what I could tell of the explanations of methodology in Accelerate (as well as Jez Humble and/or Nicole Forsgren talking about it) they seem to do relatively solid survey-based work.
Post reply on HN