Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

faculty.washington.edu

Post reply on HN
Print view View original

161–170 of 174 posts

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

#161

Post by idolaspecus »

hvidgaard wrote: post #121
idolaspecus wrote: post #61

Earlier quoted context omitted.

I appreciated the first 90% of your comment, and consider the picture of greatness you painted therein something to aspire to. Deep thoughtfulness, personal responsibility, craftsmanship, and virtuosity are all traits I hope to one day embody. But as a matter of argumentation the last line is simply discordant, it does not follow from the anecdote (beyond the obvious fact that the anecdote is anecdotal). In my experi…

Isn't that what "Greatness is a property of the person" is saying?

It definitely could be the case that my last point and GP's last point overlap to some extent. I read it (with the sentence before it) more as a claim that certain characteristics aren't factors when it comes to "greatness".

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

#162

Post by suyash »

eeZah7Ux wrote: post #96
alacombe wrote: post #47

Earlier quoted context omitted.

> Imo great engineers produce a lot of good to great quality work fast Sounds awfully like the Myth of the 10x Engineer .

Indeed, "a lot of good to great quality work fast" smells a bit of "SLOC per day" count. "SLOC per day" is the opposite of productivity: terrible developers can produce tons of bloated and unnecessary code.

+1 - Lines of Code mean very little, I'd rather see the impact that work produces.

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

#164

Post by andrekandre »

kthejoker2 wrote: post #132
bottled_poe wrote: post #81

Earlier quoted context omitted.

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

> and then help you agree on the smallest possible experiment to take the hill.

in most corporate environments, that wont cut it though... what management wants, and product owners are preassured to deliver, are large wins and overal product milestones, not incremental updates (outside or bug fixes)

> the disconnect between the work being done and "those who pay you."

yes, i think in many places, there is a fundamental tension between the "corporate thinking" and "agile thinking" and without real syncronization of methodologies and culture, any kind of "buy in from management" will usually lead to dysfunction and overall dissapointment

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

#165

Post by groby_b »

kthejoker2 wrote: post #21
groby_b wrote: post #7

Earlier quoted context omitted.

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…

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

Pretty much all existing incarnations of agile have a planning meeting. And an entire edifice around managing longer-term planning. (Stories. Epics. Sagas)

Sure, we can true-scotsman, but in practice agile asks you to estimate.

In the client-vendor context, you can sidestep that with a fixed price bid. Somewhat. If you're bad at estimating your fixed price, your business will burn.

In the employee context you can sidestep that somewhat as long as you consistently deliver more value than you cost, but even then, making choices requires having an idea of opportunity cost. If you can't give that idea at all, there are usually better uses of the money.

In almost all contexts, you are compensated for your time. Almost no one likes writing blank checks.

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

#166

Post by mgkimsal »

mgkimsal wrote: post #135
watwut wrote: post #112

Earlier quoted context omitted.

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

coworking space...

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

#167

Post by Viliam1234 »

renewiltord wrote: post #94
renewiltord wrote: post #45

I think if you follow John Carmack's finger files and his Twitter account you can form your own opinion as to how it works. That guy is clearly a top 10 engineer and he hides little about his thought process. His appearance on the Joe Rogan Experience was great too.

As an aside, in his appearance on JRE, there's one part where Joe Rogan asks him about working hard and JC says something like (going off memory) "I don't really like that idea - of working really hard being the thing. Personally, I've noticed that after a while the quality of my work really drops off. Around 13 hours in I'm not really doing a good job". I remember the moment because I was listening to this while dri…

> Personally, it reminded me of how people say "it's not a sprint, it's a marathon". Yeah, but Haile Gebreselassie runs the marathon at an average of 20 km/h.

He is so agile he can run the marathon as a sequence of sprints. I wonder if software developers will be expected to do the same.

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

#168

Post by gwittel »

lolive wrote: post #29

The more experienced I get, the more doubtful I am about every code. In the end I will be an ermit on a mountain imagining a code base that does not evolve into a monstrous mess. Honestly, I envy the young Mavericks who code shit and get work done. They at least sleep at night.

> Honestly, I envy the young Mavericks who code shit and get work done. They at least sleep at night.

Ignoring the burden shifting of on call rotations, I often find the young mavericks don't sleep at night -- they're fire fighting and debugging their work.

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

#169

Post by abiogenesis »

jackblemming wrote: post #70
abiogenesis wrote: post #67

Earlier quoted context omitted.

It can be that high. It's not the number of lines of code produced but the value/utility created. A great engineer can actually make the same product in X days where it takes an average developer 10X days to come up with the same. The better engineer might (and in most cases, would) have written less code.

Yes it can be that high depending on _how you're measuring_. I think this is why the myth has gone on for a long time. It also greatly depends on who you're comparing. Are you comparing Peter Norvig to a 1st year undergraduate, or someone on Peter's team who has around the same experience and skillset? But I don't want to derail the thread ;)

Fair enough, but the problem is you can't always find a team full of people "who has around the same experience and skillset as Peter Norvig".

That's basically what "The Mythical Man-Month" (the origin of the 10x developer) says: "Always recruit star programmers if you can, but most of the time you can't. Therefore learn how to best utilise the average ones."

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

#170

Post by tacitusarc »

vorhemus wrote: post #115
daly wrote: post #46

In 50 years of programming I've worked with a few. One characteristic is a deep understanding and command of all that they touch. For example, I worked with Bill Schelter (GNU Common Lisp). In 1980, prior to the Internet, we were working on a problem (tail recursion). He was using the emacs editor and he found a bug. Bill stopped what he was doing, fetched the sources for emacs (using ftp), found the source of the bu…

The variety of tools that many software engineers work with today is so large that I find it virtually impossible to fully master them. Let's say a software engineer writes a C++ application that stores documents in an inverted index and he also takes care that the program is stored in a docker container and deployed to Elastic Kubernetes Service via Jenkins. Good luck understanding your IDE, C++, Tries/Radix trees,…

After a few years focused on those areas, with a solid understanding of computers and software as a foundation, it may even be possible for many engineers. The issue is the tech landscape shifts so quickly that you probably won't be using that exact stack in just a couple years. Swap jenkins with gitlab ci, docker with podman, c++ with golang. Functionality is still pretty close, but implementation details are different. And the road to mastering them is reset.
Post reply on HN