1x Programming
tim.mcnamara.nz
tim.mcnamara.nz
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.
The 10x dominates the tools ( and techniques and people and capital) that multiply her.
If you have a car you can easily and consistently go 10x faster that walking pace. The same applies for your job.
Working on a given company, with access to capital and people and tools can multiply you.
10x is systems for the system, including good judgment
All the biggest and most important productivity and outcome enhancing things I've done at work have been done without management knowledge or approval.
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.
I believe this is incorrect. The baseline (or 1x) is the lowest-performing member of the team. At least that's how I learned the term.
I’ve always internalized as a “typical, competent programmer” rather than team-specific anything (Peopleware’s definition notwithstanding).
A negative number. A 0.1x programmer gets work done acceptably but is slow.
A negative programmer on the other hand creates more work for other people to fix, and you’d be better off not having them touch the code at all.
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.
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.
- 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.
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!
> > * 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...
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.
This. Gamification, but for real prizes.
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.
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.
EDIT: if you want data, compare the GDP for hour worked in Italy with Germany or the US: https://en.m.wikipedia.org/wiki/List_of_countries_by_labour_...
> Labor productivity is the gross domestic product generated per hour of working time.
I also disagree that continuously improving is unnecessary. It absolutely should IMO. But it should happen between 9-to-5, in the workplace.
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.
It's absolutely unhealthy.
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.
And then let your boss fumble if they are making things up, aka arbitrary deadlines.
The team collectively ought to be questioning it. Not one individual.
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.
And you're 100% right that it sucks.
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.
Unfortunately, at least in my recent London experience, those people tend to be the ones having the yay/nay in hiring decisions.
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.
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.
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.
This applies to non-programmers too.
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.
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).
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.
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.
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.
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.
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.*
This is bad news for the huge amount of people with jobs like trash collector or grocery bagger.
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.
It's not the job, it's what the job means to you.
No one loves their job every moment of it and even the most rewarding job has challenges, stress, and drudgery.
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).
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
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.
> 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 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.
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.
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.
The best people outperform the average by 10x.
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?)
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.
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
Since I believe in the existence of negative-value programmers, being 10x "more" than the worst would actually be a very bad thing.
I think it really depends.
A senior that is 10x more productive than an intern or junior? That's perfectly fine, they are here to learn.
A mid-level dev that is 10x more productive than another mid-level? A bit of a red flag, and probably detrimental to the morale of the team.
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.
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.
If I didn't know any better, it sounds like you are just using the guy as someone to conveniently blame.
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.
A summary of the research: https://www.construx.com/blog/productivity-variations-among-...
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.
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".
And arguably, the "10x" had earlier origins in the 1968s studies by Sackman, Erikson, and Grant : https://www.google.com/search?q=10x+Sackman%2C+Erikson%2C+an...
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".
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.
It's a mix of chaotic tech skills, approach to technology, terrible communication and ego.
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".
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.
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.
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.
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'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.
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…
I'm confident at this point that we've doubled productivity, which would make our "Head of" a 10x engineer :)
Since we’re putting numbers on things, how did we go from 2x to 10x?
Napkin pseudo math for sure.. but when has that even stopped us from categorizing engineers with these labels.
I suppose you could also be 10x everyone else you work with by deliberately sabotaging the rest of your team...
I’ll glorify that all day.
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.
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.
That’s my experience as well. The real ultra productive devs are surprisingly easygoing. Nothing like the 10x memes.
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.
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.
It would be very interesting with a clean "we asked n programmers to solve this"-type problem, and then being able to compare the solutions.
Uh, did I just sound like I wanted to work in recruiting? #fail
It reviews academic papers in that kind (empirical software engineering).
> 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.
https://href.li/?https://third-bit.com/talks/greatest-hits/?...
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.
Thanks for sharing!
Like another poster said [0], it's not really 10x the average, it's 10x when comparing best vs worst.
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.
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.
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).
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.
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.
> 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.
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.
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].
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.
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 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...
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 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
Often times it is.
> 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.
[0] https://journals.plos.org/ploscompbiol/article?id=10.1371%2F...
Anyone care to expand on what a shape manipulator is and where that came from?
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.
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.
wordcel - stereotyped humanities or liberal arts person (or sales?) - word with suffix of cel (meme templated from incel etcetera but without that original meaning).
https://knowyourmeme.com/memes/cultures/wordcel-shape-rotato...
https://melmagazine.com/en-us/story/wordcels-numbercels-defi...
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.
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).
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.)
Anything above +0.5 is fine.
2 is amazing.
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.
> 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.
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...
I am not saying one or the other, just what if.
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).
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.
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.
This. I've definitely cursed the author of some code only to realize it was me 5 years ago and I have absolutely no memory of the code or the problem.
"Lessor" is a person who leases a property. The author probably confused it with "lesser".
Unless there's a correlation between leasing and programming... hmmmm.
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.
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
Loved this.
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 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.
Doesn't producing that kind of software involve novel, interesting ideas in the first place?
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).