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.
Things I’ve learned in my 20 years as a software engineer
221–230 of 745 posts
Re: Things I’ve learned in my 20 years as a software engineer
#222Earlier quoted context omitted.
>, 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.ycombin…
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?
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.
Re: Things I’ve learned in my 20 years as a software engineer
#223> 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 h…
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.
Re: Things I’ve learned in my 20 years as a software engineer
#224The 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…
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
Re: Things I’ve learned in my 20 years as a software engineer
#225Earlier quoted context omitted.
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 t…
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.
Presumably you want to maximize the positive impact your volunteering has on others.
Re: Things I’ve learned in my 20 years as a software engineer
#226Earlier quoted context omitted.
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 t…
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.
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.
Re: Things I’ve learned in my 20 years as a software engineer
#227Earlier quoted context omitted.
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.
Presumably you want to maximize the positive impact your volunteering has on others.
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.
Re: Things I’ve learned in my 20 years as a software engineer
#228Earlier quoted context omitted.
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…
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 mu…
> 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.
Re: Things I’ve learned in my 20 years as a software engineer
#229Earlier quoted context omitted.
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. I…
> How long would it have taken you or me to write Doom, or Quake? Almost definitely not 10 years.
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.
Re: Things I’ve learned in my 20 years as a software engineer
#230Earlier quoted context omitted.
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. I…
> How long would it have taken you or me to write Doom, or Quake? Almost definitely not 10 years.
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.