30 ms·

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

305 points by 7d7n 6y ago

bart3r 6y ago
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.
- AnimalMuppet 6y ago
  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. (I believe this shorter-than-three-weeks idea came from Extreme Programming, but I'm not quite certain of that.)
  - __alias 6y ago
    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
    - BOOSTERHIDROGEN 6y ago
      Interesting take, mind sharing how do you use fibonacci ? Thanks
      - bart3r 6y ago
        https://www.youtube.com/watch?v=iZYSapFCg4A https://www.youtube.com/watch?v=iZYSapFCg4A
      - redis_mlc 6y ago
        0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610 Hope (Days) = Calculated Est. (Hours) 1 day = 8 hours 2 days = 8 + 13 = 21 hours 3 days = 8 + 13 + 21 = 34 hours H(days) = Fn(6+days) hours, where days >= 2
      - mgkimsal 6y ago
        Not the OP, but one of the teams I'm on uses fib somewhat differently. Any point with 1-2 is estimated at < 1 day. Some are literally 20 minute fixes, but ... you don't always know that up front, you just generally know it may be pretty small. 2 might sometimes go up to a day. A 3 is assumed to be a day or two. A 5 is assumed to be 3-4 days. An 8 would be 1-2 weeks. Anything higher is backlogged until it's broken down into smaller segments. Not sure how well that compares to usages by other teams, but that's one data point for your question.
    - deleted 6y ago
      [deleted]
  - valenterry 6y ago
    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...
    - AnimalMuppet 6y ago
      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.)
      - mgkimsal 6y ago
        "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?
        deleted 6y ago
        [deleted]
        AnimalMuppet 6y ago
        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...
- slumdev 6y ago
  > 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.
  - groby_b 6y ago
    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 isn't fixed - so frequent estimates with frequent course correction. But you're still estimating.
    - deleted 6y ago
      [deleted]
    - Fire-Dragon-DoL 6y ago
      This is the definition of Agile, the officiak one: https://agilemanifesto.org/ https://agilemanifesto.org/
    - kthejoker2 6y ago
      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, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate - which in software lingo actually means "commitment" .. > The real tragedy is the client understands their problem better than she's able to predict what will solve it. But in the anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins. > Try showing up at your doctor's office and giving her your "requirements". Tell her the prescriptions you'd like written and the operations you'd like scheduled. If she's nice, she'll smile and say, "That's interesting, tell me where it hurts." > In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships more like doctor-patient and less like waiter-diner.
- Geminidog 6y ago
  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 and very accurate time predictions is a sign of a bad manager that is overly reliant on engineers and lacks understanding of software. A good manager should have the technical knowledge to make a technical guesstimate himself (that will also likely be wrong) and have the foresight to be able to manage delays and allow for buffer time. A great team of people creating a product consists of both great Technical product managers and great software engineers. A rockstar software Engineer alone may not have the ability to manage the politics of unrealistic expectations.
  - username90 6y ago
    > 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 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. And yes as you get more skilled your predictions will become more accurate. Hence accurate predictions being a sign of skill.
    - Geminidog 6y ago
      >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.
Kranar 6y ago
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 employee is going to say something like "Lazy liars who treat people like crap make great software engineers." At the very least you'd expect a study to have a control group in order to filter out these useless questions. For example send a similarly worded survey to a group of grocery cashiers and ask them if they think attributes such as "Hard work, honesty, integrity, long term thinking, being a team player." make someone a great engineer. My hypothesis is you'd end up getting similar answers from taxi drivers as you would from Microsoft employees and consequently that there isn't much value derived from this survey or their selection of participants. Anyways, I'm by no means an expert and could be misjudging this research but frankly it looks to be beyond useless.
- glushkov 6y ago
  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 usually glorified position papers under the guise of an empirical study.
  - kqr 6y ago
    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.
- brentsch 6y ago
  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 a truly detailed understanding of the factors involved in developer productivity. Even if there's a broad intersection between the answers one would get from taxi drivers and from computer scientists, the distance between the two fields makes that an unexpected result, which should prompt us to change how we think about computer science* and/or how we think about studying it. *or cab driving
hn_throwaway_99 6y ago
OK, so I admit I just started with the abstract, but the first item listed is "writing good code". Umm, I would hope that is kinda part of the definition? I was actually looking for some valuable insight (e.g. how are great software engineers able to consistently write good code) but I didn't see it in this report.
calcsam 6y ago
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.html https://www.teamten.com/lawrence/writings/norris-numbers.htm...
- kens 6y ago
  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.
m1117 6y ago
A good engineer will prob write some code instead of reading this nonsense
- balls187 6y ago
  Sure, but this is about great engineers.
nanoscopic 6y ago
Great software engineers know not to create PDFs when HTML works fine.
- ineedasername 6y ago
  But the ones who prize job security over all else will make their code as obscure as possible.
- nanoscopic 6y ago
  You guys can't take a joke can you? You should read the rules for why or why not to downvote stuff. This sort of "not what I personally want" nonsense is not what the feature is for. This is exactly why I barely ever post or comment because of the massive "downvote squad" that is hacker news regulars.
- MattGaiser 6y ago
  Given that it is presumably part of a journal, I am not sure that HTML would have worked fine. The purpose was to publish in one of those. We are a secondary audience.
  - bottled_poe 6y ago
    Woah woah woah, what is this? Requirements analysis?
  - blackbrokkoli 6y ago
    Great excuse. If your research is so important, maybe let blind people read it?
Subsentient 6y ago
Well I guess that makes me about average. I'm generally liked where I end up working, but tend to just do stuff on my own. I'm polite, but don't go out of my way to interact with others typically. I do check the boxes on the code quality stuff however, especially writing code that plans for the future.
jackblemming 6y ago
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 management and produce quality work that users actually want.
- alacombe 6y ago
  > Imo great engineers produce a lot of good to great quality work fast Sounds awfully like the Myth of the 10x Engineer.
  - jackblemming 6y ago
    Not quite that high, but you'd be silly to believe there's no difference in speed at all.
    - abiogenesis 6y ago
      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.
      - jackblemming 6y ago
        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 ;)
        6y ago
known 6y ago
"You are a product of your environment" --Clement Stone (b. 1902) The Pygmalion effect, or Rosenthal effect, is a psychological phenomenon wherein high expectations lead to improved performance in a given area https://en.wikipedia.org/wiki/Pygmalion_effect https://en.wikipedia.org/wiki/Pygmalion_effect
valenterry 6y ago
Great software engineers create/build software only as a last resort, once all other options have been exhausted. :)
- lolive 6y ago
  And they can feel in their flesh the entropy increase of each of their commits.
- quickthrower2 6y ago
  This reminds me of the saying about don't expect someone to do something when their paycheck depends on doing the opposite. That said yes a great software engineer would be writing software BUT would have said no to a lot of other tasks, so that the task she is working on is vital and has a big impact.
- username90 6y ago
  No they don't, writing new code is often cleaner and simpler than adding a library. Exactly when to do either is arguable, and picking the right choice requires skill. So always going the library route when possible means you aren't a great software engineer.
  - valenterry 6y ago
    Please read my post again. What I said comes way before the kind of decision that you mentioned.
    - username90 6y ago
      What you said includes the decision I mentioned.
      - valenterry 6y ago
        Hm, I don't know where you got this idea from... I certainly didn't mean it like that.
ketzo 6y ago
> 1. Introduction > “At the end of the day, to make changes [to software], it still takes a developer, a butt in a seat somewhere, to type [Source Control System] commit. — Dev Manager” Not entirely relevant, but this opening comment just struck me as funny.
lolive 6y ago
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.
- nevertoolate 6y ago
  On the contrary. Who are young still work through the night. If work keeps you up it means that you can’t make trade-offs quite well enough.
- gwittel 6y ago
  > 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.
  - lolive 6y ago
    As a freelancer, I am usually hired 3 months before the delivery of the product to help them firefighting. In the end, juniore don't deal with the real issues in their code. We, senior developpers, do. Note: after a stroke of lucidity, I stopped accepting those kind of missions.
ketzo 6y ago
Weird to me how down these comments are on what I read as the main message of the paper, i.e. that engineers aren’t just code monkeys. Being a “great engineer” is not strictly determined by technical ability; in fact, social ability plays a big role in a so-called “individual contributor role.”
- username90 6y ago
  What is even a code monkey? A coder takes a problem described in human language and solves it using computer code. In order to do this well you need to both be able to properly read and understand problems in human language and be able to write and structure code. There is no world where you can write code without thinking about the hard stuff, at least not if you write something more complex than a basic static frontend webpage.
  - luisehk 6y ago
    I think the term has negative connotations because of people who build the wrong thing before asking critical questions or clarifying anything that would help shape the requirements. I understand some people enjoy being just implementers, though. I don't think that's enough but to each their own.
tschellenbach 6y ago
There's only 1 rule: Shipping code that delivers value to users.
- suyash 6y ago
  that's a nice one to remember!
probinso 6y ago
and here I always thought the answer was Adderall
- nullsense 6y ago
  Plot twist: it's not the Adderall, but actually the ADHD. The engineers with an interest-based nervous system who have trouble switching off and hyperfocus on their latest interest staying up coding all night tend to learn a lot of shit faster than their peers because they simply spend more aggregate time doing it. Source: ADHD engineer. I don't actually take Adderall. Tried Ritalin briefly but stopped as it doesn't affect me at all. Might try Adderall and report back.
kevindeasis 6y ago
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 certain things outside of playing basketball that you have to worry about. I guess i'm asking cause it's kinda annoying when people tell me what makes a great engineer. Anyone I know who has been doing this a few years knows what makes a great engineer. It doesn't mean they want to be a great engineer because the trade-offs arent just worth it
- BeetleB 6y ago
  No, they do not. There isn't even a consensus on what "great" means. You play basketball in a very static environment. The rules don't change from game to game, or team to team. The duration of a match is constant. How well the team performs is a well known metric. People do not do engineering in a static environment. The needs asked of one changes from team to team. The quality metrics vary from application to application. The people he/she relies on varies even when you stay in the same team. An engineer who is really useful in one company may be harmful to another one.
  - llimllib 6y ago
    I suspect you haven’t played much basketball! The same player on different teams can be much better or worse - some players fit in with almost any team and others need a team built around them. (I don’t disagree with your larger point! Just that basketball is an example of a “very static environment“ relative to programming)
  - cortesoft 6y ago
    > You play basketball in a very static environment I would strongly disagree - basketball is a highly dynamic environment, simply because you have an opponent. Everything you are trying to do, you have someone else trying to stop you. They are as adaptive as you are. Because of this dynamism, many players who were great in previous eras couldn't survive in the modern era (and vice versa, really)... for example, most centers who played even 10 years ago would be abused in the modern game by opposing centers shooting threes. It simply wasn't part of the game 10 years ago, and now everyone does it. There was literally a player (Roy Hibbert) during the transition who was a star before and suddenly became unplayable as teams adapted to the new environment. He was out of the league in 2 years.
Rapzid 6y ago
The word "retirement" doesn't appear in this document.
renewiltord 6y ago
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.
- renewiltord 6y ago
  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.
  - w0utert 6y ago
    This rings close to home for me, I'm a firm subscriber of the mantra that laziness a good quality for a software engineer to have. It has saved me many times already working on difficult/never-seen-before problems, and (conversely) not adhering to it has bitten me multiple times. Often it simply takes some time for solutions to new problems to percolate, and you need to take a step back regularly during the process. Forget about the problem completely and do something completely different, interspersed with short bursts of research and reading on related topics. Sooner or later the contours of a solution will start to form and you will (hopefully) be able to realize it much quicker and at higher quality compared to 'working hard' by pounding yourself and trying to force things. I cannot count the number of times I almost gave up on a problem after working myself into multiple dead-ends, and almost instantly seeing a path forward after taking a few steps back and allowing my brain to work itself out of these dead-ends. Not spending 1 week of 'hard work' on a bad solution can save you months of work in the future.
  - yowlingcat 6y ago
daly 6y ago
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 bug, fixed it, and sent off a patch. After that he restarted emacs and continued right where he left off. It was a virtuoso performance. It was like watching Victor Borga (https://www.youtube.com/watch?v=dKeqaDSjy98 https://www.youtube.com/watch?v=dKeqaDSjy98). I know a guy who plays guitar. He can listen to a performance and repeat it as easily as I can type what I read. He can transpose keys, add riffs, change tuning "on the fly", and even play thru with a broken string, adjusting chords to the new "5 string" form. He also knows guitar characteristics, pedal effects, etc., basically "all things guitar". 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). They also write beautiful "crafted" code. I'm keyboarding a FORTRAN punched card deck (for an historical museum). You can see from the code that the author wrote clean, careful, and clear code. You can almost feel how good he was. Greatness isn't about "team player", "hard working", "good at time estimation", or anything "social". Greatness is a property of the person, a deep love of the craft, and a focus on "doing it right".
- chokeartist 6y ago
  That was a beautiful story. Thank you for sharing.
- runawaybottle 6y ago
  Don’t confuse familiarity with greatness. Of course if you wrote the damn thing you can demonstrate technical virtuosity. Edit: Maybe I read too fast. Anyways, intuition is sort of the precursor to greatness. You know those designers that pick out colors innately? No amount of color theory studying will get you to that level. You are probably describing someone with an intuition for debugging. One of those things in life everyone has to learn eventually. Don’t fight the tide, find the waves that are certainly for you.
TrackerFF 6y ago
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. etc. Having been in many other (technical) fields outside software engineering, I've never seen the same mentality or obsession there.
- anonytrary 6y ago
  I think passion is everything. Everyone is 10x at their passion. Strive to have passion in all that you do.
  - burnthrow 6y ago
    Yes. This "greatness" is actually quite a fragile thing when one considers the mysterious origin of passion, etc. Without motivation there's nothing.
- runawaybottle 6y ago
  It’s a form of narcissism. The same way humans marvel at how Earth could possibly have the perfect conditions for life to exist. Shit must be have been meant to be right? In our own small little worlds, we build software that sort of fits the business, and collect a check. Woah, how’d that happen? I wonder if we’re like, amazing or something?
- ZephyrBlu 6y ago
  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.
- blackbrokkoli 6y ago
  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.
Razengan 6y ago
When they're the users of what they make.
b20000 6y ago
The ability to negotiate and to get properly paid for all the hard work and education they invested in over all the years.
- mirekrusin 6y ago
  It's like musicians - do you have to go to great music school to be good? No. Does it help? Yes.
runawaybottle 6y ago
I think this thread is not defining ‘greatness’ well enough. If we’re really talking about greatness, there should like 0.5% of HN that fit the bill, or something like that across the industry. Reframe the question, who are our Bachs and Beethovens? Were they great because they created a lot of good work fast? Is good even enough? None of that shit defines greatness. Our best developers came from open source. The stuff they made was undeniable. Is being super productive the same as making undeniably useful programs(languages, tools)? Look at our greats and I think you’ll see they made a breed of work that sits outside workplace metrics of productivity, the same way a Hitchcock was genre defining.
inopinatus 6y ago
A steaming dumpster fire of a paper that assumes greatness can be determined by a ranked numerical model, then smears this assumption all over the floor and carpet. The algorithmic HR startup that inevitably follows will be gamed into oblivion. Greatness is by acclamation, not quantification.
wildermuthn 6y ago
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 their own weight?” If you could build a skyscraper according to rules limited only by our imagination, then perhaps we’d see a lot more of them collapsing. And given that frequency of failure, we’d see a lot more debate about what makes for excellence in skyscraper-building. Maybe a better question to ask is, “What makes for a poor software engineer?” That question seems a lot easier to answer. A poor engineer takes a long time to write unreadable, unmaintainable, buggy code that only partially solves problems that no one has. Ironically, such code often goes unnoticed by its very nature: it takes a lengthy period of time to even come into existence, when it does exist it is so buggy that its failure seems related to bugs rather than that it solves no problems, and the unreadable nature of the code is mistakenly attributed to essential complexity rather than incidental. And that last point is where I think we get closest to an answer: Good engineers reduce complexity. Bad engineers magnify complexity. Tolstoy wrote, “All Happy families resemble one another, but each unhappy family is unhappy in its own way.” It seems to me that the same could be said of software engineers.
- Ygor 6y ago
  "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 up being "uptaken". Also, just because buildings don't collapse and fail catastrophically, I assume there are many flaws in the design that get "worked around" during construction. Many flaws (bugs) do likely end up "in production", but they are more of a technical debt type of issue that will be a burden for building maintenance and/or future tenants.
  - PretzelFisch 6y ago
stevefan1999 6y ago
Alternative title: What makes me a good software engineer?
eeZah7Ux 6y ago
Warning: this is a survey on what people THINK makes great engineers.
- WJW 6y ago
  Even narrower, what expert Microsoft engineers think makes a great engineer. That seems extremely likely to shift the responses towards qualities important at large enterprise-focused companies.
MHard 6y ago
>> Two attributes received negative ratings —“A great developer should not have this; it isnot good” [...] and hardworking [...] I found this amusing but not necessarily wrong.
Havoc 6y ago
Asking a broad sample of people seems like a approach that would get you “how to be a good engineering” at best.
hyperpallium2 6y ago
(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

305 points by 7d7n 6y ago

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.

AnimalMuppet 6y ago
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. (I believe this shorter-than-three-weeks idea came from Extreme Programming, but I'm not quite certain of that.)
- __alias 6y ago
  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
  - BOOSTERHIDROGEN 6y ago
    Interesting take, mind sharing how do you use fibonacci ? Thanks
    - bart3r 6y ago
      https://www.youtube.com/watch?v=iZYSapFCg4A https://www.youtube.com/watch?v=iZYSapFCg4A
    - redis_mlc 6y ago
      0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610 Hope (Days) = Calculated Est. (Hours) 1 day = 8 hours 2 days = 8 + 13 = 21 hours 3 days = 8 + 13 + 21 = 34 hours H(days) = Fn(6+days) hours, where days >= 2
    - mgkimsal 6y ago
      Not the OP, but one of the teams I'm on uses fib somewhat differently. Any point with 1-2 is estimated at < 1 day. Some are literally 20 minute fixes, but ... you don't always know that up front, you just generally know it may be pretty small. 2 might sometimes go up to a day. A 3 is assumed to be a day or two. A 5 is assumed to be 3-4 days. An 8 would be 1-2 weeks. Anything higher is backlogged until it's broken down into smaller segments. Not sure how well that compares to usages by other teams, but that's one data point for your question.
  - deleted 6y ago
    [deleted]
- valenterry 6y ago
  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...
  - AnimalMuppet 6y ago
    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.)
    - mgkimsal 6y ago
      "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?
      - deleted 6y ago
        [deleted]
      - AnimalMuppet 6y ago
        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...
slumdev 6y ago
> 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.
- groby_b 6y ago
  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 isn't fixed - so frequent estimates with frequent course correction. But you're still estimating.
  - deleted 6y ago
    [deleted]
  - Fire-Dragon-DoL 6y ago
    This is the definition of Agile, the officiak one: https://agilemanifesto.org/ https://agilemanifesto.org/
  - kthejoker2 6y ago
    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, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate - which in software lingo actually means "commitment" .. > The real tragedy is the client understands their problem better than she's able to predict what will solve it. But in the anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins. > Try showing up at your doctor's office and giving her your "requirements". Tell her the prescriptions you'd like written and the operations you'd like scheduled. If she's nice, she'll smile and say, "That's interesting, tell me where it hurts." > In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships more like doctor-patient and less like waiter-diner.
Geminidog 6y ago
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 and very accurate time predictions is a sign of a bad manager that is overly reliant on engineers and lacks understanding of software. A good manager should have the technical knowledge to make a technical guesstimate himself (that will also likely be wrong) and have the foresight to be able to manage delays and allow for buffer time. A great team of people creating a product consists of both great Technical product managers and great software engineers. A rockstar software Engineer alone may not have the ability to manage the politics of unrealistic expectations.
- username90 6y ago
  > 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 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. And yes as you get more skilled your predictions will become more accurate. Hence accurate predictions being a sign of skill.
  - Geminidog 6y ago
    >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.

Kranar 6y ago

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 employee is going to say something like "Lazy liars who treat people like crap make great software engineers." At the very least you'd expect a study to have a control group in order to filter out these useless questions. For example send a similarly worded survey to a group of grocery cashiers and ask them if they think attributes such as "Hard work, honesty, integrity, long term thinking, being a team player." make someone a great engineer. My hypothesis is you'd end up getting similar answers from taxi drivers as you would from Microsoft employees and consequently that there isn't much value derived from this survey or their selection of participants. Anyways, I'm by no means an expert and could be misjudging this research but frankly it looks to be beyond useless.

glushkov 6y ago
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 usually glorified position papers under the guise of an empirical study.
- kqr 6y ago
  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.
brentsch 6y ago
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 a truly detailed understanding of the factors involved in developer productivity. Even if there's a broad intersection between the answers one would get from taxi drivers and from computer scientists, the distance between the two fields makes that an unexpected result, which should prompt us to change how we think about computer science* and/or how we think about studying it. *or cab driving

hn_throwaway_99 6y ago

OK, so I admit I just started with the abstract, but the first item listed is "writing good code". Umm, I would hope that is kinda part of the definition? I was actually looking for some valuable insight (e.g. how are great software engineers able to consistently write good code) but I didn't see it in this report.

calcsam 6y ago

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.html https://www.teamten.com/lawrence/writings/norris-numbers.htm...

kens 6y ago
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.

m1117 6y ago

A good engineer will prob write some code instead of reading this nonsense

balls187 6y ago
Sure, but this is about great engineers.

nanoscopic 6y ago

Great software engineers know not to create PDFs when HTML works fine.

ineedasername 6y ago
But the ones who prize job security over all else will make their code as obscure as possible.
nanoscopic 6y ago
You guys can't take a joke can you? You should read the rules for why or why not to downvote stuff. This sort of "not what I personally want" nonsense is not what the feature is for. This is exactly why I barely ever post or comment because of the massive "downvote squad" that is hacker news regulars.
MattGaiser 6y ago
Given that it is presumably part of a journal, I am not sure that HTML would have worked fine. The purpose was to publish in one of those. We are a secondary audience.
- bottled_poe 6y ago
  Woah woah woah, what is this? Requirements analysis?
- blackbrokkoli 6y ago
  Great excuse. If your research is so important, maybe let blind people read it?

Subsentient 6y ago

Well I guess that makes me about average. I'm generally liked where I end up working, but tend to just do stuff on my own. I'm polite, but don't go out of my way to interact with others typically. I do check the boxes on the code quality stuff however, especially writing code that plans for the future.

jackblemming 6y ago

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 management and produce quality work that users actually want.

alacombe 6y ago
> Imo great engineers produce a lot of good to great quality work fast Sounds awfully like the Myth of the 10x Engineer.
- jackblemming 6y ago
  Not quite that high, but you'd be silly to believe there's no difference in speed at all.
  - abiogenesis 6y ago
    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.
    - jackblemming 6y ago
      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 ;)
      - 6y ago

known 6y ago

"You are a product of your environment" --Clement Stone (b. 1902) The Pygmalion effect, or Rosenthal effect, is a psychological phenomenon wherein high expectations lead to improved performance in a given area https://en.wikipedia.org/wiki/Pygmalion_effect https://en.wikipedia.org/wiki/Pygmalion_effect

valenterry 6y ago

Great software engineers create/build software only as a last resort, once all other options have been exhausted. :)

lolive 6y ago
And they can feel in their flesh the entropy increase of each of their commits.
quickthrower2 6y ago
This reminds me of the saying about don't expect someone to do something when their paycheck depends on doing the opposite. That said yes a great software engineer would be writing software BUT would have said no to a lot of other tasks, so that the task she is working on is vital and has a big impact.
username90 6y ago
No they don't, writing new code is often cleaner and simpler than adding a library. Exactly when to do either is arguable, and picking the right choice requires skill. So always going the library route when possible means you aren't a great software engineer.
- valenterry 6y ago
  Please read my post again. What I said comes way before the kind of decision that you mentioned.
  - username90 6y ago
    What you said includes the decision I mentioned.
    - valenterry 6y ago
      Hm, I don't know where you got this idea from... I certainly didn't mean it like that.

ketzo 6y ago

> 1. Introduction > “At the end of the day, to make changes [to software], it still takes a developer, a butt in a seat somewhere, to type [Source Control System] commit. — Dev Manager” Not entirely relevant, but this opening comment just struck me as funny.

lolive 6y ago

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.

nevertoolate 6y ago
On the contrary. Who are young still work through the night. If work keeps you up it means that you can’t make trade-offs quite well enough.
gwittel 6y ago
> 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.
- lolive 6y ago
  As a freelancer, I am usually hired 3 months before the delivery of the product to help them firefighting. In the end, juniore don't deal with the real issues in their code. We, senior developpers, do. Note: after a stroke of lucidity, I stopped accepting those kind of missions.

ketzo 6y ago

Weird to me how down these comments are on what I read as the main message of the paper, i.e. that engineers aren’t just code monkeys. Being a “great engineer” is not strictly determined by technical ability; in fact, social ability plays a big role in a so-called “individual contributor role.”

username90 6y ago
What is even a code monkey? A coder takes a problem described in human language and solves it using computer code. In order to do this well you need to both be able to properly read and understand problems in human language and be able to write and structure code. There is no world where you can write code without thinking about the hard stuff, at least not if you write something more complex than a basic static frontend webpage.
- luisehk 6y ago
  I think the term has negative connotations because of people who build the wrong thing before asking critical questions or clarifying anything that would help shape the requirements. I understand some people enjoy being just implementers, though. I don't think that's enough but to each their own.

tschellenbach 6y ago

There's only 1 rule: Shipping code that delivers value to users.

suyash 6y ago
that's a nice one to remember!

probinso 6y ago

and here I always thought the answer was Adderall

nullsense 6y ago
Plot twist: it's not the Adderall, but actually the ADHD. The engineers with an interest-based nervous system who have trouble switching off and hyperfocus on their latest interest staying up coding all night tend to learn a lot of shit faster than their peers because they simply spend more aggregate time doing it. Source: ADHD engineer. I don't actually take Adderall. Tried Ritalin briefly but stopped as it doesn't affect me at all. Might try Adderall and report back.

kevindeasis 6y ago

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 certain things outside of playing basketball that you have to worry about. I guess i'm asking cause it's kinda annoying when people tell me what makes a great engineer. Anyone I know who has been doing this a few years knows what makes a great engineer. It doesn't mean they want to be a great engineer because the trade-offs arent just worth it

BeetleB 6y ago
No, they do not. There isn't even a consensus on what "great" means. You play basketball in a very static environment. The rules don't change from game to game, or team to team. The duration of a match is constant. How well the team performs is a well known metric. People do not do engineering in a static environment. The needs asked of one changes from team to team. The quality metrics vary from application to application. The people he/she relies on varies even when you stay in the same team. An engineer who is really useful in one company may be harmful to another one.
- llimllib 6y ago
  I suspect you haven’t played much basketball! The same player on different teams can be much better or worse - some players fit in with almost any team and others need a team built around them. (I don’t disagree with your larger point! Just that basketball is an example of a “very static environment“ relative to programming)
- cortesoft 6y ago
  > You play basketball in a very static environment I would strongly disagree - basketball is a highly dynamic environment, simply because you have an opponent. Everything you are trying to do, you have someone else trying to stop you. They are as adaptive as you are. Because of this dynamism, many players who were great in previous eras couldn't survive in the modern era (and vice versa, really)... for example, most centers who played even 10 years ago would be abused in the modern game by opposing centers shooting threes. It simply wasn't part of the game 10 years ago, and now everyone does it. There was literally a player (Roy Hibbert) during the transition who was a star before and suddenly became unplayable as teams adapted to the new environment. He was out of the league in 2 years.

Rapzid 6y ago

The word "retirement" doesn't appear in this document.

renewiltord 6y ago

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.

renewiltord 6y ago
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.
- w0utert 6y ago
  This rings close to home for me, I'm a firm subscriber of the mantra that laziness a good quality for a software engineer to have. It has saved me many times already working on difficult/never-seen-before problems, and (conversely) not adhering to it has bitten me multiple times. Often it simply takes some time for solutions to new problems to percolate, and you need to take a step back regularly during the process. Forget about the problem completely and do something completely different, interspersed with short bursts of research and reading on related topics. Sooner or later the contours of a solution will start to form and you will (hopefully) be able to realize it much quicker and at higher quality compared to 'working hard' by pounding yourself and trying to force things. I cannot count the number of times I almost gave up on a problem after working myself into multiple dead-ends, and almost instantly seeing a path forward after taking a few steps back and allowing my brain to work itself out of these dead-ends. Not spending 1 week of 'hard work' on a bad solution can save you months of work in the future.
- yowlingcat 6y ago

daly 6y ago

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 bug, fixed it, and sent off a patch. After that he restarted emacs and continued right where he left off. It was a virtuoso performance. It was like watching Victor Borga (https://www.youtube.com/watch?v=dKeqaDSjy98 https://www.youtube.com/watch?v=dKeqaDSjy98). I know a guy who plays guitar. He can listen to a performance and repeat it as easily as I can type what I read. He can transpose keys, add riffs, change tuning "on the fly", and even play thru with a broken string, adjusting chords to the new "5 string" form. He also knows guitar characteristics, pedal effects, etc., basically "all things guitar". 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). They also write beautiful "crafted" code. I'm keyboarding a FORTRAN punched card deck (for an historical museum). You can see from the code that the author wrote clean, careful, and clear code. You can almost feel how good he was. Greatness isn't about "team player", "hard working", "good at time estimation", or anything "social". Greatness is a property of the person, a deep love of the craft, and a focus on "doing it right".

chokeartist 6y ago
That was a beautiful story. Thank you for sharing.
runawaybottle 6y ago
Don’t confuse familiarity with greatness. Of course if you wrote the damn thing you can demonstrate technical virtuosity. Edit: Maybe I read too fast. Anyways, intuition is sort of the precursor to greatness. You know those designers that pick out colors innately? No amount of color theory studying will get you to that level. You are probably describing someone with an intuition for debugging. One of those things in life everyone has to learn eventually. Don’t fight the tide, find the waves that are certainly for you.

TrackerFF 6y ago

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. etc. Having been in many other (technical) fields outside software engineering, I've never seen the same mentality or obsession there.

anonytrary 6y ago
I think passion is everything. Everyone is 10x at their passion. Strive to have passion in all that you do.
- burnthrow 6y ago
  Yes. This "greatness" is actually quite a fragile thing when one considers the mysterious origin of passion, etc. Without motivation there's nothing.
runawaybottle 6y ago
It’s a form of narcissism. The same way humans marvel at how Earth could possibly have the perfect conditions for life to exist. Shit must be have been meant to be right? In our own small little worlds, we build software that sort of fits the business, and collect a check. Woah, how’d that happen? I wonder if we’re like, amazing or something?
ZephyrBlu 6y ago
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.
blackbrokkoli 6y ago
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.

Razengan 6y ago

When they're the users of what they make.

b20000 6y ago

The ability to negotiate and to get properly paid for all the hard work and education they invested in over all the years.

mirekrusin 6y ago
It's like musicians - do you have to go to great music school to be good? No. Does it help? Yes.

runawaybottle 6y ago

I think this thread is not defining ‘greatness’ well enough. If we’re really talking about greatness, there should like 0.5% of HN that fit the bill, or something like that across the industry. Reframe the question, who are our Bachs and Beethovens? Were they great because they created a lot of good work fast? Is good even enough? None of that shit defines greatness. Our best developers came from open source. The stuff they made was undeniable. Is being super productive the same as making undeniably useful programs(languages, tools)? Look at our greats and I think you’ll see they made a breed of work that sits outside workplace metrics of productivity, the same way a Hitchcock was genre defining.

inopinatus 6y ago

A steaming dumpster fire of a paper that assumes greatness can be determined by a ranked numerical model, then smears this assumption all over the floor and carpet. The algorithmic HR startup that inevitably follows will be gamed into oblivion. Greatness is by acclamation, not quantification.

wildermuthn 6y ago

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 their own weight?” If you could build a skyscraper according to rules limited only by our imagination, then perhaps we’d see a lot more of them collapsing. And given that frequency of failure, we’d see a lot more debate about what makes for excellence in skyscraper-building. Maybe a better question to ask is, “What makes for a poor software engineer?” That question seems a lot easier to answer. A poor engineer takes a long time to write unreadable, unmaintainable, buggy code that only partially solves problems that no one has. Ironically, such code often goes unnoticed by its very nature: it takes a lengthy period of time to even come into existence, when it does exist it is so buggy that its failure seems related to bugs rather than that it solves no problems, and the unreadable nature of the code is mistakenly attributed to essential complexity rather than incidental. And that last point is where I think we get closest to an answer: Good engineers reduce complexity. Bad engineers magnify complexity. Tolstoy wrote, “All Happy families resemble one another, but each unhappy family is unhappy in its own way.” It seems to me that the same could be said of software engineers.

Ygor 6y ago
"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 up being "uptaken". Also, just because buildings don't collapse and fail catastrophically, I assume there are many flaws in the design that get "worked around" during construction. Many flaws (bugs) do likely end up "in production", but they are more of a technical debt type of issue that will be a burden for building maintenance and/or future tenants.
- PretzelFisch 6y ago

stevefan1999 6y ago

Alternative title: What makes me a good software engineer?

eeZah7Ux 6y ago

Warning: this is a survey on what people THINK makes great engineers.

WJW 6y ago
Even narrower, what expert Microsoft engineers think makes a great engineer. That seems extremely likely to shift the responses towards qualities important at large enterprise-focused companies.

MHard 6y ago

>> Two attributes received negative ratings —“A great developer should not have this; it isnot good” [...] and hardworking [...] I found this amusing but not necessarily wrong.

Havoc 6y ago

Asking a broad sample of people seems like a approach that would get you “how to be a good engineering” at best.

hyperpallium2 6y ago

(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