[HN Gopher] Things I've learned in my 20 years as a software eng...
       ___________________________________________________________________
        
       Things I've learned in my 20 years as a software engineer
        
       Author : D_Guidi
       Score  : 1102 points
       Date   : 2021-10-08 10:04 UTC (12 hours ago)
        
 (HTM) web link (www.simplethread.com)
 (TXT) w3m dump (www.simplethread.com)
        
       | codedeadlock wrote:
       | Great advice.
       | 
       | One of the things that I have learnt is how important effective
       | communication is for software developers. It can make or break
       | the products.
        
       | sporedro wrote:
       | I feel like once you've worked on a few projects the desire to
       | "reinvent" the wheel is quickly destroyed. The main thing they
       | never teach in school and you really can't understand until your
       | doing it is maintenance.
       | 
       | Projects are like a balancing act where you need to weigh the
       | pros and cons of every choice and choose the best one. The hard
       | part is being able to do that and do it in a reasonable amount of
       | time.
        
         | jb3689 wrote:
         | The difference between a senior engineer and a junior engineer
         | to me is that a senior engineer knows how to evolve a system
         | into the system that they want/need it to be. They don't just
         | say "well, looks like we have to throw the whole thing out the
         | window and use this other new shiny/rebuild it from scratch".
         | The desire to reinvent is important to keep throughout your
         | years as long as it is rooted in reason and in the best
         | intentions of the team and company.
         | 
         | Riffing on that, more senior engineers better know how to
         | evolve those systems (whether that is working with larger
         | systems or working on people problems or working to support
         | large customers, etc)
        
           | mgkimsal wrote:
           | Whenever I've "started over", I've sometimes longed for going
           | back to pre-existing stuff and evolving it. Sometimes, but
           | not always. Whenever I've 'evolved' existing systems, I've
           | almost always wish we'd started over (or some variation
           | thereof).
           | 
           | Recent-ish project: holding on to multi-year old legacy data
           | that was simply bad/broken (but was assumed to be good
           | because it was barely used/examined), then requiring every
           | single new feature to work flawlessly with broken data,
           | ensuring that legacy customers 'never' hit an error (when 95%
           | of them have not logged in in years). That's a candidate for
           | 'rewrite from ground up' - you can keep an old system going
           | in maintenance mode, build the archetypal "version 2", then
           | decide if/when/how to migrate old data over...
           | 
           | Knowing that you _can_ 'evolve' a system towards improvements
           | and knowing when you _should_ do that is another sign.
           | Something may be technically possible, but the time
           | /effort/cost can outweigh whatever benefits there may be.
        
       | mandeepj wrote:
       | > We should be far more focused on avoiding 0.1x programmers than
       | finding 10x programmers
       | 
       | I disagree here. A 10x programmer (or whatever other metric you
       | want to use) brings a high level vision and uses that to turn
       | around things faster like building Dynamics UIs, automation, or
       | other tools.
        
       | maerF0x0 wrote:
       | > 19. Interviews are almost worthless for telling how good of a
       | team member someone will be
       | 
       | I've been pondering the wisdom of having engineers do interviews
       | at all. Interviewing, and getting someone to reveal their hand to
       | you, is a massively specific skill, one that few get good at, let
       | alone software engineers. Why is it that we think a 2 hour course
       | on ethics and STAR can make someone capable of telling the
       | difference between a con artist and a genius?
       | 
       | I do wonder if having a professional hiring team to dig into who
       | the person is, and then just trial them for competence would be a
       | superior strategy?
        
         | ipnon wrote:
         | My Markov chain hiring process: Flip a coin. Heads, hire them
         | on the spot. Tails, give them the usual guantlet of algorithm
         | problems and coding challenges.
        
       | DrBazza wrote:
       | 21. is that management cannot, will not, and will never
       | understand why open plan offices are the worst for reducing
       | productivity. You don't want the plebs to also have their own
       | offices.
        
         | commandlinefan wrote:
         | 22. no matter how well you plan, as soon as the (completely
         | arbitrary) deadline gets close, everybody - even people who
         | know better - will demand that you throw in last-minute hacks
         | at 10 PM to "fix" a problem that nobody thought of before that
         | create technical debt that will never be paid off and will be
         | blamed on you.
        
       | jimt1234 wrote:
       | The one thing I've learned in software/computers: The more I
       | learn, the less I know.
       | 
       | To survive in this field, one has to accept the fact that
       | everything he/she's worked so hard to learn and master is gonna
       | be replaced by something new in a few years. Don't fight it.
       | Embrace it.
        
       | journey_16162 wrote:
       | > The 10x programmer is a silly myth. The idea that someone can
       | produce in 1 day what another competent, hard working, similarly
       | experienced programmer can produce in 2 weeks is silly.
       | 
       | I think the 10x programmer myth was never about productivity. The
       | idea is more about creativity. I.e. one creative programmer can
       | create a product that would have never existed otherwise.
        
         | ugjka wrote:
         | the dot com boom is over, you can make the next apple or google
         | from your garage any more. All the low hanging fruit have been
         | picked...
        
       | progx wrote:
       | Expect always the worst case.
       | 
       | Don't assume anything.
       | 
       | If it is not the worst case, be happy, it saves you work. If it
       | is the worst case, be happy, you expected it.
        
       | khalilravanna wrote:
       | This is a great list. My two from 10 years of experience would
       | probably be:
       | 
       | - Simplicity is everything. Complexity is fun but business is not
       | about fun. It's about solving problems. It's about having other
       | people be able to read your code and quickly understand it. Or
       | having a system that can be debugged without a PhD in the
       | specific tool you're using.
       | 
       | - Everything is a tradeoff. If something feels too good to be
       | true it probably is. If it's easy up front, it's probably hard in
       | other ways. If you want to make something faster you'll probably
       | need to make it more complicated.
        
       | Graffur wrote:
       | > 11. One of the biggest differences between a senior engineer
       | and a junior engineer is that they've formed opinions about the
       | way things should be
       | 
       | I don't like this one. IMO it tells you nothing and assumes
       | everyone shares the same culture of pushing opinions.
        
       | [deleted]
        
       | the_only_law wrote:
       | > "How can you not know what BGP is?" "You've never heard of
       | Rust?" Most of us have heard these kinds of statements, probably
       | too often.
       | 
       | My problem is I've heard of it, probably even know a bit about it
       | but never used or worked with it. Meanwhile it seems like
       | everyone around me is both an insane domain expert in their own
       | thing while also a pretty damn good generalist having worked
       | across everything.
        
       | ozim wrote:
       | I think I agree with every point on that post.
       | 
       | Only thing that I would add to the context:
       | 
       | If someone is a junior developer and has position where he has to
       | "just write code" don't worry much about that advice. Yes you
       | should understand what this advice is and look for ways to grow
       | into that mindset but as junior dev such person still has
       | privilege to fully focus on coding stuff as quickly as possible
       | to learn have their movements worked out.
       | 
       | Then as such junior gets to 2 or more years of experience this
       | advice should sink in and such person should start working as
       | those points guide. After 2 years of being code monkey and having
       | the feel for the code one can start looking at bigger picture.
        
       | quadcore wrote:
       | _The 10x programmer is a silly myth. The idea that someone can
       | produce in 1 day what another competent, hard working, similarly
       | experienced programmer can produce in 2 weeks is silly._
       | 
       | You know, 10x is an optimistic number here. Some programmers will
       | do in 1 day what you wont achieve in a life time. And not
       | understanding that makes you a bad programmer by my book simply
       | because this is the foundation of the job.
       | 
       | So let me give one advice: you are not producing code, you are
       | engineering code. Some will find solutions that the others will
       | not find. Thats where the 10x programmer thing come from. The guy
       | who wrote bittorrent said something like the following: "I've
       | written bittorrent in a way you would never have thought about".
       | 
       | You think John Carmack was the only one trying to make 3d games
       | when Doom came out? Thousands of programmers where trying to.
       | Does that make him a 10x programmer in your opinion? Or more like
       | a 1000x?
        
         | closeparen wrote:
         | I think that depends on the context in which you're working.
         | Flashes of genius don't have much place an an enterprise code
         | base. Everything is rigorously standardized and separated into
         | layers. Each layer has a bunch of bookkeeping about
         | dependencies, interfaces, mocks, expectations, and test cases.
         | This is not really brain work; it's typing. Now maybe if you're
         | really brilliant, you'll do much better than average with the
         | implementation of a really tricky layer. But the layers are
         | rarely tricky, implementing them never takes all that much
         | time, the slow part is always the integration and associated
         | mocking rituals. Typing speed pays better dividends than
         | brainpower in terms of productivity, there.
        
           | FlyingAvatar wrote:
           | I find this true to an extent, but this also where a lot of
           | unnecessary complexity, risk aversion and process live.
        
           | jimbokun wrote:
           | So the 10x programmer realizes you can accomplish the same
           | goals with 1/10 of the book keeping, dependencies, interfaces
           | etc. etc. etc.
           | 
           | In other words, the processes themselves place hard upper
           | limits on the possible productivity.
        
             | closeparen wrote:
             | One could make the argument that skipping the bureaucracy
             | catches up with you in the long run.
             | 
             | Or maybe a small team of 10x programmers could really get
             | away with it, indefinitely. But can you reliably staff
             | enough of them, now and forever, to keep that going? For a
             | business it is often better to have a codebase that scales
             | with arbitrarily many average-quality engineers, than to be
             | dependent on hiring miracles. Even small numbers of them.
        
           | IshKebab wrote:
           | Maybe that's why so many people think 10x programmers don't
           | exist - they work in environments where a 10x programmer
           | isn't needed and couldn't really demonstrate their skills.
        
             | gopher_space wrote:
             | How many people will never achieve their potential because
             | they don't work in a room with a door?
        
         | joelthelion wrote:
         | The confusion is that it's all about what people can and cannot
         | do, not how much code they can write.
         | 
         | If your development needs are mundane crud stuff, you don't
         | need a "10x programmer". If you're doing tricky stuff, on the
         | other hand, you absolutely do.
        
           | baobabKoodaa wrote:
           | Even if you are doing mundane crud stuff, you are eventually
           | going to run into hard problems that don't have obvious
           | answers. Not everyone has to be able to solve those problems,
           | but it's useful to have _someone_ in the team who can.
        
           | avgDev wrote:
           | I do CRUD stuff mostly at work but I always research things
           | to improve. A good programmer can make a huge difference in
           | CRUD applications. Things like proper relational database
           | design can save a lot of issues down the road. Using good OOP
           | practices can improve reliability. Keeping things DRY is
           | great too.
           | 
           | I have seen some awful source code that run business
           | applications for years.......but bad engineering practices
           | may cost millions in the long run one way or another.
        
             | joelthelion wrote:
             | I shouldn't have said CRUD. I agree with you, there's a
             | place for genius stuff everywhere.
             | 
             | What I meant is that there is also a lot of boring stuff
             | that just needs to get done. A 10x programmer won't help
             | you much there.
        
         | crvdgc wrote:
         | On the edge of possible/impossible, ratios will lose their
         | meanings. In the same way, you can say "Einstein is a 10,000x
         | scientist."
         | 
         | Continuing with this analogy and using Kuhn's concepts, maybe
         | it's better to bracket out breakthroughs (paradigm shifts) when
         | talking about everyday productivity (normal science).
        
         | taeric wrote:
         | Carmack is an interesting choice here, oddly. He and team were
         | among the first ones there, but it isn't like they weren't
         | rapidly met. Nor, strictly, the first. Ultima Underworld, I'm
         | pretty sure, has a bit of that distinction.
         | 
         | Even more impressive, much of the success of later titles came
         | from his picking the likes of Abrash to help make things fast.
         | Notably, the WTF comment in the "fast square root" trick was
         | from Carmack about a contractor's code that was speeding things
         | up.
         | 
         | Getting even more meta on it, they had amazing dev tools at
         | their disposal that many other programmers just couldn't
         | afford. Look at the recreations folks do nowadays using pico8
         | and friends. Some folks get some really amazing tricks running
         | in that field.
         | 
         | None of which is to say Carmack is a bad dev. Quite the
         | contrary, he is quite good. But don't discount the role of
         | everything else to the early success that Doom and friends had.
         | In particular, the artistic execution and vision of everyone
         | else was probably worth more than you'd consider.
        
         | madsbuch wrote:
         | I think the "10x programmer" as a term is confusing.
         | 
         | In one analogy it could be the 10x bricklayer. One who does a
         | well defined job 10 times faster than the others. I think this
         | is the notion people oppose.
         | 
         | Another analogy is the 10x classical composer. A person who
         | produces music that is 10 times better music. But this is much
         | more about creative/artistic capacity than about producing.
         | Nobody oppose this.
         | 
         | I that your examples incarnate the same idea: It is not about
         | producing code faster. It is about having better ideas.
        
           | 908B64B197 wrote:
           | > In one analogy it could be the 10x bricklayer. One who does
           | a well defined job 10 times faster than the others.
           | 
           | Software as brick-laying gets a laugh out of me. If someone
           | uses that analogy, that's a red-flag: they don't really
           | understand software (and tech). It's like offshored bodyshops
           | that just keep throwing more warm bodies at a codebase.
           | 
           | Truth is, a 10x isn't someone who lays bricks 10 times
           | faster. A 10x is someone who thinks differently. Instead of
           | building you a something with load-bearing walls, he'll
           | innovate and use an internal steel frame, paving the way for
           | your building to be taller than anything previously
           | considered possible. [0]
           | 
           | [0] https://en.wikipedia.org/wiki/Home_Insurance_Building
        
             | madsbuch wrote:
             | I think this is entirely correct. In this framework we
             | wouldn't call it a 10x programmer, but a 10x thinker.
        
           | HeyLaughingBoy wrote:
           | But very often what makes an idea "better" _is_ that it
           | produces a result faster. I 've done exactly this: spent
           | hours trying to solve a problem to no avail. Then walk away,
           | come back to it and see that a completely different approach
           | will solve it in ten minutes.
        
             | madsbuch wrote:
             | I doubt the bricklayer will become more efficient by taking
             | a walk ruminating. But sure, some tasks are like that.
             | Those are the tasks where you have 10x producers.
        
         | [deleted]
        
         | petepete wrote:
         | I'm about 1/1,000,000th a Fabrice Bellard, and I'm fine with
         | that.
        
           | nickelpro wrote:
           | Bellard is who I reference in these situations also. He's a
           | sort-of empirical refutation of the assertion "10x
           | programmers don't exist". I always liked that he lists qemu
           | and ffmpeg on his website as afterthoughts mixed in with all
           | the other code he's written.
        
             | The_Colonel wrote:
             | Bellard is obviously 10x (or 100x) engineer when you need
             | to port Linux kernel to JavaScript or compute the longest
             | Pi sequence.
             | 
             | But most jobs aren't like that and require a mixed skillset
             | - problem solving, people skills, stress resistance etc.
             | and it's entirely unclear how Bellard would fare there.
        
         | hooande wrote:
         | You don't say that so-and-so is a "10x painter". Art is
         | obviously not about the quantity of paint used per day, but how
         | it gets used and in what context. This is what you seem to be
         | communicating with your quote about bittorrent.
         | 
         | Because we're programmers, we chose an empirical measurement
         | ("10x") as our term for high skill. This terminology is
         | confusing and stupid, but now we're stuck with it
        
           | jimbokun wrote:
           | I'm guessing there are clearly 10x painters other painters
           | can identify, but there are even fewer quantifiable metrics
           | to measure a painter's output than there are for programmers.
        
         | karaterobot wrote:
         | When you say "[s]ome programmers will do in 1 day what you wont
         | achieve in a life time" you are no longer talking about the 10X
         | programmer myth. You're talking about invention, rather than
         | day-to-day productivity.
        
           | nickelpro wrote:
           | They're the same thing if your day-to-day productivity
           | requires invention, as it does in Carmack's case (and I would
           | argue most programmers)
        
             | karaterobot wrote:
             | I would argue that that's not the case for most
             | programmers, at least not in the sense of developing a new
             | p2p protocol, or a fast inverse square root algorithm.
             | Would John Carmack code, e.g. a checkout system for an
             | iPhone app 1000x faster than most programmers? I doubt
             | that.
        
             | dudeman13 wrote:
             | They are not the same thing, unless they achieve what a 1x
             | programmer won't on a lifetime on a day-to-day basis.
             | 
             | If the 10x, 100x or 1000x programmer does not do the 10x,
             | 100x or 1000x times on average on their day to day then
             | they are not 10x, 100x or 1000x programmers.
             | 
             | (for whatever the heck a 1x programmer is, which people
             | talking about 10x programmers oddly always skip on giving
             | any decent definition)
        
         | 908B64B197 wrote:
         | I think the fundamental issue with 10x is that a lot of people
         | simply never met one. These guys tend to fly under the radar
         | quite a bit. If you are in a tier 2 market or company, your
         | chances of attracting one are close to nil. Because they are
         | extremely valuable, they don't interview a lot and tend to hop
         | between companies where they know people (or get fast tracked
         | internally).
         | 
         | I remember someone laughing at the idea of 10x programmers. I
         | asked him where he hired from and what's the compensation like.
         | Turns out two high performers I had recently hired were from
         | the same college he was trying to hire from. Of course, he had
         | no chances of attracting anyone since my offer was ~3x what he
         | was offering!
        
         | [deleted]
        
         | hatch_q wrote:
         | Author nails it though with: "We should be far more concerned
         | with keeping 0.1x programmers off our teams than finding the
         | mythical 10x programmer."
        
           | readams wrote:
           | This is just rescaling. The author is actually acknowledging
           | that there exists 10x differences but divides by 10 for some
           | reason.
        
             | The_Colonel wrote:
             | 1x is supposed to be a baseline for an average productive
             | programmer.
             | 
             | 0.1 is someone who isn't actually a productive engineer but
             | somehow faked the interview process.
             | 
             | It's not difficult to be 10 times more productive than
             | somebody who isn't productive at all. I'm at least 100x
             | better Kotlin developer than my 30 years dead grand-grand
             | father who never saw computer IRL.
             | 
             | It's much more difficult to show that you can be 10 times
             | more productive than the average productive developer.
        
         | mswtk wrote:
         | > You think John Carmack was the only one trying to make 3d
         | games when Doom came out? Thousands of programmers where trying
         | to. Does that make him a 10x programmer in your opinion? Or
         | more like a 1000x?
         | 
         | I think the idea of 10x programmers gets so much pushback
         | because it's often bundled with this kind of toxic hero
         | worship. There's a difference between acknowledging the
         | impressive ability of outliers, and idolizing heroic one-man
         | efforts as the pinnacle of what we should all aspire to as
         | software developers.
         | 
         | Incidentally, Carmack was not the only programmer on early id
         | Software games, and Doom was far from the first 3d first-person
         | game made. Arguably, it wasn't even that ambitious compared to,
         | say, Ultima Underworld, but the programmers working on that get
         | much less immediate recognition.
         | 
         | As a matter of fact, these discussions often remind me of that
         | famous IGN quote of Warren Spector. Except we really should
         | know better on HN.
        
         | jimbokun wrote:
         | This is always my go to example of a 10x programmer:
         | 
         | https://norvig.com/spell-correct.html
         | 
         | How many developers do you know that would bang out a spelling
         | corrector on a single plane flight, in half a page of code?
         | 
         | It's a question of knowing the algorithms of tools that make
         | things possible that other developers might not even consider,
         | and how to express those ideas cleanly and concisely, evaluate
         | your solution, and iterate and improve quickly.
         | 
         | And then consider the quality of his documentation and
         | considerations for improvement and future work.
        
           | BeetleB wrote:
           | Norvig wasn't given a random problem that he then solved
           | quickly. He picked the problem to work on. I'm sure I can
           | give him problems of similar complexity that I work on for my
           | job and he wouldn't do it that quickly. Quicker than me, for
           | sure - but it wouldn't be hard to find someone who does it
           | quicker than he did.
           | 
           | I'm sure I can find problems that I can solve quickly and
           | amaze people. Being able to pick your own problems makes for
           | a bad metric for identifying 10x programmers.
        
             | jimbokun wrote:
             | This is one example.
             | 
             | Norvig has written a ton of kick ass programs in his career
             | that are concise, efficient, and correct, in much less time
             | than most programmers would require.
             | 
             | Furthermore, even picking your own problems can be a way to
             | achieve > 10x productivity, as identifying useful problems
             | to solve is also a crucial skill.
             | 
             | I attended a talk given by Norvig, where he frankly
             | admitted Google picked markets to enter where they could
             | get good quality data to train their machine learning
             | models on (this was many years ago). Maybe lesser
             | developers wouldn't have that insight.
        
           | zenithd wrote:
           | _> It 's a question of knowing_
           | 
           | Exactly. Norvig's skill set happens to be of the upscale
           | variety, but similar "10x" knowledge+practice effects exist
           | in more pedestrian domains as well.
           | 
           | Compared to my current self, my teenage self was a 10x PHP
           | programmer. I'm absolutely sure that it would take _years_
           | for me to get back to being even remotely good at PHP-
           | interleaved-with-HTML style coding.
        
         | VMtest wrote:
         | What do people gain by arguing over these? Genuinely confused
         | 
         | Just to be proud and gain that dopamine?
        
           | baobabKoodaa wrote:
           | > What do people gain by arguing over these? Genuinely
           | confused
           | 
           | If you assume some arguments (eventually, in some way) lead
           | to people altering their opinions closer to the truth, then
           | people gain more accurate views of the world. This also
           | reduces the spread of misinformation (when the people who
           | have corrected their views no longer spread it), thus having
           | a compounding effect on more people getting closer to the
           | truth.
           | 
           | Or if you assume people never change their opinions as the
           | result of arguments, then I suppose people gain nothing by
           | arguing.
        
         | BeetleB wrote:
         | > Some programmers will do in 1 day what you wont achieve in a
         | life time. And not understanding that makes you a bad
         | programmer by my book simply because this is the foundation of
         | the job.
         | 
         | Most projects out there will not benefit from such a person. If
         | you don't understand this, then in my book it makes you a poor
         | employee. I mean, it's great if this 10x guy can solve some
         | challenging problems that most people cannot, but if that 10x
         | guy cannot show how it helps the business, I hope he's not in
         | my team.
         | 
         | Most businesses are complex and messy. Connecting your code to
         | business value is not easy.
         | 
         | Looking at some of the comments here, people are going out of
         | their way to both defend the existence of 10x programmers,
         | while simultaneously working very hard at _not_ putting any
         | kind of metric on their ability (e.g.  "no, it doesn't mean
         | they can produce 10x code or replace 10 people or ... it means
         | <something very hard to measure>"). If you're going to insist
         | on some quality that is hard to quantify, then stop using
         | numbers to describe them. They are geniuses, but not 10x.
         | 
         | In my experience:
         | 
         | 1. You cannot replace 10 average programmers with a 10x
         | programmer and hope to achieve the same output. Output, by the
         | way, is not defined by code, but by activities that help the
         | business move forward.
         | 
         | 2. While there are some good claimed 10x programmers who work
         | well with others, most of the ones I've encountered do not. In
         | my last job, we had a team of several truly brilliant folks.
         | They could dive deep to the assembly level or work at the
         | system level (scripting, etc). Any bottleneck that arose - they
         | would dig deep and figure it out.
         | 
         | It was the least productive team I've been in. They argued
         | amongst themselves on the pettiest of things that had no impact
         | on the business. When asked why I was leaving the team, I
         | literally told them that I want to be in a team that writes SW.
         | That team's productivity was so low I couldn't reasonably claim
         | they wrote SW. It's not that they didn't write code, but that
         | most of it would not see the light of day because of constant
         | bickering.
        
           | WizzleKake wrote:
           | A 10x programmer doesn't cost 10 times as much as a regular
           | programmer. 10x programmers are real and drive real business
           | value. The people who insist 10x programmers are a myth
           | simply have not worked with one. Do not conflate brilliant-
           | but-an-asshole or prodigious-output-but-creates-a-mess
           | programmers with 10x programmers.
        
             | BeetleB wrote:
             | Yet another comment that uses the phrase 10x but does not
             | provide any way to quantify it.
             | 
             | No one is disputing geniuses exist. Calling them 10x,
             | however, is problematic.
        
               | WizzleKake wrote:
               | How is it a problem?
        
               | jasode wrote:
               | _> that uses the phrase 10x but does not provide any way
               | to quantify it_
               | 
               | Understand your complaint but "10x" is best interpreted
               | as a figure-of-speech and not an exact mathematical
               | equation. It's just a short & snappy sounding label
               | that's easy-to-say and easy-to-type on the keyboard. (My
               | previous comment about that:
               | https://news.ycombinator.com/item?id=13753178)
               | 
               | We use numerical type phrases without quantitative
               | precision all the time:
               | 
               | - He _doubled-down_ on his opinion. (We don 't nitpick
               | and ask how can an opinion be quantitatively measured as
               | 2x?)
               | 
               | - The old editors like vi/emacs is _a million_ times
               | better than IDEs. (We don 't nitpick about where the 10^6
               | quantity improvement comes from.)
               | 
               | - Microsoft _decimated_ the competition. (Some might
               | nitpick that exactly 1 /10th didn't get eliminated but
               | Websters Dictionary says that so-called "correction" is
               | wrong anyway: https://www.merriam-webster.com/words-at-
               | play/the-original-d...)
               | 
               | And yesterday, the top comment[1] in "Economics
               | Programming Languages" wrote:
               | 
               | - _> a new language to be adopted it needs to do
               | something (something reasonably important) 10x better
               | than the competition. Even 2x better is not enough to
               | motivate the disruption of changing languages._
               | 
               | Yes, it's hard to measure "10x" in languages beyond
               | synthetic benchmarks. But I think most of us get the idea
               | that "10x" is a just a synonym for "a massive amount" of
               | a fuzzy quality.
               | 
               | For some reason, "10x" attracts a lot of extra nitpicking
               | that we don't _consistently_ apply to many other examples
               | ( "double-down", "million times", etc).
               | 
               | [1] https://news.ycombinator.com/item?id=28784181
        
               | BeetleB wrote:
               | Most of your examples are commonly used phrases. "10x
               | programmer" is a unique phrase. We don't hear "10x
               | electrical engineer" or "10x politician".
               | 
               | Phrases like "decimate", double-down, etc are part of the
               | English language, and is well understood to have multiple
               | meanings.
               | 
               | Your other examples (e.g. vi/emacs being a million times
               | better) are examples of _random_ numbers people throw
               | out. Someone will say vi /emacs is a ton better, or an
               | order of magnitude better, or a million times better.
               | Whereas with 10x, it's _always_ 10x. I don 't hear people
               | talk about 3x programmers or 20x programmers.
               | 
               | The HN comment actually supports my point. You can see
               | how different people are interpreting 10x in the
               | responses. That's the exact same problem we have in this
               | comment thread.
        
               | jasode wrote:
               | _> Most of your examples are commonly used phrases. _
               | 
               | Yes, and "10x" is itself also _becoming_ a commonly used
               | phrase that 's getting less tied to the math number 10.
               | This thread's extensive _non_ -quantitative usage from
               | many people is evidence of that. (I'm guessing that in a
               | few decades, the bikeshedding about "10x" will eventually
               | stop and it will be accepted as a non-numerical
               | description like "a million times better")
               | 
               |  _> We don't hear "10x electrical engineer" or "10x
               | politician"._
               | 
               | The "10x" is relatively new compared to "double-down" but
               | it's spreading out to other uses besides "10x
               | programmer":
               | 
               | - "10x manager" :
               | https://www.google.com/search?q=%2210x+manager%22
               | 
               | - "10x author" : https://www.amazon.com/10X-Author-Level-
               | Left-Behind/dp/10841...
               | 
               | - "10x <various_nouns>" : https://www.hugo.team/10x
               | 
               | - "10x" spreading out to company names, etc :
               | https://www.google.com/search?q=10x
               | 
               | - "10x programming language" : yesterday's HN thread
               | comment example
               | 
               | Why do all the above non-mathematical usages keep
               | happening? Probably because "10x" sounds cool. We're
               | witnessing language evolution as it happens.
               | 
               |  _> Whereas with 10x, it's always 10x. I don't hear
               | people talk about 3x programmers or 20x programmers._
               | 
               | Sometimes people talk about 100x and 1000x and infinityX
               | to try and emphasize extra rare skills etc. Again,
               | interpreting 1000x literally as 10^3 isn't the intended
               | meaning. And to build on your point... the fact that
               | nobody says "9x programmer" or "11x programmer" but
               | almost always "10x" is actually evidence that it's not
               | trying to communicate exact mathematics.
        
               | BeetleB wrote:
               | > This thread's extensive non-quantitative usage from
               | many people is evidence of that.
               | 
               | Even putting aside comments like mine complaining about
               | the actual number, this thread's extensive use of 10x to
               | mean as many different things is a good reason to avoid
               | the term altogether. The whole thread is just "10x
               | programmers don't exist because X" and "10x programmers
               | exist because Y", where X and Y are unrelated.
               | 
               | > "10x manager"
               | 
               | All but one of the links in the first page were in the
               | context of SW, or written by people in the SW industry.
               | Many of them explicitly pointed out they derived the
               | phrase from 10x developer.
               | 
               | I cannot count this as an independent use of 10x.
               | 
               | > "10x author"
               | 
               | Written by a tech guy.
               | 
               | > 10x <various_nouns>" : https://www.hugo.team/10x
               | 
               | Written by a guy who started a SW company.
               | 
               | > "10x" spreading out to company names, etc :
               | https://www.google.com/search?q=10x
               | 
               | Sad, but fair enough.
               | 
               | It sounds like 10x is the equivalent of putting 2.0 on
               | everything (and also as meaningless).
        
               | jasode wrote:
               | _> 10x to mean as many different things is a good reason
               | to avoid the term altogether. The whole thread is just
               | "10x programmers don't exist because X" and "10x
               | programmers exist because Y", where X and Y are
               | unrelated._
               | 
               | Yes, I understand your complaint here too but the various
               | meanings isn't really the fault of "10x"... it's caused
               | by _any label_. Previous comment about that:
               | https://news.ycombinator.com/item?id=28797871
               | 
               | E.g. the alternative word "expert" or "effective" such as
               | "effective programmer" would cause the same debates:
               | 
               | - I think an effective programmer is one who understand
               | the whole stack from hardware gates to web stack
               | 
               | - No I think a truly effective programmer is one who
               | empowers his team members.
               | 
               | - No an "effective programmer" is really X. No it's Y.
               | 
               | - <... ad infinitum disagreements ... >
               | 
               | It doesn't matter what the word is... "10x", "talented",
               | "expert", "master", etc. There's no consensus definition
               | and yet we haven't tried to eliminate those words.
               | 
               | Generally, I understand that people typically mean _"
               | 10x"_ as a synonym for _" massively better"_. (Because
               | nobody who says "10x" has a stopwatch and rigorous
               | academic studies measuring it.) And yes, the
               | counterargument is _" 10 doesn't really mean anything"_
               | ... that's true but the _" 'massively better'"_ also
               | doesn't really mean anything -- and yet we can't strike
               | "massively better" from our language so we're back to the
               | same issue.
               | 
               | There is no short label X that "really means" whatever
               | everybody agrees it to mean. That's human language. We
               | muddle onward regardless.
        
               | admiral33 wrote:
               | > They argued amongst themselves on the pettiest of
               | things that had no impact on the business.
        
         | gavinray wrote:
         | Agreed, I don't know why the industry (or people?) in general
         | have a problem with accepting this abilities gap.
         | 
         | It's as if the notion of people being arbitrarily born more or
         | less with a knack for something is evil.
         | 
         | Let me tell you the story of when I realized I was (at best), a
         | "not-mediocre" dev:                 1. I've been programming
         | for fun even as a kid. That's what got me into it: If you count
         | kid-programming as "programming", I've been programming for
         | ~14-15 years.            2. There was a girl who used to work
         | with me at $DAYJOB, who is fairly well-known on The Orange
         | Website, and has written some "thought leader" papers in
         | certain niches. A real einstein.
         | 
         | I asked her in DM at work about her background and how long
         | she's been coding -- both in general and the language she's
         | well-known for. The answer was:                 "A couple of
         | years -- and a few of those were writing another language. This
         | is my first real job writing $LANGUAGE_WELL_KNOWN_FOR."
         | 
         | Well, fuck me.
         | 
         | This is called "innate ability". Humans aren't created equal,
         | nobody said they had to be, and it's not a crime to acknowledge
         | it. Folks ought to get over it IMO, it's not a big deal.
         | 
         | I will never understand CS and programming-language theory
         | concepts at that caliber or that intuitively, but who cares?
         | 
         | I'm also short as fuck so I doubt I'll be playing in the NBA
         | anytime soon either. Life goes on.
        
           | austincheney wrote:
           | > Agreed, I don't know why the industry (or people?) in
           | general have a problem with accepting this abilities gap.
           | 
           | Bias and poor processes. When people become reliant upon a
           | technique or process to attain viability that means of
           | execution becomes more important than the thing you are
           | producing. As a result people will defend slow unproductive
           | means of execution to the death. This is also a socially
           | reinforced phenomenon.
           | 
           | It is completely realistic to achieve 10x (or even much
           | greater) productivity and it isn't challenging, but it
           | requires abandonment of closely held ideas that are socially
           | reinforced.
        
             | charlieflowers wrote:
             | Yeah, 10x is really fast. Lots of companies couldn't bear
             | to go that fast ... the rate of change scares them.
        
             | dosethree wrote:
             | It's harder to achieve 10x in a vacuum, but if you make 10
             | engineers twice as productive, there ya go
        
             | [deleted]
        
             | jimbokun wrote:
             | > It is completely realistic to achieve 10x (or even much
             | greater) productivity and it isn't challenging, but it
             | requires abandonment of closely held ideas that are
             | socially reinforced.
             | 
             | OK, you piqued my curiosity. Can you elaborate?
        
               | austincheney wrote:
               | This is completely off the top of my head.
               | 
               | Objective quick wins:
               | 
               | 1) Less code. The less there is the less there is to
               | debug and maintain. This applies to all code including
               | dependencies, frameworks, abstractions, and decoration in
               | your own code. If abandoning OOP means substantially less
               | code then do it without question.
               | 
               | 2) Iterate faster. If you have a build that takes 10
               | minutes and the next guy has a build that takes less than
               | a minute they can fail 10x more frequently and achieve
               | the same level of productivity.
               | 
               | 3) Know your foundations with confidence. Things you rely
               | upon become more of a barrier than a help given a long
               | enough time line (shorter time line that could otherwise
               | imagine).
               | 
               | 4) The point of software is automation. If you find you
               | are doing manual curation in the code you are likely
               | wasting your productivity. An investment in better
               | automation returns interest on the initial investment.
               | 
               | More opinionated personal preferences:
               | 
               | 1) Unless you are writing in a language where you manage
               | access to memory, such as C++ or Rust, abandon OOP. In
               | garbage collected languages like Java, JavaScript, C# it
               | only provides composition. It is a tremendous increase in
               | code that does more harm in troubleshooting.
               | 
               | 2) Prefer a statically typed language. As a JavaScript
               | developer I have fallen in love with TypeScript. There
               | are performance benefits to ensuring all primitives are
               | strongly typed, but the developer performance benefits
               | come from typing complex types. This is a quick win for
               | defining execution of microservices and functional
               | programming.
               | 
               | 3) Prefer functional programming techniques and code
               | portability. Code is less defective when it is highly
               | predictable and explicit.
               | 
               | 4) Save composition for last. Don't worry about how to
               | put things together. Complete each micro-task in
               | isolation, which forces a separation of concerns. Once
               | everything is written putting things together becomes
               | natural and typically works itself out.
               | 
               | 5) Avoid pronouns in the code. The pronoun of JavaScript
               | is the keyword _this_. Don 't use it. You don't need it.
               | I have been writing in this language full time for 13
               | years both at work and for personal projects. In that
               | time I have really needed _this_ only twice. The problem
               | with pronouns is that they aren 't clear (in either value
               | or intention) by just reading the code, which takes
               | substantially more time to interpret as a human.
               | 
               | 6) Think in writing. You can save some refactoring effort
               | by having a solid execution plan. The best way to plan is
               | write things down as if to explain it to somebody who has
               | no idea. If you cannot even explain it to yourself you
               | won't be able to do in code.
        
               | jimbokun wrote:
               | Great stuff!
               | 
               | > 2) Iterate faster. If you have a build that takes 10
               | minutes and the next guy has a build that takes less than
               | a minute they can fail 10x more frequently and achieve
               | the same level of productivity.
               | 
               | I think this is very under rated. There are so many
               | things that can reduce developer latency (time between
               | making a change to the code and seeing if it works, or
               | deploying to production) is one of the most under rated
               | aspects of software engineering productivity.
               | 
               | Most other factors pale in comparison.
        
           | softfalcon wrote:
           | Totally agree with you. I'm in the same category and have had
           | to accept my fate to some degree. I keep improving relative
           | to myself, but that's all I can reasonably do.
           | 
           | What gets me is when I meet many of these "innate talent"
           | coders I get to hear phrases like:
           | 
           | "I just want to work with the best possible team..."
           | 
           | And then from their behaviour, you see how they get irritated
           | with the regular folks and try and convince everyone that if
           | we all just "be more like them" it'll all work better.
           | 
           | Many of them are blind to how much their talents make what is
           | easy for them, very hard for the rest of us.
           | 
           | I call this the "talented arrogance" syndrome.
        
             | knodi123 wrote:
             | > Many of them are blind to how much their talents make
             | what is easy for them, very hard for the rest of us.
             | 
             | See also: Asking very old people how they managed to win so
             | long.
        
           | munchbunny wrote:
           | > Agreed, I don't know why the industry (or people?) in
           | general have a problem with accepting this abilities gap.
           | 
           | I don't think it's that people have a problem admitting that
           | there are significant outliers. It's that there's a backlash
           | to the fetishization of "hiring 10x programmers" and most
           | people claiming to be one really aren't.
           | 
           | I know I'm good at it, but I am not and will probably never
           | get to 10x on just writing code. I've worked with people who
           | have a better claim to being a 10x. And having seen that, I
           | have also never encountered any company that claims to hire
           | 10x engineers that actually has a process to consistently
           | hire even 1-2x engineers.
        
             | dosethree wrote:
             | If there are 10x engineers, it's a right place, right time
             | situation. Very good engineers with the right experience,
             | luck, a good idea, and the relentless desire to execute.
             | Miss any of those things, and you can still be a a
             | multiplier, just probably not 10x.
             | 
             | Even so at my companies the difference between between good
             | engineers and bad is massive (a lot of the difference is
             | talent and motivation). Imagine you had a company full of
             | shitty engineers, a motivated good engineer in the right
             | could deliver 10x the value of some shit engineer
        
               | Shaanie wrote:
               | There's honestly quite a few developers that produce zero
               | or negative value (e.g. by implementing the wrong things,
               | introducing lots of bugs or significant complexity etc).
               | 10x:ing them is not difficult.
        
           | cvlasdkv wrote:
           | The reason people struggle with the idea of 10x programmers
           | is that people are very bad at evaluating the impact of
           | others. Obviously we can all agree on a select few but for
           | those who are just "regular" workers there is often not
           | enough context.
        
             | llaolleh wrote:
             | I think it's also because we have a lot of ego. Let's admit
             | it. There are some people who have a rare insight or
             | mobilize people and code in a way that provides 10x value
             | to the company and people.
             | 
             | Think about all the kickass Python libraries people have
             | wrote. Those provide 10x value across the board to entire
             | industries.
        
           | bingohbangoh wrote:
           | There was some tweet recently that went "Saying 10x engineers
           | don't exist is as true as saying 10x basketball players don't
           | exist or that all writers are basically the same." It's self-
           | evidently not true.
        
             | alerighi wrote:
             | No. It's like saying that a good mechanic can fix a car 10
             | times faster than another. Even if a good mechanic manages
             | to find the problem in less time than a non experienced
             | one, he still has to do the repair.
             | 
             | That is similar to programming: even if you have everything
             | clear in your head, you know how to do every single thing
             | that is written in the requirements of the program, you
             | still have to type it out.
             | 
             | A lot of time I thought, well this is fairly easy, and then
             | spent I month just typing out code.
             | 
             | The only situation where really a more experienced
             | programmer can be more or less 10 times faster than a non
             | experienced one is in debugging/troubleshooting problems,
             | because with more experience he tends to know by experience
             | where it's most likely that the problem is and thus test in
             | that direction.
        
               | marvin wrote:
               | You are misunderstanding the definition. A 10x developer
               | does not write code ten times faster than average. They
               | have ten times higher impact on the results of an
               | organization than average. And that's not far-fetched at
               | all. This does not magically happen. There are
               | individuals behind it, often a surprisingly small number
               | doing the critical work that visibly brings the world
               | forward.
               | 
               | It's not about writing a regular boring CRUD app that no
               | one cares about as fast as 10 regular developers. It's
               | about choosing the right problems to solve on their own
               | initiative, building the foundation of a technology
               | organization that can sustainably & quickly grow in scope
               | and users, being the first to solve a problem no one else
               | has understood such that the organization crushes their
               | competition and so on.
               | 
               | Leading the development of web software that scales to
               | 100 million users in 2003. Planning novel computer vision
               | algorithms to a vehicle fleet of millions of vehicles,
               | running on custom hardware they've also made
               | contributions towards. Realizing that consumer VR
               | headsets are now _just barely possible_ if you do
               | everything right, and bringing it to market. Etc.
               | 
               | This is the difference between a small organization being
               | capable of solving a difficult business problem and
               | achieving profitability, and not.
        
           | rpmisms wrote:
           | I accepted this long ago. I don't have the right brain to be
           | an uber-dev, I'm not technically gifted, I just have a high
           | enough IQ to brute-force my way through technical challenges.
           | 
           | I'm great at writing, simplifying technical concepts, and
           | strategizing on larger projects, so I try to work to those
           | strengths, which usually means making my PM's life a hell of
           | a lot easier.
        
           | iammisc wrote:
           | > It's as if the notion of people being arbitrarily born more
           | or less with a knack for something is evil.
           | 
           | The stretch from person A is a better programmer / SW
           | engineer than B to 'thus, person A is innately better' is
           | unnecessary.
           | 
           | In my experience, the programmer that spends more time
           | programming is almost always better than the one who does
           | not. You can hate side projects, open-source work, whatever
           | as much as you want, but IME, the programmers that engage in
           | that (and thus have multiple times more actual experience
           | than one who works 9-5) are universally the 10x people.
           | 
           | In other words, it's not innate intelligence... it's simple
           | effort and working towards improvement.
           | 
           | Now... there are some people that are truly just stellar, and
           | I can attribute perhaps some of this to innate ability, but
           | the difference between mediocre programmer and 10x is
           | typically one of hard work. Between 10x and the extremely
           | rare 100x... well maybe we can talk brain differences. Those
           | programmers are so rare though, it's futile to expect you'd
           | be able to hire them, since there's not enough supply. 10x is
           | good enough.
        
             | 5e92cb50239222b wrote:
             | > You can hate side projects, open-source work, whatever as
             | much as you want, but IME, the programmers that engage in
             | that (and thus have multiple times more actual experience
             | than one who works 9-5) are universally the 10x people.
             | 
             | The usual correlation-vs-causation disclaimer goes here.
             | How many open source developers spend time on it _because_
             | they produce good code?
             | 
             | I spent quite a bit of time on side projects and helping
             | (as I thought) others with projects that I like. After many
             | years of doing this I have come to the conclusion that I
             | simply cannot produce really good code. So rather than
             | being a drain on already overworked maintainers I decided
             | not to bother them anymore. Seeing a few others starting
             | 5-10 years later and quickly outrunning me is quite
             | discouraging, but such is life.
        
               | gavinray wrote:
               | > "I spent quite a bit of time on side projects and
               | helping (as I thought) others with projects that I like.
               | After many years of doing this I have come to the
               | conclusion that I simply cannot produce really good
               | code."
               | 
               | I have essentially no hobbies outside of programming, and
               | a ton of side projects + OSS contributions in free time
               | (check my GitHub) and I'm still no x10 dev.
               | 
               | Who cares if it's "GOOD" code -- did you have fun/did you
               | enjoy it? It surely couldn't have been SHIT code, because
               | you cared even the slightest degree.
               | 
               | Statistically, I figure most people writing code don't
               | give a rat's ass and are there to pay rent.
               | 
               | "GOOD" is just skewed by the fact that you can also write
               | code so brilliant it changes the course of humanity --
               | that's quite an upper bound to place on "great" or
               | "10/10" code.
               | 
               | -------
               | 
               | On the topic of "x10 Developer/Engineer" and terminology:
               | 
               | You know _" that 1 genius kid in the grade/school"_ who
               | is just on a completely different level -- that's been my
               | experience with these "x10" programmers.
               | 
               | There's a 17 year old in the Scala Discord (christ, she's
               | legally a CHILD!) that I thought was a 30-something with
               | some higher degree and was teaching me a bunch of stuff.
               | I about spit out my drink when it casually came up in
               | conversation from some older regular that she was 17.
               | 
               | Half of what she says I can't understand.
               | 
               | That's the sort of thing that comes to mind, for me
               | anyways. Even though I live and breathe code, I think I'd
               | have to be delusional to think I'd ever be as competent
               | as her.
               | 
               | I could maybe memorize the amount of KNOWLEDGE she has
               | currently, but there's a depth of understanding that I
               | can't begin to comprehend.
        
             | Joeri wrote:
             | I think it is more a case of "talent x perspiration =
             | skill". Everybody can get better by working at it, but some
             | people advance more quickly.
        
           | phkahler wrote:
           | I figure there are a lot of aspects to the job and I'm
           | exceptional at some of the ones most people suck at, and I
           | dont know much about some common things and can find that
           | embarrassing at times. The rest I'm average. So I try to find
           | work where I can bring those less common skills, and I try to
           | fill my gaps too sometimes. Everyone is different, find a
           | place that needs what you have to offer.
        
         | faizshah wrote:
         | This is the opposite of how you should want any knowledge
         | worker to think. If you believe that there's some innate
         | ability that makes people 10x better at a skill than you rather
         | than hours of practice and study then you are much less likely
         | to acquire that skill or learn those skills efficiently. You
         | need to have a growth mindset to be an effective knowledge
         | worker not a fixed mindset.
         | 
         | This is discussed in the book Make It Stick on learning
         | science, in chapter 7 they discuss how your own views on
         | whether skill is innate vs the result of practice affects your
         | own ability to learn and grow.
        
           | [deleted]
        
           | ryandrake wrote:
           | As your sports coach always said "You don't need talent to
           | practice!"
           | 
           | I'm not a huge believer of some mystical "innate ability"
           | that people sometimes use to explain talent. Imagine a great
           | concert pianist who plays flawlessly. After the concert,
           | someone says, "Oh, you were born with such a wonderful gift
           | of talent!" If I were that pianist, I'd be kind of offended--
           | it totally ignores the decades of daily practice it took to
           | get that good. Or a chess grandmaster. You're such a natural!
           | Oh yea? STFU, this took years of grinding!
        
             | qez wrote:
             | The capacity to practice is itself partially innate. Take a
             | person with ADHD - they will naturally have a harder time
             | practicing piano. I myself was unable to practice piano as
             | a child, but for different reasons.
        
               | dragonwriter wrote:
               | > Take a person with ADHD - they will naturally have a
               | harder time practicing piano.
               | 
               | Or easier. Depending on how the hyperfocus-or-none dice
               | roll for piano...
        
             | ferrumfist wrote:
             | Talent is used as a label by someone who doesn't understand
             | the practice involved in the given craft.
             | 
             | No one wakes up and paints a masterpiece. It takes years
             | and years of hard work and studying to get to a point
             | before you can even get close to masterpiece level.
        
           | VMtest wrote:
           | Couldn't agree more, thanks for this perspective!
        
           | baobabKoodaa wrote:
           | > This is the opposite of how you should want any knowledge
           | worker to think.
           | 
           | Some of us don't choose our beliefs based on what is most
           | convenient or most beneficial to us. Instead, we try to see
           | the world for what it is, truthfully (or as close to a true
           | representation of the world as it's possible to get, anyway).
           | If having a realistic worldview hinders my ability to learn,
           | then so be it. Not everything is about maximizing
           | productivity.
        
             | gopher_space wrote:
             | One thing I've learned in programming as well as life is
             | that Sources of Truth are deeply tied to individual
             | perspectives.
        
             | faizshah wrote:
             | If you read the book the researchers argue that worldview
             | is neither factual nor is it helpful.
        
               | baobabKoodaa wrote:
               | > factual
               | 
               | Nope. Just because it says so in a book doesn't make it
               | true. When you make a statement of the form "X does not
               | exist", a single counter-example is sufficient to prove
               | you wrong. Lucky for me, many such counter-examples
               | exist, and many have even been discussed in this thread.
               | I'll add one to the list: tourist (Gennady Korotkevich).
               | He's a competitive coder that's several orders of
               | magnitude (e.g. 1000x) better at coding competitions than
               | the average competitor. And the average competitor is a
               | few orders of magnitude better than the average
               | professional programmer who doesn't have algorithm
               | experience. All of this is measurable (at most we can
               | quibble about whether the skill differences are 100x or
               | 10000x or infinite). If you don't believe me, please go
               | and take a simulated Codeforces competition right now and
               | see how long it will take you to solve some set of
               | problems that tourist solved in under 2 hours (or if you
               | will be able to solve them at all - I certainly won't be
               | able to solve the hardest Codeforces div1 problems no
               | matter how much time I put in).
               | 
               | I have a feeling this mountain of empirical evidence was
               | insufficient to change your mind about this. I would
               | appreciate if you could take the time to explain why? Why
               | is this evidence not enough?
        
               | faizshah wrote:
               | I think you're missing the point or I was unclear. The
               | point is not that masters at a skill don't exist. The
               | point is that attributing their skill mostly to something
               | innate rather than practice, study, etc is not supported
               | by the body of research they review in the book (the book
               | is written for a general audience, their academic
               | research supports the arguments in the book).
        
               | baobabKoodaa wrote:
               | There is a mountain of evidence to the contrary. No
               | matter how much you or I would practice, study, etc. we
               | would never become as good as tourist. Most people reach
               | their plateau in competitive coding within 1 year.
               | 
               | For example, here's my Codeforces profile:
               | https://codeforces.com/profile/baobab
               | 
               | Started in 2015, plateau'd in 2016 and no measurable
               | improvement from subsequent 3 years of practice and
               | study.
        
         | dionidium wrote:
         | I don't know about producing in one day what it would take
         | another person 2 weeks to accomplish, but I do know there are
         | some core features of my company's app that were created by a
         | very talented developer that I don't think could be reproduced
         | by some of our junior developers in a year.
         | 
         | I think it's a mistake to conceive of the difference as one
         | between the tortoise and the hare, where the tortoise gets
         | there, eventually. There are bits of this code that the
         | tortoise just _wouldn 't ever_ end up producing if you gave
         | them _all the time in the world._
        
         | bigbizisverywyz wrote:
         | If nobody had previously succeeded then I would take the point
         | that Carmack was somehow unique, but by the time Doom came out
         | _lots_ of programmers had produced 3d games, and we had ray-
         | tracing and lots of graphics theory and implementation (e.g.
         | elite written in 6502 assembly on an 8 bit cpu).
         | 
         | >You think John Carmack was the only one trying to make 3d
         | games when Doom came out? Thousands of programmers where trying
         | to.
         | 
         | Yes Doom was a great game, and well programmed, but it didn't
         | really move the state of the art forward massively, as I would
         | argue that hundreds of programmers had already written and
         | published 3d games by that point.
        
         | xyzelement wrote:
         | > You know, 10x is an optimistic number here. Some programmers
         | will do in 1 day what you wont achieve in a life time
         | 
         | Exactly. There are many modes of that, and you named a few
         | examples. Another example, company has 2 systems maintained by
         | 10 people each. Someone comes in and figures out how to
         | generalize one of the systems to both cases, so they free up 10
         | of those programmers to go do something else.
         | 
         | Or - 10 people are beating their head on a problem for months,
         | someone comes along and says "it might be OK if we don't solve
         | that problem, let's move on"
         | 
         | Or - someone figures out that a system/module doesn't need to
         | be written because an out-of-the-box solution exists.
         | 
         | Like, I am not a 10X programmer in the sense that I can write
         | 10X the code of the next guy. But have I prevented
         | 10-people's-worth of wasted effort in my career? Yeah...
        
         | paxys wrote:
         | The myth part is that you can hire these 10x programmers by
         | asking harder whiteboard coding questions and they will sit and
         | close jira tickets for your company thereafter.
        
       | shantnutiwari wrote:
       | Agree with most of this.
       | 
       | > 1. I still don't know very much
       | 
       | Same here, Im still realising how much I dont know.
       | 
       | > The 10x programmer is a silly myth.
       | 
       | Yes it is. It's a stupid harmful myth. Everyone on HN and Reddit
       | think they are the "10xers", and its used as an excuse to be rude
       | and insufferable.
       | 
       | Some time ago, I decided I'd be happy being a 1x programmer[1]
       | 
       | > Don't mistake humility for ignorance
       | 
       | Very true. Some of the best engineers I worked with, those who
       | would never get job at these 10x companies, were quiet and
       | reserved. But when you actually talked to them, you realised it
       | was humility and a willingness to learn.
       | 
       | > Interviews are almost worthless for telling how good of a team
       | member someone will be
       | 
       | Yes, interviews are just a form of hazing. The survivors are
       | those who can stand the hazing, not the best programmers
       | 
       | 1. https://new.pythonforengineers.com/blog/confessions-
       | of-a-1x-...
        
         | Fordec wrote:
         | The 10x exists, I've met and worked with him and it's not me.
         | But it is a guy who graduated Stanford before he could legally
         | drive a car, so good luck finding many like him. But yeah, if I
         | had to use a word to describe him, humble would fit.
        
       | yoyar wrote:
       | It was alluded to in the list but I like this great quote:
       | 
       | "the best way to deal with complexity is to remove it"
        
       | JackFr wrote:
       | 30 years of experience, 2 more:
       | 
       | * You don't know what the hard part was until the software is in
       | production.
       | 
       | * If you know the right way to do it, do it the right way.
        
       | revskill wrote:
       | Programming to an interface rather than the implementation is the
       | only rule to me.
        
       | sunnyday1337 wrote:
       | I have seen many similar posts what people have learned but not
       | once have I seen:
       | 
       | "Don't assume anything".
       | 
       | So many times when shit hit the bricks because someone assumed
       | something about some other thing they clearly don't know
       | everything about. Which eventually lead to the system failing.
        
         | vbezhenar wrote:
         | That's a useless advice IMO. How can you not assuming anything.
         | I assume that my CPU works, for example. You can't write useful
         | programs without many assumptions. Imagine program that does
         | not assume that CPU works and reruns every algorithm few times
         | with few different code versions to verify that outputs match.
         | It might make sense for moon mission, but definitely not for
         | another CRUD app.
         | 
         | I don't have 20 years of experience yet. But my PoV is as
         | follows: assume as much as you can and ensure that if those
         | assumptions are broken, you have fail-fast-and-log triggers
         | (when it's possible). So when that trigger hits, you'll
         | understand what assumption is broken. For example in Java I'll
         | write Objects.requireNonNull(x, "x") and move on. If that
         | assumption is broken, I'll have stack trace in my logs and I'll
         | write additional logic. It won't take much time. But if that
         | assumption will not be broken, I just saved few hours of time
         | and few dozens of LoC from future maintenance.
         | 
         | Some people hate NullPointerExceptions and want to get rid of
         | them. I love them. They're incredibly useful for me.
        
           | throwaway858 wrote:
           | > I assume that my CPU works
           | 
           | This is not a blind assumption that you make, but one based
           | on lots of evidence (for example you are aware of the testing
           | procedures and QA processes of the CPU manufacture, and you
           | are aware that millions of people and companies use the same
           | CPU model as you and if there were bugs they would have
           | detected them).
           | 
           | If you were to buy some CPU that someone shady made
           | themselves in their basement, them you would probably not
           | make the assumption that the CPU works.
           | 
           | A lot of times programmers make assumptions without properly
           | verifying that the assumption is true, and that is when
           | problems happen. for example, when working with a library
           | function, the programmer might test that it works with
           | certain types of inputs and then just assume that it also
           | works with other types, without actually checking the
           | documentation or verifying
        
             | Piskvorrr wrote:
             | TBH, I got bitten by this assumption. Once, in the course
             | of many decades. A single flipped bit - in a place where it
             | never could happen in the program. After checking
             | everything up and down the stack, this was our conclusion:
             | "the issued command was invalid, thus caught and aborted;
             | the higher-level operation was rolled back, retried, and
             | succeeded; impact: some insignificant delay; root cause:
             | probably cosmic rays; probability of repeating:
             | infinitesimal. Result: no point in guarding against that."
             | (Note that this was in normal athmospheric conditions, not
             | in deep space, hence the probability.)
        
           | fesc wrote:
           | I completely agree with your second paragraph but the last
           | sentence seems like you don't know what people mean when they
           | say they hate NullPointerExceptions.
           | 
           | They don't mean that you just silently ignore the null value,
           | they mean that they would prefer to use a language that has
           | proper optional types.
        
             | Jensson wrote:
             | People tend to not languages without null though. They have
             | all those NullPointerExceptions in their mind and figure
             | coding would be easier if those didn't exist, but when you
             | give them that they don't like it. Null sits in a very nice
             | spot between dynamic typing and static typing.
        
           | Piskvorrr wrote:
           | I believe you are violently in agreement ;)
           | 
           | You are doing exactly that, assuming nothing. The number of
           | times I've seem "meh, x can't be null here, just do nothing
           | about it" (instead of some way of asserting that assumption,
           | such as you provide) is staggering.
        
         | pydry wrote:
         | It would be impossible to do any work at all without making
         | assumptions.
         | 
         | This attitude belies the fact that of the 1000s of assumptions
         | you make every day 1 or 2 will end up being incorrect, but it's
         | usually very, very hard or even impossible to know which in
         | advance.
        
           | danparsonson wrote:
           | Yes the point would better rather be made as "continually
           | question your assumptions" especially when troubleshooting
           | (hence the value of having a rubber duck).
        
             | pydry wrote:
             | The original point is invalid, although one could say that
             | being good at systematically validating and invalidating
             | assumptions is the sign of a good engineer.
             | 
             | One who doesnt make assumptions at all just wouldnt _do_
             | anything, though.
        
           | Aeolun wrote:
           | It's fine when you don't do it deliberately. It's just that
           | about 100% of the time someone says "I just assumed..." that
           | is the source of whatever problem you are having.
        
         | koonsolo wrote:
         | A colleague of mine always came with the quote: "Assumption is
         | the mother of all fuckups".
         | https://www.youtube.com/watch?v=7rr88Szc5q0
        
           | DoingIsLearning wrote:
           | A principal I worked with for a couple years, actually has
           | that quote up on the wall of his office. It is specially true
           | with projects where you have multiple teams or distributed
           | systems.
        
       | khazhoux wrote:
       | Anyone who denies the existence of the 10x programmer has either
       | simply not encountered one, or is blinded by their own ego. In my
       | 20 years in industry, I can think of maybe 10 engineers I've
       | directly worked with who were an order of magnitude above all
       | their peers in terms of both code volume AND quality.
       | 
       | These are people who will implement a feature with clean code,
       | well commented, well thought-out and meeting the exact need,
       | correctly structured, in the time that the entire rest of the
       | engineering team would still be scratching their head and
       | debating what to do. One guy years ago who refactored the entire
       | backend at a startup in 2 days, then asked "OK, what can I work
       | on now?" Another guy who wrote an IPC system we needed, which I'd
       | expected would take us 6 weeks, and he did it over the weekend
       | (and it worked perfectly). Another who debugged and patched a
       | critical infrastructure problem in a very complex system, in
       | about 2 days... and would do this time and again, just cranking
       | out features and fixes, week after week.
       | 
       | * "Oh, but their code must have been rushed!" It was fast but not
       | rushed. Some of the best code I've seen.
       | 
       | * "Oh, but they didn't consider user requirements." They did.
       | 
       | * "Oh, they must have been insufferable to work with!" For the
       | most part, super friendly and great teammates.
       | 
       | And so on.
       | 
       | So, sorry if it offends, but some people are just _much_ better
       | developers than everyone else around them (including, possibly
       | yourself). I was much happier after I realized and accepted this
       | fact!
        
         | [deleted]
        
         | beebmam wrote:
         | In my 20 years of industry at both small and large tech
         | companies, I couldn't disagree more with you. I'd also
         | appreciate if you toned down the insults.
        
           | khazhoux wrote:
           | It should not be an insult to be told that there are people
           | more skilled than you, though. It is hubris to think
           | otherwise.
           | 
           | Are you saying in 20 years, you haven't met any engineers
           | that were head and shoulders noticeably more productive than
           | their peers, in terms of code volume+quality?
        
             | philosopher1234 wrote:
             | There are undoubtedly developers who are 10x more
             | productive. But I doubt its because they are born smarter.
             | There are developers who are 100x more invested in their
             | work, and only 10x more productive.
        
       | Sohcahtoa82 wrote:
       | > "if they ask about time off in the first interview then they
       | are never going to be there!"
       | 
       | The fact that this attitude is common scares me when I'm doing
       | interviews.
       | 
       | Time off is incredibly important to me. What's the use of making
       | a great income if you can't get the time off to enjoy it?
       | 
       | The culture about the use of PTO varies wildly between companies.
       | A friend of mine worked somewhere that supposedly gave 20 days
       | PTO per year, but trying to actually use more than a single day
       | at a time was always met with denials, and even if you did take a
       | Friday off, you were expected to work 10 hours/day the other 4
       | days of that week to make up for it.
       | 
       | So yeah, when I'm interviewing, I want to know how much time
       | people are taking off, but I don't want the interviewer to think
       | I'm lazy and will be trying to avoid work as much as possible.
        
         | [deleted]
        
         | skeeter2020 wrote:
         | If the company thinks they have a good story around PTO they
         | will sell it in the first interview. As an interviewee it's
         | very important to me and I will definitely ask questions, but
         | later in the process when I have more leverage. I don't think
         | someone asking in the first interview is lazy, just perhaps
         | naive. They'd be better to ask about work/life balance and
         | expectations in general and then probe what the interviewer
         | answers back.
        
           | bluGill wrote:
           | At my company you get one interview, if you get a second
           | interview it is because we liked you but someone else was
           | better and passed your resume on to a different team. One
           | thing we do is take every candidate to lunch (COVID has
           | changed this of course) with someone who doesn't have input
           | into if you are hired: so feel free to ask those questions
           | that you are not sure about.
           | 
           | Having done a few interviews, nobody knows what questions to
           | ask.
        
             | swader999 wrote:
             | I always leave time off conversations to the offer
             | negotiation stage when I make it past the interview stage.
             | I want my time off in writing and if it's not enough I'll
             | ask for much more money before I accept.
        
             | adrianmonk wrote:
             | > _lunch_ ... _with someone who doesn 't have input_
             | 
             | I think part of this could be that they don't know whether
             | to believe that you truly have no input.
             | 
             | When I was an interviewee, my lunch escort told me they
             | didn't, and I was _pretty_ sure it wasn 't a devious trick
             | to get me to let my guard down, but I had no way of knowing
             | for sure. I also thought, if there isn't a formal process,
             | maybe if I say something too dumb or wrong, they would
             | still mention it to someone. So I stuck to really
             | superficial topics.
             | 
             | Then I got hired and later served as a lunch escort. Now
             | knowing the process and knowing there truly is no input, I
             | tried to convince the interviewee, and he didn't seem to
             | believe me just like I didn't when I was in his shoes.
        
           | rsj_hn wrote:
           | Correct. It is in the interest of the company to sell you on
           | all the perks and they should do that up front.
           | 
           | It is in your interest to view PTO as any other form of
           | compensation and to make those compensation demands after you
           | have demonstrated how valuable you are to the company via the
           | interview process. You don't start negotiating salaries
           | before the first interview, because that's a bad strategy.
        
         | linuxhansl wrote:
         | Usually I am more inclined to hire someone who discusses time
         | off during an interview. It shows that they think about their
         | life-work balance.
         | 
         | I do not need heroes, I need reliable folks who do not burn
         | themselves out.
         | 
         | Or to put it in a cliche... I need people who work to live
         | rather then live to work.
        
           | Barrin92 wrote:
           | and also importantly people who have family to take care of.
           | If someone comes to me and asks for time off because they
           | have children or partners or parents to take care off and
           | they take that seriously that certainly deserves some respect
           | 
           | would make a better impression on me than someone showing up
           | with a Patrick Bateman business card in hand
        
             | cat199 wrote:
             | plenty of people have families and abuse the crap out of
             | them, and people without families that want one still need
             | to socialize enough to meet people to eventually have a
             | family
             | 
             | book != cover
        
               | bluGill wrote:
               | We interviewed someone a while back and she said (without
               | being asked - asking questions on this line is illegal)
               | she was prepared to leave her husband and kids to move
               | here. It didn't affect our results, but we all agreed in
               | the discussion after that was a negative sign if we were
               | allowed to consider it. She probably would have been
               | good, I hope her search went well.
        
             | swader999 wrote:
             | Nobody should have to even give a reason for a time off
             | request if it's part of your work agreement.
        
         | 5faulker wrote:
         | Agree. If I were the interviewer I would probably do the same.
         | Asking about how people spend their life can also reveal a lot
         | about their personality as well.
        
           | bluGill wrote:
           | Asking about how people spend their life is often illegal to
           | ask. If you don't know the local laws only ask job related
           | questions. This is why my company gives me a script of
           | questions I'm allowed to ask - to get the conversation
           | started on legal topics in ways that are unlikely to stray
           | into illegal areas. (more than once I've had illegal
           | information given to me - but I didn't ask so that is okay)
           | 
           | Illegal information isn't anything that will affect how
           | someone does the job in general. You learn about personality,
           | but I hope you can deal with those personalities anyway.
        
         | xwolfi wrote:
         | The problem is not what's important to you when you do an
         | interview. It's not a friendly club, it's the guys who will pay
         | your rent for a while, just act like you pretend to understand
         | this, and ask by side channel, out of sheer strategy.
         | 
         | You CAN refuse once the contract arrives for signature, the
         | interview is a lot also for the company to have argument to
         | sell you to management as a worthy investment.
         | 
         | I admit I never take a guy talking about time off myself,
         | because while I agree it's an important contractual part and
         | something we must give as generously as we can, the fact he
         | asked the first minute of our relationship means it's going to
         | be painful for him and for us, because we're not a paradise
         | company, things can be tough and high pressure (investment
         | bank), people not nice on purpose and sometimes you have to do
         | the right thing rather than the perfect thing, so compliant
         | positive nearly sacrificial profiles will be happily surprised
         | by what's still good while a dude asking "and holidays, 20 or
         | 25 days" the first day will be very sad and burnt out by all
         | the shit.
        
           | heartbreak wrote:
           | > things can be tough and high pressure (investment bank)
           | 
           | > people not nice on purpose
           | 
           | Sounds like a miserable place to work.
        
             | bluGill wrote:
             | I've considered places like that - but none would offer me
             | 5x market pay. If they would pay me 5x what I'm worth - I
             | can save the extra for 5 years and then retire.
             | 
             | I'm not sure if I'd take such a job if it was offered, but
             | at least it would be an interesting offer.
        
           | rnotaro wrote:
           | Sounds like a toxic workplace environnement. I'm grateful
           | that my bank/employer cares about our work/life balance. A
           | burnout employee is not a productive employee.
           | 
           | I've stopped applying to place where they are not upfront
           | with their PTO / Salary brackets. It sounds like you don't
           | want people to take their PTO.
        
         | Spooky23 wrote:
         | The context is key. _First interview_.
         | 
         | The issue isn't taking time off, it's that the prospective
         | employee's head is up their proverbial ass. First interview is
         | propspecting. If you were selling a product, if the customer is
         | asking about the return policy before even selecting an option,
         | it's a similar signal.
         | 
         | When you're in a subsequent interview talking about the benefit
         | plan, salary, etc, that's where that sort of question is
         | appropriate - you're finalizing the deal.
        
           | redisman wrote:
           | Umm exactly? I'd rather get my own red flags out of the way
           | rather than waste 8h of everyone's time to find out the
           | company has a shitty culture. I also checksum the
           | compensation and on-call and other things in the first
           | interview
        
             | WalterBright wrote:
             | Like it or not, when interviewing for a job, you're doing a
             | sales presentation. A good sales presentation doesn't open
             | by saying what you want. It opens by finding out what the
             | customer's problems are, then you demonstrate that you can
             | solve them, then when the customer is sold the price
             | negotiation starts.
             | 
             | If you want to vet a company's benefits and culture
             | beforehand, which is a good idea, do the homework first and
             | research it before getting into the sales process.
        
               | ingvul wrote:
               | > Like it or not, when interviewing for a job, you're
               | doing a sales presentation
               | 
               | Maybe in the 90s. Nowadays it's becoming very balanced in
               | the way that companies are the ones who are doing a sales
               | presentation as well.
        
               | WalterBright wrote:
               | The company buys, the candidate sells. This is proven by
               | which way the money flows - from the company to the
               | employee.
               | 
               | But both have to agree. You're right that a company will
               | have to be willing to offer enough to get the candidate
               | willing to sell.
               | 
               | I recall interviewing a candidate long ago who was only
               | interested in what the company could do for him. He never
               | displayed any interest in the company or what he could do
               | for the company. I recommended no hire.
               | 
               | After all, what would you think if you went to a car
               | dealership and their salesman would only talk about how
               | much you had to pay and how much the dealership wanted
               | your money, and never talked about what the car would do
               | for you?
        
               | redisman wrote:
               | I understand that I have to bullshit people like you in
               | interviews and pretend to care.
        
               | WalterBright wrote:
               | Picking a career you're interested in and company you're
               | interested in makes things a lot easier than having to
               | maintain a phony facade.
               | 
               | A word of caution - interviewers tend to interview people
               | an order of magnitude or two more times than candidates
               | do interviews. What this means is they learn to detect
               | the bullshit. A friend of mine is in the recruiting
               | business. He interviews candidates all day, and has for
               | many years. He told me that detecting bullshitters and
               | liars is a crucial job skill, and he's pretty good at it.
        
               | redisman wrote:
               | I don't have to maintain a facade. Most companies don't
               | actually give a hoot if you buy into the CEOs
               | blabberings. They care if I can get my tasks done on time
               | and with decent quality. It's all a part of the Gervais
               | principle
        
               | WalterBright wrote:
               | You're right, but people know that someone interested in
               | the work is likely to do a better job. Also, my point is
               | about selling your ability to solve the company's
               | problems rather than focusing on "what do I get".
               | 
               | Besides, why not pick a career that interests you? It
               | makes for a better life.
        
               | bluGill wrote:
               | Maybe, but who dreams about envelopes? Yet society would
               | fall apart without someone making them. The same can be
               | said for the vast majority of things most companies make
               | - it needs to be made, but it is in reality boring.
               | 
               | All companies have interesting problems to solve along
               | the way. But most have boring products. I can work for
               | most companies because even though the product is boring
               | I know I will find something interesting. (the exceptions
               | are companies doing something I find immoral)
        
               | WalterBright wrote:
               | > who dreams about envelopes?
               | 
               | There are all kinds of people. That said, if envelopes
               | isn't your bag, nobody is making you interview with them.
               | Find something that does interest you. Me, I'd rather be
               | a lion tamer than a tax accountant (yes, I have the hat),
               | but the guy who does my tax accounting loves it.
               | 
               | > I know I will find something interesting.
               | 
               | And there you go.
        
               | WalterBright wrote:
               | P.S. 99.9% of the population regard my particular career
               | as super boring and fit only for the nerdliest nerds. The
               | opposite sex thinks it's about as attractive as
               | collecting chunks of concrete. Well, I am a nerdly nerd
               | and I enjoy it very much.
        
           | shoemakersteve wrote:
           | I find this line of thinking incredibly bizarre. If PTO is
           | important to the candidate, why should they waste their time
           | spending hours interviewing only to find out that the work-
           | life balance in this position isn't going to work for them?
           | To you that's _having their head up their ass_? God that 's
           | strange to me. I'm sure glad I don't work for people who make
           | sweeping judgements like that.
        
             | Spooky23 wrote:
             | You're looking for a job. You have 10 minutes to ask
             | questions that make you stand out, to a individual who
             | probably cannot answer the question.
             | 
             | You do you.
        
               | xyzelement wrote:
               | That's so spot on. Your Q&A session is your chance to
               | learn something real and convey what you care about. A
               | good question might me like "what's the hardest thing you
               | had to do this year" or "how did you make decisions in
               | cases of disagreement?" or something like that. It shows
               | you're thinking about the job and whether you're a right
               | fit.
               | 
               | High quality questions say something about you. Low
               | quality questions do too. Would you ever hire someone
               | whose question is like "so, do a lot of hotties work
               | here?" Probably not, because ... what kind of person is
               | this? Similarly, if the person who doesn't have an offer
               | and doesn't know much about the role is hyper-focused on
               | their time-off, something is off too. PTO is important,
               | it's just a thing you need to be thinking about once you
               | have an offer and think the job is otherwise a match, not
               | as like the #1 question.
        
               | bluGill wrote:
               | Depends. HR does everything they can to ensure I don't
               | consider the questions I'm asked when deciding if we hire
               | them. They can't stop me, but it is tricky to shoehorn
               | your questions into their form so I don't try.
        
               | redisman wrote:
               | Different priorities I guess. Personally I'm exchanging
               | my time for money and would like to know what kind of a
               | deal I'm getting. I'm too old for all the fluff bullshit.
               | 
               | Yes yes yes I'm sure you're changing the world and
               | creating super exciting CRUD
        
               | CRConrad wrote:
               | Hey, nothing wrong with CRUD; it's what makes the world
               | go around.
               | 
               | Not that that's anything like a reason not to ask what
               | you need to ask, and turn a Q&A into a brownnosing
               | session.
        
               | redisman wrote:
               | I know, I'm creating CRUD as we speak
        
               | verve_rat wrote:
               | Employment is a partnership, not servitude. That means
               | the employer needs to convince the employee to work for
               | them. I'm fine being rejected by a place that will treat
               | me like shit.
        
           | mileycyrusXOXO wrote:
           | Working a full time job with family and hobbies is incredibly
           | time consuming. I'm not going to squeeze in 6-10 hours of
           | interviews for a company before I ask an important questions
           | about company culture, PTO, benefits, salary etc. I'll ask
           | the questions I find important in the first interview, if it
           | isn't a good fit I just saved me hours of time interviewing
           | at a company I don't want to work at - and I just saved hours
           | of interviewing an employee they don't want to have.
        
         | 30minAdayHN wrote:
         | I'm hearing answers about why they would be either inclined to
         | or not inclined to hire based on that question. My opinion is
         | that it's just a question. Answer it and move on. Don't read
         | for patterns where they don't exist. This also reflects lot of
         | unconscious biases we might be nurturing by having strong
         | opinions about these.
        
         | didibus wrote:
         | Your quote of the article made me think I was going to hate the
         | advice, but then I realized you quoted it out of context,
         | here's the full quote:
         | 
         | > People might claim they have "signals" for these things...
         | "if they ask about time off in the first interview then they
         | are never going to be there!" But these are all bullshit. If
         | you're using signals like these you're just guessing and
         | turning away good candidates
        
           | gshulegaard wrote:
           | I had the same thought process.
        
           | DantesKite wrote:
           | That's a pretty huge distinction. Can't believe he
           | misrepresented the author like that.
        
             | Vinnl wrote:
             | If you re-read the comment with the assumption that they
             | were not trying to (mis)represent the author, it still
             | makes sense, so I don't think that was the intention.
        
             | Sohcahtoa82 wrote:
             | That was not my intention. I was operating under the
             | assumption that anybody in the comment section had read the
             | article first, since then it would have been known that I
             | wasn't quoting the author, I was quoting something the
             | author quoted.
        
             | TedDoesntTalk wrote:
             | Vote with the down arrow. Why is it the first comment in
             | this thread eden is complete nonsense?
        
             | qez wrote:
             | He didn't misrepresent or disagree with the author. He
             | added extra commentary on something the author brought up.
        
               | jussij wrote:
               | That is not how quotation marks are designed to work.
               | 
               | The words offered up as a quote are meant to represent
               | the views of the person being quoted. In this instance
               | that is clearly not the case.
               | 
               | This is a perfect example of how quotes can be used to
               | misrepresented a view.
        
               | ezekiel68 wrote:
               | The lack of context reltated to what the author wrote is
               | a sin of omission -- because anyone reading a top-level
               | comment that begins with a quote (like this) is, to a
               | first approximation, going to imagine the commenter is
               | responding to the position of the author.
        
               | heavyset_go wrote:
               | A sin or lie by omission requires intent, and the OP
               | stated their intent was not to misrepresent the author.
        
               | eyelidlessness wrote:
               | I think that's a good reason to read the linked article
               | before drawing conclusions about its contents from
               | discussion threads. Having read the article first, I
               | understood immediately that the comment was not
               | misrepresenting anything from the article, and that their
               | commentary bolsters the point made there.
               | 
               | And you don't necessarily have to read the article before
               | comments. I often don't! But when I encounter something
               | in comments which seems incongruous with what I'd expect
               | or hope to find in the article, that's a good prompt to
               | go ahead and read it to gain context.
        
           | ramraj07 wrote:
           | Maybe we should all ask this question in our interviews so we
           | can avoid these shitty teams that way!
        
             | TheCoelacanth wrote:
             | Unfortunately, there are too many different ways to be
             | shitty, so while it would filter out a few, a lot of shitty
             | teams wouldn't be detected by that particular question.
        
               | colecut wrote:
               | So you're saying we need more questions
        
           | Sohcahtoa82 wrote:
           | Ooof...re-reading my comment, I can certainly see your
           | interpretation.
           | 
           | It definitely was not my intent to paint the author of the
           | article as the person who made that quote.
           | 
           | Unfortunately, I can't edit my comment now.
        
         | brundolf wrote:
         | Yeah, if I ever discovered that a potential employer took this
         | view of PTO then I wouldn't want to work there anyway. Huge red
         | flag.
        
           | gregd wrote:
           | Small point: The author of the article does NOT have this
           | attitude. He's calling it out as a bullshit attitude...FWIW
        
             | brundolf wrote:
             | Whoops! I should have read the article. Edited.
        
         | chaoticmass wrote:
         | And then there are cases where you can take PTO, but you end up
         | having to work during that time anyway.
        
         | ghaff wrote:
         | This is especially true if the company uses "unlimited"/not-
         | tracked/etc. time. Otherwise, unless you know someone at the
         | place (and even then it can vary by group), you're left with
         | making assumptions about norms that may not be accurate.
         | 
         | Personally, I've never _not_ used all my PTO in a given year
         | and would consider being unable to do so a show stopper.
        
           | chinchilla2020 wrote:
           | I've heard the "unlimited PTO" policy referred to jokingly as
           | the "no PTO policy" at some shops.
           | 
           | Most companies are great about it though and encourage PTO.
        
           | heartbreak wrote:
           | The author's company avoids that "unlimited PTO" pitfall in
           | their job listings by describing the benefit as:
           | 
           | > generous time off
        
             | coldacid wrote:
             | That doesn't necessarily mean it's "unlimited". It could be
             | that you get eight weeks and they just don't say so.
        
               | rsj_hn wrote:
               | I think most people understand that "unlimited" does not
               | mean you can take half the year off. It means there is no
               | hard limit and it is up to a discussion between you and
               | your manager. 8 weeks is pretty generous.
        
           | theonething wrote:
           | I really like the policy of "minimum mandatory time off" some
           | companies have. That makes a big statement about where their
           | priorities are in terms of care for their employees' well-
           | being.
        
             | bluGill wrote:
             | Banks tend to have this policy because there are a lot of
             | ways to steel in ways that you can cover your tracks. But
             | most of those ways require regular effort to cover your
             | tracks, so if you are locked out of the office for at least
             | two weeks someone is likely to notice. Note that this is
             | two continuous business weeks. Nothing happens over
             | Christmas so that doesn't count.
        
             | Sohcahtoa82 wrote:
             | The company I'm at effectively has that as part of their
             | unlimited PTO policy, though the timing is company-
             | mandated, being the first week of August and the week
             | between Christmas and New Years, which is a week so many
             | people are likely to take off anyways, it just makes things
             | easier to make everyone take it off.
             | 
             | Going into the week off in August, I wasn't sure how
             | seriously they took it, but sure enough, I didn't get a
             | single e-mail that week other than weekly reports from
             | automated tools. I even checked Slack that Friday, and
             | there wasn't a single message except for the channel where
             | people post pictures of fun stuff they do over the weekend.
             | 
             | It was pretty nice.
        
               | ghaff wrote:
               | I pretty much hate policies that require you to take PTO
               | at specific times. They're almost never the times I would
               | choose to take on my own and are often at times it's
               | difficult to combine into a longer trip.
        
           | hinkley wrote:
           | Unlimited just means they don't have to pay out when you quit
           | or get laid off, doesn't it?
        
             | Sohcahtoa82 wrote:
             | I live in a state where that's not required, so it doesn't
             | happen anyways. -\\_(tsu)_/-
             | 
             | When I put in my two-weeks at my last job, my boss said
             | that if I can get all my work transferred in only a couple
             | days (I did, since I basically had almost no work, hence my
             | search for a new job), then I could just fill the rest of
             | my two-week notice time with my remaining PTO. No reason to
             | spend two weeks pretending to work at my computer.
        
             | ghaff wrote:
             | Yes, but it also doesn't give any indication of norms
             | around the amount of time off people take.
             | 
             | Expectations may differ from how much time is in a
             | traditional PTO bank but at least in general, it's OK to
             | take accrued time off barring special circumstances.
        
               | hinkley wrote:
               | I worked at a place that gave us 2 weeks and then took an
               | act of Congress and months of social engineering to take
               | even a day.
               | 
               | We got bought out and the new overlords announced they
               | were going to give us _five_ weeks of vacation. There was
               | actual laughter in the room. We can 't even use 2 weeks,
               | what's 5 gonna do for us?
        
               | redisman wrote:
               | We really need a new standard. Unlimited PTO Min 20
               | days/year. If you don't put a number then it's assumed to
               | be 0
        
             | johncessna wrote:
             | Yeap, PTO is a liability on the books and unlimited PTO is
             | a way to get rid of it.
        
             | coliveira wrote:
             | Bingo.
        
         | mandelbrotwurst wrote:
         | Someone who replies with that kind of hyperbole is just saying
         | they don't want anyone who is going to take more than a bare
         | minimum of PTO.
         | 
         | If you're dealing with a reasonable person, you should be able
         | to preface the question by explaining how having sufficient
         | time off helps you do your best work and avoid burnout, and
         | that you want to clarify expectations up front to make sure
         | that you and the company are an ideal match.
         | 
         | It's also of course a bit less risky to bring up this sort of
         | thing a bit later in the interview process when you've built a
         | bit of a rapport with the interviewer and ideally demonstrated
         | your value somewhat.
        
           | thomasahle wrote:
           | > If you're dealing with a reasonable person, you should be
           | able to preface the question by explaining how having
           | sufficient time off helps you do your best work and avoid
           | burnout
           | 
           | If you are dealing with a reasonable person, hopefully you
           | want have to explain any of that.
        
             | bluGill wrote:
             | If you are not dealing with a reasonable person you don't
             | want to work there anyway.
        
             | mandelbrotwurst wrote:
             | Sure, I've just found that it can be helpful to clarify
             | intent is all, especially when you're dealing with someone
             | you've just met - e.g. maybe the interviewer is mostly
             | reasonable, but is scarred from past negative experiences
             | with colleagues who were legitimately lazy. This phrasing
             | might help such a person understand where you're coming
             | from a bit more easily.
        
               | Cyph0n wrote:
               | If you need to clarify intent for something as
               | fundamental as work/life balance, wouldn't that be (at
               | best) a yellow flag?
        
               | redisman wrote:
               | This needs to not be a taboo. It's very important how
               | many days I get off, how many hours I'm expected to work
               | and if I'm expected to work nights and weekends. Those
               | are like my top 3 concerns, I don't really care about
               | your snacks or vision or stack to be honest.
        
         | ferrumfist wrote:
         | There's a delicate balance. I've worked on teams where it felt
         | like I could never rely on one team member because he was using
         | sick leave, personal days, PTO, and going to appointments at
         | every opportunity. I don't hold it against him personally, but
         | professionally it's hard to estimate workload for a given task
         | if one person on a team of 5 is hardly ever actually doing
         | work.
         | 
         | I've also worked on teams that, same as your friend, heavily
         | implied that taking longer leave breaks were a no-go.
         | 
         | As with all things, it's a balance.
        
         | sly010 wrote:
         | Think about it the other way, if they reject a candidate for
         | asking, it's their way of saying "The PTO situation is terrible
         | here".
        
         | coliveira wrote:
         | I think time off is very important, but you don't need to ask
         | it during the interviews. Just wait until they give an offer
         | and then ask for what you want.
        
           | skeeter2020 wrote:
           | agree: if you don't get the job it doesn't matter, and until
           | they offer you the job you don't have any leverage.
        
           | chrsig wrote:
           | so spend how much of my time and theirs going through the
           | entire interview process to find out the answer to a trivial
           | question that could make or break any final decision?
           | 
           | ....Or...and hear me out here...fuck that noise.
           | 
           | if people are making snap judgement about candidates from
           | asking a basic company culture/hr question during the
           | interview question, then the candidate winds up having dodged
           | a bullet one way or the other.
        
           | bbarn wrote:
           | Nah, just like salary, I'm getting a ball park range on that
           | topic before bothering to come into the office for an
           | interview. Otherwise, you're wasting other people's time and
           | your own.
        
         | decebalus1 wrote:
         | Spot on. I always ALWAYS ask about time off during interviews.
         | But I don't ask the manager because I found they always try to
         | stretch the truth or reframe shit.
         | 
         | I just ask the individual contributors how much PTO they've
         | taken in the past 12 months. It's more or less an open
         | question, doesn't necessarily means I'm interested in taking
         | too much PTO. You'd be surprised of how honest people are. I
         | had interviewees even start venting about burnout. Someone from
         | an e-commerce company (not Amazon) told me he's gonna take a
         | month off as he took 0 vacation days for the past 1.5 years
         | (!!!). He admitted he's probably going to get in trouble but he
         | doesn't care anymore.
        
           | bluGill wrote:
           | You should ask about vacation and sick leave both, not
           | generic PTO. The two can be very different, or the same
           | thing.
           | 
           | I get vacation that I'm required to take every year. I have
           | unlimited sick leave - but I actually have to be sick to use
           | it (going to the dentist for a regular checkup counts as sick
           | though)
        
         | aosmond wrote:
         | As I once told a boss who tried to cancel my already approved
         | vacation in a former job/company, you can't stop me from going.
         | You can only stop me from coming back. Let me know which you
         | prefer. (I really needed that vacation and I was done with
         | bullshit.)
        
           | eloff wrote:
           | Well put. I'm guessing there were no consequences, other than
           | to lower your already low opinion of the company?
        
             | aosmond wrote:
             | No consequences. I think my opinion truly hit the gutter
             | when I got that boss from hell :).
        
           | thanhhaimai wrote:
           | I had a manager who tried to cancel my vacation the day I was
           | at the airport for the flight. I had given advance notice,
           | and they agreed to it, especially when my vacation days have
           | been maxed out for months. Obviously I went for it anyway,
           | and left the team as soon as I come back.
        
         | m463 wrote:
         | I remember a friend who wanted to work for apple. He wanted to
         | take time off before he started.
         | 
         | They said "hey, we shutdown anyway during the holidays you can
         | take it then, just start now"
         | 
         | and of course, did he get to take that time off? NO.
        
       | ravenstine wrote:
       | I have some comments as a software engineer of 8+ years of
       | professional experience.
       | 
       | > 1. I still don't know very much
       | 
       | Yep.
       | 
       | > 2. The hardest part of software is building the right thing
       | 
       | That's definitely hard but I'd say it's the _people_ that are the
       | hardest part.
       | 
       | > 3. The best software engineers think like designers
       | 
       | I'm not sure I entirely agree. It's also in total conflict with
       | the growth economy the employs many of us; properly designing
       | stuff takes _time_. No matter what, I always end up in a
       | situation where  "they want this as soon as possible". Being able
       | to take the time to actually design something seems more like the
       | exception than the norm. The only way around it is experience so
       | that something resembling good design can occur by knee-jerk.
       | 
       | > 4. The best code is no code, or code you don't have to maintain
       | 
       | > 5. Software is a means to an end
       | 
       | > 6. Sometimes you have to stop sharpening the saw, and just
       | start cutting shit
       | 
       | Yes.
       | 
       | > 7. If you don't have a good grasp of the universe of what's
       | possible, you can't design a good system
       | 
       | Honestly, I don't that any of us have a good grasp of the
       | universe of possibilities. A "good" system is highly subjective.
       | Bad code is at least somewhat measurable if it doesn't work,
       | isn't efficient, or takes a long time for engineers to
       | understand.
       | 
       | There may be no such thing as good code. There's _working code_
       | and there 's code that fails to do its job.
       | 
       | > 8. Every system eventually sucks, get over it
       | 
       | I'd put an asterisk in front of "every". Many "good" systems turn
       | out to suck not only because people _ruin_ them but because
       | engineers learn, grown, and change. While I tend to hate
       | codebases more over time, there are some that I come back to
       | years later and am still impressed by.
       | 
       | > 9. Nobody asks "why" enough
       | 
       | Yes. This has to be part of company culture, however. Many get
       | defensive when subordinates question even the simplest of things,
       | no matter how much they encourage that you "ask questions".
       | 
       | > 10. We should be far more focused on avoiding 0.1x programmers
       | than finding 10x programmers
       | 
       | Maybe, but I've met more 10x developers than I have 0.1x. And
       | I've met exactly _one_ 10x developer.
       | 
       | There was one guy who got canned at the first company that I
       | worked for, and my bosses justified it because they thought he
       | "wasn't doing anything". In actuality, he was directed poorly.
       | Some people can just ignore bullshit management but others need
       | seniors who can provide direction and some level of mentorship.
       | That doesn't mean they are 0.1x developers. It may mean that team
       | leaders haven't managed to find that developer's particular
       | strength.
       | 
       | The closest I've found to 0.1x developers were some dudebros I
       | met during my education, but every one of them flunked out.
       | 
       | > 11. One of the biggest differences between a senior engineer
       | and a junior engineer is that they've formed opinions about the
       | way things should be
       | 
       | I've always had opinions so I'm not sure I relate to this as a
       | senior engineer. I have _more_ opinions, and sometimes more
       | nuanced ones, but in many ways I feel similar to how I did as a
       | junior engineer. I 'm frequently astounded by how much more I
       | need to learn.
       | 
       | I guess the major difference I see is in the _kind_ of opinions.
       | Many juniors have opinions, but they are largely additive. Senior
       | engineers who have been in the battle field long enough have
       | opinions but they 're more _subtractive_ , or saying "you know,
       | we don't need to add more steps to our toolchain, and maybe we
       | don't need another framework".
       | 
       | > 12. People don't really want innovation
       | 
       | Innovation rocks the boat for businesses beyond a certain "escape
       | velocity" and what many consider "innovative" is actually
       | confusing since innovation by definition is _non-standard_.
       | 
       | > 13. Your data is the most important part of your system
       | 
       | > 14. Look for technological sharks
       | 
       | > 15. Don't mistake humility for ignorance
       | 
       | Yes.
       | 
       | > 16. Software engineers should write regularly
       | 
       | Meh.
       | 
       | > 17. Keep your processes as lean as possible
       | 
       | If I had things my way, I'd get rid of "standups" and "retros",
       | uninstall unadulterated bullshit like Pivotal Tracker in favor of
       | something much simpler like Trello or even a Google spreadsheet,
       | eliminate estimations, and only have meetings that are goal
       | oriented.
       | 
       | > 18. Software engineers, like all humans, need to feel ownership
       | 
       | > 19. Interviews are almost worthless for telling how good of a
       | team member someone will be
       | 
       | > 20. Always strive to build a smaller system
       | 
       | Yes.
        
       | StatsAreFun wrote:
       | 5. Software is a means to an end
       | 
       | Yes, yes and yes. Many times we lose sight of the fact our job is
       | to support the business (money-making) functions of the company.
       | The software itself isn't the end-all-be-all point of what the
       | organization does unless you write open source software all day
       | long and survive off donations. My gut tells me that most
       | departments are like this and sees themselves as the core of the
       | company but I think software engineers think of themselves more
       | highly than most (and more highly than they should). A bit of
       | humility would really help - myself included more than most
       | probably.
       | 
       | I agree with a lot of what he says... A few points are a little
       | off IMHO but I've only been doing this for a few more years than
       | this gentleman. Perhaps I'll feel differently in a few more. :)
        
       | lukaslalinsky wrote:
       | I'd say the top lesson I learned is that when you get a list of
       | requirements from someone, most of the time they are not 100% set
       | on them and if they agree to change something very minor, it can
       | allow you to create significantly simpler solution and all
       | parties will benefit from that.
       | 
       | Junior developers often get lost while trying to design a super
       | complex system, which satisfies all the requirements, while it
       | doesn't really need to be that complex.
        
       | brabel wrote:
       | > You can design the most technically impressive thing in the
       | world, and then have nobody want to use it. Happens all the time.
       | 
       | Very true... just yesterday someone posted about the Pony
       | language main user switching to Rust:
       | 
       | https://www.wallaroo.ai/blog-posts/wallaroo-move-to-rust
       | 
       | Despite Pony being an impressive programming language,
       | technically, with a lot of promise, pretty much only one company
       | ever used it and now that it's moved on, Pony is pretty much in
       | the camp "no one uses it".
       | 
       | And much of it is serendipity. A few tiny things could've
       | happened differently, and now everyone would be talking about
       | Pony, not Rust. Similarly, perhaps, happened with Ceylon (anyone
       | remembers that??) VS Kotlin.
        
       | SMAAART wrote:
       | Not a Software Engineer here, but in Operation here:
       | 
       | 1. This is great advice
       | 
       | 2. The overall spirit applies to any and all roles across any
       | company.
       | 
       | 3. YMMV
        
       | unobatbayar wrote:
       | The sad realisation that I'm the 0.1x software engineer.
        
         | halfmatthalfcat wrote:
         | Maybe software engineering isn't for you? Not judging you but
         | if you admit to being 0.1x, why continue to do it?
        
           | unobatbayar wrote:
           | I really hope software engineering isn't the problem. I love
           | building software; Thinking about creative solutions, trying
           | to apply the right design pattern in the right context and
           | all.
           | 
           | Seeing myself in 3rd person, the main reason why I'm 0.1x
           | engineer is attitude/motivation problem. Not having power
           | over specification/design, reading bad code, seeing a bad UI
           | specification, or when my code doesn't work is enough for me
           | to start complaining, getting super pissed and not get
           | anything done.
           | 
           | I just can't work for other people, and really believe if I
           | leave, many people would have the biggest sigh of relief.
        
       | begueradj wrote:
       | "If you don't have a good grasp of the universe of what's
       | possible, you can't design a good system"
       | 
       | That is what the "old" models such as waterfall say: as a first
       | phase, complete and accurate software requirements list to be
       | captured in a product requirements document
        
         | dgb23 wrote:
         | You are conflating process with design. You can have an
         | iterative process and still take time to think, design and
         | specify things.
        
       | Tade0 wrote:
       | 10. I don't think the bottom end of the scale is zero. I've seen
       | people being actively harmful to the project.
       | 
       | That being said where you lay on the scale depends on context.
       | 
       | In my previous project I was a [-0.25;0.25], so I quit, because I
       | was miserable and so were my teammates who had to work with me.
       | 
       | Now I'm doing great and even helping others be more productive.
        
       | johnmato wrote:
       | This is an interesting perspective. As a developer, I already
       | realized that there's too much to learn as our technology is
       | progressing rapidly.
        
       | l2cluster wrote:
       | > 11. One of the biggest differences between a senior engineer
       | and a junior engineer is that they've formed opinions about the
       | way things should be
       | 
       | I found that another thing which separates a junior from a senior
       | is tendency to give up and cut corners. Stuck a wall making that
       | integration test work? get back to it after the current task,
       | don't settle on manual testing.
       | 
       | But maybe that's a trait of bad developers, rather than junior
       | ones.
        
         | axegon_ wrote:
         | I really disagree with point 11. I've seen and worked with so
         | many "senior" engineers who had wretched opinions about
         | everything. One thing in particular is what I like to call
         | "perl behavior". The structure and logic makes perfect sense to
         | the developer but is borderline gibberish to anyone else.
         | Eventually senior software engineers enforce their view as the
         | baseline(which is over flooded with anti patterns) to junior
         | developers and they too end up pouring buckets of the same
         | gibberish everywhere. For example custom built linters which
         | partially follow some standard, and partially doing the
         | complete opposite of what the standard says. But you know...
         | The senior engineers enforce it and 2 years down the line when
         | the junior jumps into another job, it's back to the basics all
         | over again. Anyone with X number of years of experience has
         | strong opinions, that does not make anyone "senior". To my
         | mind, point 11 should be the ability to consider, shift or
         | change your strong opinions when presented with an alternative.
        
         | sdevonoes wrote:
         | Umm, I don't agree (with OP). Senior (or juniors, if it
         | matters) engineers who have strong opinions about anything are,
         | in my limited experience, very stubborn and difficult to work
         | with. I find myself more and more answering with "it depends,
         | give us more time to see what can be done/what tools we can
         | use".
        
       | winternett wrote:
       | In my 22+ years of work as an Engineer/Architect, I've found
       | that:
       | 
       | 1. Software development skill means nothing if the power goes
       | out, always cultivate other skills and passions, those passions
       | will drive you to develop more meaningful, functional, and well
       | informed tools.
       | 
       | 2. My resume never parses correctly on the job application, no
       | matter how big the company is, and I'll always have to retype it
       | over again.
       | 
       | 3. The level of functionality on each company's web site job
       | application tool tells you everything you need to know about the
       | development quality and talent within each company.
        
         | kreeben wrote:
         | >> resume never parses
         | 
         | Every time I rewrite my CV I always think, finally it's picture
         | perfect. Next time I revisit it, because I'm looking for
         | another job, I always think, who the F wrote this piece of
         | crap.
         | 
         | I'm either slowly making progress or I'm running in circles.
        
           | winternett wrote:
           | I found a lot more success in the working world once I choose
           | to just embrace the "normalcy" of certain things that
           | routinely don't make sense in the working world, and to
           | simply try to make what I can make work better.
           | 
           | The working world is really nonsensical and absurd if you ask
           | me, but the end goal of doing a job for money that in turn
           | allows me to do things that "make sense" to me is the payoff.
           | 
           | Self Sacrifice is sometimes necessary for success, but it is
           | a finite resource, and can hurt or destroy you if not
           | carefully applied (the simple equation)
           | 
           | A resume just needs to show the mountains you've climbed
           | against the odds, without lamenting about the battle scars
           | you got along the way... Resume formatting is really just
           | fluff, that you don't need if they need you because you've
           | proven that you can climb real mountains. :P
        
       | ipaddr wrote:
       | "Nothing worries me more than a senior engineer that has no
       | opinion of their tools"
       | 
       | Nothing worries me more than the opinioned. Open your mind. You
       | shouldn't have deep opinions on your tools because they change,
       | your need and understanding of them changes.
        
       | wnevets wrote:
       | There are so many items on this list that I've internalized over
       | the years and this has done a great job breaking them down into a
       | paragraph of text.
        
       | sas224dbm wrote:
       | Learned: software that you write will ALWAYS be for other people
       | to pick-up, and that is hard. Keeping things simple is a tool to
       | that end.
        
       | dragonwriter wrote:
       | > The 10x programmer is a silly myth. The idea that someone can
       | produce in 1 day what another competent, hard working, similarly
       | experienced programmer can produce in 2 weeks is silly.
       | 
       |  _N_ x programmers for _N_ >1 are mostly not _N_ x cowboy solo
       | code slingers, lots of gains are in enabling other members of the
       | team.
       | 
       | The idea that programmer contributions to output are all in solo
       | code slinging is a close cousin of the myth "programmer
       | contributions can meaningfully be measured in lines of code".
        
         | ljm wrote:
         | At some point, you start to become effective not by churning
         | out code faster than anyone else can do it, but by anticipating
         | upcoming blockers and clearing them out before they become a
         | problem for the team. You're able to use a holistic insight of
         | the project to your advantage in order to keep the team's
         | efficacy to a high level.
        
       | mooreds wrote:
       | I loved a lot of this list, but the best part was the disclaimer
       | in front. I've given talks about software development in the past
       | and usually start with a similar disclaimer.
       | 
       | If I am giving you advice, you should know my context. It'll help
       | you determine if my advice is useful in yours.
       | 
       | Bravo!
        
       | nicholast wrote:
       | If you try to wait for the money making opportunity in order to
       | build something it may never come. Just start building. Keep
       | building. There are more ideas at the end of a long path than
       | there are at the start. If you don't keep building they will
       | remain unseen.
        
       | hhyndman wrote:
       | An excellent article. Thank you for your insights. I used to run
       | a software engineering practice and I must admit that almost all
       | of your points resonated with me.
       | 
       | I'd like to add that one should catch oneself when falling into
       | the "Perfect is the enemy of good" trap. As engineers, we would
       | like things to be perfect, but sometimes at the peril of late
       | delivery, little feedback, and development of features not
       | required.
        
       | vishnugupta wrote:
       | > 13. Your data is the most important part of your system
       | 
       | +1. Most (including me) internalise, if at all, this lesson the
       | hard way through trial and error.
       | 
       | I wish this is was taught in colleges. Software is mostly about
       | manipulating data and it's a pity that not much is taught in a
       | structured manner about building systems around data.
       | 
       | I expected Domain Driven Design (DDD) would address this but it
       | doesn't.
        
         | brianmcc wrote:
         | Agree. This is one hill I would choose to die on, data is so
         | much more important and valuable than code.
         | 
         | Database design - normal form, relations, etc - was a major
         | part of my education. Surely that's not unusual?
        
         | JackFr wrote:
         | Thirty years ago at my first job, a senior dev told me "2% of
         | what we do is interesting. 98% is sort, select, sum."
         | 
         | (I think then that was more or less true, but the numbers in
         | the industry as a whole have gotten a lot better in the past 30
         | years. And I've gotten better jobs.)
        
         | Aeolun wrote:
         | It _is_ taught. And then you enter the real world and you find
         | that everyone just ignores this shit whenever it is convenient
         | (and unsurprisingly the data is garbage).
        
       | ctrlp wrote:
       | This is a great list. Really appreciate all the experience.
        
       | jjice wrote:
       | I liked 8 a lot
       | 
       | > Every system eventually sucks, get over it
       | 
       | I'm a fresh recent grad developer, and this is good to know to
       | calm me down from over architecting. I'll do my damnedest, but
       | it's to know it's not awful if things get a bit messy eventually.
        
         | dgb23 wrote:
         | A better way to phrase this is that there is always room for
         | improvement but we don't have infinite time. Deciding what to
         | improve when is a skill.
        
       | agomez314 wrote:
       | "We may be the culmination of our experiences, but we view them
       | through the lens of the present."
       | 
       | This is so important. I think a lot of the advice given out there
       | comes with the bias of having been successful doing it. There are
       | countless others who have tried to scale the same ladder, doing
       | the same things even, and still did not achieve the same success.
        
       | wccrawford wrote:
       | "Interviews are almost worthless for telling how good of a team
       | member someone will be"
       | 
       | Just like "avoid the 0.1x programmers", interviews are for
       | weeding out the really bad team mates. They aren't for finding
       | the best ones.
       | 
       | For instance, I and a female programmer do the interviews. During
       | one interview, my coworker kept asking questions of the
       | candidate, and he would not look at her when he talked. He would
       | actually talk to _me_ instead while answering her questions.
       | 
       | My first through was that he was misogynistic, which is an
       | automatic disqualification. But even if he was just shy, he's
       | going to have to work with her _daily_ for the first few months,
       | and be in meetings with her for the entire time he worked there.
       | 
       | That's an extreme example, but there were plenty of instances
       | where we were looking for the best candidate, and the interview
       | made the decision easier when the code hadn't. We can only hire 1
       | candidate, and we have to do what we can to pick the one that
       | will do the best work and get along best with the team.
       | 
       | That's what interviews are for.
        
       | brightball wrote:
       | It's rare that I see a post where I agree with it enough that I
       | probably could have written it, but here we are.
        
       | tshanmu wrote:
       | 4. The best code is no code, or code you don't have to maintain
       | 
       | 5. Software is a means to an end
       | 
       | these x1000!
       | 
       | Thanks for a very succint, distilled list.
        
       | dom96 wrote:
       | This is a great list, I often wonder how people come up with such
       | lists. Is it a long-term conscious effort to write down points
       | like these as they come to you or do they sit for a few hours and
       | these points come to their mind. I can't imagine being able to
       | compile such a good list in a day.
        
       | n_time wrote:
       | Wish there was more philosophy of science and exploration into
       | what "technology" means in CS programs. Maybe get undergrads to
       | read Crime and Punishment by Foucault. Not saying he's the be-all
       | end-all but just that perspective of seeing technology as
       | subjective and situated in historical contexts.
       | 
       | Technology in CS ends up instead being taught to be magical
       | progress fuel that brings us towards the inevitable future rather
       | than tools built by people with access to capital in order to
       | achieve specific ends
        
         | beaconstudios wrote:
         | I feel that programmers in general have a lot to learn from the
         | postmodernists. Learning about social constructivism alone can
         | teach you a lot about how to think about abstractions.
        
       | legohead wrote:
       | most valuable lesson I've learned in 20 years:
       | 
       | * companies and/or owners don't care about you. take everything
       | you can get and don't be shy about it. don't listen to them when
       | they continually tell you that you're "highly paid"
        
       | cbovis wrote:
       | Excellent advice. I would add:
       | 
       | Showcase your work as much as possible and refine your ability to
       | do so over time - Not only does regular showcasing of things
       | you've built improve your reputation within a company but also
       | allows you to disconnect from the implementation and focus on how
       | something will be used. You'll often find bugs, shortcomings, or
       | opportunities for improvement that you may otherwise have
       | overlooked. Look for opportunities to showcase wherever possible
       | and advocate for opportunities if they don't exist already.
        
       | ChrisMarshallNY wrote:
       | I like the advice (and the "context" caveat, at the start).
       | 
       |  _> The best code is no code, or code you don't have to maintain_
       | 
       | I always say "The best code I write, is the code I don't write."
        
         | janto wrote:
         | I always say "code is a liability".
        
           | ChrisMarshallNY wrote:
           | I remember seeing a .sig someone had, that said something
           | like:                   I hate code, and want as little of it
           | as possible in my programs.
        
       | scottious wrote:
       | > I'd rather someone give me opinions that I violently disagree
       | with than for them to have no opinions at all.
       | 
       | I've been a developer for 15 years... anybody else feel like the
       | further they get into their career, the more they want to keep
       | their opinions to themselves?
       | 
       | I feel like as a junior dev I had way stronger opinions and I was
       | a lot more vocal about them. Now, I still have opinions, but I've
       | learned that nobody gives a damn about my opinions so I just keep
       | them to myself.
        
         | PragmaticPulp wrote:
         | Having opinions is good, but only if they're genuinely informed
         | opinions and everyone is willing to disagree and commit.
         | 
         | I've worked with too many people who think that their opinions
         | are their identity and defended them as such. A difference of
         | opinions shouldn't become an excuse to go to war with your
         | coworkers or argue endlessly instead of getting things done.
         | 
         | One of my worst work experiences was with a team of developers
         | who were old friends from a college debate team. We could never
         | have any productive discussions because they entered every
         | conversation intent on _winning_ instead of having an honest,
         | productive conversation.
         | 
         | The best engineers I've worked with have had strong opinions
         | but have also been happy and willing to go a different way if
         | that's what the team decides as a whole.
        
         | jimmyvalmer wrote:
         | Junior dev: Let's use this amazing algo I learned in school!
         | 
         | Senior dev: This won't work but it's no use explaning why since
         | they've made up their minds (as have I).
        
         | chronofar wrote:
         | Most people mostly care about his/her own opinions, and others
         | opinions only insofar as they reflect on himself/herself (even
         | though of course the others are also thinking about themselves
         | mostly), we're hopelessly self-involved creatures like that.
         | Nonetheless there is inertia and subtle shifts that can come
         | from sharing them, and though it may often feel like coming up
         | against a brick wall if you look in the right way you'll see
         | the bricks may be aligned a bit differently, and you can trace
         | some of those differences to opinions you may have expressed.
         | 
         | As always the wise approach is probably somewhere in the
         | middle, in this case choosing your battles. You don't have to
         | voice every opinion, but you shouldn't be silent if you have a
         | strong and well-formed opinion about something important.
        
         | hereforphone wrote:
         | It's the same in any area of life and is called maturity.
        
         | jb3689 wrote:
         | All said and done I think you tend to learn that opinions are
         | just that - opinions. Often a team doesn't need more opinions,
         | they need to make decisions and come to consensus, so helping
         | them decide on which opinion is best is more important than
         | bringing yet another complicating-but-not-discussion-
         | progressing vote to the table
        
         | marcus_holmes wrote:
         | No, I've been doing this for ~30 years now and I have _really_
         | strong unpopular opinions on things. Like:
         | 
         | - NPM/Yarn/Gems etc is a disaster waiting to happen. Having
         | lots of dependencies is a security nightmare and a maintenance
         | issue. As these projects get dropped by their original
         | maintainers we'll start seeing more supply-side attacks and
         | more vulnerabilities going unpatched.
         | 
         | - Docker is a great solution for a specific problem. But I
         | don't think it needs to be used for _everything_. Same for K8s.
         | Same for microservices architecture.
         | 
         | - Simplicity is an important design goal for all systems.
         | Complexity breeds bugs. Boilerplate is simple. DRY can be taken
         | too far. Every abstraction layer leaks at least a little.
         | "clever" code is usually not what is needed for reliable
         | software.
         | 
         | I expect to get downvoted because these are unpopular opinions.
         | But I'm used to arguing about them. It's always interesting to
         | discuss.
        
           | travisgriggs wrote:
           | Fellow 30+'er here...
           | 
           | You had me at
           | 
           | > - Simplicity is an important design goal for all systems.
           | Complexity breeds bugs. Boilerplate is simple. DRY can be
           | taken too far. Every abstraction layer leaks at least a
           | little. "clever" code is usually not what is needed for
           | reliable software.
           | 
           | Nuff said.
        
           | ryandrake wrote:
           | Those seem like pretty unobjectionable opinions. Have an
           | upvote!
           | 
           | You want a controversial opinion (on HN), how about mine:
           | 
           | "It's not always a good tradeoff to throw something under the
           | bus to save developer time."
           | 
           | So many important things are routinely sacrificed at the
           | altar of developer speed and comfort, app runtime performance
           | being the big one. It's used to justify all sorts of crazy
           | things we do in modern software to ship faster, but so hard
           | to push back on because developers are expensive and software
           | needs to be done yesterday.
           | 
           | Some things are worth giving up so that developers can move
           | faster, but I argue not everything. Need to evaluate case by
           | case.
        
           | paxys wrote:
           | Quite brave to share these unpopular opinions like "npm is
           | bad" on HN.
        
           | ItsMonkk wrote:
           | Last month I ran into The Principle of Least Power, and it's
           | grabbed me and the more I think about it, the more it
           | expands. I think all of your statements lines up with this
           | principle, except one.
           | 
           | Containers are a simpler solution than Operating Systems.
           | Operating Systems is a tightly bound non-simplistic system
           | that breeds complexity, just as you state npm does. Because
           | those interfaces are tightly bound, we were not about to
           | build on top of them. Almost immediately after we got Docker,
           | we got K8s. Once we got Docker we got the ability to manage
           | these things at a higher level. That's the mark of a more
           | simple solution.
           | 
           | Are there things that Docker can't do? Are there things that
           | require so much performance that Docker can't handle it? Only
           | then should you step back to the more powerful solution.
           | 
           | Not to say that there aren't problems with Docker.
           | Dockerfiles have a lot to improve. Running containers has a
           | lot to improve.
           | 
           | I think. I'm still at a state where I might change my mind.
           | It's partially why I'm posting this.
           | 
           | [0]: https://blog.codinghorror.com/the-principle-of-least-
           | power/
        
           | Fiahil wrote:
           | > I expect to get downvoted because these are unpopular
           | opinions.
           | 
           | Well, not really. These opinions are very common among my
           | peers. We sold multi-million dollar transformation projects
           | with the stated goal of making things simpler and easier to
           | use and understand.
        
           | sangnoir wrote:
           | > Simplicity is an important design goal for all systems.
           | Complexity breeds bugs
           | 
           | Counterpoint: some problem-spaces are inherently complex;
           | _most_ problem-spaces have hidden complexity. _Complexity
           | cannot be removed_ , it can only be moved up or down your
           | tech stack, and obviously, you can needless add more
           | complexity.
           | 
           | Docker, K8s and the like are perfectly fine when they fall
           | below your project's complexity floor - they are good place
           | to shift your complexity to as they are battle-tested and
           | well-documented. If your projects complexity floor is lower
           | than docker/k8s, then integrating them will just increase
           | your solutions complexity needlessly.
        
         | d23 wrote:
         | I pick my battles pretty judiciously these days. I've learned
         | that a huge amount of what people talk about doing ends up
         | going nowhere anyway, so why burn the energy and look
         | disagreeable? A lot of people with bad ideas also aren't very
         | good at getting things done.
        
         | barbazoo wrote:
         | For me it's more a matter of putting those opinions into
         | perspective. Example: I still highly value good API design but
         | I'm not getting into debates anymore if an endpoint isn't
         | RESTful or 100% consistent with every other endpoint. It's
         | often just not that important at the end of the day.
        
         | TameAntelope wrote:
         | What a depressing reaction to adversity. An alternative
         | reaction is to try and figure out _why_ nobody cared, and get
         | better at expressing yourself in ways that people _will_ care.
        
         | davemo wrote:
         | It comes in waves. I'm in my 22nd year of developing software
         | and I can reflect on times when I felt incredibly confident and
         | didn't shy away from sharing my opinions, and other times when
         | I felt like it was better to remain silent because I had things
         | to learn from others.
         | 
         | There are times for both speaking and listening in our careers;
         | as I've progressed further in my career I have felt it is often
         | more valuable to exercise active listening.
        
         | dosethree wrote:
         | The longer you are in a career, the more you realize opinions
         | are one of those things that always change (and should). Strong
         | opinions weakly held
        
         | JackFr wrote:
         | I got dinged in a 360 review by peers for not advocating for my
         | views more.
         | 
         | I feel that if I present what I think we should do, and why I
         | think it's the best alternative, I shouldn't have to get into a
         | shouting match or even a debate. I don't take it personally if
         | people disagree with me.
         | 
         | If I've got the best ideas and my managers are ignoring them
         | for the loudest ideas, that's on them, not me.
        
         | allenu wrote:
         | Same here. Been working professionally as a dev for 20 years
         | and each year I care less and less about changing other
         | people's minds about architecture.
         | 
         | Just this year I was working with another team that wanted to
         | move to an architecture that I thought was overengineered for
         | their specific problems. They shared with me an article about
         | some company that was using it. I explained my experiences with
         | such a pattern and where the pitfalls were, hoping their lead
         | dev would think about it or discuss the pros and cons. Well, it
         | was met with silence. They went ahead with their plan anyway.
         | 
         | Too many times that's happened in the work world, so at least
         | now I don't invest a lot of effort into changing minds. Best
         | advice
         | 
         | I've learned these last few years is don't tie yourself to your
         | work. If you're opinionated about how to do things because you
         | love designing software, that's great, but you're setting
         | yourself up to be disappointed by how things really get done.
        
         | ozim wrote:
         | I think that is also because as a Junior one thinks that he
         | should have opinions and be vocal about them and be right to
         | further their career or to become Senior/Manager/Leader. Just
         | like getting good grades in school you would have to put your
         | hand up and tell that smart thing to the class/teacher.
         | 
         | After couple of years people realize that just having opinion
         | and being vocal about it does not make one a
         | Senior/Manager/Leader. There is much more to it and one learns
         | about it on the job.
        
       | papito wrote:
       | # 20 - Always strive to build a smaller system, is probably the
       | most important one. The new generation of engineers have yet to
       | learn (again) that complexity kills. The amount of resources
       | spent maintaining unnecessary complexity is staggering. _Your
       | small thing does not have to be a distributed system_.
        
       | austincheney wrote:
       | Point 12 is objectively the most true in practice.
       | 
       | In my 20 years of experience quality of software engineer comes
       | down to personality, the ability to make decisions based upon
       | evidence more than intuition and the ability to make decisions in
       | the face of insufficient evidence. There is a certain vision of
       | systems that cannot be taught as many people are incapable of
       | accepting concepts of economic abstractions outside what they can
       | put their hands on.
        
       | pizzaknife wrote:
       | this one got me "10. We should be far more focused on avoiding
       | 0.1x programmers than finding 10x programmers" - preach
        
       | mrpotato wrote:
       | > 1. I still don't know very much
       | 
       | > "How can you not know what BGP is?"
       | 
       | I learned a while ago that answering someone who asks you "What
       | is X?" and replying with a phrase similar to the above is
       | probably one of the worst ways to broach the subject. It comes
       | off as questioning the person's intelligence/knowledge.
       | 
       | Instead try to see it as a teachable moment. If it is something
       | you think is cool and/or you are passionate about, you should be
       | excited that you can show your friend/coworker something really
       | cool. ie: "I've never seen Rick and Morty", "You are absolutely
       | going to love that show. I know what you will be binge watching
       | this weekend!"
       | 
       | Anyhow, to put it bluntly, don't be a dick about it.
        
         | mehphp wrote:
         | I used to be pretty bad about this, and I honestly didn't
         | realize I was doing it until someone pointed it out.
         | 
         | I hate when people do it to me, so no idea why I was doing it
         | right back.
        
       | naruvimama wrote:
       | > 11. ..... > Nothing worries me more than a senior engineer that
       | has no opinion of their tools or how to approach building
       | software.
       | 
       | The more you learn the more you realise you were wrong.
       | 
       | Having an opinion has often come to mean one is a fan boy of
       | something and will have it no other way.
       | 
       | I have heard team leads say "this python code is bad because it
       | uses no classes" or "we need to use EMR so we can process all
       | customer data together"
       | 
       | Bad opinions formed can be dangerous and counter productive.
       | 
       | Though I do agree that an opinion based on having a well thought
       | out plan and experience is a sign of maturity.
        
         | jgilias wrote:
         | I think that there is a very important distinction between
         | having opinions, and willing to have it 'my way only'.
         | 
         | I subscribe to the 'strong opinions, weakly held' model. It's
         | necessary to have opinions about things you're involved with.
         | However, the real art is to be able to not be too attached to
         | one's opinions, be open to change them, and be able to be a
         | productive team member, even if there is a decision to do
         | things in a way that doesn't conform to one's opinions even
         | when the opinions haven't changed.
        
         | jrimbault wrote:
         | I think points 11 and 15 (Don't mistake humility for ignorance)
         | play of each other.
         | 
         | I don't have a hate/love opinion on most things. I may have an
         | opinion on wether or not one particular technical choice is
         | contextually a good or bad idea. I may not be able to form an
         | opinion.
        
         | moonchrome wrote:
         | The more I learn the more I realise everyone else is wrong too.
         | Especially when it comes to general purpose tools - there's so
         | many tradeoffs even in an ideal world but really often the
         | original author just did things wrong, but right enough that
         | his solution stuck and everyone kept piling on and building on
         | top.
         | 
         | PHP and node come to mind immediately.
         | 
         | Ruby is down right retarded with promoting Concerns for
         | modeling cross cutting concerns and fat controller/model is a
         | pattern for creating technical debt.
         | 
         | Dealing with python environments and packages makes me want to
         | avoid python if at all possible.
         | 
         | Using C# and Java means I'm probably going to have 3 projects
         | for a hello world.
         | 
         | I'm not positively opinionated about my tools - it's more about
         | deciding which one sucks least for a particular task.
        
           | taf21 wrote:
           | Was the slur super necessary to make your point?
        
           | heartbreak wrote:
           | Your comment about Ruby is actually referring to the Rails
           | framework. It also suffers for the slur.
        
             | moonchrome wrote:
             | True, my problem with Ruby is stuff like having
             | select/filter/find_all or map/collect and then frameworks
             | also inventing their own conventions and this somehow being
             | ruby philosophy. Also naming conventions like to_i to_a
             | to_s to_h. And then the scoping rules. I'm not a fan of the
             | language or the design philosophy and will avoid in all
             | future projects.
             | 
             | As for calling it retarded - it's the emotion it evokes, I
             | don't find it particularly offensive - but thankfully I'm
             | not from the pronoun declaring part of the world.
        
               | stnmtn wrote:
               | Do you think that because you don't find it offensively
               | personally, that it's 100% fine to say and anyone else
               | who finds it distasteful is wrong?
        
               | moonchrome wrote:
               | Tasteful is subjective by definition. In a casual
               | conversation on a anonymous forum ? I don't really see
               | the issue. The only people that might be offended here
               | are authors of RoR but then again, I have no qualms about
               | offending them since their designs caused me a lot of
               | pain the year I worked on a project written with it.
        
           | kortex wrote:
           | > Dealing with python environments and packages makes me want
           | to avoid python if at all possible.
           | 
           | I see this a lot, and I don't blame folks for having this
           | stance. It's taken me over a decade to dial in my workflow.
           | 
           | Quick rundown:
           | 
           | - don't use python2. Ever.
           | 
           | - don't use the system python, or brew python for anything
           | other than bootstrapping
           | 
           | - only use `pip install --user` for exactly one thing: `pip
           | install --user pipx` when you don't have brew
           | 
           | - never, ever, ever `sudo pip` anything. No exceptions.
           | 
           | - use pyenv to manage your python versions.
           | 
           | - use `pipx` to install stand-alone CLI tools, like
           | virtualenvmanager, poetry, black, mypy.
           | 
           | - always develop in virtualenvs. No exceptions
           | 
           | - prefer installable python packages over scripty standalone
           | .py files
           | 
           | - using PYTHONPATH is a smell
           | 
           | - poetry is likely the future of tooling, but it's not mature
           | enough to be considered best practice for python beginners
           | just yet. Stick with pip if you are uncertain.
           | 
           | - use lockfiles for writing applications but not writing
           | libraries
           | 
           | - editable installs are a double-edged sword
        
             | marcosdumay wrote:
             | None of that fix the fact that 3 years later, all of your
             | dependencies will have conflicting requirements.
        
             | jfk13 wrote:
             | I think the fact that you feel working with python requires
             | adhering to a specific 12-step programme may go some way to
             | explaining why I've never gotten comfortable with it.
        
               | hereforphone wrote:
               | I love Python and the Python 2-3 debacle really soured
               | things for me as well. It was hard to get over that hump
               | and I can understand that many were put off by it
               | forever.
        
         | scottious wrote:
         | > I have heard team leads say "this python code is bad because
         | it uses no classes"
         | 
         | And they'll say it's "best practice".
         | 
         | "best practice" has basically come to mean "whatever that
         | particular developer knows/likes"
        
           | bussierem wrote:
           | Just to be fair: in Python, there are "best practices".
           | They're in PEP-8.
           | 
           | If someone is making a claim about anything outside PEP-8
           | (like whether to use classes) or worse, AGAINST
           | PEP-8...that's when you know there's a problem.
        
         | jtanderson wrote:
         | While I agree, I think the essence of this comment is that the
         | converse of OP is not true, i.e. "you should trust a senior
         | engineer that has strong opinions". As a sibling pointed out,
         | it's sort of two steps: 1) make sure they have opinions, then
         | 2) ask yourself if those opinions are that of a fan-boy or
         | somebody who has been around the block enough to know a thing
         | or two.
        
       | new23d wrote:
       | A relevant and a fascinating read is this recent paper by Barry
       | M. O'Reilly titled The Machine in the Ghost: Autonomy,
       | Hyperconnectivity, and Residual Causality [1].
       | 
       | > This article will examine the unnamed and potentially
       | devastating constraining effect of software on human autonomy. I
       | call this concept residual causality, where software design
       | decisions made long ago in different circumstances for different
       | reasons constrain human action in an unknown future. The less
       | aware the designers of software systems are of complexity in
       | social systems, the more likely they are to introduce residual
       | causality."
       | 
       | [1] https://www.mdpi.com/2409-9287/6/4/81/htm
        
       | kevmo314 wrote:
       | > "6. Sometimes you have to stop sharpening the saw, and just
       | start cutting shit"
       | 
       | Yeah no kidding. I learned how to write code in notepad but now
       | it's like what happened to me :(
        
       | spion wrote:
       | > they've formed opinions about the way things should be
       | 
       | I feel the opposite. I'd rather have no opinions rather than have
       | strong opinions that prevent me form seeing new possibilities.
       | Infact, I work hard on keeping my opinions under control.
        
       | goodpoint wrote:
       | 20 years of experience here. My little contributions:
       | 
       | 21. Do not mistake hype and popularity for quality.
       | 
       | 22. The best code is no code, but configuration is worse than
       | code. Maintaining 1000 lines of YAML is worse than 9000 lines of
       | code.
       | 
       | 23. The best code is no code, but replacing a script with a zoo
       | of tools and libraries is often worse.
        
         | marcosdumay wrote:
         | The best code is no code; the second best code is high quality
         | third party code; the third best code is your code; the worst
         | code is low quality third party code, and that one is by a huge
         | margin.
        
           | goodpoint wrote:
           | Nicely put. Yet I would add that your code is preferable to
           | third party code if you can solve the same problem with 10x
           | less SLOCs or complexity.
        
             | marcosdumay wrote:
             | To change a completely misunderstood citation into a new
             | one that nobody will understand either:
             | 
             | > Unnecessary flexibility is the source of all evil
             | 
             | Just as with the original "premature", the word
             | "unnecessary"is doing a lot of heavy lifting here, and
             | there's no way to state that rule that saves people from
             | thinking before applying. Some times those 10x SLOC are
             | really important and will save you; most times it's just a
             | 90% waste ratio multiplied over your previous one.
        
         | dgb23 wrote:
         | I think I somewhat disagree with 22. Not specifically in terms
         | of YAML or what is categorized as configuration (basically
         | anything?). I think a well designed data model is much more
         | productive and simple than arbitrary code.
        
       | cryptica wrote:
       | Amazingly, I agree with every single point.
       | 
       | >> Nobody asks "why" enough
       | 
       | This point is the most important IMO. It's so common for people
       | to do things without asking themselves why they're doing it.
       | Every line of code should fulfill a clear purpose. You want to
       | avoid writing code which is difficult to explain to a non-
       | technical person.
       | 
       | >> People don't really want innovation... If you believe in what
       | you're doing, and know it will really improve things, then brace
       | yourself for a long battle.
       | 
       | This sounds ridiculous at a glance, but it 100% matches my own
       | experience in pretty much every company and project I've ever
       | worked on.
       | 
       | It applies to everything; jobs, getting funding. Nobody wants to
       | see real innovation and nobody wants to see real talent. If
       | you're too good as a developer and innovate too much, developers
       | who work for big companies will get jealous and they will reject
       | you. If you're very good, you need to pretend to be mediocre and
       | above all; compliant.
        
         | dustintrex wrote:
         | I think "jealous" is not a useful lens here. People reject
         | innovation because genuinely changing the way the way they have
         | to do things is _painful_ even if the attempt fails, and will
         | probably lead to some people losing their jobs if it succeeds.
        
         | mattcwilson wrote:
         | Mmm, in my experience, it's more that people don't believe that
         | something truly valuable to them comes packaged in your
         | arrogance, brilliance, or effortlessness.
         | 
         | They're so accustomed to those things being signs of assholes,
         | or reasons to feel inadequate, that they resist looking at
         | what's being delivered.
         | 
         | The OP's point about bracing for a long battle means that truly
         | persuading others is not just about making the amazing thing.
         | It's about having the humility to weather their resistance and
         | care harder than they do about the merits of the way. And
         | patiently, tenaciously demonstrating the value instead of doing
         | anything that seems like boasting about it. Then they'll stop
         | ignoring you, and you'll both win.
        
           | cryptica wrote:
           | I'm not at all arrogant in real life. My last boss even told
           | me that I don't stand up for myself enough. Besides, I didn't
           | even say it was about me and merely brought it up to make a
           | point.
           | 
           | Imagine constantly improving yourself for 15 years, then
           | after 15 years, everyone you work with only gives you
           | positive feedback and everyone wants to be on your team. You
           | even launch open source projects which get thousands of stars
           | on GitHub... You know you're good because there is no other
           | explanation and nobody helped you and you have 0 meaningful
           | industry connections and come from a modest background... but
           | somehow you struggle to even land a first technical interview
           | at a big tech corporation in spite of having the required
           | university degree. That's my situation, so forgive me if I
           | sound like an asshole on this anonymous website where I can
           | finally vent my frustration.
        
         | prancer_or_vix wrote:
         | > developers who work for big companies will get jealous and
         | they will reject you. If you're very good, you need to pretend
         | to be mediocre and above all; compliant.
         | 
         | To add to what another poster said, it's not jealousy.
         | 
         | Big companies move slow because generally, to get big, they had
         | to be successful (to some extent) and changing too much all at
         | once is a risk that the bureaucracy isn't always comfortable
         | with.
         | 
         | One of my old managers (I work in "enterprise") used to say
         | things like "the efficiencies that this solution will bring the
         | company..." which was just a euphemism for more folks getting
         | laid-off (happened all the time, and glassdoor was full of
         | warnings about this) or more jobs being shipped to our offshore
         | units or even down-sizing in our offshore units.
         | 
         | I think it's reasonable, at least in the US, where healthcare &
         | retirement & welfare is so tightly coupled with employment, for
         | folks in big companies to be wary of innovation. They might
         | want their job to be easier, sure, but too easy and they could
         | be out of a job (for example, if the workload that previously
         | took 5 people can now be managed by 2 or 3).
         | 
         | We're building software for people.
        
       | agonmon wrote:
       | "People talk about innovation a whole lot, but what they are
       | usually looking for is cheap wins and novelty." This rings true
       | from being at a Fortune 100 going through "digital
       | transformation". So much jabber about "innovation" and AI /
       | machine learning this and that, when what they really wanted was
       | just to do what everyone else was doing, and just implement
       | similar systems to what Amazon had done a decade+ ago.
        
       | RNCTX wrote:
       | Speaking of iteration, iterating over the most popular replies to
       | this tells me that the points which hit home enough to drive
       | engagement are replies to the effect of:
       | 
       | 1) "No, my 37 day interview process is good, actually."
       | 
       | 2) "Rails sucks"
       | 
       | 3) "Making a thing people would want to use is a bad idea."
       | 
       | 4) (two long threads) "The 10x programmer exists, I saw him once
       | at a con."
       | 
       | 5) "No one cares what anyone else thinks."
       | 
       | HN really does represent the finest that the largest corporations
       | have to offer. The proof is in the pudding.
        
       | johanneskanybal wrote:
       | Similar experience and life path, agree with each one of these
       | really, very valuable. The silly 10x argument which is quite
       | prevalent around here especially, probably says a bit about the
       | audience.
        
       | jimmyvalmer wrote:
       | Perspective by definition is something that requires time, so any
       | top 10 list of this kind can't be applied consciously with any
       | rigor. I will say point 12 (everyone loves cheap wins, and hates
       | substantive progress) is unadulterated (but unactionable) truth.
        
       | debarshri wrote:
       | One of the things I have noticed lately is that people who change
       | jobs often have completely different perception of the industry
       | as compared to people who don't change that often. Both of the
       | strategies have pros and cons. For instance people who change
       | jobs quite often don't seem to care alot about the business per
       | say they seem to emphasis on the technology more as compared to
       | people who stick to one org. However, people who have changed job
       | quite often, seem to have seen broad variety to problem sets and
       | always bring fresh new pair of eyes to existing business. People
       | who stick to the same org, do tend to become very conservative
       | but it often good for the business as people not quitting brings
       | lot of stability. Again, it really depends on situation, person
       | to person. In general this is my observation.
        
         | ozim wrote:
         | If you are good in tech that is transferrable skill.
         | 
         | Being good at what your company does is often not that useful
         | anywhere else and usually you get non-compete so you cannot
         | really use it.
         | 
         | If someone is a dev it is better to switch jobs and sharpen
         | your "software stack" skills than waste time on learning
         | whatever business needs. Of course there is some level that one
         | has to understand the business they make code for - but don't
         | overdo it.
        
           | debarshri wrote:
           | You can always argue that every 5 years there is shift,
           | sharpening your software stack might be a continuous process
           | as compared to being a domain expert
        
       | Buttons840 wrote:
       | > 4. The best code is no code, or code you don't have to maintain
       | 
       | > 17. Keep your processes as lean as possible
       | 
       | > 20. Always strive to build a smaller system
       | 
       | He stops just short of saying it, but IMO a program with fewer
       | lines of code is almost always better. You can write your Java in
       | Python and have it be 1/5th the lines. You can drop the classes
       | and use functions and save some lines.
       | 
       | Exceptions to this rule only happen because lines of code isn't
       | an infallible measure of "size" or complexity.
       | 
       | > Project size is easily the most significant determinant of
       | effort, cost and schedule
       | 
       | https://blog.codinghorror.com/diseconomies-of-scale-and-line...
       | 
       | This comes to mind after having written some short pieces of code
       | which get "improved" by others. But all they did was move things
       | into different files and turn some functions into classes. As
       | though what makes good code is trivially wrapping everything in a
       | class. I can't understand it.
        
         | w-j-w wrote:
         | More lines is generally less good, but I hesitate to really
         | give out this advice. Classes are useful because they make
         | great nucleation sites for future complexity, and often, more
         | simpler lines of code is easier to read (and change). Not all
         | additional lines of code are equally bad.
        
         | Zababa wrote:
         | I think that's because non-generated lines of code are a form
         | of "incompressible human work". Sure, one person can write
         | twice as much lines as another. Even 10! But when you have a
         | codebase of 10 millions lines of code, this is going to take a
         | certain amount of man-years, and there is no way to reduce
         | that. This is in stark contrast to the programs we write, that
         | can replace large quantities of human work easily.
         | 
         | Some other ways of looking at this: compilers are an impressive
         | force multiplier. When you compare the size of the source and
         | the size of the executable, it's easy to see how much work you
         | avoid. Compilers allow one single person to create way bigger
         | programs. That would also explain why some people are so
         | insistent on Lisp: macros are compilers. If you can write your
         | own compiler, you can increase even more your own productivity.
         | 
         | This raises the question of why not everyone uses Lisp. The
         | answer is collaboration. Collaboration happens when people
         | share a mental model of things. The bigger the language, the
         | harder it is to find lots of people that share that entire
         | mental model. This may be why you often hear programmers with a
         | lot of experience that prefer "small and simple" things, like C
         | or Go. It makes collaboration easier. Dynamic vs static typing
         | might be the same. It's about "how much context you need in
         | your head at all time". If you have a lot of context in your
         | head, it's easy to think about things succinctly. But when
         | people don't have the same context as you or you lose yours,
         | understanding their short and full of context code might be
         | very hard. Spaghetti programs are that, a mix of context. You
         | can't take one spaghetti out. You have the same exact problem
         | in parsing, context-free vs context-sensitive grammar.
         | 
         | I don't know if and how the context-free vs context-sensitive
         | ideas translate in terms of people. If anyone really likes
         | using Lisp or Go or Haskell, I would be interested in your
         | opinion about my "theory", and if you think that preference for
         | context-free or context-sensitive applies to other parts of
         | your life or personality.
        
       | aehlsf wrote:
       | Reinventing the wheels lol it's everywhere. Not just in software
       | engineering field. Some people do it to look busy and others do
       | it to keep employed! Thanks for sharing your wisdom. I have
       | enjoyed reading your writing.
        
       | pjc50 wrote:
       | This is a very insightful list. But there is one thing I'd
       | quibble with: while it's inherently a super-subjective metric, I
       | would say that 10x programmers do exist. Both in the "can support
       | a company by themselves" sense and the "mad lone genius" sense.
       | Not all the 10x programmers are good at working with other people
       | or on other people's ideas.
       | 
       | 0.1x programmers are often lost or afraid, although they may just
       | be unimaginative. The real risk of fear is introducing 0.1x
       | _processes_. People are often willing to sacrifice any amount of
       | development velocity to avoid being seen to make mistakes.
       | 
       | Sometimes this makes sense, sometimes it doesn't. Arguably the
       | reason for the success of SpaceX is that they were willing to
       | fly, crashland, and improve a dozen rockets in the time that a
       | conventional company would spend agonizing over whether to launch
       | at all. On the other hand, nobody wants to be on the same roads
       | as the "move fast and break things" self-driving car.
        
         | mettamage wrote:
         | I've also met one 10x programmer in my life. A lot comes down
         | to being able to reason fast, architect well, and write code on
         | the fly without resorting much to:
         | 
         | * Documentation
         | 
         | * The debugger / print()
         | 
         | Becoming a 10x developer means that you have a set of skills
         | that work well together in an end to end process from going to
         | initial requirements to fully fledged architecture and/or code.
        
           | jameshart wrote:
           | So there are these moments in development, where the task
           | boils down to 'I just need to build this system. I can see it
           | all in my head, and I need to turn it into code'
           | 
           | And for that task, factors like how well a developer knows
           | the libraries, how fluently they can express themselves in
           | the language, how fast they can type, how seamlessly their
           | mental model fits with the tools available.. all of those
           | things can make the difference between it being something one
           | dev can crank out in a couple of days, and another dev takes
           | a few weeks over.
           | 
           | And I definitely want more of the first kind of dev on my
           | team than the second kind.
           | 
           | But here's where that doesn't match up to what we expect of
           | lead developers and more senior devs as their careers
           | advance, and why '10x' is not necessarily an indicator of
           | 'ready for promotion'.
           | 
           | The person who can see the whole problem and turn it into
           | code in 2 days often struggles to figure out how to scale
           | what they do to more people. They can't express how the code
           | should work to someone else because they're already three
           | steps ahead - explaining how it needs to be done will take
           | longer than just doing it!
           | 
           | So the problem is as soon as this person encounters a problem
           | that is too big to fit all in their head and crank out in a
           | few days, or that requires expertise they don't yet have, so
           | they need to collaborate... the approach they have learned to
           | rely on stops working.
           | 
           | But it turns out there are 10x team leaders too - devs who
           | can break large projects up into chunks that can be delivered
           | separately, who make sure the team is building the right
           | thing, who know how to make use of that individual who can
           | just crank out a complex system in a couple of days -
           | repeatedly and sustainably - and who make systems that are
           | the right shape so that later features are cheaper and easier
           | to add, rather than becoming harder and slower. In fact at
           | this level the multipliers go way beyond 10x.
           | 
           | And some of those skills build on the individual 10x dev
           | skill set but some are _orthogonal_ to it. Some are downright
           | _opposed_.
        
           | Aeolun wrote:
           | Being a 10x developer is a factor of experience. You don't
           | need to debug the issue if you can already reason through to
           | where it must be.
        
             | Jensson wrote:
             | Yes, but some people generalize their experiences much much
             | better and therefore can master domains and adjacent things
             | to a degree others will never reach.
        
           | louthy wrote:
           | I think most people who have worked with me would consider me
           | a 10x developer, I am capable of writing something in hours
           | that would take others weeks (not in a half-arsed way, but
           | taking all of the complexities of the domain into account).
           | And I think that's what most people think a 10x'er is: that
           | they can just do stuff quicker.
           | 
           | That's not what I think 10x'er is though. I think a 10x'er is
           | someone who enables the 'average' developer to become a 2x,
           | 3x, 4x developer. This can be through writing some core tech,
           | a library used by all, or through mentoring and guidance. The
           | 10x'er can then become a 100x or even 1000x developer. The
           | 10x dev is the person who picks up the really difficult or
           | ugly stuff and says: "Hold my beer, I'll get that done" -
           | motivating the team and helping them to keep velocity. They
           | lead by example and explain to the team why they've taken the
           | approach they have.
           | 
           | Sometimes people use the term Rockstar to define a 10x
           | developer. I think that's a loaded term that comes with an
           | 'arrogance' tag. The true 10x developers shouldn't be
           | arrogant (beyond the base level arrogance everyone of ability
           | has), they can and should be the glue that holds a team
           | together and helps everyone achieve more.
        
             | jimmyvalmer wrote:
             | In the fantasy organization where means justify ends, the
             | 10x-er's time is better spent making the 1x-er obsolete.
             | Your lip service to the 1x-er however does not go
             | unappreciated as keeping him on and making him feel more
             | productive is instrumental for political advancement, which
             | is more important for your fortunes than the technical
             | kind.
        
               | louthy wrote:
               | What an incredibly cynical view of the world. Teams where
               | people collaborate are more successful, if you think
               | trying to make your colleagues obsolete is time "better
               | spent", I honestly feel sorry for your co-workers. Yes,
               | if I sat and just wrote code all day I would get a lot
               | done. But, if I help my colleagues too, we all get lots
               | more done.
        
             | mettamage wrote:
             | The way I see it:
             | 
             | Developer: a person that creates software.
             | 
             | 10x development: a person that does it 10x faster.
             | 
             | What you describe, I'd simply call a lead developer since
             | making other developers 2x or more is a lead developer his
             | job.
             | 
             | If you're a developer and you're doing this, then it'd be
             | one argument to get promoted to lead.
             | 
             | Also, if you really are a 10x dev, the one I know works in
             | the HFT space. He's making bank. I'm not sure if that's
             | your thing, but I've noticed they seem to appreciate 10x
             | devs a lot more than any other company out there (and that
             | includes FAANG).
        
               | louthy wrote:
               | Leading by example is not necessarily the same as being a
               | lead developer. For example, my principal engineer is
               | easily a 10x'er as just a pure developer, but he's also a
               | force multiplier for everybody on the team, he's
               | literally a machine. He leads no one, I made him
               | principal engineer so he didn't have to.
               | 
               | If he was to just write code he'd be a 10x'er, with the
               | other work he does to help his colleagues, he's many
               | times more than that.
        
           | nuerow wrote:
           | > Becoming a 10x developer means that you have a set of
           | skills that work well together in an end to end process from
           | going to initial requirements to fully fledged architecture
           | and/or code.
           | 
           | The problem with that definition is that it tags the coveted
           | 10x label onto the problematic cases mentioned in the
           | article: that guy who is able to hack together POC code that
           | he demos and passes off as the solution, but requires a whole
           | team to fix and to rewrite and to rearchitect to get it to
           | actually work and be production-ready and be maintainable.
           | 
           | Inadvertently, this means that we see the 10x label being
           | tied to observable behaviors that are actually a productivity
           | nightmare just because they go from zero to demo in record
           | time.
        
             | mettamage wrote:
             | Disclaimer: I feel strongly about this. However, if you
             | have a strong other opinion, then I applaud you and I'd be
             | curious to read it. Rationally, I don't think this term
             | matters a lot as there are better terms to describe
             | programmers, but emotionally it's tied too much to a friend
             | of mine and that's what makes me feel so strongly about it.
             | 
             | > The problem with that definition is that it tags the
             | coveted 10x label onto the problematic cases mentioned in
             | the article: that guy who is able to hack together POC code
             | that he demos and passes off as the solution, but requires
             | a whole team to fix and to rewrite and to rearchitect to
             | get it to actually work and be production-ready and be
             | maintainable.
             | 
             | As I said in another comment. I've met one 10x programmer.
             | So I consider him to be the archetype 10x programmer since
             | he's the only visible proof I have. We're good friends, we
             | mostly talk about life. I sometimes see him code. Let me
             | assure you, he is the last guy that would hack together POC
             | code. I know this, because I'd be one of the first to do
             | that and he gives me a lot of flack for that when I show it
             | to him xD
             | 
             | I should have left out the "or" in my definition. He knows
             | how to architect, he knows how to code, he micro-optimizes
             | every nano, is capable of understanding how underlying ISAs
             | are doing their thing. He knows how to reason well. At
             | companies where he'd enter as a junior, he was immediately
             | recognized for having better technical skills than people
             | 10+ years their senior (note: not his social skills, those
             | are simply normal).
             | 
             | They exist. And it's easy to see why 10x programmers exist.
             | Take a bell curve of ability and you find many 10x'ers on
             | many scales of ability.
             | 
             | Or would you argue that people like Einstein was not a 10x
             | physicist, or that Euler wasn't a 10x mathematician? And
             | there are many more that I wouldn't even know of.
             | 
             | 10x programmer is very related to the idea of a genius, in
             | my opinion. It's simply a subset of it.
             | 
             | Feel free to disagree. It's good to see other perspectives.
        
             | dijit wrote:
             | Honestly I've met real 10x programmers.
             | 
             | Well, speaking honestly probably more like 5x, but it would
             | take a solid 5 person team working well together to do the
             | same things he did.
             | 
             | His ability to reason about the problem- get to the root of
             | the persons actual issue, proof of concept intitial
             | revision and iterate until it was better quality than most
             | popular open source projects was honestly awe inspring.
             | 
             | His only problem was his own lack of self confidence. He
             | used tools and always asked if they were really the best or
             | if he was inflicting them, had good reasons for not using
             | things that we consider industry standard (he prefers
             | restructured text over markdown because it's more
             | expressive, for example) but was ultimately very sad about
             | every project he made because he felt like he had inflicted
             | his (good) work on the world.
             | 
             | So, idk. The people who think they are rockstars probably
             | not. He definitely didn't think he was but he was a god to
             | me.
        
             | Jensson wrote:
             | If their code isn't running in production with little
             | maintenance required then they didn't actually produce the
             | thing. Just add that requirement and it becomes clear.
        
         | AlexCoventry wrote:
         | I think he's beating up a straw man, here.
         | 
         | > The idea that someone can produce in 1 day what another
         | competent, hard working, similarly experienced programmer can
         | produce in 2 weeks is silly.
         | 
         | Over such short time scales, maybe, but the idea that someone
         | could contribute in 1 year what another programmer wouldn't
         | accomplish in 10 years is highly plausible, to me.
        
         | davedx wrote:
         | > People are often willing to sacrifice any amount of
         | development velocity to avoid being seen to make mistakes.
         | 
         | I'm living this at the moment and it's driving me crazy.
        
         | fouric wrote:
         | > while it's inherently a super-subjective metric, I would say
         | that 10x programmers do exist
         | 
         | Even worse than super-subjective, it seems like people don't
         | agree on the definition of "10x programmer".
         | 
         | Is that 10x value (code * code quality) produced per unit of
         | work-time? Per brain cycle? Are you controlling for programmer
         | experience, or domain knowledge, as [1] pointed out? Do you
         | _actually_ mean 10x, or is that a stand-in for  "significantly
         | more productive" with an unknown value? Do you include
         | collaborative skills and working with a team, or even
         | _entirely_ base your definition off of that?
         | 
         | I'm both curious as to the exact definition _you_ have in mind,
         | and also trying to point out the more general issue so that
         | others arguing past each other can realize that they have two
         | different ideas in mind.
         | 
         | [1] https://news.ycombinator.com/item?id=28797923
        
           | pjc50 wrote:
           | For me, it's definitely "a stand-in for "significantly more
           | productive" with an unknown value". Neither the input nor the
           | output can be properly quantified, and we don't really know
           | the full set of variables to control for, and it inevitably
           | runs into serious questions of inequality, SES, and
           | background that are likely to make people even more cross.
           | 
           | I see it as more of a compliment. Nobody should be seriously
           | and unironically calling themselves a 10x programmer, it
           | should be bestowed by other people.
        
           | Jensson wrote:
           | Have a 1 year project. One side is a team of 10 developers
           | with 5 years of experience in the field. Other side is 1
           | developer with 5 years of experience in the field. Do you
           | think it is unreasonable that there is any developer that
           | could beat the team in that situation? The quality
           | expectations for both are the same, so no shortcuts.
           | 
           | I don't find that unreasonable at all, most teams are very
           | unproductive. So what I'd call it is "A 10x developer is a
           | developer who can outperform a typical team of 10
           | developers".
        
         | grey-area wrote:
         | _People are often willing to sacrifice any amount of
         | development velocity to avoid being seen to make mistakes._
         | 
         | IMO that attitude never makes sense - it can make sense to
         | avoid certain mistakes at all costs (self-driving car), but it
         | never makes sense to try to avoid blame for them (company
         | refuses to admit their car isn't good enough).
         | 
         | This is a problem of culture, not individuals.
         | 
         | Does the culture at a company openly admit mistakes, try to
         | learn from them, and put systemic fixes in place to address
         | them, or do they punish people for mistakes?
         | 
         | If the latter, you end up with nobody admitting to mistakes and
         | a terrible culture, it's not about the people, it's about the
         | situation you have put them in and the incentives given to
         | them.
        
           | isolli wrote:
           | No, it's also a matter of personality. One manager used to
           | urge me to do things in half the time at 90% of quality, and
           | stop chasing the remaining 10% at such high opportunity cost.
           | To this day, I try, but it's hard to overcome a natural,
           | obsessive tendency.
        
           | pjc50 wrote:
           | > it can make sense to avoid certain mistakes at all costs
           | (self-driving car), but it never makes sense to try to avoid
           | blame for them
           | 
           | Eh? As you say, it's a culture thing, and the culture of a
           | lot of humans is that the mistake only matters if you take
           | blame for it. Plenty of people and organisations put more
           | effort into avoiding blame for things than the thing itself.
           | 
           | Blame-free culture is great, but it has to be actively
           | maintained.
        
         | lazide wrote:
         | Also, sometimes it isn't someone 'moving fast and breaking
         | things' - sometimes everyone else gets paralyzed with
         | indecision and can't even get started.
         | 
         | Someone who can sit down and start coding in an ambiguous
         | environment, period, can easily make 10x more value themselves,
         | and allow others to go from .1x to 1-5x merely by being able to
         | pick somewhere to start and just doing it, which allows
         | everyone else to break their own 'freeze' and start engaging as
         | now there is something concrete that breaks the locked up state
         | they were in.
         | 
         | I've done it a few times, and seen others do it to. It's magic
         | going from 'everyone rehashing things on a whiteboard for the
         | 10th time' to 'everyone working on the next iteration'
        
           | bigbizisverywyz wrote:
           | >sometimes everyone else gets paralyzed with indecision and
           | can't even get started.
           | 
           | I once worked on a project where exactly that happened, and I
           | view it as one of my biggest failures of my career. I often
           | wonder why I didn't just sit down one day and type int main(
           | ... and just get on with it.
           | 
           | In the end the project got canned and both contractors
           | terminated early, so I made sure that never happened again.
        
           | pjc50 wrote:
           | The "MVP" or "strawman" is incredibly valuable; people can't
           | tell a blank sheet of paper what they want, but if you show
           | them a thing they'll tell you what's wrong with it.
           | 
           | I've noticed myself that I can happily write detailed
           | comments on HN or StackOverflow but have no inclination for
           | blog posts, for that kind of self-content-marketing that
           | seems to be popular these days.
        
         | jasode wrote:
         | _> , I would say that 10x programmers do exist._
         | 
         | Yes but I think the underlying issue is that some people really
         | Really don't like to acknowledge (or are unaware) there's a
         | small set of elite programmers that can do things average
         | coders can't. But _any label_ we use to describe them (i.e.
         | "10x", "rockstar", "ninja", etc) will be psychologically
         | distasteful. I previously commented about that effect:
         | 
         | - https://news.ycombinator.com/item?id=13753178
         | 
         | - https://news.ycombinator.com/item?id=24753594
         | 
         | To see that hidden psychology driving the narrative... look at
         | how the author constructed his comparison with extra qualifiers
         | of "competent" & "similarly experienced" : _" >The idea that
         | someone can produce in 1 day what another competent, hard
         | working, similarly experienced programmer can produce in 2
         | weeks is silly."_
         | 
         | In other words, if we artificially construct the comparison by
         | _a priori_ assuming both programmers are _equal_ , then the 10x
         | difference is a myth. Well yes, that's tautology. If you invent
         | a sentence to "prove" a point, you can set any conditions in
         | the artificial universe in your favor that seems to support it.
         | 
         | However in the real world, the stack of resumes will have a
         | candidates with wildly different skill levels. Some struggle
         | with Fizz Buzz. Some can write a 3d game from scratch. But it's
         | impossible to create a label to describe that wide gap which
         | also doesn't invite bikeshedding on that label.
         | 
         | EDIT reply to: _> "Why can't we call them master programmers?"_
         | 
         | Because we'd still have endless bikeshedding of the label _"
         | master"_ as in _" Master programmers are a myth..."_
        
           | jerf wrote:
           | How many times faster is an O(n) algorithm over a O(n^2)
           | squared algorithm?
           | 
           | How many times faster is a developer who _can_ write a
           | compiler over one who _can not_?
           | 
           | We are at least consistent; I rather frequently see
           | programmers claiming a "105 times faster!" benchmark that was
           | actually the result of a fundamental complexity change.
           | 
           | Not everything is on a linear scale.
        
           | willcipriano wrote:
           | We don't call Vermeer a 10x painter, Beethoven a 10x
           | composer, nor Shakespeare a 10x author. It would be silly to
           | call Turing a 10x computer scientist, or rockstar and ninja
           | would be insulting.
           | 
           | Vermeer, Beethoven and Shakespeare are masters of their
           | crafts. The same word we use for skilled tradesmen. Why can't
           | we call them master programmers?
        
             | TheOtherHobbes wrote:
             | Because we're talking about different things.
             | 
             | A master _craftsman_ will solve a problem quickly,
             | efficiently, and elegantly, combining insightful attention
             | to detail with speed and effectiveness.
             | 
             | A master _creator_ will produce work of lasting relevance
             | and power. The metric is quality and impact, not speed and
             | efficiency.
             | 
             | Occasionally you get people like Mozart who combine
             | elements of both, but they're exceptionally rare. And they
             | work best in a relatively limited context which they have
             | mastered completely. They're not perpetually chasing the
             | latest shiny. (Mozart basically knew one style. Even he
             | would struggle to master all the languages and genres that
             | are common today.)
             | 
             | Turing would likely have made a poor backend developer, but
             | he produced work that had lasting impact.
             | 
             | A typical 10X developer will be more like a master builder
             | than a master computer scientist.
             | 
             | I don't find the labelling offensive, because it's clearly
             | realistic. Some people are just very, very good. They
             | produce clean, tight, code at speed, far more quickly than
             | muddlers who produce reams of mediocre code which creaks
             | along, breaks when you look at it, and doesn't actually
             | solve the problem.
             | 
             | But a 10Xer isn't going to be good at everything. If they
             | mostly do backend, they're not going to go toe to toe with
             | game devs. Etc.
        
             | bilger321 wrote:
             | I think part of the reasoning is in the trades there's the
             | presumption that to be a master you must also be old (with
             | exceptions, Da Vinci was active when he was still younger,
             | 20).
             | 
             | In the programming industry, there's likely a bias more
             | toward younger people, and hiring offices ask for the
             | world. They'd like a whole staff of masters and rockstars.
             | Though that doesn't preclude "older" people from being
             | known as masters either. Take John Carmack or Jonathan
             | Blow, for example.
        
               | willcipriano wrote:
               | That is a interesting thought, that seems to imply that
               | those young programmers will not improve. If you are a
               | master at 25, what do you call yourself after you have
               | gained twenty more years of experience? It may be that
               | those 25 year old's a more like journeymen then masters,
               | or that programming is more like sports where youthful
               | vigor are more important than experience.
        
               | Jensson wrote:
               | John Carmack programmed Wolfenstein at 21 and doom when
               | he was 22. At that point he did what most "masters of
               | that craft" couldn't do. What would you call him? And
               | what would you call him now, 30 years later?
        
             | Jensson wrote:
             | People typically call them geniuses, not masters. And the
             | reason we don't call them genius programmers is that people
             | don't like to use the genius label for people who aren't
             | famous.
        
         | e1g wrote:
         | My go-to examples of 10x developers are benevolent dictators
         | like antirez (of Redis), evanw (of esbuild + Figma CTO),
         | youyuxi (of Vue), Carmack, etc.
         | 
         | Both qualitatively and quantitatively, their output is _at
         | least_ 10x of a typical developer at a typical company, not
         | even counting everything these people do besides writing code.
         | Many more are not famous but are in the same league of impact
         | /productivity - I'm genuinely puzzled how someone can say such
         | people do not exist.
        
           | ignoramous wrote:
           | You mix popularity with 10x. Not all 10x programmers are
           | popular.
           | 
           | I believe 10xers exist within a business or technical
           | context. This isn't limited to the field of computer science,
           | but even traditional engineering (Edison) and sciences
           | (Newton) have plenty 10x examples.
        
             | texasbigdata wrote:
             | IF 10x exist, some will be popular and most won't.
             | Obviously he won't know the obscure ones or pick examples
             | you can't relate to. So while he didn't prove his point
             | perhaps, perhaps you didn't disprove his either. :)
        
             | e1g wrote:
             | I'm not mixing - as I wrote, many more are not famous, but
             | their impact is similar. When discussing abstract concepts,
             | it helps to have concrete examples of that phenomena. Using
             | "famous" people is a shortcut to define a _shared_
             | definition for what  "10x" might look like.
             | 
             | And yes, there are "10x" teachers, investors, lawyers,
             | storytellers, sales folks, etc. Similarly, the distribution
             | of talent that helps with "software development" might have
             | a very long tail, leading to extraordinary performance
             | versus the median.
        
           | pcauthorn wrote:
           | I agree. Another example, Linus T wrote git from scratch to
           | hosting the Linux kernel in 2.5 months. I'd say 10x is a low
           | estimate.
           | 
           | I've worked with a guy who wrote great code like he was
           | typing an email.
           | 
           | Everyone has a ceiling of the complexity of problems they can
           | handle, some programmers are outliers in this regard.
        
             | dustintrex wrote:
             | Bit of an aside, but writing an email is its own art. Not
             | many developers know how to write an email that a busy,
             | non-technical VP will read, understand and act on in the
             | way they intended. (Then again, neither do many managers.)
        
           | randomsearch wrote:
           | To pose it another way: for general software Dev (not some
           | niche use case that only one guy understands), let's say
           | building websites in Vue or React, the idea of a 10x
           | developer is that they can work in January and another,
           | average, programmer can then spend February, March, April,
           | May, June, July, August, and Sept... and the average guy
           | won't get more done?
           | 
           | Or they come in only every other Monday and contribute as
           | much as a median Dev working full time?
           | 
           | It just doesn't seem reasonable at all, at least if we read
           | it literally.
           | 
           | I have worked with and met great, outstanding, developers who
           | are much better than me. Some of them famous. None of them
           | are anything close to 10x as productive, and I'm not
           | particularly great. They're much smarter than me, for sure,
           | but they're not 10x as productive.
        
             | ahupp wrote:
             | That definition is too narrow. How about this one: can
             | someone work for 1 year and (consistently) produce 10x more
             | value for their organization than the median engineer? This
             | seems transparently true if you've worked in any large
             | organization.
        
             | e1g wrote:
             | There is no "10X" touch-typist because a) the performance
             | limit is absolute & relatively low and b) the learning
             | curve is such that it's easy to get to the limit and
             | plateau. Now let's increase complexity - still typing, but
             | you must translate the text from another language. Increase
             | again - now you're translating poetry. Increase again - the
             | poetry is original Shakespeare. You need to translate into
             | contemporary English approachable to Gen Z, as a script for
             | a TikTok short, referencing memes from current events.
             | There is no doubt that _some_ people will have a
             | combination of talents - in language, typing, copywriting,
             | built-up cultural knowledge, lived experiences - that will
             | make them 10X in such jobs.
             | 
             | The more software development work approaches touch-typing,
             | the less difference between 1x and 10X -- strict Jira
             | tickets in, garbage out, maybe slightly faster. Spec-work,
             | and most grunt-work, is undifferentiated and does not
             | benefit from a 10X person. The more your work approaches
             | poetry - such as exercising user empathy, improving the
             | architecture, considering UX, respecting performance
             | constraints, understanding user's jobs to be done, and
             | improving your implementation around that - the more
             | creative space there is for 10X to reveal itself.
        
               | thrower123 wrote:
               | Even with drudge ticket-punching work, there is a vast
               | spectrum of productivity between somebody who is capable
               | and conscientious enough to do it correctly the first
               | time and the person who has to rework everything multiple
               | times because they can't do it right the first time and
               | continue making mistakes.
        
               | dexen wrote:
               | _> There is no "10X" touch-typist_
               | 
               | Ironically enough your example is flawed: there are
               | documented 10x touch-typists.
               | 
               | The realities of the court system place high demands on
               | the typists; the _minimum required_ typing speed is
               | already quite high: _trained court reporter or closed
               | captioner must write speeds of approximately 180, 200,
               | and 225 words per minute (wpm) at very high accuracy in
               | the categories of literary, jury charge, and testimony,
               | respectively_ [1] - and some exceed the minimum and go
               | for 300 wpm. Even better, _the official record for
               | American English [is] 375 wpm_ [2].
               | 
               | Compare that to the _average typing speeds around 30 - 40
               | wpm_ [3] Granted, the court reporters use specialized
               | input devices (stenotypes) - but hey, the same can be
               | said about highly productive programmers, who use
               | specialized development environments - and sometimes also
               | specialized input devices.
               | 
               | --
               | 
               | [1] https://en.wikipedia.org/wiki/Stenotype
               | 
               | [2] ibid.
               | 
               | [3] https://en.wikipedia.org/wiki/Touch_typing#Speed
        
               | e1g wrote:
               | You make a good point that hints at another often-
               | undefined assumption in these discussions - 10X
               | performance vs _who, exactly_? IMO, it should be vs  "a
               | typical peer in that profession". For court reporters, if
               | "a typical peer" is a trained court reporter who averages
               | ~200 wpm, and a superstar is at 300wpm, then it's a 1.5X
               | gain. If a "typical peer" is a regular Joe, then 300wpm
               | would be 10X - but this doesn't feel appropriate because
               | we compare productivity of a "10x developer" vs a
               | "typical developer", rather than vs "an average Facebook
               | visitor".
        
               | dexen wrote:
               | Fair enough.
               | 
               | I've had good luck discussing the subject back in 2013:
               | https://news.ycombinator.com/item?id=6464807 and
               | https://news.ycombinator.com/item?id=6465175, with the
               | insightful replies.
               | 
               | Wow, reading the discussion from back then shows how much
               | HN changed in spirit.
        
             | pjc50 wrote:
             | > some niche use case that only one guy understands
             | 
             | But that's where all the value is! Step 1 of being an
             | exceptional worker is not to do unexceptional work if you
             | can at all avoid it.
             | 
             | > at least if we read it literally
             | 
             | This is where it does fall down. There isn't an X that you
             | can reliably measure 10 of, it's all very subjective.
        
             | knorker wrote:
             | How long would it have taken you or me to write Doom, or
             | Quake? How long would it have taken Carmack, if it'd just
             | been him?
             | 
             | I think you have a false dichotomy here. Carmack isn't 10x
             | better a C or assembly than me. But in his domain he's
             | easily 10x smarter and more productive than me.
             | 
             | And on top of that, he has a quarter century more
             | experience in graphics programming than me. That shit
             | accumulates.
             | 
             | Yes, actually. In graphics programming, from 2D and
             | software rendered, to OpenGL and VR, you could give him and
             | me (and presumably you) any task achievable in a few human
             | decades, and he'd do it more than 10x faster.
             | 
             | "Graphics programming" is not a small niche, and yes in
             | that space he's a 10x programmer.
             | 
             | I think you're thinking of this the wrong way. I agree that
             | for something as simple as "build some websites", yeah, 10x
             | is going to be very hard. You're then just turning specs
             | into code, pretty much.
             | 
             | 10x programmers are those that don't waste 9 months. The
             | hard part is knowing which 9 months out of 10, which 9
             | ideas and components out of 10, is waste.
             | 
             | For "build a web forum" or something, yeah there are no 10x
             | programmers. Though there are many many 0.1x programmers
             | still.
        
               | davemp wrote:
               | > How long would it have taken you or me to write Doom,
               | or Quake?
               | 
               | Almost definitely not 10 years.
        
               | datameta wrote:
               | I think it's more likely that we wouldn't have thought
               | something like Doom to be possible until Carmack came
               | along and squeezed oodles of math tricks and hacks into
               | the game to let it run on hardware of the era. So it may
               | as well have be an infinitely long development time for
               | us.
        
               | pjc50 wrote:
               | If you wanted to write Doom, starting in 1993, and take
               | 10 years, your most efficient strategy would probably be
               | to do something else for the first nine of them and wait
               | for the technology to change around you.
        
               | jimbokun wrote:
               | Waiting for the equivalent of Carmack to write and open
               | source the underlying libraries, basically.
        
               | knorker wrote:
               | Almost certainly you would just plain have not been able
               | to do it at all. Not in 1993-1996. Not without it already
               | having been done once.
               | 
               | And if you had, it would have taken you more than 10
               | years to realize what the right thing is, and to solve
               | all very complex problems that showed up on the way.
               | 
               | Quake doesn't even have any load times! Not even with the
               | hardware available at the time.
        
               | randomsearch wrote:
               | > How long would it have taken you or me to write Doom,
               | or Quake? How long would it have taken Carmack, if it'd
               | just been him?
               | 
               | I'm not a games programmer. I doubt a median games
               | programmer would take 10x the length of time that it
               | would take any other games programmer. It just seems
               | implausible, and I don't know why people want to defend
               | it.
        
               | baobabKoodaa wrote:
               | > I doubt a median games programmer would take 10x the
               | length of time that it would take any other games
               | programmer. It just seems implausible, and I don't know
               | why people want to defend it.
               | 
               | Then why did all those thousands of other game
               | programmers fail at creating a decent 3d game, before
               | Doom was released? It's not like Carmack was the only one
               | trying.
        
               | knorker wrote:
               | The median games programmer wouldn't be able to do it in
               | 50 years. (assuming they were locked in a room for 50
               | years with that same hardware, not that they got to see
               | state of the art progress and upgrade their machine)
               | 
               | The amount of innovation, from applied BSP, Zbuffer
               | tradeoffs, light maps with interpolation, interleaved FPU
               | corrections for texture mapping, multiplayer protocols
               | (qtest used TCP), brush-levels, etc...
               | 
               | Before ID software did these things, they weren't
               | checkboxes for what to do. After, sure. But the hard part
               | of programming is not typing.
               | 
               | The median programmer would not have been able to do it
               | before it had been completely irrelevant. The median
               | games programmer could do it in 2005. In 1993-1996? Not a
               | chance.
               | 
               | The main competitor to Quake was Duke Nukem, which
               | technologically was just "doom and a half". The enemies
               | were sprites, ffs.
               | 
               | ID software was years ahead of every other games
               | developer.
               | 
               | The reason other games licensed the Quake engine wasn't
               | that it was cheaper than doing it yourself, it was that
               | they couldn't do it.
               | 
               | Edit: granted, I have a low opinion of the median
               | programmer. But sometimes in life you meet people who,
               | with things you think you're actually pretty good at,
               | just completely mop the floor with you without even
               | trying (or showing off). It's humbling.
        
               | munificent wrote:
               | I spent 8 years at EA and was a senior software engineer.
               | I have absolutely witnessed 10x game programmers.
               | 
               | I think in any field where you have a deep domain with
               | complex, difficult constraints, it is entirely possible
               | to have programmers with 10x the effectiveness of the
               | median simply because of their greater domain expertise.
               | They know the unique algorithms, data structures, design
               | patterns, hacks, tricks, hardware quirks, tools,
               | debuggers, code smells, etc. All of that has a _huge_
               | compounding factor when it comes to output.
               | 
               | Here's a story I like to tell:
               | 
               | I joined EA shortly after the PS2 came out and worked at
               | the studio that made Madden. Madden was a launch title on
               | the PS2 (meaning it shipped right as the PS2 hardware
               | did) and that version essentially sealed Madden's
               | success. It was _hugely_ successful.
               | 
               | But making a launch title is really hard. You're
               | developing softare for a hardware platform that is itself
               | in flux. When EA first started working on Madden PS2,
               | they didn't have any dev kits to work on. I don't know if
               | dev kits even _existed._ They needed to write code that
               | they couldn 't compile and run. But if they didn't start
               | immediately, they would never be able to get the game
               | done in time for the launch.
               | 
               | They had a guy on the team with a reputation for being a
               | wizard. He took the MIPS R5900 reference manual, and
               | disappeared into an office with blacked out windows for
               | some number of weeks. When he re-emerged, he had written
               | a PS2 emulator _despite never having access to an actual
               | PS2_. The rest of the team were able to compile and run
               | the game on that emulator so that they could make
               | progress until eventually real dev kits arrived. From
               | what I heard, when the real hardware showed up, the game
               | actually ran on it.
               | 
               | Now, some of this legend may have grown in the retelling
               | (it was already legendary by the time it was told to me),
               | but I worked with that engineer a few times and I can
               | vouch for his incredible ability to get stuff done. I
               | remember once when FIFA was having performance problems
               | and couldn't get their framerate high enough to ship. He
               | was called into to help and a few _days_ later, got it up
               | to a solid 30 FPS. This was even though the team 's own
               | engineers had been trying to make progress and he had
               | never touched the code before.
               | 
               | I think people dislike the mythos of 10x engineers
               | because it's interpreted as some sort of cognitive
               | essentialism. But I think most of it is just really deep
               | domain expertise. Instead of talking about "10x
               | engineers", we should talk about 10x _at what_.
        
               | [deleted]
        
         | majgr wrote:
         | I like FactoryFactory devs, they are even worse than 0.1x.
         | After some time every other team member who touches their code
         | becomes 0.5x.
        
           | lukaslalinsky wrote:
           | And then you encounter the 10x programmer, who is not afraid
           | to throw the bullshit code away and write it in a way that is
           | easy to manage for other devs. I'd say this is really a more
           | realistic example of a 10x programmer. Most programmers are
           | just afraid of asking the "why" question and the actually
           | acting if there is no good answer.
        
           | kirubakaran wrote:
           | I'm not claiming to be a 10x developer or anything like that,
           | but I have a related story to share:
           | 
           | Once I had to tweak a 7000 line signal generator (ie spits
           | out wav files) written in Java. It had a mind boggling
           | structure, and I'm sure whoever wrote it was a mad genius of
           | some kind.
           | 
           | I rewrote it in less than 100 lines of Python, where each
           | signal primitive was basically a few lines of code max, which
           | you can functionally combine.
           | 
           | Since this new program was not even 100 lines long, we were
           | able to do a LOT more with it, and in a super flexible
           | manner.
           | 
           | It's one of my happiest accomplishments.
        
         | mosburger wrote:
         | I like to say that I am a 10x developer 10% of the time. My
         | work tends to be very "bursty" followed by long bouts of low
         | productivity. It probably has more to do with my mental health
         | than anything else. :/
        
           | vicda wrote:
           | Sounds like ADHD hyperfocus.
        
             | bkromhout wrote:
             | Was just coming here to say, this is my exact situation
        
             | sumtechguy wrote:
             | There can be that. But also some managers do not like you
             | wander off task. So stick in your lane stick to your
             | tasks... So eventually after years of that you just do only
             | what is needed and skip anything else. After a few of those
             | 'that is very nice but...' conversations you just say screw
             | it and coast. Every once and awhile I get a burst where I
             | can propel my group forward. But then usually I feel like I
             | am bolder chained to them and dragging them down. More than
             | likely I am just average and doing OK.
        
           | pjc50 wrote:
           | My personal joke about this is "I used to be a 10x developer
           | but then I took an arrow to the knee".
           | 
           | Many, many years ago a colleague wrote about the experience
           | of being bipolar and choosing to stop taking the lithium for
           | a temporary productivity boost and subsequent crash.
        
           | dgb23 wrote:
           | I have the same problem. But the more I tackle it in
           | reasonable ways, the better it gets. Here's some pointers
           | that work for me:
           | 
           | - enough sleep, rather get in bed early than late as the
           | quality of the sleep depends on natural rhythms
           | 
           | - engage with people that are affected by my work - this is
           | important for motivation and to keep track of what actually
           | matters
           | 
           | - operationalize everything, say out loud what to do next
           | 
           | - being honest when I have bad focus, talk about it
           | 
           | - trust my instinct and do the right thing, if I don't I
           | quickly lose focus and motivation, if opinions don't align
           | learn why
        
         | itsibitzi wrote:
         | Saying 10x programmers are a myth because it's crazy that
         | someone could do in 1 day what another could do in 1 week makes
         | the assumption that both programmers in the example have the
         | same amount of context, background understanding, and
         | experience.
         | 
         | The benefit of talented engineers comes from the fact that they
         | avoid costly pitfalls - not that they pump out more code per
         | hour worked.
         | 
         | I feel this "10x programmers are a myth" attitude comes from a
         | good place of wanting to promote harmonious working and skill-
         | up junior engineers, but it seems so totally detached from
         | reality. I'm not sure the "benefit" of propagandizing against
         | talented assholes is worth the cost of demotivating people who
         | might be inspired that they could become a 10x engineer.
        
           | NineStarPoint wrote:
           | Realistically, I've always found it a weird sentiment more
           | because issues caused by software developers are not of the
           | "this person is 1/10 as productive as this other person"
           | type. A bad developer isn't a low positive effect on a
           | project, but an active negative effect. As such, you can put
           | literally any Y for a (Y)X programmer, since the scale of how
           | inefficient a programmer can be goes up to infinite.
           | 
           | I think the pushback against 10X programmers comes primarily
           | from the fact that many programmers who look good to managers
           | (constantly push out new features) are in actuality an
           | albatross around the necks of the other programmers who
           | constantly have to fix the messes they create (in reality, a
           | negative on team-wide production). What matters more to me in
           | a teammate than how productive they are is to ensure that
           | they are on the positive side of the scale at all, which the
           | perceived 10X programmer is often actually a failure at.
           | 
           | Though I've definitely met people who just have such a wide
           | knowledge base and think so quickly that they are in fact 10X
           | as effective as a standard productive programmer, so I do
           | understand where the idea comes from.
        
             | pjc50 wrote:
             | More people should be aware of Comrade Stakhanov, the "10x
             | miner": https://en.wikipedia.org/wiki/Alexey_Stakhanov
             | 
             | > In 1988, the Soviet newspaper Komsomolskaya Pravda
             | claimed that the widely cited achievements of Stakhanov
             | were puffery. The paper insisted that Stakhanov had used a
             | number of helpers on support works, while the throughout
             | was tallied for him alone. Still, according to the
             | newspaper, Stakhanov's approach had eventually led to
             | increased productivity by means of a better work
             | organization, including specialization and task sequencing
             | 
             | Exactly the same discussion, except there it was tonnes of
             | coal which can be easily and unambiguously measured. But
             | they can't be easily _attributed_. How much of his work was
             | really that of his team? And how much of it was simply
             | inflation by his managers for propaganda purposes? And how
             | much of it was, underneath all the propaganda, real process
             | improvements?
        
           | 908B64B197 wrote:
           | > I feel this "10x programmers are a myth" attitude comes
           | from a good place of wanting to promote harmonious working
           | and skill-up junior engineers
           | 
           | When comparing juniors you observe the same distribution.
           | 
           | I've met 10x straight out of college who ran around other new
           | grads.
        
           | dijit wrote:
           | I always read it as a direct comparison though.
           | 
           | It doesn't matter if I have better experience or I can
           | contextualise intent better; the phrase "10x" means it would
           | take a team of 10 to do it, in the time, scope, budget
           | (whatever).
           | 
           | But there are major reasons this could be the case, if I'm on
           | my own and I know the direction then I don't have to quibble
           | about what framework to use, how to name my variables, what I
           | consider "proof of concept quality". You just get your head
           | down and do it with the entire scope and progress in your
           | head at once.
           | 
           | No infighting about semantics, no deeply technical progress
           | reports or trying to subdivide tasks which are not inherently
           | subdividable.
           | 
           | More people is more communication and it's quadratic.
        
           | t43562 wrote:
           | Why do people need to be motivated in such a way? Won't that
           | just lead to a lot of disappointment and misery later on? Why
           | isn't "being a good programmer" something we should admire?
        
           | JoeAltmaier wrote:
           | Of course one programmer can create 10X the code of another.
           | The limit isn't how fast they type. Its how correct the code
           | is, and how much it leverages what you have and what you'll
           | need. And that results in 'pumping out' more code per day.
           | Whatever the reason (context, background, experience)
        
             | kiklion wrote:
             | > The limit isn't how fast they type. Its how correct the
             | code is
             | 
             | And how good your autocomplete tools are, or you repertoire
             | of code based to copy from.
        
           | michaelcampbell wrote:
           | > Saying 10x programmers are a myth because it's crazy that
           | someone could do in 1 day what another could do in 1 week
           | makes the assumption that both programmers in the example
           | have the same amount of context, background understanding,
           | and experience.
           | 
           | Yes, because that's how it's always presented. And if it's
           | not, then it's also a myth because then it's not a 10x dev,
           | it's 10x context, background understanding, and experience.
           | 
           | Either way it doesn't hold water.
        
             | Jensson wrote:
             | > it's 10x context, background understanding, and
             | experience.
             | 
             | A person who is able to build 10x context, background and
             | understanding is a 10x developer. Most people lack the
             | ability to do that. Your post makes it seem like you could
             | give those traits to anyone easily, but it doesn't work
             | that way building the right mental models and being able to
             | generalize your knowledge are key factors in talent.
        
           | Aaargh20318 wrote:
           | > The benefit of talented engineers comes from the fact that
           | they avoid costly pitfalls - not that they pump out more code
           | per hour worked.
           | 
           | Not just avoid pitfalls, being able to put together a good
           | architecture is a huge factor as well. The effect is
           | cumulative. If you have a good design to begin with,
           | everything becomes easier with less risk of bugs. The result
           | is that implementing new, or changing existing functionality
           | takes less time.
           | 
           | The 10x developer doesn't write 10x as much code, (s)he will
           | probably write _less_ code than the 1x developer.
        
             | bogwog wrote:
             | > (s)he will probably write less code than the 1x
             | developer.
             | 
             | Or better yet, remove code.
        
               | pjc50 wrote:
               | https://www.folklore.org/StoryView.py?story=Negative_2000
               | _Li...
        
               | jimbokun wrote:
               | This needs to be required reading for every first time,
               | non-technical manager of software developers.
        
             | llaolleh wrote:
             | Exactly. It's not how fast someone churns out code but how
             | well thought out/elegance in approach that delivers this
             | 10x value.
             | 
             | Instead of writing entire systems from scratch, maybe you
             | have enough experience or familiarity with well known
             | techniques and libraries to ship faster.
        
           | WhompingWindows wrote:
           | 1 day vs 1 week: wouldn't that make them a 5X engineer?
           | That's half of the advertised 10X...
        
         | Nursie wrote:
         | -1x programmers also exist, in a variety of guises. From the
         | dev with long cv of projects he's contributed nothing to and
         | been sidelined from, but who manages to keep getting hired
         | because of his cv, to the dev who crowbars in new tech where
         | it's not needed and causes a ton of problems.
        
           | [deleted]
        
           | lucumo wrote:
           | Presumably a 1x programmer is an average programmer. The type
           | who does his job acceptably. He doesn't create huge problems,
           | nor solve them. He is a fine team player and team member, but
           | not a leader. Nobody despairs when he leaves, and he will be
           | forgotten after a few months.
           | 
           | Basically, the majority of programmers.
        
             | heipei wrote:
             | This was about minus 1x, so having a negative impact. And
             | yes, these do exist.
        
               | mushishi wrote:
               | Now that I think about it, the worst code seem to lead to
               | situations where the top developers can really show their
               | value.
               | 
               | I mean if the code base is quite good and is kept that
               | way, then a normal developer can deal with it quite well.
               | But if you get a legacy mess, then the hard-core
               | developer can make really drastic changes that have
               | enormous value to the maintainability, future development
               | and bug-wise.
               | 
               | If a normal developer tries to tackle that mess, it's
               | easy to get into trouble and drown in the sea of
               | opportunities and not see the big picture and take a
               | proper road plan to improve things.
               | 
               | So in a way -1 developers enable the top developers to
               | show the gap between them and the normal devs.
        
           | Koshkin wrote:
           | This could be managers who deem themselves programmers or
           | software architects. (Often they would use their authority to
           | promote their ideas and effectively shut everyone else up.)
        
         | grecy wrote:
         | I once worked on a team that in hindsight had two 10x
         | developers in a team of only 12. They were vastly different,
         | and the difference to me is extremely interesting.
         | 
         | The first one was not a bad person by any means, but had no
         | social skills, no ability to communicate and often just forged
         | ahead building great stuff on his own. Entire areas of the
         | software were entirely conceived and created by him, and it was
         | difficult to even grasp what he was doing while pair
         | programming with him. In a day he would write more tests and
         | get more coverage than the rest of us would create in a week.
         | 
         | The second one had come from a FAANG-ish place where he was
         | extremely successful, but didn't want the money or stress. He
         | was extremely kind, considerate and great at communicating.
         | Pair programming with him was a joy and he helped everyone else
         | on the team grow. I'm confident he could have created entire
         | regions of the software on his own, but he knew that wasn't the
         | right thing to do. He would often ask questions until someone
         | else on the team could solve a problem, even though I'm sure he
         | knew how to solve it easily himself.
        
           | xwolfi wrote:
           | Yeah the first one is a risk. I've met one whom I had to take
           | over the code of when he left and psh, I wished he was a
           | dumbass instead. He could produce shitloads (but would never
           | test, interestingly), do stuff I honestly can't do, but do
           | you really need to bitshift instead of doing a modulo to save
           | 1 CPU instruction ?
           | 
           | The amount of obscure waste of programming complexity made us
           | actually just abandon the thing he spent years on to just not
           | do it. And everything works fine and we still make money and
           | we're just probably a little bit less clever about how we do
           | it. We also have a lot more time to listen to users and solve
           | their problems, rather than gloat on our genius and solve our
           | own created problems :D
           | 
           | Your second example is inspiring and I hope to meet one to
           | learn from too !
        
       | agentultra wrote:
       | _Avoid the word 'just' and be suspicious of those that use it_:
       | It's _just_ a new model and a few pages, how hard could it be? It
       | should take _just_ a couple of weeks. When people use this word
       | they are being overly optimistic about something they 're not
       | sure of.
       | 
       |  _It 's harder than you think_: The name of the game is to avoid
       | fooling yourself and you're the easiest person to fool (that's
       | from Feynman). If the problem seems hard it probably is harder
       | than you think. Be ruthless and don't settle for unsatisfactory,
       | hand-waving solutions to these problems. Most people can't detect
       | deadlocks or temporal properties of concurrent programs in their
       | heads.
        
       | SergeAx wrote:
       | > We should be far more focused on avoiding 0.1x programmers than
       | finding 10x programmers
       | 
       | Exactly my words two weeks ago:
       | https://news.ycombinator.com/item?id=28640661
       | 
       | We as an industry really should put a lot of effort into helping
       | 0.1x coders improve their skills to 1x level.
        
       | [deleted]
        
       | [deleted]
        
       | boffinAudio wrote:
       | 40+ years of experience here, and I'll tell you the #1 thing I've
       | learned:                   * Software is a social service.  Its
       | for other humans.
       | 
       | Incredibly, it doesn't matter how educated the developer, they
       | still seem to have to learn this lesson themselves, over and
       | over, until it sinks in...
        
         | JohnL4 wrote:
         | A corollary-ish observation of my own:                  * If
         | coders could write useful documentation (starting w/inline
         | comments) they probably wouldn't be coders.
        
           | michaelmdresser wrote:
           | What would they be instead?
        
           | jnaddef wrote:
           | They would be what then?
        
         | vnorilo wrote:
         | I think software is human expression. It can be a social good
         | or a business driver. But it does not have to be. It can have
         | no users, no IO or never run on a computer and still encode
         | deep meaning.
         | 
         | Does it need to be social to be _useful_? That is a value
         | system.
         | 
         | Many here communicate (beautiful) value systems, and that's
         | great! But ideas and software can transcend those.
        
         | Waterluvian wrote:
         | What do I do with this, though?
         | 
         | I think I get what it means but how do I act on it?
        
         | chii wrote:
         | you can replace the word "software" with basically any other
         | professional work and that is still the same. I don't know what
         | you can learn from the fact that it's a social service.
        
           | boffinAudio wrote:
           | Well, all economy is human economy, so yeah .. okay.
           | 
           | You can learn from the fact that its a social service by
           | actively NOT resisting the truth of this fact.
           | 
           | Incorporate it into your thinking with every commit you make
           | and you _will_ become a better programmer over time.
           | 
           | (Corollary: those developers who forget this fact, make
           | shitty software...)
        
             | Jensson wrote:
             | Everyone agrees that software is to serve humans. What they
             | disagree about is how to best make software that serves
             | humans.
             | 
             | For example, lets say you write an API that translates
             | text. Should you assume the text the human sent in is
             | correct and return an error? That way you can make better
             | translations when they send the right data. Or should you
             | try to be helpful and automatically fix spelling errors you
             | think you've found in order to make the API more human
             | friendly? Would make it easier but reduce accuracy.
             | 
             | You seem to be in the second camp, reduce power of API and
             | make them easier to use. But lots of people think that the
             | best way to serve humans is to make more powerful and
             | strict API's.
        
               | boffinAudio wrote:
               | Either option is fine, as long as your user agrees.
        
               | Jensson wrote:
               | You have more than one user. Some of them will want
               | power, other will want ease of use. You can't satisfy
               | everyone without making multiple products.
        
               | TeMPOraL wrote:
               | More than that, there may be a whole stack of software
               | components between your API and your users. In this
               | sense, quite a lot of software is written for computers
               | and not other humans (or, your users are other software
               | devs).
               | 
               | This is to say, "all software is written for humans" is
               | too general to be useful - the important issues are all
               | in the details.
        
           | wccrawford wrote:
           | I've met a lot of people who are writing code to satisfy
           | requirements and collect a paycheck. They're good people, but
           | just don't automatically think about the end user. They stop
           | when the requirements are met, instead of when the user will
           | be happy.
           | 
           | That's what they're supposed to learn from that, IMO.
        
             | jimbokun wrote:
             | Some organizations are structured such that it is difficult
             | for an engineer to do anything else. An engineer doesn't
             | always have access to the end user, unfortunately.
        
             | chii wrote:
             | > They stop when the requirements are met, instead of when
             | the user will be happy.
             | 
             | that's because they are doing software "for other humans" -
             | aka, their manager and PM, who gave them the requirements.
             | 
             | So the problem is not the software engineer, but the person
             | who creates those requirements to be fulfilled.
        
               | lazide wrote:
               | I think what the parent may have been complaining about
               | is essentially myopia in interpreting things - 'well,
               | this technically checks the box of what they ask for'
               | while willingly avoiding thinking about the larger
               | context of what is being attempted or trying to
               | understand requirements that don't make much sense.
               | 
               | Don't get me wrong - it has it's place, and if everyone
               | always tried to understand everything, there are a lot of
               | organizations and situations it would be crushing - but
               | it's also very frustrating in many situations for those
               | who want high quality products.
               | 
               | It's the 'not my job' syndrome, essentially.
        
               | dragonwriter wrote:
               | > I think what the parent may have been complaining about
               | is essentially myopia in interpreting things - 'well,
               | this technically checks the box of what they ask for'
               | while willingly avoiding thinking about the larger
               | context of what is being attempted or trying to
               | understand requirements that don't make much sense.
               | 
               | I think what _your_ post's parent was pointing out is
               | that in lots of environments, such myopia is just an
               | engineers job definition, for which they will be punished
               | if they stray. Interpreting end-user needs is someone
               | else 's job.
        
               | lazide wrote:
               | I think we just violently agreed, and even repeated the
               | same last line?
        
               | wccrawford wrote:
               | I'm not asking that develop to go against the
               | requirements. But it's often possible to satisfy
               | requirements without satisfying the user, even though
               | it's actually possible to do both.
        
         | DrBazza wrote:
         | Is this meant to be "code is for the reader, not the compiler",
         | or "people are the ultimate end users of your software"?
        
         | xwdv wrote:
         | Isn't this true of basically any job?
        
           | boffinAudio wrote:
           | Sure, but that doesn't make it any less useful as a fact -
           | especially when you are working with other developers who
           | choose to try to ignore/avoid it as a maxim.
           | 
           | Please don't tell me you've never met such a developer ..
        
             | xwdv wrote:
             | I am such a developer.
        
               | boffinAudio wrote:
               | See you in 30+ years! :P
        
         | hungryforcodes wrote:
         | I fully agree with this.
        
         | chaps wrote:
         | I do a lot of dev work with non-profits and such. About a year
         | ago I was working on an extremely difficult project as a
         | volunteer where I was insistent that a specific part was
         | vitally important to getting the project to move forward
         | (generalizing tables extraction from scanned OCR docs) and I
         | was spending a lot of time on it. One of the devs I worked
         | with, with 40+ years of experience, basically told me this
         | exact thing. He argued that what I as working on was a waste of
         | time and that I shouldn't work on "code golf" problems, because
         | of the likelihood of failure and that ultimately I should
         | consider the human side of the problem. He said it was best to
         | work on other things instead.
         | 
         | Fast forward a month later, I managed to actually do it, and it
         | worked almost flawlessly, across about 100k scanned PDFs.
         | Multiple long-term projects spawned off from the extracted
         | information, including some projects from the dev who told me
         | to stop.
         | 
         | My point being -- sometimes it seems like that line is used as
         | an excuse to not tackle hard problems if they seem likely to
         | fail. I agree with the line, and it's the exact reason I worked
         | on it as hard as I did, but the dev failed to consider that I
         | understood the social part of the problem, on experienced
         | principle.
        
           | bobthepanda wrote:
           | > generalizing tables extraction from scanned OCR docs
           | 
           | I would actually categorize this as a human problem. As a
           | society, we scan documents all the time. Data entry is a
           | massive time sink usually involving lots of corrections.
           | 
           | True code golf would be like switching languages/frameworks
           | for no discernable reason or trying to hit an arbitrary code
           | coverage metric because you're unsatisfied with the current
           | one.
        
           | darthvoldemort wrote:
           | If you're volunteering, why shouldn't you work on projects
           | that you find interesting? I don't understand the point of
           | view of the older dev.
        
             | minitoar wrote:
             | Presumably you want to maximize the positive impact your
             | volunteering has on others.
        
               | darthvoldemort wrote:
               | But having people working on potentially extremely useful
               | moonshots that they are interested in for free is a huge
               | win. I think it's really just a case of bad advice, and
               | not all developers with 40+ years of experience are
               | correct. In my opinion, it's better to have a motivated
               | volunteer engaged and working on something with unknown
               | impact that she is interested in, rather than get her to
               | work on boring things with less impact.
        
               | throwaway14356 wrote:
               | of course not, humans are most often wrong about
               | everything. Someone with experience is just that. Our
               | perspective changes.
               | 
               | I started coding at 12 because everyone said it was much
               | to hard for me. Now im old and motivate people by doing
               | the same. At the same time its good to be reminded by
               | others what happens if you drop one thing in favor of the
               | other.
        
             | schraeds wrote:
             | Even if you're volunteering you still have to work towards
             | agreed upon objectives. You wouldn't show up on a Habitat
             | for Humanity build site an start modifying the blueprints
             | and working on whatever you found interesting because you
             | are volunteering and are entitled to only work on
             | interesting projects.
        
             | inglor wrote:
             | I've found that volunteer work is _harder_ in terms of
             | getting the human aspect right.
             | 
             | New volunteers sometimes expect the red-carpet treatment as
             | someone volunteering their (pretty expensive presumably!)
             | time and as someone accomplished in their field. Volunteers
             | usually get the opposite treatment since it turns out the
             | other volunteers tend to come from a similar perspective
             | and someone doing the hard human work is often contributing
             | a lot more to the project than an otherwise excellent
             | engineer.
             | 
             | You can of course choose your volunteer activities to be
             | interesting to you. Open source is one such very fun
             | activity but lo-and-behold in projects I've been involved
             | with the human aspect is often very important and requires
             | a similar amount of hard work. This is often truer for
             | bigger projects/organizations than small ones.
        
           | WalterBright wrote:
           | > sometimes
           | 
           | Any rule of wisdom, followed blindly, leads to disaster.
           | 
           | Don't substitute rules for good judgement.
        
             | Y_Y wrote:
             | If we take your first statement to be a "rule of wisdom"
             | then it is either false, or all roads lead to disaster
             | anyway.
        
               | WalterBright wrote:
               | If you leave off the rest of my post, you're likely to
               | misunderstand it :-)
        
           | dempseye wrote:
           | Make an API out of that. There is huge demand for it.
        
             | mlboss wrote:
             | Looks this does it https://www.extracttable.com/
        
             | mediascreen wrote:
             | I'm pretty sure AWS Textract does that already.
             | 
             | https://aws.amazon.com/textract/
        
             | leesalminen wrote:
             | I'm in need of that right now! Would pay for it, especially
             | if the proceeds benefitted that non-profit!
        
             | mvcatsifma wrote:
             | I believe such an API already exists:
             | https://pdftables.com/ (no affiliation).
             | 
             | Went to a presentation at a Golang meetup in Amsterdam by
             | the guys behind this company. Seemed to know their stuff.
             | But I have no real world experience using it.
        
               | vic-traill wrote:
               | I had a look - from their FAQ [0]:
               | 
               |  _However, some PDFs are scanned documents, or only
               | contain images. PDFTables doesn 't perform Optical
               | Character Recognition (OCR) to turn these images into
               | text._
               | 
               |  _To process these kinds of documents, you will need to
               | either enable OCR in your scanning software, or run the
               | PDF through specialist OCR software before using
               | PDFTables._
               | 
               | [0] https://pdftables.com/faq
        
             | agustif wrote:
             | I needed to do this, so happy someone else made it!
             | 
             | A nice FOSS library for it was on HN recently, sharing is
             | caring I guess
             | 
             | https://news.ycombinator.com/item?id=28680136
             | 
             | https://extract-table.com/
             | 
             | https://github.com/vegarsti/extract-table
        
           | agumonkey wrote:
           | minuscule anecdote: my most cherished lines of code were an 8
           | lines vba excel macro to count duplicates for a non tech
           | colleague.
           | 
           | Turned her day from hell to cool (she had to filter
           | duplicates by hand and quadratic formulas over 2000+ lines
           | spreadsheet.
           | 
           | That's what computers are for.
        
           | xwolfi wrote:
           | It's a permanent balance. I have to "manage" (but I still am
           | a main contributor) a small team in a big investment bank
           | with angry busy trader-users, irrational "global" management
           | in other continent thinking we're all dumbasses in Asia, and
           | people on loaned rotation.
           | 
           | So, like your colleague, I try to strategize delivery. I
           | would never tell a guy not to work on a genius idea that
           | could change the entire paradigm, in fact I let 3 of my guys
           | do just that for the last 3 months, together, sometimes
           | alone. But they either not deliver, or very slowly, or
           | sketchily (not working as well as thought).
           | 
           | So what I do a lot is a compromise. I force them, despite
           | their complaint I don't care enough about the big picture of
           | their non-delivering work, to take smaller issues every week.
           | 1 or 2, give a candy to the user, and do your stuff then.
           | 
           | It worked incredibly well: while they've delivered absolutely
           | nothing of value in their own initiatives yet (but I still
           | think they can, it's just very long term), the users are
           | delighted by a constant stream of little innovations and
           | we've been recently identified as one of the most productive
           | team.
           | 
           | Meanwhile, the team next to us, algo programmers in C++, can
           | take 2 months to enhance an error message. Because they're
           | all revolutionizing the system and have no time for basic
           | human needs. They don't know yet, but they're gone soon. The
           | budget people found there's a new model of delivery that
           | could work, I wonder which one ;)
        
           | cbsmith wrote:
           | As per the blog's opening statement: context is key.
           | 
           | The industry (and really, it's not specific to the industry)
           | is rife with people who take pearls of wisdom out of their
           | context and apply them without the context to serve their own
           | ends.
        
         | bbarn wrote:
         | The biggest mistake people in our industry make is thinking
         | they are somehow exempt from the rules of society and business
         | just because they can use a computer better than most people.
         | 
         | Heads down genius coder everyone steps around ends up fired or
         | stuck in mid level forever, in reality. Guy who makes friends
         | with the Customer Service department and Sales team with
         | mediocre fixes get promoted, and in reality achieves more with
         | his career.
         | 
         | Software is useless without users.
        
         | nonima wrote:
         | Software is whatever you want it to be. I can write software
         | that is not for other humans. That's the most fun part of
         | software engineering to me, when you don't care about the users
         | and just do it just for the fun of doing it.
        
           | nkssy wrote:
           | Don't forget to write for _future you_. They 'd appreciate
           | some consideration as well. Mostly along the lines of "wtf
           | does this module do?"
        
             | throwaway14356 wrote:
             | The best one for me was documentation to complicated for me
             | - by me.
        
               | nkssy wrote:
               | You seem to have a complicated relationship with your
               | past self. I foresee further trouble in your future. Its
               | best if you take a torch or you'll be eaten by a grue.
        
           | goto11 wrote:
           | Almost any advice is useless if you write code purely for
           | your own enjoyment. This is why the context is so important.
           | If you enjoy writing convoluted unmaintainable useless code
           | then who is to stop you? Just understand most advice does not
           | apply to your context.
           | 
           | Most software development advice tacitly assume you want to
           | write code which works and is long-term maintainable
           | (potentially by someone other than yourself) and which
           | fulfills some purpose beyond just the fun of writing the
           | code.
        
             | matheusmoreira wrote:
             | > If you enjoy writing convoluted unmaintainable useless
             | code then who is to stop you?
             | 
             | Does anyone actually do this? I think it's the opposite.
             | 
             | I've spent truly absurd amounts of time thinking about how
             | to do things properly. I read books, read other people's
             | code, read programming language implementations, I just
             | read and learn as much as I possibly can before I even
             | start doing anything. I want my code to be right. I want it
             | to represent the truth of how the world works.
             | 
             | In a professional context where people actually have
             | deadlines, working code is usually enough to satisfy them.
             | How complex and maintainable it is tends to be a lesser
             | concern, to be addressed at a later time or never.
        
               | warkdarrior wrote:
               | > > If you enjoy writing convoluted unmaintainable
               | useless code then who is to stop you?
               | 
               | > Does anyone actually do this? I think it's the
               | opposite.
               | 
               | Code style, structure, and design are more of an art than
               | a science, so different people will have wildly different
               | opinions (extreme examples notwithstanding).
        
           | mattcwilson wrote:
           | And, as the article says, your advice and the GP's are
           | contextual.
           | 
           | If you're interested in creating software that makes people
           | happy, solves their problems, gets cherished and recommended
           | - then work hard to not lose sight of that goal in the thick
           | of crafting a massive code edifice.
           | 
           | If you're interested in pushing the limits of your own
           | creativity, and building a technical structure capable of
           | handling domain complexity with ruthless efficiency - then
           | sure, don't worry too much about how it looks, how it reads,
           | or how others respond to it.
           | 
           | If you're lucky, you might get to do both in the same body of
           | code. But not likely.
        
             | boffinAudio wrote:
             | Even if YOU are the only user, you're still writing
             | software for a human.
             | 
             | Hopefully.
        
               | ninkendo wrote:
               | You're writing software for all of your future selves.
               | 
               | http://www.catb.org/~esr/writings/unix-koans/prodigy.html
        
               | Jensson wrote:
               | With that argument you could say that everything humans
               | ever did was for humans. So either it is a platitude or
               | it is wrong.
        
               | boffinAudio wrote:
               | You could say that, but my cat thinks you'd be wrong.
               | 
               | However, I'm yet to see my cat boot up the computer.
        
               | ta988 wrote:
               | My cat would often turn the computer on or the tv off,
               | and I swear he did it on purpose because that's when he
               | was complaining he didn't got enough attention.
        
               | Jensson wrote:
               | Ultimately pets are for humans, whatever you do for your
               | cat you do for humans. The same logic works there.
        
               | bloak wrote:
               | With cats it's the other way round: the humans for cats.
        
               | Jensson wrote:
               | And from a computers perspective all human work is
               | ultimately for computers. Either making them or feeding
               | them data. The purpose of the cat is to generate cat
               | pictures for the computer etc.
        
               | SketchySeaBeast wrote:
               | My cat has turned off my computer on me - does that
               | count?
        
               | lucumo wrote:
               | Well, you could create software as art. Basically to
               | create it for the fun of creating it, not to use it.
               | 
               | But yeah, the end result is useless then, and can be
               | thrown out.
        
               | lazide wrote:
               | Or, like some art, of variable degrees of folks caring
               | about it based on other interesting properties - and made
               | for some purpose other than maintainability.
               | 
               | Demoscene, obfuscated coding contests, etc. seem to fall
               | under that category.
               | 
               | Uselessness in the eye of the beholder or something like
               | that.
        
               | lucumo wrote:
               | But in those cases you are creating for other people. The
               | point was made about software that didn't have any use
               | for any people.
               | 
               | In those cases, only the creation itself has a use, not
               | the end result. By definition.
        
               | dynamite-ready wrote:
               | But then we can also go the other way, and forget how
               | crazy and diverse humans are. So you will still,
               | eventually, end up facing the same challenge, framed
               | differently.
        
           | koonsolo wrote:
           | So you write code in machine language? Or are you writing in
           | a language that tries to be readable by English speaking
           | humans?
        
             | schwartzworld wrote:
             | Or they write it for themself and not _other_ humans.
        
               | j7ake wrote:
               | Your future self can be seen as "other" humans given a
               | long enough time frame.
               | 
               | Anybody who has looked at their own code done more than 5
               | years ago can surely attest.
        
               | SketchySeaBeast wrote:
               | 5 years is optimistic. A lunch break can be enough.
        
           | matheusmoreira wrote:
           | > when you don't care about the users and just do it just for
           | the fun of doing it
           | 
           | Yes!! That makes me so happy.
        
         | pjmlp wrote:
         | Approching the same experience level and fully agree.
         | 
         | A piece of coding art that doesn't fulfill customer needs, or
         | requires understading of language standard minutia for fellow
         | devs to do maintainance updates is worthless.
        
           | lazide wrote:
           | Yes, or in some cases even worse than useless - an active
           | problem that requires expensive specialization to not make
           | things an even bigger mess
        
         | mooreds wrote:
         | Can't agree with this enough. Sometimes it is directly for
         | other humans (a GUI), other times it is indirectly related (an
         | ETL job that converts data into a form that can be easily used
         | to drive a recommendation engine which provides recommendations
         | ... to people).
         | 
         | This is tied into asking "why", another one of the author's
         | points. At the end of the day, if you dig deep enough, the why
         | will be related to human happiness.
         | 
         | Bonus! If you keep this in mind, you'll also gain perspective.
         | While you don't want to live at 30k feet all the time,
         | periodically gaining high level perspective of the problem you
         | are solving has been, for me, one of the joys of software
         | development. (Not the only one, but definitely a significant
         | one.) Hopefully it is that way for you too.
        
           | kiklion wrote:
           | > At the end of the day, if you dig deep enough, the why will
           | be related to human happiness.
           | 
           | At one of my jobs, one of my tasks was to take client HR
           | feeds and load them into downstream systems for travel
           | management. On your second day of employment at your company,
           | you should have a profile in our system which was a portal
           | that displayed all travel policies and a profile in whatever
           | booking tool your company used.
           | 
           | We knew who your manager was so approval emails went out
           | automatically. We knew what corporate card was assigned to
           | you, so you never had to deal with that. We knew what
           | preferred vendors your company had agreements with etc
           | 
           | All I was doing was data manipulation and loading on a
           | scheduled or triggered basis. But ultimately it allowed new
           | hires in a new environment to have an easy time booking their
           | trip for mandatory training.
           | 
           | Any time our process failed, you had a traveler stressed out
           | that they wouldn't be able to book the trip in time or have
           | to outlay money and reimburse later or get stuck at a distant
           | airport.
        
         | Annatar wrote:
         | I reached quite the opposite conclusion: the purpose of
         | software is to make a computer do work. Then again, I purposely
         | refrain from writing end-user software and focus on backend
         | automation. It is a deliberate choice.
        
           | boffinAudio wrote:
           | For whom does the computer do work?
        
             | pbourke wrote:
             | Other computers
        
               | Aeolun wrote:
               | I see you work in finance. Where the humans are just
               | office decoration.
        
               | boffinAudio wrote:
               | It may be computers all the way down, but at the bottom
               | there is a human. Somewhere. Poor thing.
        
               | kiklion wrote:
               | Unless it's consumed by an AI. Which I don't fully
               | understand but am comfortable assuming that the AI might
               | be able to 'teach' itself to consume an API.
        
           | koonsolo wrote:
           | Do you keep your code human readable? Why?
        
         | agumonkey wrote:
         | Very few recent programs i've seen were socially useful. Some
         | might find comedy in this but the app my current gig uses:
         | 
         | - is un ergonomic and redundant (typing the same thing over and
         | over, no keyboard shortcut jquery era procedural code)
         | 
         | - the overall design is useless, it produces libreoffice
         | templates that takes ages to be badly filled
         | 
         | - secretaries go faster using fucking paper and filling
         | everything by hand
         | 
         | - the application has all the data at hand but nobody has
         | access to stats or complex queries, people have to also write
         | down stats with stick marks on paper so the hierarchy knows
         | what's going on
         | 
         | alas
        
         | taneq wrote:
         | Gonna expand on this just a bit. Software _isn 't a product or
         | a service_. It's a tool. No end user cares what your stack
         | looks like, they just want to click a button that solves their
         | problem.
         | 
         | Nothing between "click button" and "problem solved" is your
         | user's problem, they're all yours.
        
         | 535188B17C93743 wrote:
         | What's the quote? Knowledge can be taught. Wisdom can't be
         | taught or told... it can only be learned through experience?
         | 
         | Edit: Ah, found it.
         | 
         | "Wisdom cannot be imparted. Wisdom that a wise man attempts to
         | impart always sounds like foolishness to someone else ...
         | Knowledge can be communicated, but not wisdom. One can find it,
         | live it, do wonders through it, but one cannot communicate and
         | teach it." - Siddhartha
        
           | ArteEtMarte wrote:
           | The way I was told it: "Knowledge is knowing it's a one-way
           | street. Wisdom is learning to look both ways anyway."
        
           | hutzlibu wrote:
           | "Wisdom can't be taught or told... it can only be learned
           | through experience"
           | 
           | I recently had the thought, that good education guides you to
           | certain experiences to really learn the subject and not
           | memorize some definitions.
        
             | Jensson wrote:
             | Problem is that people learn the wrong things from their
             | experiences, not that they lack the experiences.
        
         | svilen_dobrev wrote:
         | 35y+ here, i just sent him something along:
         | 
         | "software is communication, made by people, for people"
         | 
         | (which is more or less what you say :)
         | 
         | With all the consequences. Most people, on either side, don't
         | get it. Ever.
        
         | jeffwask wrote:
         | 20+ years and I concur.
         | 
         | Improvements in my "soft skills" have carried me further than
         | any technical learning.
        
         | Aeolun wrote:
         | Probably something to do with the computer not caring about
         | that. If you constantly divide your time between someone that's
         | 100% logical, and someone that generally isn't, you're bound to
         | get confused.
        
         | dxbydt wrote:
         | > Software is a social service. Its for other humans.
         | 
         | I deeply disagree with this Calvinist utilitarian sentiment.
         | Its akin to saying sex is for making babies. Maybe its an
         | academic thing - When I went to grad school for CS, on Day 1 my
         | Algorithms Professor paraphrased Perlis's famous quote on the
         | blackboard - "Shaft the paying customer!"
         | 
         | You can find the whole quote on the first page of SICP[1], or
         | elsewhere[2]. imho its a highly toxic sentiment to think that
         | whatever a programmer does is for other humans. Software as a
         | Social Service...SAAS :)
         | 
         | imho the best software is written to scratch a personal itch.
         | Not to appease this customer. Not for other humans. Not as a
         | social service. In fact all the people I deeply admire in the
         | software world - Arthur Whitney, Kenneth Iverson, Mattis &
         | Kimball, Perlis, Dijkstra, hell even Linus, are generally
         | characterized as egotistical assholes in the public space who
         | really don't give a flying fuck about social service & humans
         | but care deeply about the software they created for their own
         | selfish reasons.
         | 
         | Mattis is quite explicit about this - "You should understand
         | that the GIMP and GTK weren't written to fill holes in the
         | software available under the GPL...GIMP was started because I
         | wanted to make a Web page. GTK was started because I was
         | dissatisfied with Motif...These are purely selfish reasons.
         | That is probably why the projects...eventually succeeded. I
         | find it much more difficult to work on something for selfless
         | reasons."
         | 
         | Perlis - "I hope we don't become missionaries. Don't feel as if
         | you're Bible salesmen. The world has too many of those already.
         | What you know about computing other people will learn."
         | 
         | otoh the people I deeply detest in software (too numerous to
         | name) are generally these do-gooder types who write software to
         | save the world & provide social service, employment to the
         | masses, add "value" insert-marketing-speak-here etc...
         | 
         | I'm ok with the hypocrisy in pretending to care about software
         | as a social service because I need to put food on the table
         | like any other programmer on the market, but deep inside, I
         | write code only for myself. I think a big fraction of
         | developers are like that. There's no harm in saying it out
         | loud.
         | 
         | [1]https://cloudflare-
         | ipfs.com/ipfs/QmQ3C4ooSCmBMuK7mKq4sqVAfGq...
         | 
         | [2]https://www.goodreads.com/quotes/405620-i-think-that-it-s-
         | ex...
        
           | spion wrote:
           | So if Linus works on Linux for his own selfish reasons,
           | howcome Linux isn't a one-person effort that nobody else is
           | using? And why did they pick the GPL?
           | 
           | It sounds to me like you're describing bad social behavior
           | but generally altruistic motivations with good social
           | behavior but non-altruistic motivations, and you prefer the
           | former over the latter. Sure, thats fine.
        
           | wizzwizz4 wrote:
           | > _provide social service, employment to the masses,_
           | 
           | If I want the computer to do XYZ, and I can provide an XYZ
           | service to other people? They're paying me to do my bug
           | testing, and I get to feel good about it.
           | 
           | If you're providing something that you think is a really good
           | service, but not for people like you, and not for somebody
           | specific you know either, it's _probably_ going to be
           | rubbish.
        
         | gjvnq wrote:
         | > Incredibly, it doesn't matter how educated the developer,
         | they still seem to have to learn this lesson themselves, over
         | and over, until it sinks in...
         | 
         | That's probably because many devs were socially isolated when
         | growing up. (How do you think they got so much time spent
         | tinkering with computers?)
         | 
         | Also, it is generally hard to imagine yourself in other's
         | shoes. Example: imagine trying to use your UI but with a
         | 60-year old vision instead of that of a 20-yo. Example: imagine
         | having no formal address or no citizenship (stateless).
        
         | euske wrote:
         | I think this applies to not just software, but engineering in
         | general. See, science is mostly about observing the natural
         | phenomena. On the other hand, there are jobs that are mostly
         | about taking care of people's needs. Engineering sits in the
         | middle. It's a mediator. We have to understand the circumstance
         | of both sides - nature (this could be something like hardware
         | capacity in our case) AND people. Just taking care of one side
         | makes you a bad engineer. You need to be technical and
         | sympathetic at the same time.
        
           | pydry wrote:
           | It applies to every job not just engineering. I thought this
           | was considered obvious.
        
             | lazide wrote:
             | For many people it definitely is not - some folks get into
             | software engineering because they have the mistaken (albeit
             | not as mistaken as if they were going into another career
             | like medicine!) belief they can avoid people and just deal
             | with machines.
        
             | BoiledCabbage wrote:
             | To clarify, you're saying that you vire that that being
             | technical and observing natural/physical phenomena are
             | important parts of selling clothing at retail, being a
             | novelist and working as a receptionist?
             | 
             | I think those are important jobs, and completely disagree
             | with you. I'm trying to understand if those are jobs you
             | weren't considering, or if we view each the
             | responsibilities of those jobs very differently.
        
               | pydry wrote:
               | No. I'm saying that retail, much like being a novelist or
               | a receptionist or a software programmer or indeed _any_
               | job is, as the OP puts it, a  "social service".
               | 
               | That being one of the defining charactetistics of a job.
        
         | SavantIdiot wrote:
         | 30+ years here, so I'm just a youngster compared to you, but
         | yes, that seems to get lost.
         | 
         | My first mentor in the 80's was a jolly drunken programmer
         | genius who enjoyed getting me to laugh at how bad my code was.
         | 
         | His biggest lesson was that other people need to read and use
         | my code, not just me. It isn't enough to just hack a solution
         | -- "Anyone CAN write code, but not everyone SHOULD write code"
         | was his favorite quote -- but code needs "style" and "heart".
         | 
         | He even had a t-shirt made for me after my internship ended
         | that had those two words and a bunch of my worst code examples
         | printed on it. I still have it: just a bunch of MASM code. I'll
         | Never forgot that guy.
        
         | zanethomas wrote:
         | another 40+ here w0rd!
        
       | taylodl wrote:
       | I've been developing software for decades and here's the most
       | important thing I've learned: systems will be around running for
       | _far longer_ than you ever thought possible, even when you
       | allowed for systems being around for far longer than you thought
       | possible!
       | 
       | Keeping that in mind, I'm continually amazed at the number of
       | developers who just _love_ complexity. Don 't get me wrong, they
       | all profess to strive for simplicity but their work betrays them.
       | They just love intricate dances carefully coordinated across
       | several components, never minding how anyone 5, 10, 15 or 20
       | years down the road will ever comprehend this madness or how it
       | will ever be maintained without incurring exorbitant costs.
       | 
       | I religiously adhere to the KISS principle - Keep It Stupid
       | Simple. Once you think it's simple look for ways to make it even
       | more simple. Think about operations failing at the worst time of
       | day possible on the worst possible day of the year - how will you
       | _quickly_ find and resolve the issue? What if it 's a new hire
       | who gets the call? I'm just amazed at how developers gloss over
       | this, all while bitching about the "spaghetti code" they
       | inherited. It boggles the mind.
        
         | lowercased wrote:
         | In 2017 I had someone call me and say "the system's broken". I
         | knew who it was, but didn't know what they were referring to.
         | Turns out it was a web application I'd put together in 2003.
         | 14+ years later, it wasn't working, and... they needed help.
         | 
         | I went spelunking a bit in my own code, cursing the jerk who
         | built some of it, praising the genius who put in other parts,
         | remembering cutting certain corners to get home for dinner on
         | time, etc.
         | 
         | Having to support anything 10-15-20 years down the line gives
         | you a different perspective on maintenance and simplicity that
         | I don't think you can quite ever really comprehend beforehand.
        
       | UncleOxidant wrote:
       | "1. I still don't know very much"
       | 
       | I've been in the game for almost 30 years. I often feel like I
       | know less than I thought I did 25 years ago, and that I know less
       | as time goes by. I'd also have this as my #1 on the list because
       | it just feels so surprising. I think most of us start out in our
       | 20s thinking that in 30 years we'll have mastered the field, but
       | it definitely doesn't feel like that, not even close.
        
         | ipnon wrote:
         | The domain of software engineering has almost certainly
         | increased in size and complexity faster than any of us have
         | learned. We must focus on the fundamentals. All of the new
         | languages and architectures are a storm hovering over a bedrock
         | of empirical computer science.
        
           | UncleOxidant wrote:
           | It's not just all the new stuff that's emerged in the last 30
           | years. I feel like I didn't really understand a lot of the
           | fundamentals like I thought I did back in my 20s and that
           | there were some major holes in my education that only became
           | apparent after some years of experience in the field. Often
           | you don't know what you don't know. I now know there's a lot
           | I didn't (and don't) know and I think that's a valuable thing
           | that mostly only comes with experience.
        
       | api wrote:
       | I've been into it about 25 years. Here's a few of mine.
       | 
       | 1. This industry is very faddish, and many fads are designed to
       | make money for the people driving them or lock you into someone's
       | ecosystem. Avoiding those is a superpower. A ton of today's cloud
       | native trends fit into this category. They are gateways to a
       | paradigm where you buy a lot of things as a service at a massive
       | markup that are relatively easy to do locally or obtain at much
       | lower rates.
       | 
       | 2. Simplicity is harder than complexity. Managing complexity is
       | merely clever while eliminating it is intelligent. Eliminating it
       | without sacrificing coverage of the problem domain is genius.
       | There is some very interesting academic literature on the idea
       | that intelligence is or at least heavily involves data
       | compression (and that this is what "learning" is), so this has
       | some basis beyond the field.
       | 
       | 3. Unfortunately re: #2 more complex less elegant solutions often
       | win. Many argue that this is because they capture more of the
       | problem domain, but I often disagree. I think it's a mixture of
       | sophomore developers being impressed by complexity (having not
       | yet learned #2) and the fact that complexity creates industries
       | where money can be made on adjacent software, services, and
       | consulting. As a result of the latter complex clunky solutions
       | can be better at building an ecosystem full of self-interested
       | evangelists. Recent example: Kubernetes vs. the Hashicorp stack.
       | 
       | 4. If you make something work, you are only maybe a quarter of
       | the way to making it a product. UI/UX is the rest of the journey.
       | UI/UX tends to not be fun, so people have to be paid to do it.
       | This is why open source and open systems almost always fail to
       | achieve wide adoption beyond developers and IT people. They have
       | no economic model, so they can't hire people to make the product
       | usable for people other than nerds.
       | 
       | 5. Infosec people are usually afraid of the wrong things. Most
       | breaches involve social engineering or a passive mode of entry.
       | Infosec people like to obsess about things that are sexy like
       | cryptography but will happily type "npm install" as root on
       | production and pay far too little attention to security against
       | social engineering vectors.
       | 
       | 6. There are 10X (ish) developers just like there are 10X
       | athletes, 10X mathematicians, 10X writers, 10X salespeople, 10X
       | musicians, and so on. The reason many people don't believe in 10X
       | developers is that it's so hard to objectively measure developer
       | productivity, especially at scale.
        
       | lincpa wrote:
       | You might like a programming methodology based on elementary
       | school mathematical models (take Clojure as example)----The Grand
       | Unified Programming Theory: The Pure Function Pipeline Data Flow
       | with Principle-based Warehouse/Workshop Model.
       | 
       | Based on the simplest and most vivid mathematical model is its
       | biggest advantage.
       | 
       | Its mathematical prototype is the "water in/out of a pool"
       | problem in elementary school mathematics. When we increase the
       | number of pools and water pipes, the combination of different
       | types of liquids, the time and speed of input and output, and
       | other factors in this mathematical problem. It forms a
       | warehouse/workshop model in the form of a dynamic tree Gantt
       | chart. It should be the IT architecture with the simplest and
       | most vivid mathematical prototype.
       | 
       | It is an epoch-making theoretical achievement in the IT field, it
       | surpasses the "von Neumann architecture", unifies the IT software
       | and hardware theory, and raises it from the manual workshop
       | production theory level to the modern manufacturing industry
       | production theory Level. Although the Apple M1 chip has not yet
       | fully realized its theory, Apple M1 chip has become the fastest
       | chip in the world.
       | 
       | It has a wide range of applications, from SOC to supercomputer,
       | from software to hardware, from stand-alone to network, from
       | application layer to system layer, from single thread to
       | distributed, from general programming to explainable AI, from
       | manufacturing industry to IT industry.
       | 
       | The Grand Unified Programming Theory: The Pure Function Pipeline
       | Data Flow with Principle-based Warehouse/Workshop Model:
       | 
       | https://github.com/linpengcheng/PurefunctionPipelineDataflow
        
       | chown wrote:
       | > No one is going to tell you in an interview that they are going
       | to be unreliable, abusive, pompous, or never show up to meetings
       | on time. People might claim they have "signals" for these
       | things...
       | 
       | I had a great interview with one of the FAANG companies. The
       | technical interviews, 6 of them in a row!, felt more like they
       | were wanting to see me fail spectacularly rather than focus on my
       | approach of solving whiteboard problems. Still, I did more than
       | average to get "pass" from them. But HR dropped me because she
       | didn't like the answer to "what's your weakness?" question along
       | the lines of - "I focus too much on job at hand to an extent that
       | I struggle with work-life-balance and working on it. If I can
       | overcome that and learn how to take breaks timely I might be more
       | productive.". HR didn't like it because it was not one of the
       | canned responses she was expecting -\\_(tsu)_/-
        
         | xyzelement wrote:
         | >> I struggle with work-life-balance and working on it. If I
         | can overcome that and learn how to take breaks timely I might
         | be more productive.". .. HR didn't like it because it was not
         | one of the canned responses she was expecting -\\_(tsu)_/-
         | 
         | Just curious, how do you know that (a) you failed in HR (b)
         | that it was this question and (c) for this reason?
         | 
         | I ask because it's unlikely that this was literally the
         | feedback given you. Also, "I work too hard" does sound a bit
         | canned.
         | 
         | >> The technical interviews, 6 of them in a row!, felt more
         | like they were wanting to see me fail spectacularly rather than
         | focus on my approach of solving whiteboard problems.
         | 
         | I do think this is more "in your head" that real. Nobody shows
         | up to an interview wanting the other person to fail, but "how
         | they solve whiteboard problems" isn't the goal either. It's
         | more about - how does the person, think, collaborate, make
         | tradeoffs and drives to an outcome - the goal being
         | specifically to translate that outside the whiteboard space.
        
           | skrtskrt wrote:
           | Yeah even if the person came to this answer of their own
           | independent thought process, this answer to the weakness
           | question either comes off as:
           | 
           | 1. "I work too hard" which is one of those classic canned
           | answers to avoid that makes you sound like a suckup
           | 
           | or
           | 
           | 2. "I can't manage my time to the point where I am in danger
           | of tanking my own productivity or burning out or both", which
           | even if true (plenty of us suffer from this), it is obviously
           | not a great answer to give in a hiring process.
        
       | Arjuna wrote:
       | _"The 10x programmer is a silly myth."_
       | 
       | Incredibly high performers exist, but are rare.
       | 
       | For example, the following quote is from a talk given by Gabe
       | Newell.
       | 
       | (Unfortunately, I do not have the URL to the source video for
       | this quote.)
       | 
       |  _"At IBM in the 1980s, typical productivity would be 1,000
       | debugged, shipped lines of code per year. That was the metric
       | that they used for their median employee. Where as, when we were
       | shipping Half Life 1, one employee, Yahn Bernier, was shipping
       | 4,000 lines of code per day."_
        
         | hereforphone wrote:
         | HalfLife 1 wasn't shipped in the 80s though. Maybe HL3 will be
         | shipped in the (20)80s.
        
         | jeremyjh wrote:
         | If you measure lines of code you will indeed find people who
         | produce a lot of it. Is that a lot of value though?
        
         | marcus_holmes wrote:
         | I think it's more that the "10x programmer" myth has caused a
         | lot of pain and bullshit.
         | 
         | There are startup CEO's who won't settle for anything less than
         | a "10x programmer" and waste everyone's time trying to find
         | one.
         | 
         | There are narcissistic coders who think they're "10x" and
         | therefore can act like spoiled children to everyone around
         | them.
         | 
         | If I hear "10x programmer" in anything other than "...is a
         | myth" then it's a sign that whoever is speaking is probably
         | someone I don't want to work with.
        
       ___________________________________________________________________
       (page generated 2021-10-08 23:00 UTC)