I praise 1x programmers, but for reasons that might go against the grain in HN. I'm from Spain so our working ethic is different from the Anglo-Saxon world. "Work to live, don't live to work" as the saying goes.
My principles for a 1x programmer:
* Work is a means to an end. A job should support the lifestyle you want to achieve, not be an end on itself.
* 9-to-5 is a perfectly reasonable schedule. Fiercely protects personal and time off.
* Prefers to spend time with their family or hobbies (e.g. train for that marathon) rather than working on a side project in Github.
* Strives to do a "good enough" job rather than absolute excellence.
* Keeps their skills at a reasonable level to do the job, but doesn't necessarily work on continuously improving.
* Most companies don't really need 10x engineers, and would do just fine with 1x ones.
Some people might cringe at this list. Some will argue that one could never be a good developer following those principles. I'm ok with that. I think we should acknowledge for many people programming is just a paycheck and they don't share the passion of the HN crowd. We should broaden our horizon of what success looks like in the development job. Me, for one, feel like some of my friends that fit the description are winning at life more than I do.
> Some will argue that one could never be a good developer following those principles.
I'll argue those people need a reality check based on how things work in every other profession.
My dentist is a great dentist but she works 8am-3pm and most decidedly does not spend an additional 8 hours slogging through leettooth exercises on topics barely realated to the practice of dentistry.
My friend is a respected surgeon, but when he clocks out of the hospital he goes cycling and to the beach.
Same goes for pretty much every professional career outside of software development. Many of those have continuous education requirements, but they are done as part of the job. For example my dentist is out several weeks a year on that, not available for appointments.
So I agree with the above list, but there's nothing to apologize for in it. Working 9-5 and then completely disconnecting is the mark of a professional.
> My friend is a respected surgeon, but when he clocks out of the hospital he goes cycling and to the beach.
But to become a surgeon, he probably had to put in ridiculous hours for years as a med student and then resident.
Going through that gauntlet is what earned him the reasonable hours and good pay, by reducing his competition.
Similarly the people doing leetcode are doing it to stand above the competition and make big bucks in silicon valley. The people working reasonable hours in Spain are making much less extravagant salaries.
Basically the general rule is if you desire above average money, you have to put in above average effort at some point in your career.
If you want to put in average effort, you have to be happy with average salary. Which is fine for many people.
But you won't get FAANG/surgeon pay if you never put in above average effort.
> Basically the general rule is if you desire above average money, you have to put in above average effort at some point in your career.
My (probably cynical) take is that most SV devs are also 1x. You make the big bucks not just by being a 10x dev, but by some combination of going to the right schools, making the right connections, learning how to negotiate and when to look for new jobs, learning to jump through the big tech interview hoops etc. So yeah, you have to put in above average effort, but maybe not directly into improving your craft.
> My (probably cynical) take is that most SV devs are also 1x.
Not at all cynical and why not? That's basically my impression and I've been hiring people here for 30+ years.
A team needs a mix of people with differing skills and interests. Even notice how "all star" games are so boring? no sabermetics used in picking those people. And in any company, 90+% of the effort is routine stuff, especially once you've launched.
Jumping through big tech interview hoops is the most correct part of your statement and it invalidates the idea that you ned to go to the right school or have the right connections. And for what it's worth, the average FAANG developer I've worked with has been much better than my colleagues at prior companies.
> And for what it's worth, the average FAANG developer I've worked with has been much better than my colleagues at prior companies.
I worked at a FAANG and I'd agree with that: the people there were good. But there was a huge caveat: most of them were definitely doing what would be "1x work" in a non-FAANG jobs. FAANG is very good at hiring but not too good at using the people to their full potential.
FAANG Software Engineer pay is not that great when compared to a Surgeon (or many other good jobs) for people who have been doing other good jobs for decades.
How many Software Engineers do you who drive Ferraris? Probably not many, but for Surgeons, Sales People (at good companies) it's not a big deal.
No other industry would anyone tolerate being told to study 4-8 hours a day for months for a chance to pass an interview.
I realize I'm ranting but I've a Software Engineer with over 20 years experience and I've kind of lost interest being in an industry where the only thing that matters for an interview is how good I can cram leetcode, rather than what I've designed and built. Granted it would be hard for me to easily find something that pays more so I'm not quitting my day job (and now extra night job).
There are two ways to prep for interviews. One is to actually learn the principles. The other is to grind and memorize. 4-8 hours a day for months is the latter and is not the intended interview process, though some people go that route. “Review for a weekend” is, in my observation, what people at these companies are hoping that you’ll do.
One problem though (and I've interviewed at FAANG companies and similar process) is now they really expect you to memorize at lot because other developers are doing it as well. On one of my questions
I was supposed to quickly recreate the quick-select algorithm from memory in 10 min. Stuff like this I learned a long time ago but have no need to memorize how to code it by hand quickly.
Brushing up for the weekend is not enough if you haven't touched the stuff in 20 years. When I've spoken with recruiters they recommend studying many hours per day ever day for at least 2 months.
No doctor, lawyer, real estate agent (and many other much higher paying professions) would ever tolerate this type of interview.
Personally the interview prep is so boarding I can't wait for the day to be done with this field (not actually software development) just having to do it for work.
> No doctor, lawyer, real estate agent (and many other much higher paying professions) would ever tolerate this type of interview
Hah. The grass is always greener on the other side I guess.
- The doctor has to pass exams to get their license to practice. And additional exams to be able to practice in a specialty. It often takes YEARS before a doctor passes the requisite exams to be able to practice in their chosen specialty.
- The lawyer situation is somewhat worse. It is significantly challenging to get a job after you get a law degree (which usually is rather expensive and at any rate an additional expense after your first degree), presuming you pass the bar exam. Let's say you did better than average, you'll probably end up becoming a lawyer in a small firm with <100k salary. The big money is in New York city firms (the equivalent of "FAANG" in the legal sector) which is super competitive, and they plainly won't consider any job application from "qualified lawyers" who worked in lesser firms for a couple years.
The FAANG situation is simply a result of lack of gatekeeping in the software industry (you don't even need a CS degree) and general inclusiveness compared with the other professional industries. You don't need have a piece of paper proving you can code -- and that means sometimes candidates really literally can't code.
If the software industry operated like the medical profession, you'd have to pass a leetcode test before you are allowed to use a C++ compiler without supervision. And you'll have to take tests every 5 years to prove that you still know how to write quicksort.
If the software industry operated like the legal profession, FAANG companies would refuse to consider applications unless you had a perfect GPA from the top 20 CS programs or from another FAANG company. And then you'd have the privilege to work 60 hour weeks with them.
If the software industry operated like real estate, you'd get a low base salary and most of your money would be made on how many users your features contributed to revenue for your employer.
Nobody says you _need_ to work for FAANG. Most people don't. Given the competitive situation, obviously some people think the increased chance of getting an offer is worth the time invested in grinding leetcode problems. If you think the grass is really greener on the other side, try studying a law degree and getting a job in a New York city firm and then tell me it's really a better experience.
Disclaimer: I have a law degree (not in USA) and work for a FAANG. When I have choice over interview questions I don't ask leetcode style questions.
>completely disconnecting is the mark of a professional.
Slight nitpick, but this is the mark of a person with a vocation. A "professional" answers to a higher ethical calling. The name derives from "professing" an oath; for example, for a doctor to "do no harm" or an engineer to work in the public good. This can occur within a 9-5 window, but I would expect that, if needed, a professional would put their oath above clock hours if it was in conflict.
I would argue the other way around. A "professional" gets paid for a job, full stop. A "vocation" derives from "to call", or someone's "calling", as in someone's purpose in life.
Maybe our etymology is what sets us up for work-life imbalance :)
Clergy was the first example where the term derived so I don't know if the roots of the word align with your definition. Granted, colloquial usage changes word meanings over time.
I'm from Italy, very similar country, very similar work ethic.
I agree that, if anything, it's people like me who are weirdly obsessive about their jobs to be the odd ones out.
I have a couple drifts about that, though:
- I spend 40+ hours a week in front of a terminal. That is a lot of time. Trying to do a good job and finding interest in what I do is at least in part a self-defense mechanism: if I'm invested in what I do, I'm more likely to be happy at work and have positive relations with coworkers.
- It mustn't become a way to fend off productive change. Refusing new good practices "because we don't want to learn" or "because it's good enough as it is" is incredibly stupid and self-destructive. Unfortunately, there's overlap between "it's just a job" and "different = bad" attitudes.
It's certainly okay if one is just in for the money, it's none of my business to investigate people's motivations. But if you want to do this job for the rest of your life, 35 years times 48 weeks a year times 40 hours a week is a lot of time, so it's not an attitude I'd necessarily encourage.
> I spend 40+ hours a week in front of a terminal.
Italians work way more than Northern Europeans, but their salaries are significantly lower because of low productivity. This is true for any occupation, including software development.
I need to see those "Low productivity" numbers. I worked with ppl all around the work and I'd never seen that, what I see is companies offering lower salaries because the can in some countries, period.
Anecdata: My previous team mate was Italian, a guy in his 50, former co-founder of an small Italian ISP super productive, bast amount of knowledge and working for 55k€ so.. please cut that "you get what you deserve".
Productivity doesn’t only depend on hard work, but also on many other factors, such as capital intensity and institutions.
One example that comes to mind is that in the UK I get a new laptop every other year and whatever software licence or training I may need. My brother in Italy was given a 5 year old laptop that would crash every other hour and his budget for software and training was 0. The result is that he used to work twice as hard as me, while being half productive.
I mostly agree with this list, I’d just like to add a caveat that working on a side-project can be a hobby!
I have some DnD-related campaign ideas that won’t work in DnD, so I’m trying my hand at making them a pixelart game. Definitely a hobby and creative outlet!
OTOH, I’m also trying to write a database implementation in modern C++. While fun, it also mostly serves as a “look me smart” for future job applications because I’d love for my job to be a bit more in depth.
I think it’s important to acknowledge the differences!
I think GP points more towards working on side projects for the sole sake of showing off over anything else, which is a particularly insidious part of "hustle culture" being normalized by a lot of "top tech advice". Especially among the younger crowd, where the market is far harsher on jobseekers and almost everyone is met with skepticism unless what they worked on almost perfectly matches what the company is already doing.
> > * Prefers to spend time with their family or hobbies (e.g. train for that marathon) rather than working on a side project in Github.
Ha! I've encountered people whose lives revolved around running. They often fly to marathons on weekends. They'd spend mornings or evenings getting treatments from physical therapists, or cross-training with personal trainers. They spent lots of money and were in pain a lot of the time.
Nobody was forcing them to do this. They weren't ever going to run fast enough to become rich or famous. They did want to beat their previous times and/or run more marathons than last year. They enjoyed a sense of community with fellow runners.
Should these people receive corresponding advice about 1x marathoning? Maybe...
10x can come from many different places, a few examples:
- Person A gets assigned a bug, that there is a memory leak in the library, they are familiar with the code, they open up the profiler, see that there's an excess of Object X, they look for all the allocations, and see that it's not freed in one of 3 places. Whereas Person B does not really have a really good grasp on how either a library or the profiling tools work and mulls around, perhaps has to ask for help, and takes a lot more time.
- A is confronted with an algorithmic challenge, they figure out an elegant solution in 1 hour, they think it through really well, the solution is flawless the first time. B takes more time, say 2x, and still are not sure in the solution. They implement it nevertheless, and pass it onto QA, who finds bugs, and the issue needs to be reconstructed, the code rewritten and retested. These things compound and add up.
- Writing tools instead of doing things manually as others have pointed out
- Using a library meant to solve a problem instead of rolling your own
All these things are based on concrete experiences that happened to people around me.
10x is a really bad term, it tries to quantify a difference without a baseline.
The difference isn't in quantity, but imo rather in mentality. Relentlessly automating repeatable tasks can net 100x or 2x or 0.5x depending on context, but something that don't happen often enough.
The lowest performing member of your team could be negative. Or they could be twice as good as the lowest performing person on some other team, or they could be above the industry average, meaning a 10x programmer becomes a 5x or 20x when the team changes.
I’ve always internalized as a “typical, competent programmer” rather than team-specific anything (Peopleware’s definition notwithstanding).
I often find that developers with an interest in product development and the business side can make huge contribution by suggesting alternative solutions to writing more code.
With some gentle pushback on requirements they can help clarify what the real issue is. Of course, this has to be done carefully or it will quickly get very annoying.
Another useful skill is to have a feeling for when problems get too hard and it's time to backtrack. At least in my work, most of it is basic CRUD of different varieties. If I find myself inventing new things or not finding any answers Googling my problem, it's likely that I'm on the wrong track and there is a simpler path I missed.
Managed services. S3 instead of building a process to store and replicate files on a file system that you manage. DynamoDB or RDS instead of managing your own DB.
Libraries instead of cutting your own code for everything.
Effective searching for projects who have already done the thing you’re about to do.
Sometimes: it’s as simple as taking a day or few days to think the problem through to ensure you really understand it.
Finding a way to deliver the needed functionality in Excel/Sheets instead of a custom application.
To be more than a 1x programmer, you have to work on things that are not the most immediate goal all the time. This isn't necessarily more effort, it's just different effort, and will not have immediate positive outcome for your company.
All the biggest and most important productivity and outcome enhancing things I've done at work have been done without management knowledge or approval.
Not at all. To be a 10x programmer you need to be lazy. Automate everything, brutally eliminate complexity, and focus 100% on what makes sense from a business point of view.
I agree that this work ethic is indeed healthier and with most of the list, but I want to make one caveat: a programmer working secretly after hours to deliver more is not really a 10x programmer, he's just someone doing unpaid overtime (and risking burnout). Truly 10x developers also only work 9-to-5, the same as 1x.
I also disagree that continuously improving is unnecessary. It absolutely should IMO. But it should happen between 9-to-5, in the workplace.
Is that really a thing, secretly working more to give the appearance of higher output, while not even getting paid for it? Given the little time we have on this planet, this sounds like a suboptimal use of it.
It definitely is. It happens with over-achievers but it also happens very frequently with under-achievers.
In jobs where people have quotas it is very visible, seeing people scrambling to finish it all by the end of the month, to the detriment of their free time. But this is also the "secret" of some over-achievers.
I think I'd rather invest the extra time into OSS or a hobby project, which, even if you only do it for vanity, might even look more impressive to others.
The secretly part is usually what doesn't happen. Most brag about it. You don't get paid extra regardless because most of us are salary and don't get overtime even if you work 80 hours per week.
I fully agree with you, that it is important to keep your day job separate from the rest of your life and be able to detach yourself from work.
However, I believe strongly that you can only have a happy life if you love what you do in your day job too. 9-to-5 are too many hours to be miserable and wait for end of your work day[*]. Also you spend a lot of time with your colleagues. Life is short, don't waste that time.
I'm German, by the way, and I'm not sure how well my attitude fits the cliche;-)
[*] Don't you have a nicer word for the end of your work day in English? In German it is called "Feierabend", where "Feier" comes from fire but means celebration and "abend" is evening. So we have a party evening every day. What an apt word.*
I think you're making an assumption here that menial or dirty jobs are always unrewarding, but that's not my experience.
I've met many people doing the kind of jobs you describe who find it satisfying. They may love using their hands, making the world a little cleaner, helping others, or just like their coworkers. Some say they like the simplicity of a job where it's easy to tell when you did it well and you never need to take your work home with you. Some find it ennobling because of what they pay lets them do.
At the same time, I've met just as many people in theoretically "good" jobs like well-paying software engineering that are utterly miserable.
This falls apart when there are less jobs than individuals who would be happy in that job (extrapolated to all fields and interests), or conflicting interests appear. Realism doesn't always mesh with that ideal.
I've been developing professionally for about 10 years in the US, and I feel like just in that time frame, the culture is shifting more in this relaxed direction. The really intense work ethic was pushed by the startup culture. People thought they could be the next Zuckerberg. In recent times, we've seen countless startups either fail, succeed and become evil Big Tech, or fail and become evil anyways like Theranos. On top of that, when startups finally get their big payday, the developers often get screwed over, so what was all the sacrifice for? Working normal hours is just much healthier unless you really have some realistic goal that you're sprinting for.
I’m Australian and I agree with your general perspective. However I disagree with this:
> Strives to do a "good enough" job rather than absolute excellence.
For me, one of my biggest sources of personal satisfaction is striving for excellence. Of course I have realistic expectations, there are many pressures that may ultimately prevent me from achieving excellence, but having the goal of being the best at my craft is one of the main things that gives meaning to my work.
I'm also Australian and let me just say; careful, this is the path to burn out.
I spent much of the Easter weekend learning Go, and to me that was a solid investment of my time. I do not make a habit of coding extracurricularly though. If I want to hone my skills or work on a personal project, I'll do this in dead time during my fulltime work.
As an exercise, it is better to improve your ability to get things done within the 9-5 window than to allow that to balloon into your personal time.
You can still strive for excellence without running yourself fullsteam into burnoutland.
I’ve experienced burnout. (Probably while producing a lot of the docs you consumed learning go, btw ;)
Like I said, I agreed with my parent post’s points on just working 9-5 (on average I probably work less than that), but I just think it’s important to try to do things really, really well, but within the constraints of having a balanced life.
I once had a boss who espoused all these principles while simultaneously telling us we needed to work nights and weekends to hit completely arbitrary deadlines. (American aerospace company.) I honestly couldn't believe what I was hearing. I stuck around just long enough to hit my cliff, buy a little stock, and then run for the hills.
I think it is entirely a fair question to ask. What's driving the dealine gives team a perspective of the stake holders and what needs to be accomplished.
The team collectively ought to be questioning it. Not one individual.
which is just fine, it simply means you now have a very solid reason to look for a different place with a better boss that understands what it means to plan a project and deliver value.
I don't want to do excessive overtime (or overtime at all if I can help it, but I'll make an occasional allowance). But I also don't really want to be sitting around during the workday without things to do. That's its own kind of unpleasant experience, to me.
> But I also don't really want to be sitting around during the workday without things to do.
Funnily enough, that was my experience working for a FAANG and a couple startups that had just recently gotten a lot of investment money. They need 300 developers, and only the best, but they're a bit disorganised and don't have enough work for all devs. Lots of sprints finished three days earlier, lots of digging holes and filling them back.
> I'm from Spain so our working ethic is different from the Anglo-Saxon world.
People adapt to their environment. I don't think there is anything ethical involved. Most people have found that their best trade off is not caring too much about their careers, a byproduct of decades of incredibly low mobility inside the job market, because of high unemployment and the legal framework. This is not longer true for software, companies are hiring like crazy, salaries are going up and people are jumping ships.
I think your first principle is applicable to all.
* Work is a means to an end. A job should support the lifestyle you want to achieve, not be an end on itself.
Whether a 10x programmer, a 1x programmer, a startup founder. We all have different views on what a well lived life is. Which could include being the best or prioritizing things outside work.
Work is life. I don’t want to spend a third of my life on something that’s just a “means to an end”. It is me. It is mine. It is my expression. It’s the result of everything I’ve got to give to this world.
So, to each, their own. This game is better played when you have skin in the game (equity, control, recognition).
> This game is better played when you have skin in the game
I think framing a life as a "game", which implies that there is a specific goal upon which one can either "win" or "lose" is the core of your disagreement with that particular way of thinking. Some people see things as more of an open-ended, "freestyle" exercise, rather than a win-or-lose plan
Count on the best people outperforming the worst by about 10:1.
Count on the best performer being about 2.5 times better than the median performer.
Count on the half that are better-than-median performers outdoing the other half by more than 2:1.
What nearly everyone who has read that remembers is the following:
The difference you point out doesn't matter because not everyone who uses "10x" in conversation is rigorously tracing it back to the 1987 DeMarco and Lister "Peopleware".
But again, that 1968 origin doesn't matter because many people are just using "10x" as a rhetorical synonym for "really good programmer that's much better than average".
The problem with dealing with these concepts quantitatively rather than qualitatively is that the deeper you dig, the less sense this sort of statement makes. There's two ways to read your quote. If "the best people" are the best in an absolute sense -- say, the top ten in the profession -- then the chance that /your team/ will sample the long tail of these high performers depends on the size of the team, but is nearly zero for any reasonable team size. And the distribution described is non-normal, with long tails skewing towards high performance. So if /the/ best people outperform /the/ worst by 10:1, /your/ best will outperform /your/ worst by less than 10:1. Alternately, if the statement is true for a typical team, then the expectation varies significantly with team size -- which has changed (in my impression, for smaller overall teams in many cases) since Peopleware was written.
I think we should assume the distribution is pretty non-normal. Feels to me like performance in many careers, especially so knowledge work, follows a power law. There's pretty good evidence for it: http://www.hermanaguinis.com/PPsych2012.pdf
Tangent: apparently contra DeMarco and Lister, I'd argue that "the worst" are often outright detrimental to a team or project. Which in turn makes me question the "math".
I'll never forget having a negatively productive programmer on my team. If he spent an hour on a PR it would take 1.5+ hours of work to get the PR into shape to merge by other people because it took so much explaining for this guy. It was usually better to just scrap his code and start over. If code of his did slip through reviews often times there would be production defects that would then take more time to solve (tracking down the issue, figuring out where the code was, overhead of service tickets etc) than the original implementation. Just totally wild, he had somehow survived years in the org being shipped from team to team and being a nice pleasant guy to be around. How does one calculate the productiveness of someone on a team compared to that?
Being outwardly pleasant can take precedence over just about anything. I find it ironic as this can lead to a lot of other unpleasantness, perhaps even resentment, people leaving, etc.
Being technically competent while also being perceived as merely neutral personality wise can lead to a lower overall qualitative evaluation, potentially affecting raises, promotions, etc.
I guess the lesson is that you (almost) always have to play the game or at least that playing the game well can yield many personal benefits.
Just be thankful there is a process to get the PR's into shape.
My worst experience is someone who was highly prolific at creating enormous amounts of tech debt without the process in place to block it. We are still only about 50% through working off this giant stack of tech debt 2 years later.
I heard of a creature like that. I think they are called human being. Someone who was assigned to a team of highly efficient robots that never make mistakes and produces bug-free code. Production defects? Yeah, it's obviously that guy's fault alone. /s
If I didn't know any better, it sounds like you are just using the guy as someone to conveniently blame.
I disagree with that, it really isn't "normal" to have someone like that, but it does definitely happen. Doing a crap PR once in a while is absolutely normal for everyone, but doing that regularly isn't.
This is clearly someone who is working beyond their abilities, and needs help and mentoring.
This is not the person's fault, though, this is a management issue, and maybe also a cultural one, where people just assume this person "should know" just because they've been at the company for a long time, and mentoring would be "beneath" them.
The original study was timing how fast developers could solve a given task. The slowest took 10x the time of the fastest. With this setup you can't really get negative results. And participants who didn't finish the task were excluded from the results.
I don't think there is anything wrong with the math, it is just that real-world productivity is not as easy to measure. The study didn't measure the "maintainability" of the resulting solutions, only how fast they were completed.
McConnell from code complete mention this, because in one of the studies the multiplier only comes from people who completed the task, meaning in actuality it was infinite.
this aligns with the hypothesis that some people have that a handful of people do most of the work (and the others are the "worst" performers").
What this misses, is that in any highly functioning teams everyone is important and in order for the "rockstar" to be the "rockstar" they need people to help keep the machines running and to support them. This is usually why a team that has a mix of both veterans and newbies works so well. Everyone can operate at their own level while learning and growing. Is the veteran a 10x when compared to a newbie? If you make up some metrics, maybe, but the veteran cannot do meaningful work without the newbs (think rock concert without all the supporting crew. could any band do their own concerts without all the supporting crew?)
If a "veteran" cannot do meaningful work without the newbs, either that "veteran" is not very good or your processes are too manual.
The best programmers I worked with were not "rockstars", but "icebreakers" -- they would solve the hardest problems and leave the clear path for others. For example, they might solve a sporadic memory leak in a few hours, and thus save a less experienced team member at least a week of effort.
They were "10x" in the sense that any team they were on would get 10x better because everyone does more.
yeah. talking about "rockstars" and "newbs" is probably not helpful. but...
the veteran not only can do what the newbies are doing, they can do it better and faster. The point is that in having the newbs do that, the veteran's time is better used on harder / more open ended problems.
to use an analogy, if we are building a sewer line, the veteran knows how to dig as he's done it before and it represents no challenge to them. Not only that but they have better technique and stamina. Now, someone has to also decide where the line goes and organize the workers. So the veteran's time is best used figuring out where the line should go and coordinating, not digging, but his work is enabled by the people that do all the "actual" work
If the worst performers on the team weren't creating negative value (the team would be more productive without them) then that was an incredibly good team to start with.
If by 10x, you mean engineers that add 10x more value compared to an average engineer in the team, then from working 10+ years in the industry, it is abundantly clear to me that 10x programmers exist, and a good team is likely to have 5-10% of those. However, these engineers are rare, and when you do find them, they are not perfect. They might have flaws in other areas - communication and teamwork is a common one.
Most of these anti-10x engineer posts either assume a different meaning of 10x engineer or are unable to accept that engineering is a skill just like every other skill, there are masters and not every one can be a master. Every person cannot be a great engineer. Every engineer in your company/team does not need to be a master. But you need a few of them to be successful if software engineering is critical for your product.
The thing about communication skills, how eager would you be to communicate with others if you knew in the time it took you to explain the problem to someone else, them allocating time to do it, doing it, then reviewing the results, and fixing the issues, you could do it twice over?
Some coworkers are like that unfortunately.
Person good at communicating would understand and navigate this situation and then figure out what to communicate for overall efficient solution.
Communication goes both ways. People who think they are so above that its easier to wave off others are more often than not missing different parts of the picture.
I somewhat agree, lurking in this post is a strawman of a 10x programmer, who demonstrates negative qualities, but that might not be who a 10x programmer really is, or someone else’s own definition of a 10x programmer.
I still bookmarked the post because after stripping away the negative 10x stuff there is good material on how to be a quality team member.
I find these stereotypes very reductive, and having a bit of prejudice.
Being unproductive is not a guarantee of having good communication skills, and likewise being being highly-productive is not a guarantee of being bad at communication.
If communication is part of the job, in the case of seniors mentoring juniors, for example, then lack of communication skills would definitely prevent someone from being a "10x".
I think a big contributor to this "Brilliant asshole" trope is that if you ignore some things like teamwork/communication it's a lot easier to appear to be doing 10x the work. This can manifest in so many ways...
Not doing any code reviews? Leaving tests "for somebody else to write"? Refusing to work on legacy code-bases and only working on greenfield projects? Tuning out (or just not even joining) API design meetings so you can work on your own stuff? Bonus points if you have the authority to turn around in a few weeks and make folks re-write the API because you don't like the decisions you ignored - those pesky 1x engineers, eh?
There's a bunch of things that fit into this category that can make an engineer seem like they're doing 10x the work, but if you look closer it's frequently only because they're taking shortcuts or pushing more work onto their colleagues.
To be clear - I'm not saying 10x engineers don't exist, just that folks with "teamwork issues" who appear to output 10x as many features are frequently not as productive as they seem.
Yeah, this is similar to the "10x, but they work twice as many hours a week". It's not someone who's more productive, it's just someone who manages to be more productive by making everyone less.
Didn't mean to discount communication issues. They are definitely a blocker for growth and impact. The best engineers I worked with had these issues, but worked on them and improved over time to increase their impact.
To me, a big part of multiplying your programming efficiency isn't about a crazy investment of time or ruining your other priorities in life, it's more about objectively looking at how you work and removing or minimizing the things that are a waste of time. It's really about self reflection. Are you spending a lot of time hunting and pecking through menus? Why not learn the keyboard shortcuts? Are you confused about part of your tech stack, maybe the build system? It might be worth a couple hours to get a solid foundation rather than leaving it as a mystery box. There are huge improvements in time saved from cleaning up a lot of little things.
The other thing, I think, comes down to losing your religion. For instance, people tend to treat SOLID religiously. I won't claim whether those principles are right or wrong, but what I don't see a lot of programmers do is consider why they believe those things (a blog told them to do it?), and whether those concepts fit into what they're currently doing. Is dependency injection actually simplifying your life? I'm not saying it's a bad idea, I just think a lot of programmers cargo cult things without considering the context they were invented in. The most efficient coders I know rarely over-architect things.
I made another comment about this elsewhere in this thread, but many programmers don't seem motivated to learn these productivity multipliers. There's a huge difference between "it's just a job" and "it's a job but I (at least usually) enjoy it."
I've never quite understood this because learning skills and techniques as described above makes the job easier and more enjoyable IMO, but I also can't fault people for not caring too much because in the end it is just a job.
Way back when I first saw the 10x engineer proclamations I actually thought they were … a joke. Like a meme or something.
They described a lot of anti social and strait up toxic behavior and seemed to glorify it. It was absurd. It seemed like the kind of behavior that would all but ensure someone thinks they’re so much more productive than everyone else, and would prevent them from ever seeing that they aren’t.
I was a bit dismayed when I realized they were serious…
Unfortunately (or fortunately) there certainly are 10x engineers, and if they happen to be your coworkers, that's the most amazing thing in life. It's the difference between handing a task over to someone, and finding next day that it's done in amazing quality and finding they haven't made any progress at all.
And in my experience, these people usually are not braggarts or have huge egos, they are just really good at solving problems expediently.
Some make a great career out of it, many get stuck in the trenches.
Another huge factor is that some people actually enjoy programming, which is not to say there's anything wrong with people who don't, but when you're having fun writing code it's going to be much easier to be productive than when you view every task as a slog, and it honestly seems like there's more of the latter than the former.
Again, I want to emphasize that there's nothing wrong with being a programmer who's not super into programming in most work environments, but along with aptitude, experience, and what not, actually enjoying the task can make a big difference.
it honestly seems like there's more of the latter than the former.
Probably people who went it programming for the money in the last decade. I can't imagine writing lines of code everyday for years if it's something you dread.
I always found these discussions absurd as well. I’ve worked with people who were great team players (usually leads and principles, actually) who also produced quality code in a much shorter timeframe than anybody else. They also tended to be amazing mentors and role models.
We have a small team (8 devs) and we've focused a ton of energy on developer experience and ergonomics to reduce the cost of contribution and code reviews, and facilitate interaction with other stakeholders.
I'm confident at this point that we've doubled productivity, which would make our "Head of" a 10x engineer :)
That 2x is being assumed to apply to all 8 devs, so if you 2x the performance of 8 devs you get 8 extra devs worth of productivity. I assume the logic is that if that took 1 person worth of effort, then that person had 8x output.
I imagine they’re saying that since the team is overall twice as productive, you could say this manager who got them there made each individual 2x productive. And if you add all those together you have > 10x impact.
Napkin pseudo math for sure.. but when has that even stopped us from categorizing engineers with these labels.
The term "10x engineer" always leads to incongruous conversation. Everyone has a different impression of what a 10x engineer is, depending on who they've met and how much they enjoy coding. There's those who think 10x = not team player, and there's those who've met an engineer who's both extremely productive and likable. There's those who think 10x = no life inevitable burnout, and those who realize there are people who genuinely enjoy programming more than "normal" hobbies, along with people who are unusually productive but otherwise normal.
This author believes that "10x programmers care about the code. Everything else is secondary." That seems even more arbitrary than other definitions.
I say we let the term become a joke meme and nothing more.
You don't get to be an Nx programmer by working N times harder or longer. You probably have a diverse background of experience and well versed in applying knowledge from one area in another, and general creative problem solving.
I certainly don't work 2x more than other devs on my team and perhaps less than 1x on many days. I do try to stay sharp in terms of what I'm doing, why it's being done, and on the lookout for alternative means of achieving the same or related ends. I'm sure that there's many times I've worked 2x harder, longer and produced 0.5x results in a complex and contrived process that I thought was more interesting, better in some vague way, or had great potential, only to find it should be trashed and done the 1x way. Sometimes though that informal R&D pays off in other circumstances. I do this because the 8 hours I spend working goes by much easier and I don't feel tired at the end of the day doing something I feel is ineffective.
I haven't even done this for advancement in my career although it's a major factor that's considered when praising 1x. To each their own.
At several companies I worked for, by using Scrum Points, it was always visible that the most experienced devs were able to regularly deliver a multiple (definitely around 10x) more points than interns and about 2x more than the average dev. Not a perfect metric by any means, of course, but definitely quantifiable and observable. Metrics for LOC and commits/PRs made also followed a similar pattern. Again, not perfect metrics, but it's what we had.
Like another poster said [0], it's not really 10x the average, it's 10x when comparing best vs worst.
The problem with this metric is it can be gamed. We had something similar, and there was a huge 'meta' over who gets the shiny new features, and who has to fix the legacy code which was like Jenga, and a single misstep could break thousands of tests, and writing code was like playing minesweeper.
The people who won the 'meta', got to be the most productive.
Thing is, probably the guy who fixed a bug in the legacy hairball by writing 10 lines of code produced tons of value for the organization (those unit tests weren't for show, they were customer use cases), while the other one only produced some, if the fancy new feature got adopted.
Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories? Or estimating story points vastly differently than other members of the team?
In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures.
> Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories?
Your objections make no sense.
If a story is easy but the number of points is not reflecting the ease, then the estimation is wrong, period.
If there is someone on a team with such an estimation superpower so that they're able to know which tickets are easy, then just make this person estimate all the tickets. Problem solved.
You either accept that someone is more productive, or you accept the estimation you performed is wrong by a factor of 2x. You can't have it both ways.
> Or estimating story points vastly differently than other members of the team?
In all the teams I worked the estimation was done by the entire team. If it's not being done by the whole team, then there's no real baseline to compare the work being done by two people, period.
> In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures.
The point of story points is not to give extremely accurate measurements, but rather to inform you of the amount of work a team is able to do in a period of time (often a Sprint).
> The point of story points is not to give extremely accurate measurements, but rather to inform you of the amount of work a team is able to do in a period of time (often a Sprint).
This doesn't make sense. If the measurement isn't expected to be accurate, how can it accurately inform you of the amount of work your team can do in a period of time? That's why I said it gives you an illusion of insight. There are so many external factors that points don't capture. And management frequently tries to turn them into very rigid timelines. It's a "garbage in, garbage out" problem that introduces extra stress for very little gain.
> If the measurement isn't expected to be accurate how can it accurately inform you of the amount of work your team can do in a period of time?
Please don't misquote me just to push a point, I said "extremely accurate". They are an estimation. An estimation is NOT a deadline. It is not supposed to be extremely accurate. Here's what it says on the dictionary: "Estimation: A rough calculation of the value, number, quantity, or extent of something."
It is supposed to have noise and sometimes even inconsistencies, but over longer periods it will work alright. Some stories will take too long, some too little, but in the long run it tends to even out. The more a team measures together, the closer it gets to being a very good predictor. Sometimes my team ends up the sprint with two or three small tasks left to finish, no biggie, sometimes we end up a day before and we're able to do a bit more. That's fine by us.
> And management frequently tries to turn them into very rigid timelines
Seems like none of your problems are because of Story Points.
Story Points (at least in Scrum) are NOT for management. They are for developers to estimate how much they will pull from the backlog for a sprint. You have a process problem here.
Also, if your management is trying to turn estimation into rigid timelines, you have a severe management problem that should be fixed.
...even though it seems that the person asking for perfect accuracy here is you.
Story Points work fine for me. If they don't work for you, maybe you should ask what you're doing wrong and trying to fix the situation before throwing the baby away with the bathwater.
Or maybe ask what I'm doing different. I'd be more than happy to help.
What is not fine, however, is you claiming that something is shitty, inaccurate or source of frustration for you, just because you or your team aren't using it as intended. You clearly have an axe to grind with story points, but this says more about you than about the technique itself.
> If they don't work for you, maybe you should ask what you're doing wrong and trying to fix the situation before throwing the baby away with the bathwater.
> You clearly have an axe to grind with story points, but this says more about you than about the technique itself.
This seems to be a very common occurrence whenever a criticism arises about agile or scrum -- "the issue isn't agile, it's how you're using it". At some point it's worth considering that there may be flaws in the techniques themselves, and its not always the fault of the people using those techniques.
You've taken the several very short paragraphs I posted and started flinging some pretty baseless accusations at me. I'm not sure why you're intent on turning this into something more personal, but I'm not really interested in continuing the conversation anymore because of that.
Not only you misquoted me trying to prove a fallacious point, but you also took a small comment that I originally wrote and basically started accusing some of my co-workers of gaming story points. You were even downvoted for that.
Also from the comment about managers there are some clear issues in your process and work environment. I am honestly trying to point you into a better direction.
> “the issue isn't agile, it's how you're using it”
Agile and Scrum aren’t perfect, but the literature warns about the pitfalls you encountered, and shows how to avoid them. I am also telling you how.
If your goal is to make it work without those issues, you gotta do work. But it seems you only want to criticize it to make a point. In this case I refuse to be your sounding board.
About a decade ago my company had a thing set up where were could complete coding challenges and other devs would rate them anonymously (so you couldn't rate a specific person highly unless you recognized their style). Once you completed a challenge you could see others' submissions and a ranking of how much someone's solutions were liked. Ordering was fairly consistent, with a few people recognizably always being in the top third or so (out of around 15-25 people who bothered to try the challenges, IIRC).
The original purpose of these challenges were to help people learn python, as we'd just officially moved to it not long before I joined, so to give an idea of the complexity involved, the only one I can remember was "implement a brainfuck interpreter". It was really interesting to see the different ways people organized code that did the same thing.
Wow, that sounds like a lot of fun and also (if the culture is right) like a great learning opportunity for many on the team. Since this was done at work, it kind of suggests a good culture, obviously.
No one has figured this out-- not for programmers and not for any other profession. It's certainly possible for individuals to develop good or bad reputations, but to be able to accurately evaluate how anyone will do in a job in the absence of other data is very much hit-or-miss. The most elite orgs might LOOK LIKE they figured it out, but how much of that is really their process vs just being able to attract talent because of compensation or reputation? How much of it is more a matter of being able to churn through people and replace people that get hired but can't hack it once they're in? How much of it is skillful use of professional referrals?
> It would be very interesting with a clean "we asked n programmers to solve this"-type problem [...]
It's been done, right? There's all those whiteboard interviews that highly resourced orgs study endlessly. There's a whole industry around preparing for these things. What do we have to show for it as an industry? Not much. If the stories are to be believed, folks are still flunking "fizz-buzz" at alarming rates.
I think this is one of those things where its a question of what you're optimizing for. I don't like boxing solutions into `10x` or `1x` or whatever. I think this misses the entire point. It also assumes that single software engineers can make or break a project or company, and this is rarely the real case, even if it feels like it is.
I think an often missed piece in the formula is systematic incentives. At a company, this really means culture and process. If you have a culture and process of incentivizing novel solutions and so called `10x` behaviors, you'll have lots of `10x` developers, systems tend to produce the outputs that you foster. If you have proper incentives for high throughput, you will get it. No one engineer is "born" better than the other, like stated in the article, but a culture that fosters making good choices as a whole will see results align. This is how you can 10x your teams, regardless of individuals.
I think another way to look at is this: you're likely not the Yankees, you're the Oakland A's. Don't optimize for knockouts, optimize for runs[0].
Pretty much. There are various ways to optimize, but the far majority of them depend on circumstances almost fully controllable by the company, rather than a lucky shot getting more and more whizkids.
Foresight, support and tutoring are three ways I can think of that would generate a "10x". Foresight in making better decisions which won't boggle down development later down the line. Support in the form of automating busy work, developing tools, removing impediments and making people more eager to develop (notice how some of these are not dependent on developers). Tutoring through making other people more efficient and raising new ICs.
All three of these are highly dependent on circumstances set by management. You're not getting the time to automate if management continuously pushes you to fix issues and work on the next non-workflow-related issue. You're not getting a lot of time to think about the best solution if the first working prototype is what's expanded on despite there being obvious flaws requiring exploration. No quality teaching if individuals aren't given time to prepare teaching materials and others aren't given time to listen. The list goes on.
In all likelihood you'll still need someone eager enough to go grab the knowledge and then distribute it in some form (how else are things going to change?), but it takes away the need to fill every position with a whizkid.
Something that came up recenty for me. I took a job at FAANG company and my productivity from my POV sucks! I doubt I've written more than 2k lines of code in 9 months! I'm debugging hardware/driver issues in a giant code base (~250k files) that I don't know and APIs I've not used before.
Conversely, in my own hobby code I wrote ~2k lines in the last 10 days.
It makes me wonder how often 10x is about circumstance vs programmer skill
the number of lines you write is almost irrelevant. People need to put the equal sign between lines of code written and productivity. Some of the most awesome and productive people I've worked with actually removed more code than they wrote. Code is a liability. There is no code like no code. Focus on the problem not the number of lines of code
I suppose it was my bad for using lines-of-code as a metric. What meant to convey is I feel like I've done the same amount of work in 10 days on hobby projects as 9 months on work projects.
The difference to me is the hobby project is 100% my code and relatively small (25k lines total, 2k lines in last 10 days). Vs the work project which is 1000+ developers, no idea how many lines but at least 250k files.
So, my point is, is it possible that often (not always) 10x programmers are preceived to be 10x because they are in a situation that allows them to be productive (maybe a smaller code base, maybe a code base they are super familiar with, maybe a new project so new code meaning it's their code, no someone else's) etc...
yup. coding in a group setting is harder than coding on your own. Also productivity is whatever you want to make of it. Some people may feel really productive by tweaking a system to squeeze that extra 2% perf, some people may feel productive by writing code, some people may feel productive by enabling others. there is no silver bullet and putting things in perspective always helps :)
Engineering productivity is not measured by LoC but by business outcomes, that's also what the author of the article is arguing about.
I'm not so fond of the phrase "software engineer" in that it's not a hard engineering discipline such as civil engineering. But companies need software developers who think and act like engineers. Engineers in general solve technical problems by applying methodical design, problem solving skills and having technical expertise.
Unless one works in a nonprofit or academic area, engineers are solving business problems for companies. Modern software companies with agile methodologies push engineers close to the business side, allowing them to add the most business value. Of course, many businesses suck at this and treat engineers like factory workers instead of creative individuals.
This varies a lot, depending on whether you're at a 10 person startup or at a FAANG company. Usually if the company has decent management then they have clear expectations of every position. In your case, this could be number of tickets solved or any other metric, but usually not lines of code. At least, I hope. :)
> I've written more than 2k lines of code in 9 months!
I don't find this astonishing at all. That being said, I work in an industry riddled with red tape and debugging. It wouldn't be a shock to me if you wrote less than 200 lines, maybe even less than 20-50.
> It makes me wonder how often 10x is about circumstance vs programmer skill
The link for "nobody is born a better programmer" sets off my bullshit radar.
> The most powerful evidence for this comes from Patitsas et al ... They examined grade distributions in introductory computing courses at a large university and found that only 5.8% were actually multimodal.[0]
So people may or may not be born better programmers, the link doesn't tell us whether they are, and the most evidence they can find to support their position is that grades in 5.8% of introductory classes are multimodal, which has nothing to do with whether people are born better or worse programmers.
I agree with almost everything here, but the essay is all over the place:
it starts by trying to convince the reader that it's ok to be a 1x programmer and then proceeds to give pointers on how to write simpler code and how to work better on teams (which are different topics and skills that many 10xers possess)
There is plenty of room for excellence in the humble day-to-day glue programming this post talks about. There are arguably better and worse glue programmers. I have gotten better at doing the kind of work the post describes. I also think macho bullshit posted by VCs talking about "losers", "10x engineers", and "shape manipulators" who haven't written production code in decades if they ever did and have never written the kind of code I write is bullshit.
I'm not sure I've ever heard of a "shape manipulator" before, and I'm at such a loss as to what it could be that Google isn't super useful without additional context to lean on. The only thing I saw that might fit would be NumPy arrary shape manipulation.
Anyone care to expand on what a shape manipulator is and where that came from?
It's a meme that says some people are better at visualizing and mentally manipulating 3D images in their heads, and it implies that those people can use the same brain hardware to accomplish amazing feats of engineering
I dunno if there's any truth to it at all.. I think most of programming is less of an inspired act of genius and more of a tradeskill like plumbing or roofing.
I'm pretty sure there are tasks out there that I could get done in a month even though they'd take a team of 10 people 10 months to do, but if I trained those same people they could probably come close to my performance.
> I'm pretty sure there are tasks out there that I could get done in a month even though they'd take a team of 10 people 10 months to do, but if I trained those same people they could probably come close to my performance.
Part of this may just be how we work in teams, versus in isolation. Like I built an Internet search engine alone, as a hobby, in less than a year.
If I was a member of a team of 10 people tasked with building a search engine in a year, I'm not sure we'd be able to complete on time following standard software engineering practices. So much time is lost iterating on designs and pair programming and having daily standups and looking at burndown charts and coming up with goals and debating the definition-of-done for each task and having meetings with stakeholders and preparing/having demos and drinking coffee and iterating on API interfaces and discussing code standards and so on.
While sure, that makes me 10x more effective than that team, but that is a hypothetical team including myself. In reality, I have a modicum of talent that is magnified with an extremely effective way of producing code quickly.
To be very clear: I'm not saying all these things aren't there for a reason, it is only when myopically focusing on shipping code that I appear like a miracle that is 10x faster than myself.
shape rotator (also numbercel) - STEM type person - engineer stereotype good at visualisation (can pass minds-eye shape rotation intelligence tests).
wordcel - stereotyped humanities or liberal arts person (or sales?) - word with suffix of cel (meme templated from incel etcetera but without that original meaning).
I really don't mind 1x programmer/programming, hell, probably am myself.
Most companies don't as well. Issue lies with people who create work for others on every task they are assinged to work on. Hence, -1, negative net developers, and there are plenty of them everywhere.
I've never met a 10x engineer. (Does that make me the 10x engineer? I doubt it).
Personally I believe that the myth of the 10x engineer comes from the very real and very visible fact that often times, one engineer will be 10x as productive as someone sitting in the next desk over. Why is this? There are numerous factors, and certainly innate skill and programming practice come into play. But I think that only gets you to, at maximum, 2x the average. To get to the perceived "10x" you need luck, the right mindset, and a the buy-in from management to push others aside and take on the most juicy projects (which is self-reinforcing once management sees you as a "10x engineer"). "Stealing the Corner Office" is a good book on such tactics (although it ostensibly applies to middle-managers).
I have and I'm sure others here have too.
It's usually people who are not only skilled coders but are capable of staying ultra focused for longer hours.
Go check you favorite team project on github and open the list of contributors, notice anything?
Remember it's 10 times better than the worst not average programmer. On average a 10x would be 2.5 better than average. If you think you are average or slightly above average a 10x programmer would look like a 2x to you.
I have seen a very clean example of this once -- we hired two people at about the same time, let's call them A and B. Both had about the same years of experience and worked on similar technologies in the past. Neither was familiar with our codebase.
Both got the same onboarding process (1-on-1 with experienced developers few times a week, simple tasks). Then both could choose tasks to work on from the same pool.
Two month later, A is done multiple simple tasks and in the middle of refactoring a tricky module to add much needed functionality. B is still working on their second simple task.
I would not be able to quantify difference between them, but it could easily be more than 10x.
(We later tried to see if B would do better at other projects -- a different programming language, a project that needed a small program from scratch instead of modifying our huge main codebase, etc... None of that did help.)
I have managed a number of small to large software dev teams in my career. And there was always a small core of developers who outperformed the rest of the team. Not by working harder, but by working smarter: focusing on the right priorities, reducing complexity, automating things etc.
Nor have I, but I did work with someone who was regarded as such at a company I worked for. He got the reputation for shipping features fast, but everything he did was quick and dirty. This lead to some resentment with other developers tasked with extending the new features he shipped - invariably the simple extension to the feature would take longer than the original feature. Instead of indicating that everything this guy ships is a nightmare to work with, it further cemented the notion that this guy was a 10xer.
That's not really a 10x if they're doing a crappy job. I can close hundreds of bug tickets saying "not reproducible" without really trying, but that doesn't mean I was productive.
Above that it's in spurts, luck, or some kind of specific focus or area of focus and it's usually necessary and you risk actually having failure, in which the >2x is mitigated by failure back to something normalized lower.
Should we read this as an implicit comparison to what a 10x programmer is? It seems like this is mostly just having a sane work-life balance and actually targeting deliverables. I guess I'd expect a 10x programmer to have a bad work-life balance, but also still target deliverables... just somehow, better (I'm not sure I understand what a 10x programmer is supposed to be).
> Users care about themselves. To them, they need to be the primary priority. This rift causes a problem when open source maintainers decide that their users are indeed secondary. But that might be the theme of a future post.
That came from out of left field.
I enjoy using open source programs, but understand that open source software is released to the universe as a favor, and the author has no obligation toward users like me. The ideal form of open source is just that you solved your own problem, and were kind enough to share the solution with the rest of us. If I wanted my needs to be a priority, I'd look for a relationship where I was the customer. The only issue I can see with letting user needs become secondary is that this is far too high of a priority, it leads to confusion and might infest the project with an unhealthy customer-service mindset.
I agree with the gist but in my dream I'd like to find a system programming niche that I can drill down and be really good at it, maybe even top 100 in the world.
If we only can have one 20x programmer on the team and the rest, let's say 100 or so, have to be 1x programmer, then absolutely the emphasize should be on 1x programmers. But if it is one 20x programmer on a team of 10, that doesn't make sense to emphasize the 1x programmers, right? Unless the math is missing something, such as, 20x programmer get to be 20x due to the 10 1x support; or the 20x programmer is not covering the part those 1x programmer is covering and it may end up way less than 1x if the 20x programmer is forced to cover the part that those 10 1x programmers are covering.
There is very little points talk about 20x or 1x without discussing the context.
What if, there is no reason that we only can have 1 20x programmer on the team? What if, we simply over-hired programmers and majority of the programmers shouldn't be hired as programmers and they made the 1x to be the norm and the software architecture has evolved to cater to these majority 1x programmer that we end up working with 1x teams, 1x management, 1x languages, 1x frameworks? And they made 20x unicorns? The mere acknowledge of 20x programmer exists is intriguing...
The problem with glorifying so called 10x programmers is that it acts as a rationale for all kinds of dysfunctional / toxic behavior, both from managers and employees.
Non-technical managers will accept mysteriously outweighed contributions from a staff member because they now believe it's entirely plausible that this person really is 10x as productive. When in fact they are creating piles of tech debt, grossly violating the archtictural norms, processes or other team-based aspects that everyone else is doing.
Engineers will see it as permission to cast aside solid, careful, thoughtful and consultative engineering process and just ram out code at a velocity nobody else can keep pace with. They may even use it to rationalize why they don't have to comply with processes the rest of the team is doing that slow them down.
Put together the managers and engineers both become enablers of unsustainable situation that, even if it works for a short while, is unhealthy and leads to lots of issues, whether they are technical, organizational or personal issues with staff (envy, exceptionalism, passive aggressive behavior etc etc).
Thanks for writing this - as you get more senior one of the things you realize is that the people involved in software are more important than the software itself.
Optimize for the people: The users, the community (either your team or the open source project community), and the stakeholders in your software's success. The code is a tool that you can use to make those people happier and more successful.
I feel articles like this make not working hard seem like hard work. The sacrifices made to achieve in one’s career are mostly intentional ones. The flaw of thinking there is more often about the unrealistic expectations of the outcomes.
Saying “it’s ok to not achieve big” is akin to staying “it’s ok to be normal” which is the definition of normal as far as humans are concerned.
Nice article. I wouldn't call this approach "1x Programming." This is more about how to be a net-positive member of a dev team.
As a longtime dev and recent dev manager, I hate most self-described 10x coders. I want people who are net-positive. Team players, focused on adding value, doing unsexy work, keeping the build and tests green. Being nice to each other.
Even if they're barely productive, as long as they're net-positive I'm perfectly happy having them on the team.
This is interesting to see, having been slowly going through Tim's book Rust in Action when I get the time.
I think he did a great job with the book, but I still lean a bit more towards enjoying not just programming but the CS-side of the work. It feels great to make an ergonomic, dev-friendly API. It also feels great to leverage mathematics to do something faster or better with software than otherwise possible.
- consistency is more important than speed. If you can keep at a project for 10 years you can achieve pretty amazing things even without being arockstar developer
- don't get complacent. Some people think they've seen it all and stop learning new things at a point. You don't need to learn every new framework, but you do need to put in some effort to stay on top of current best practices and technologies
To me this seems like an alternate description of how one trends towards increased effectiveness in programming. I've known 10x programmers that will put the entire team in a position of reacting to that one person's work so that rather than scaling it actually reduces to total productivity. This person was unfortunately trying to build a business.
Undoubtedly there are many skills other than programming that go into making a successful project. But if I hire an accountant I don't necessarily want career advice from him. Similarly, I'll give my opinions from a technical standpoint, but I don't tell my boss what product he wants to sell.
> Synthesis is essence of software engineering, whereas abstraction is the essence of computer science. Your job as a software developer will be to synthesise something new from composable pieces. What you create should be simple to understand and extend.
It's a nice quote, but I really disagree with this section. Yes, software development is more concrete than computer science, but abstraction is so, so important. The author acknowledges the value of simplicity, but simple code is only produced by choosing the right abstractions. Getting even 1 key abstraction wrong can create enough "friction" to eventually kill a product if the tech debt isn't managed well.
99.5% of a car mechanic's job is assembling/disassembling pre-made components, but they still need to understand how a car works.
I didn't read it as "never use abstraction". Consistently the most difficult code for me to work with (enterprise development, business use cases etc...) has come from excess abstraction and having the business context hidden behind layers of terminology used in academic settings and not the current business context. Mental mapping required for every class and method name to why the business would be interested in this code being ran.
"Programming is a tool, little more". Sounds like someone who's been sitting in a cubicle hammering out Java/C# for too long. Try programming in Clojure or Ruby for a while and you might change your mind.
I’m beginning to feel as though there simply isn’t that much novel code to write anyways. I very very much agree that programming is not inherently valuable, and is merely just a tool; I say this even as someone who got into programming at a young age and enjoys it for the sake of it.
I think in some narrow domains I can write interesting, and perhaps even mildly novel code. But a huge majority of the time, working for smaller startups, or Google, or myself, the majority of code I’m writing is something that has already been done in another form but I can’t use it for some reason. Maybe it does similar things, but it explicitly doesn’t try to solve my particular version of a problem. Maybe the license doesn’t work. Maybe it’s almost perfect, but it’s buggy or slow. Or hell, maybe I’m being a meme programmer and rewriting perfectly good code in Go or Rust just because I want to have the same thing but integrated with my favorite languages and tools.
The world of open source also changes things. You most likely should not hire someone to write a TLS stack. It’s not worth it. Chances are, a good TLS stack is not a feature that will set you apart, if it differentiates you at all in any positive ways. If you want to do things that existing TLS stacks don’t, it can still make sense to hire an expert, if that’s your thing. But, most of the time, even then, it would probably make the most sense to soft fork or upstream changes to an existing robust TLS library. Because of open source, it makes exceedingly little sense to actually have one entity maintain their own novel bits unless they’re unique and related to how the product differentiates itself. And even then, in some cases, it makes more strategic sense to just open source your bits anyways, and make yourself the standard. Google releasing Kubernetes is a great example; you can probably find many projects in the open source world, like Cockroach, which are basically clones of Google things they only released in a limited form, so the rest of the world went and standardized on non-Google implementations, and the Google versions didn’t benefit from cross-collaboration and the generalization of internal hacks. This also rings true for Facebook and React.
I think most programmers, given enough time and initiative and effort, could build cool and novel software, but the fact is, we don’t need novel software most of the time. We need better boring software. More general, less buggy, faster. If that’s depressing, well, I guess so be it. But there’s also a lot of toilets to clean out there, and someone has to do that, too. I can’t complain if it doesn’t feel like my work is exactly writing my name into history.
It’s only very slightly novel to apply solutions that we already know exist that were designed to solve a class of problems to a problem that nobody has done so for so far. Not being novel doesn’t mean it isn’t useful, though.
I think there's a lot of unexplored territory in wild and crazy ("novel") ideas for software that prevents you from doing wrong stuff, like type systems and model provers, valgrind, ASAN, etc.
That leaves room for the software that actually does stuff to be boring.
These concepts are usually confused; even in the area of languages that supposedly you can't write bugs in, Haskell is too exciting in both directions (so it's too hard to use), but Ada/SPARK is too boring (so nobody wants to use it).
"Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
I imagine the point would be that pg writes many controversial things - with some of which the author explicitly disagrees - but this is one thing on which they do not disagree.
Let's suppose, for the sake of argument, that Newton once wrote, "The sky would be most accurately described as applesauce." (The absurdity is there to suggest that you would not agree. Take something more mild but still controversial and I don't see how it's different.)
> I don't agree with everything that Newton said but F=ma.
My principles for a 1x programmer:
* Work is a means to an end. A job should support the lifestyle you want to achieve, not be an end on itself.
* 9-to-5 is a perfectly reasonable schedule. Fiercely protects personal and time off.
* Prefers to spend time with their family or hobbies (e.g. train for that marathon) rather than working on a side project in Github.
* Strives to do a "good enough" job rather than absolute excellence.
* Keeps their skills at a reasonable level to do the job, but doesn't necessarily work on continuously improving.
* Most companies don't really need 10x engineers, and would do just fine with 1x ones.
Some people might cringe at this list. Some will argue that one could never be a good developer following those principles. I'm ok with that. I think we should acknowledge for many people programming is just a paycheck and they don't share the passion of the HN crowd. We should broaden our horizon of what success looks like in the development job. Me, for one, feel like some of my friends that fit the description are winning at life more than I do.