What distinguishes great software engineers? (2019) [pdf] • Hacker News Board

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

#151

Post by myth_drannon » Mon, Nov 16, 2020, 4:01 PM UTC

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.

The thing is that even if you stick with one framework it changes. ReactJS/Redux is different from what it was 4 years ago.

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

#152

Post by roboyoshi » Mon, Nov 16, 2020, 4:22 PM UTC

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…

from [1] > people always wind up extrapolating sort of unacceptably where people think oh I worked 18-hour days or something and I have to say no I never worked 18-hour days because I know my productivity falls off a cliff after 13 hours I'm you know that's about the longest that I can do any effective kind of computer work and the key to even being able to get an effective 13 hours is having multiple tasks that you can switch between rather than just kind of sitting heads down grinding beating your head against one specific topic but I'm you know I've been for most of my career now I like working a 60-hour workweek I like being productive I you know nowadays I have I have family and kids and I don't I usually miss that Target by a bit now but I if I ever don't hit 50 hours a week I feel I'm being a slacker

[1] https://podscribe.app/feeds/http-joeroganexpjoeroganlibsynpr...

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

#153

Post by [deleted] » Mon, Nov 16, 2020, 4:32 PM UTC

watwut wrote: post #112

wildermuthn wrote: post #73

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.

[deleted]

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

#154

Post by dekhn » Mon, Nov 16, 2020, 4:32 PM UTC

Ygor wrote: post #110

wildermuthn wrote: post #73

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…

https://en.wikipedia.org/wiki/Citigroup_Center#Engineering_c...

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

#155

Post by bluedino » Mon, Nov 16, 2020, 4:34 PM UTC

cortesoft wrote: post #59

kevindeasis wrote: post #41

Question for everyone. Doesn't everyone know in the industry what makes great software engineers? And that usually there are only "blockers" that stops you from being great? Let me give an analogy. If you're paid to play basketball wouldn't you know what makes a great basketball player? If you're playing pro basketball, you can be a great basketball player. The only reason why you can;t be great is because there are…

People always seem to want to pretend it isn't a factor, but natural talent also matters, for both basketball and software engineering. 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…

>> In basketball, it is quite easy to prove that some people are simply unable to ever be a great basketball player

There's a simple cure for this: Height classes

You can still be a GREAT basketball player if you were only 5 foot 6 inches tall. Is the best 5'-6" basketball player in the world, not great? They just can't compete against the physically taller players. What if you made a league exclusively for players in between 5 and 6 feet tall?

Floyd Mayweather is a great boxer. But if there weren't weight classes in boxing, and you put him in the ring with some journeyman heavyweight, he'd lose. He's just too small to win.

It's the same thing.

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

#156

Post by hyperpallium2 » Mon, Nov 16, 2020, 5:13 PM UTC

(skimming intro & conc) reads like a joke paper:

- their top characteristic is "writing good code"

- they censored the specific VCS

- they describe their insights as (inter alia) "ecologically valid"

----

This is HN, so... I'd approach the title as "when is x10 possible?"

- insight of a far simpler or faster etc implementation (e.g. better choice of modularity, factoring out hidden commonality, dynamic programming);

- insight about a better way to achieve the end result - might be no code at all

So I'm talking about insight. What personal qualities lead to insight? (note that there isn't always a better way to be found, so personal qualities don't guarantee it)

- be really really smart. Especially, large working memory, to be able to see connections. Or at least be able to load in (cram) the information temporarily.

- the ability to step back and notice the bigger picture. Executive function.

- ability to manage stress, so they have the breathing space to do that (the wisest engineers will choose a workplace that makes this easier)

Skill in proofs is a predictor: flexibility, handling complexity, managing the top-level purpose as well as the detail (forest-for-trees), noticing connections. Mathematical knowledge itself can help sometimes too.

But probably the skill in any intellectual discipline is an equally good predicator e.g. philosophy, history, law

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

#157

Post by galoisgirl » Mon, Nov 16, 2020, 5:16 PM UTC

vbezhenar wrote: post #78

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 encounter so many bugs nowadays in my tools. I would probably spend all my time fixing those bugs in multi-million-LoC codebases (assuming that tool is open source). That story sounds like something that could happen back in the day, when things were simple enough. I wonder if it could happen today.

Documenting bugs is providing a lot of value already.

It would be also inefficient for you to spend time learning how the tool works, setting up the environment etc. when there are people who know it already.

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

#158

Post by galoisgirl » Mon, Nov 16, 2020, 5:17 PM UTC

js8 wrote: post #107

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…

Personally, I think it's two things - working hard and lack of fear/anxiety. In your example, this Emacs bug fixing, there is a lot of people who work hard but would just think that the bug is probably difficult to fix (they would fear of it taking too long to do) and decide not to do it. I know personally how much anxiety can block you from doing things that help you progress. It also makes decision-making slower. I…

Courage is not the lack of fear, but the conviction that something else is more important than fear.

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

#159

Post by cortesoft » Mon, Nov 16, 2020, 5:19 PM UTC

maccard wrote: post #147

cortesoft wrote: post #144

Earlier quoted context omitted.

I think you are underestimating the struggles he would have against even a decent 6 foot player.... you could block his shot from 10 feet away.

We can argue semantics about how great is great, but you can pretty much guarantee that he's in the top 1% of basketball players worldwide. That's pretty great.

If you are saying he would be top 1% in the general population, sure, but I don't think you can define that as great. If you are saying top 1% of people who actually play basketball regularly, I think you are wrong... he isn't going to be better than any one who plays highschool level or better, and will be average at best on an adult rec-league team.

I would certainly not call someone who is only top 1% in of the general population great... 1% of the world's population is 70 million people... there are an estimated 27 million or so software developers, so more than half of the top 1% of software developers in the world don't even write software. I would hardly call them great.

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

#160

Post by AnimalMuppet » Mon, Nov 16, 2020, 5:24 PM UTC

mgkimsal wrote: post #36

AnimalMuppet wrote: post #34

Earlier quoted context omitted.

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…

If the time to give a more accurate estimate takes more time than the actual work, you aren't dealing with an estimate longer than three weeks. If the estimate is less than a day, it's not worth getting more precise.

To your first point: Yes, that happens sometimes. When it does, your estimates can be wrong. (Hey, they're estimates - they're not prophecies.) If that happens very often, though, you might add a fudge factor for "that kind of thing". Maybe something like "unknown surprises crop up most of the time, and when they do, they take about 20% of the effort, so we'll make our best estimate, then add 20%". That won't be perfect either - sometimes it will be 40%, and sometimes 0. But, you know, estimates...