5 ms·
> Eventually, Rick snapped. Once he departed the company, the team of supposedly “mediocre” engineers redid his work to make it more elegant and efficient: “We
by d23 6y ago
> Eventually, Rick snapped. Once he departed the company, the team of supposedly “mediocre” engineers redid his work to make it more elegant and efficient: “We didn’t have any mad geniuses building everything from scratch. But our productivity was never higher.”
A silly strawman. I'd firmly put someone like this in the bucket of "not that effective."
- wutbrodo 6y agoThat was my thought too. The problem here isnt with "superstar developers", it's with people who don't understand the work trying to label people as such and doing a piss-poor job. Someone who doesn't write code others can read isn't even a mediocre developer, hes a bad one. It's arguments like these that make me very skeptical of the claims that 10x developers don't exist, as I've yet to hear such an argument that doesn't fail at basic critical thinking. That being said, I fully agree with the article's framing of this view as simply saying that talented developers need a healthy working environment in order to reach their potential.
- lambdasquirrel 6y ago> That being said, I fully agree with the article's framing of this view as simply saying that talented developers need a healthy working environment in order to reach their potential. The flip side being, a talented developer might not want to join a company where an engineer like that has been the top dog (and the people below haven’t been around enough to have an idea what being a senior engineer is about). It just ends in tears and frustration for the ”talented developer.”
- wutbrodo 6y agoIn my experience, a side effect of a healthy working environment for one person is that it's a healthy working environment for everyone. There have been a couple of teams I've been in a position of technical leadership and/or been better than the rest of the team on all or some relevant technical axes. In all of these cases, even if I was being 100% selfish, I would still _want_ to grow the people under me, since the stuff they grow into is the stuff I want to grow out of. As a concrete example, I'm currently the TL of a team, with a primary personal focus on ML, and it's been a huge win-win to hand off ML system maintenance tasks to non-ML engineers. These tasks provide them valuable exposure to the way ML production systems work, familiarity with ML workflows/tooling, and practice reasoning about ML systems. But they also free my time up of tedious, straightforward little tasks, to work on things that challenge me more. It's win-win-win, as the company is getting a more efficient and productive allocation of resources too.
- winrid 6y agoYeah, if you're not focused, and you're not even writing documentation, there is no way you should be considered very good at your job. Early in my career I had someone that kept telling me "we don't write documentation because nobody will read it". I'll never put up with that again. You can take 30mins to write a confluence page describing the context, the solution, and comparison to other solutions and why this one was picked. It will save the company many hours later when someone else has to pick up your stuff.
- cameronfraser 6y agoDifferent companies have different needs, early stage startups would probably fire you for spending too much time on documentation because they're paying you to make progress on their product and you're usually working alone anyways or very small teams with heavy interaction. So not only would nobody ready it, it would become outdated within a month.
- dawnerd 6y agoAgreed, small teams could get easily dragged down by obsessing over documentation (and even testing to some extent).
- winrid 6y agoPeople think that documentation needs to be kept up to date. It doesn't. You don't have to always write docs saying "here's how this system works". You just write a document as a proposal saying "here is how I want to build this system". It takes 30mins. It helps everyone. If you want to change the system significantly, you just write another design doc. Also, if you do this you probably don't have to redo things all the time. If a company fires you for outlining how you're going to solve a big problem - they aren't going to do well anyway so you don't miss out on much. Based on my experience from a fast growing billion dollar company, and a company that you would call "fast moving" but will never be anywhere near as successful because they can't focus, let alone sit down for 30mins and write a document.
- pjmorris 6y ago"If a programmer is indispensable, get rid of him as quickly as possible." - Weinberg, Gerald. The Psychology of Computer Programming.
- d23 6y agoThat's a great quote. I'll have to check that book out. Is it worth the read? I think about the psychology involved and our brains as part of the system far more often than I ever see it discussed.
- pjmorris 6y agoI heartily endorse it. Someone once compared Weinberg's writing to a coal mine; "there's something worthwhile in every shovel-full." 'Psychology of Computer Programming' was published in the early 70's and shows some signs of age. As illustrated by the quote, many of the situations it describes and addresses are perennial. It's $9.99 at Leanpub and Amazon, give it a shot!