5 ms·
Unfortunately I'm not sure it's trainable. It seems much more correlated to an individual's personality and drive. The traits I see in engineers who I consider
by adam_arthur 6y ago
Unfortunately I'm not sure it's trainable. It seems much more correlated to an individual's personality and drive.
The traits I see in engineers who I consider to be 10x:
Growth mentality. Always try to do things the "right way" rather than just completing a task. Educate yourself via internet/books to understand all points of view on an issue, and tradeoffs of each approach.
Setting a high bar for your work. Never solely focus on getting the job done, always question and focus on what the best way to get the job done is.
Extremely self critical. Don't get attached to your work. Always criticize yourself and question whether decisions you made were correct.
Objectivity. Always quantify objectively to yourself why you made a given design decision, why
did you name your variable X vs Y? Could you justify the merits of your approach to others without relying on subjective points?
Focus on business value. Optimize for what drives business value. Don't pursue projects that are technically interesting that don't provide long run value, for example.
Work with intensity. These people legit code 8-10 hours a day straight. They aren't coding for 30m then browsing the internet.
Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution.
Self managing. Can operate 100% independently without constant manager intervention. High level direction still important to align on business goals of course.
Ownership. These people take pride in their work and feel a sense of ownership over their code. They don't need to be asked to step in when something they've worked on has an issue.
It's not about specific knowledge at all, or training.
People could learn to follow these principals, but it's much easier when it's in your nature. I have not seen anyone really change their trajectory from median to superstar before, but I'm sure it's possible with a mentality shift.
- fctorial 6y ago> These people legit code 8-10 hours a day straight. That's physically impossible, unless you're performing some assembly line task like creating a frontend prototype from a marvelapp mock (tons of html, css, js). Can you do creative work for 10 hours in a stretch, every day.
- adam_arthur 6y agoI did this myself for many years in a startup :) Averaging around 350k lines of code a year for a few years. This was mostly frontend/product focused work, so there is more boilerplate than in other disciplines, of course. It's also important to note, the higher quality the codebase is, the less energy it takes to add to it. If you spend 50% of your time reverse engineering spaghetti code, it will be way more tiring than adding to a codebase where design is sound, code is very human readable/friendly etc. It certainly takes a lot of energy, but why do you say it's impossible?
- fctorial 6y agoI can feel my IQ dropping at a steady rate when I program for long stretches of time.
- adam_arthur 6y agoIn my case I was working in a codebase that I largely built myself, so I understood all design decisions and code at all times. It's much easier to operate in this environment. I have worked on less clean codebases where I spend hours tracing state through spaghetti-like code, and there's no way you can productively code for lengths of time in those environments. It's always better to refactor that kind of stuff ASAP, assuming the longevity of the product matters, and the refactor is a tangible improvement over the original.
- dmitriy_ko 6y agoSo it was more or less a large solo project? How do you know your code base was much better than those less clean/spaghetti codebases? Your own code is obviously easier to read/understand than that of others. In general it's easier to write code than to read/understand code of others. Developers who are founding members of a codebase are able to navigate it better vs those who come later and therefore able to work much faster. It may give them a false impression that they are genius 10x coder. Then when developer who comes later is not able to be productive, founding developer would blame it on incompetence of newer developer. But it could also be that codebase is of poor quality, but as founding developer you don't see it. It's hard to be objective about your own code. Now let's go to the reverse situation when you are spending hours "tracing state through spaghetti-like code". It could in fact be that it's actually a great code written by a 10x developer, but you are not smart enough to understand how it works. It's natural to blame someone else and not you.
- vsareto 6y agoBut this set of conditions may not be widely accepted. Say I had all those traits and you decided I was a 10x and now I've got my shiny label and I'm happy. Then I come across someone else with a stricter definition and more requirements. They say I'm not 10x. Who do I believe? Because there's no widely accepted standard, it just ends up being a game of finding the right people who like the qualities that you possess.
- adam_arthur 6y agoI don't think there needs to be a 10x label. It's not healthy to actually call people out as 10x or not publicly, I definitely agree with that. But the truth is there are people who are insanely productive relative to median, and 10x is just a rough term to refer to them. I do think it's worth paying those people 2x or more over paying 1x for two median devs. The trick is being able to identify them accurately... that relies on a well honed interview. There's risk in compensating people so highly if your judgment turns out to be wrong. Certainly definitions won't be universal, but this type of person tends to do very well regardless of the environment/language etc.
- vsareto 6y agoWell the label could be anything and the same problems are still around. The same goes for being labeled a software craftsman or not. There's enough flexibility in how we assess peoples' skill that I can accidentally get the label if I just keep trying and the stars align. (This being a genuine, verifiable belief of someone else who's in the field and not me simply lying about what they said). With interviews, those can vary by company and the person giving it. It'd be more consistent if that was focused on a widely known credential and institution that's dedicated to assessing it. When I can take company and people's biases out of it, I can more objectively decide how good I am, what I need to improve on, and what level I should be working jobs at.
- adam_arthur 6y agoI do think certification and credentials can play a much bigger role than they do today. No, I'm not talking about the BS certifications where you can spend a few hours reading a book and pass a multiple choice test... but something more "elite" and well rounded to give a quality stamp of approval. It would be a great thing if candidates could go through one process, get that stamp of approval, and receive offers from X companies.. rather than interviewing 100 times. I understand the needs of companies are individual, but most candidates who are "strong" will do well interchangeably at these companies... if it's more of a generic development role. The difficult thing is that the industry seems very stuck on algorithm and design problems as the sole focus of judging a candidate, which are pretty easy to game (design less so than algorithms). To identify these kind of people you really need to judge real world code and productivity... large projects with more elements of design. Beyond technical skill, how hardworking is the person? How much will they care? Personality traits like these tend to matter a lot more than specific knowledge. Anyway... this is kind of a meandering response, but I do believe that in the future we'll have a much better system for interviewing with less redundancy and higher accuracy. The goal is to maximize correlation between performance on the interview and performance "on-the-job".
- robocat 6y ago> Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution. That is actually a failure mode - the engineer that tirelessly works towards an impossible goal. The 10x engineer has the critical heuristics/intuition/skill to avoid dead-ends, and also the engineering taste to concentrate on technically hard but possible tasks and the skills to deliver.
- adam_arthur 6y agoFor sure, if the task is truly impossible. I more often see junior employees give up on tasks they think are impossible that aren't.