Live data from Hacker News

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

faculty.washington.edu

131–140 of 174 posts

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

#131
post #110

It’s interesting there are so many different answers given to this question whenever it is asked. If we asked, “What makes a good surgeon?” or as pointed out in another comment, “What makes for a great basketball player?” it seems that there would be less debate. It seems to me that this debate is related to another question, “Why do so many software projects fail when you don’t see any skyscrapers collapsing under t…

"Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?" I think this is a great question to use as a thought exercise. We don't see the designs that fail, as they don't pass the review? Using the analogy of software engineering being the design stage (vs build/construction stage), this would be a closer comparison. How many skyscraper designs fail before they end…

watch engineering disasters or extreme engineering and you will find a discipline that has failed and learned from mistakes for hundreds of years.

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

#132

Earlier quoted context omitted.

First, allotting an amount of time to delivering value is an anti-pattern in itself. Second, Agile doesn't ask people to estimate ("respond to change over follow a plan"). Management asks people to estimate. Jeff Patton says it best in User Story Mapping, the "client-vendor anti-pattern" > It's the client's job to know what he wants, and explain the details to the vendor. It's the vendor's job to listen, understand,…

> Second, Agile doesn't ask people to estimate ("respond to change over follow a plan"). Management asks people to estimate. I think it would be more accurate to say that those who pay for your time will ask you to estimate on the value which you expect to deliver in said time. That seems like a fair question to me.

This is ipso facto, but like all creative work, they should prefer to pay you for your work product.

And I could write a book on it here (several others have!), but I think your comment points at the heart of this entire problem, namely the disconnect between the work being done and "those who pay you."

If they were truly invested in the value fulfillment cycle, they would never ask for an estimate, they would be clear about what hill they needed to be taken next in service of the product or customer (i.e. "here's where it hurts, doctor") and then help you agree on the smallest possible experiment to take the hill.

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

#133

Earlier quoted context omitted.

People in general are terrible at predicting the future... I don't think being clairvoyant is a quality that should be expected out of an engineer or anybody. This whole time estimation thing is akin to predicting when the next hurricane or earthquake will occur. The main problem is business people don't understand that so they place this unrealistic burden on engineers. A manager or business guy who needs constant a…

> This whole time estimation thing is akin to predicting when the next hurricane or earthquake will occur. This myth needs to die. Can you predict if an item will take closer to a month or a decade? If true then it is far easier to predict than hurricanes or earthquakes. You might not make predictions as accurate as management wants all the time, but most can predict how long things will take within a factor of 3x or…

>This myth needs to die.

Let me spell it out in an example. Sports. Horse racing or basketball. You have a team of highly skilled players with a bunch of information quantized, including height, weight, score statistics, rebound statistics, biography... etc. And these guys are in a game with a very very controlled set of rules under exactly the same time pressure and everyone still fails to predict the outcome.

In software you have a product. The product is usually not concretely defined and you have a complex code base and you can never be 100% sure exactly how the new product will integrate with that code base... you're also not 100% sure how the code will be put together to define the product. Additionally are you 100% familiar with the stack? Do you know every possible primitive of psql or ruby or python or C++ that you could be using to create your project because I pretty much guarantee you every basketball player more or less knows every possible move and rule of a basketball game.

You're also working with a team that includes people that you have much less information on than normal. You worked with a guy for what at most two years does that give you accurate statistical information to the degree of say a basketball player? Also there's bound to be people you're less familiar with working on the project as well. Are you interacting with other teams as well? Does the outcome of your project hinge on the completion of a feature by an entire team outside of your own?

People can be experts on horse races or sports. Even then they can't predict things accurately. If you were to start making bets on software development dates of completion. You will also massively fail because not only are there more variables in a software project... but you have much less information.

Chaos is a phenomenon that happens to systems we have close to perfect information for. We find that if we have the perfect information of all the particles in a weather system except for say one particle. We find that information about that missing particle will make our mathematical calculation wildly inaccurate.

For software we don't even have anything close to perfect information in a system with multitudes of variables. Chaos will throw any prediction off.

>but most can predict how long things will take within a factor of 3x or so and it will be within that margin most of the time, a person who could do that for hurricanes or earthquakes would be the greatest genius in history.

3x of what. 3x can be big or small depending on x. So if I predict a project will take one year I can be off by 3 years under your logic. If I predict a month, than I can be off by 3 months. If I predict a week, 3 weeks. 3x is pretty horrible if you ask me, it's easy to make guesses within these parameters.

I predict that both a hurricane and an earthquake will happen in a century. I'll only be off by 3x or 3 centuries. Actually I can do better than that. I'm 100% sure multiple earthquakes and multiple hurricanes will happen in the next century and I am 100% sure that I will by 0x off let alone 3x.... Look I'm the greatest genius in history.

3x is not a reasonable margin of error.

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

#134
post #130

Earlier quoted context omitted.

> In basketball, it is quite easy to prove that some people are simply unable to ever be a great basketball player; there has never been an NBA player shorter than 5'3, only 25 shorter than 6'0, and only 10 under 5'10. Are you really telling me NO ONE shorter than 5'3 ever decided the trade offs were worth it? Anecdotal, I'm 6'1. At a middle school age, I was _hounded_ into playing basketball (until they realised I h…

> Anecdotal, I'm 6'1. At a middle school age, I was _hounded_ into playing basketball (until they realised I had no talent whatsoever, or any inkling that I wanted to attempt to improve that). There's definitely a selection bias in who gets started playing basketball in the first place. This has had a bigger impact than you'd imagine :-) For example quite a few tall football players have been nudged when they were ki…

> genes do matter at a certain level.

And the only example that has been given is that someone who is legally considered disabled cannot compete in the top 0.01% of professional sports. I had a bit of a search, and Jahmani Swanson [0] is 4'5, and would absolutely wreck pretty much every single non-NBA basketball player you would ever meet in your life (I am aware that the team are an exhibitionist team, and not an NBA team). I'm sure there are hundreds of other examples of people who won't be able to compete at the top 0.01% of the activity in question, but are unquestionably "great".

[0] https://www.youtube.com/watch?v=ARERrH52BGo

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

#135
post #112

It’s interesting there are so many different answers given to this question whenever it is asked. If we asked, “What makes a good surgeon?” or as pointed out in another comment, “What makes for a great basketball player?” it seems that there would be less debate. It seems to me that this debate is related to another question, “Why do so many software projects fail when you don’t see any skyscrapers collapsing under t…

> "Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?" The massive amount of regulation surrounding skyscrapers building. Including legal responsibility.

Yep. In our cowering space, a fire marshal comes by to make inspections. If we're not up to snuff, we'll get closed down. I can not imagine too many software projects where people will submit to random audits and accept total shutdown if they don't meet specific criteria.

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

#136

Earlier quoted context omitted.

> This whole time estimation thing is akin to predicting when the next hurricane or earthquake will occur. This myth needs to die. Can you predict if an item will take closer to a month or a decade? If true then it is far easier to predict than hurricanes or earthquakes. You might not make predictions as accurate as management wants all the time, but most can predict how long things will take within a factor of 3x or…

>This myth needs to die. Let me spell it out in an example. Sports. Horse racing or basketball. You have a team of highly skilled players with a bunch of information quantized, including height, weight, score statistics, rebound statistics, biography... etc. And these guys are in a game with a very very controlled set of rules under exactly the same time pressure and everyone still fails to predict the outcome. In so…

Thanks for this, I'm going to use the sports analogy in the (near) future the next time I discuss this with anyone.

It's all politics. Estimation is a purely political game by EMs/TPMs/PMs to try and shirk responsibility for engineering outcomes.

Here's another neat tack to try in this conversation. Ask for individual examples of "good estimators," and ask for details about what makes them good estimators. You'll rarely (if ever) hear that someone was so accurate that it materially impacted a project in a positive way. What would that even look like? "I was sooo accurate that the client success people were able to say that our new product would be ready 6 months ago, and now didn't have to send a follow up email to update the timeline!!!" The only answers I've gotten are that people who are good at estimating are the ones where nobody ever really has to look at their schedule and there is no drama because they are always getting things done. This is highly contextual and rarely has to do with that person's individual estimating skill. It has to do with their project, team, EM, PM, experience relative to teammates, etc. Recently I was given an example of a client-side developer who is far more experienced than the back-end guy building his API, so he's always just sitting around waiting for the API to be finished to build his features. He almost always does 3/4 of his tasks ahead of time and then just waits for the API to be done and puts his ticket in as completed at that point. So he's not really estimating at all, and he's not accurate, it's just that the project is bottle-necked on the back-end dev speed regardless, so nobody ever cares about his estimates.

It all just seems so wishy-washy and bullshit. It's just about pushing people to work hard and get more done ("you need to hit your estimates, think of them like commitments!"). Framing this all as somehow single-handedly the engineer's problem is just a sign of someone who doesn't know how to operate a software development team effectively. Estimation is a team effort in scheduling, delegation, planning, and communication.

Why in the world (if not politics) would anyone invent a concept where it punishes someone who over-achieves and chooses to work harder for a short period of time? ("you should try to be more accurate about estimates, even if you have to slow down your work, and over working like this leads straight to burn out, be careful!) It's all just nonsense invented by MBAs who have no actual experience in anything except inane "policy" and "oversight."

Software project estimation is a real thing, but it has nothing to do with one person's ability to predict the future. It's an analytical data methodology far more than an individual, experiential skill.

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

#137
post #6

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

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

[deleted]

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

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

Story points were made up to keep project managers happy so that they leave the team alone.

This is a good indicator of how much time you should spend estimating.

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

#139

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

[deleted]

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

#140
post #130

Earlier quoted context omitted.

> Anecdotal, I'm 6'1. At a middle school age, I was _hounded_ into playing basketball (until they realised I had no talent whatsoever, or any inkling that I wanted to attempt to improve that). There's definitely a selection bias in who gets started playing basketball in the first place. This has had a bigger impact than you'd imagine :-) For example quite a few tall football players have been nudged when they were ki…

> genes do matter at a certain level. And the only example that has been given is that someone who is legally considered disabled cannot compete in the top 0.01% of professional sports. I had a bit of a search, and Jahmani Swanson [0] is 4'5, and would absolutely wreck pretty much every single non-NBA basketball player you would ever meet in your life (I am aware that the team are an exhibitionist team, and not an NB…

Someone 1m 50 is considered disabled? Why? How?
Post reply on HN