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

91–100 of 174 posts

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

#91

Post by legulere »

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…

I think a lot is also circumstances. If there is too much pressure from outside even the best engineers cannot do great work.

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

#93

Post by [deleted] »

bdowling wrote: post #35
brentsch wrote: post #22

Earlier quoted context omitted.

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.

[deleted]

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

#94

Post by renewiltord »

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 driving 90 mph on I-280 and I laughed out loud.

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. Some people really do operate at a heck of a limit.

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

#95

Post by bottled_poe »

wrnr wrote: post #89
bottled_poe wrote: post #86

Earlier quoted context omitted.

> Great software engineers I've known seem to have complete command of all of the ideas, tools, and techniques. They understand their tools "all the way down to the metal" and all the way "up to the esthetics". You can see great people in all crafts (like woodworking). Do people like this exist today? I mean, the complexity at every level in the stack seems to have grown exponentially(maybe?) for decades. Are there e…

You make a mockery of the original statement, if you focus on YOUR stack (not just any) then yes with a bit of focus it should be possible, but you need to stop learning yet another JS framework.

I ain't mockin nuffin.

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

#96

Post by eeZah7Ux »

alacombe wrote: post #47
jackblemming wrote: post #19

Imo great engineers produce a lot of good to great quality work fast. They care about the big picture and get involved with the actual domain they're working in. They see code reuse opportunities and friction company wide vs only whatever team they're on. Great software engineers will write tools, packages, and guidelines that the entire company can use- not just their small team. They know how to standup to manageme…

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

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

#97

Post by ZephyrBlu »

TrackerFF wrote: post #69

A bit OT - but...I find it a bit interesting, even fascinating, how people in the field of software seem to absolutely obsess over greatness in individual engineers. You see this is in many shapes and forms - whether it's a discussion what makes one a true "10x" engineer, what lifestyle habits will result in excellent engineers, what personality traits to look after when searching for world-class software engineers.…

I think it might be related to the leverage Software Engineers have compared to people in other fields.

It's possible for a single Software Engineer to stand up an entire system by themselves. Most other fields don't have anywhere near that amount of leverage.

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

#98

Post by eeZah7Ux »

slumdev wrote: post #5
bart3r wrote: post #2

I'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.

Agile exists to micromanage people.

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

#99

Post by brigandish »

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…

> Bill stopped what he was doing, fetched the sources for emacs (using ftp), found the source of the bug, fixed it, and sent off a patch.

That would be far more difficult if the source code was in a poor state. Some libraries are easier to patch than others, I can think of a couple of libraries I've wanted to quickly patch and soon (not soon enough) realised that it's unpatchable because it's a mess (or perhaps even worse, is too clever by half and has far too much indirection and not enough comments) and would need extensive surgery.

That's not to diminish the strength of your story about Bill Schelter but only to point out that it's easier to do your best work if others are doing theirs.

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

#100

Post by blackbrokkoli »

TrackerFF wrote: post #69

A bit OT - but...I find it a bit interesting, even fascinating, how people in the field of software seem to absolutely obsess over greatness in individual engineers. You see this is in many shapes and forms - whether it's a discussion what makes one a true "10x" engineer, what lifestyle habits will result in excellent engineers, what personality traits to look after when searching for world-class software engineers.…

I think it's because measurement, metrics and estimates are so hard in software engineering.

How long should it take to do X? If X is building a shelf, servicing a power plant or designing a car headlight I would imagine at least within the field the order of magnitude is pretty clear. Sure, better tools and experience may make someone twice or thrice as fast or the new guy is taking double the normal time, but such spans fit neatly into the human brain.

But now observe how neither of these statements seem off:

Getting my new web-based CRM tool written and published took me the whole afternoon.

Getting the new web-based CRM tool written and published took us 24 months.

Now add to that the fact that nobody really understands software top-to-bottom (or at all) and it is no surprise that everyone is confused all the time, builds weird mental models of things and skills while vaguely striving to achieve the first scenario and not the second.

Post reply on HN