Comment by adam_arthur | Hacker News Reader

Comment by adam_arthur | Hacker News Reader

Parent Full thread

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.

> 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.

For sure, if the task is truly impossible.

I more often see junior employees give up on tasks they think are impossible that aren't.

> 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.

I 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?

I can feel my IQ dropping at a steady rate when I program for long stretches of time.

In 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.

So 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.

Not a solo project. I was an early dev at a startup and owned that feature area. Later on others took over the code.

How to judge whether a codebase is high quality?

Consistency of design and abstraction. Does the code use the same abstractions and design throughout? Consistency is one of the most important things in quality. How many unique concepts and abstractions do you have to learn to understand the code? E.g. in frontend context, do you use the same pattern for managing business oriented state? How is that state updated? Are those patterns consistent throughout your codebase? The biggest problem I see with the spaghetti codebases is they lack consistency in design.

Separation of concerns. What's the blast radius of any given change? If I change render logic, can it impact business logic, and vice versa? A big problem I see is that codebases do not appropriately separate these type of things out. Meaning the code is fragile and it's easy to introduce bugs inadvertently.

Anyway, I can list many points, but I'm on mobile now.

High level indicators would be: How quickly can new devs jump into the codebase? Is it easy to diagram and explain to others how the code is structured? How many bugs come out of your codebase? How quickly can you add new features to that codebase? What is the "blast radius", or is it possible to break something seemingly unrelated to a change you're making?

How do I know my codebase was good quality? I was extremely self critical when writing it and ended up rewriting it a few times before it was in a state I was satisfied with. Number of bugs are extremely low and feature velocity is high, relative to other areas of the code.

Been coding about 20yrs, In my case its not as much as the IQ but the ability to switch perspectives. I have seen that when I code or debug for long hours often I lose that critical ability and I often repeat the same mistakes. Eventually I take hours to accomplish what I would in 30mins, thats when its time to wrap up.

but I should point out that long stretches of time are different from quite (context switch free) streches of time.

It's definitely possible with drugs :)

Which ones

Modaphanil and ephedrine are my drugs of choice for this.

I would consider myself a highly productive person and I have many of the qualities they pointed out. I can’t program that long, I program in hyper-focused bursts. I have had many coworkers comment/complain that it looks like I’m not working because I’m surfing the web, watching YouTube, daydreaming, etc. But I’m constantly designing, debating, and thinking out how I should implement something that by the time I actually go to code it I know what needs to be done and bust it out in a couple hours. My managers commented on this early in my career because other developers think I’m lazy, unprofessional, or unproductive when I’m usually the most productive person on the team. Working from home removes this problem for me.

https://b.tdhopper.com/blog/thinking-at-work/

> One afternoon, I was bent over a program listing while Wendl was staring into space, his feet propped up on his desk. Our boss came in and asked, “Wendl! What are you doing?” Wendl said, “I’m thinking.” And the boss said, “Can’t you do that at home?”

That's physically impossible only for 98% of the population, like you and me.

"you can work long, you can work hard, you can work smart, but you can ONLY pick 2 out of 3" - 90's programmers.

Not impossible. I learned from an engineer to go lay down in bed for 30 minutes and stare at the ceiling. It mostly resets the brain.

But 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.

I 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.

Well 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.

I 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".

Reply on news.ycombinator.com