Hacker News new | past | comments | ask | show | jobs | submit login
I believe in the 10x engineer, but (erikbern.com)
145 points by admp on Jan 23, 2016 | hide | past | web | favorite | 164 comments

I work with a 10x engineer, I know they exist. Or at least ONE exists. We'd be DEAD without him. He's by far the smartest, fastest, and most thorough person I've worked with since starting in IT in 2000. I'm not sure he knows how good he really is and I am afraid some day he'll figure it out and leave. He's also generally nice and humble, and at the same time can be fierce and mean to get things done. He makes me feel old dumb and slow, and I love it.

I think I am a 10x engineer sometimes. It's kind of like the tide. Sometimes it's there, sometimes it isn't. Also, if you think you are something, are you really that something?

Last week I was pulled into the tail end of a project which had just got pushed back to the end of February for complications. The project was now billed at 3 guys, 3 weeks. After spending an hour in a meeting I came up with a solution that is going to be implemented on Tuesday by one guy. Same risk, but a fraction of the work.

I know most of the time when you think about 10xers you think about some kind of math / programming / algorithm god, but don't discount big picture skills. Unfortunately I'm not sure how you teach big picture skills or put them down on a resume.

I don't think it is possible to really be sure that you are a 10x engineer - it's more of an outside validation thing. Everyone thinks they're really good and that only they run into weird emotional issues that slow them down. People like to rationalize.

If you see one of your co-workers doing 10x the work of your other co-workers at high quality, then it's much easier to label them at a 10x engineer than trying to label yourself. Objective vs subjective.

You are profitable on fix-cost projects only. :-)

can you tell us more about the design alternatives?

grep and a server with 64gb of memory instead of a 4 rack Hadoop deployment.

Congratulations, you are now better than 99% of "data scientists" out there.

I worked with a guy who everyone thought was 10x, I thought he was shit. This guy and another built all the systems for this company, and a product that was the cash cow. Started in 2005 using struts. Everything they built was struts. They duplicated the entire code base for the next web app. There were like four versions of this thing customized to do different things (ie trivial shit like the web sign up form). These guys couldn't even factor out the data access/service stuff into separate modules for reuse.

When it came time to learn Spring, this guy flailed, and wrote Spring like it was struts. In addition, he was a pontificating jack ass, real abrasive personality.

The non technical and business users thought this guy was a super star. I've only quit a job once because of personalities, and this was that time.

If he built all the systems and especially the cash cow, isn't that some objective measure that he's more valuable than the average employee?

Maybe he's messy, but nobody pays the janitor millions of dollars to clean up everyone else's messes even if they tell themselves he's important. Rather, they pay the people who made it worth cleaning up the building in the first place.

One issue some programmers have is discerning that not all code has the same value. I think with code it's harder than with physical things to "know where the value is".

It's obvious, for example, that we don't need titanium cupholders in a car, but maybe titanium rods _are_ necessary to achieve a particular level of performance.

But in software, you'll see programmers doing the ethical equivalent of putting in titanium cupholders "because it's the best" or whatever, with no regard to the cost.

In my experience, a 10x programmer is a 1x programmer who knows where the value is and spends their time on that.

No. It's not creator-janitor thing. It's rather the situation that programmer A makes a huge technical debt, and programmer B must pay him off.

It's poor code design, poor code management.

It's more like:

- irresponsible house developer builds house very fast and very cheaply but he doesn't care about safety or design

- then building is beginning to collapse and tennants have to hire another developer to fix mistakes of previous developer.

They must pay twice! One time - for creation of the building. Second time - for fixing.

Absolutely, I was attempting to illustrate the difference in perspective, and how subjective '10x' is. My comment above fails in this regard.

I sometimes feel like the guy you describe (although perhaps because I do indicates that I am not?)

I have a webapp that I maintain for a family member written, by me, in 2005. It was using WebWork (which became Struts 2) and still is, and I am trying to move it to something more modern in bits and pieces. But it's requiring me to learn a lot, which I am trying to do in the limited time I have.

At my work we do way more modern thing, but so much so that I'm not able to do any UI stuff since they use tech I'm not "hit the ground running" capable of doing. But I'm trying.

I hope I'm not abrasive however.

>> This guy and another built all the systems for this company, and a product that was the cash cow.

Anecdotal, of course, but .. I've worked with quite a few 10x guys in my time, none of them liked Java, most of them would consider Java a reason to quit. It's been a while, I would guess some of them would find Scala acceptable.

I know several 10x Java coders. Honestly though 10x should transcend a language...

Why would it? Suddenly having to always look up your standard library's basic functions will slow anyone down.

10x guys let the tools do the hard work, like IDE to look up standard library's basic functions.

Which language has standard library small enough that people can memorize the whole thing?

JavaScript :) Although I keep forgetting some functions even from JS.

What are the parameters for Date.setFullYear() again? :)

You can learn stuff like that pretty quick.

You are wrong. 10x guys care about product outcome rather than fretting languages. 10x guys certainly use Java in their toolset.

There's no need to turn this into an anti-(fill in the blank) thread.

At present time, Java8 is acceptable (wit lambdas, RxJava, etc.). But yes, you are right: Spring, Hibernate, JBoss, etc. are huge reason to quit.

My own web projects in java 15 years ago were coded in java and glued by JavaScript (Rhino) with templates in JavaScript, which were compiled into bytecode for speed: fast, secure, simple, 10x faster to code.

Yes, just think how many throwaway unicorn greenfield projects these Java developers didn't participate in because they absolutely have to insist on maintaining crufty decade old code bases that actually solve a tangible business problem instead of thinking software is an afterthought to a fluffy full page HTML5 marketing video about revolutionizing the world.

Please don't.

Java actually allows for 10x work because it's so simple and let's you work quickly.

My experience was that most Java apps have a terrible compilation and startup time. I hated working with Java because of this.

10x engineers definitely exist. Know a few and have hired a few. They are not 10x compared to anyone ever, but generally 10x to their currently aged or experienced peers.

They learn for fun. They are endlessly curious. They are incredibly humble and get things done.

They do get more done in their part time hours in the evenings than a full time equivalent. More importantly, 10x really helps with building the quick things quickly and growing them as quickly as possible.

10x developers are 10x more curious, 10x less assumptive, 10x more capable of putting themselves in user's shoes... and much more.

Why would you want to work with someone who is "fierce and mean"? Sounds totally unprofessional.

Ha! Good question. I wrote this comment with out much thought really. He CAN be... maybe "stern" is a better word? He's generally totally professional, nice and friendly, but he doesn't let people push him around, and he pushes back when he needs to. He's "well rounded", how's that?

Good lord I sound like a ridiculous fan boy.

Ah, OK. It's been a few years since I've worked in the sort of place where anybody would need to be "stern" to anyone, but I can remember it! thanks for the clarification.

I imagine it's just a phrasing thing, he probably means someone that sticks up for themselves. I've seen a lot of very effective engineers get bogged down in bad work because they wouldn't push back on ideas/projects that were obviously not great ideas.

This describes me in the past. Don't let him date someone from HR, it opens up Pandora's box about relative value and standard practices with salary negotiation. The largest factor for salary at most companies is how much you ask for rather than your skills or contributions.

However there may be other things he values besides money. Continue to make those great and I'm sure he will continue to enjoy being your coworker.

My translation: labeling an engineer as 10x may be mis-attributing the discrepancy to individual people, when the causes are most often environmental. Sure, there are outstanding performers and catastrophic duds every once in a while, they do exist. But more often than not your performance is less a reflection of innate skill and more a reflection of things like your managers, your situation and motivation, your momentum and familiarity with your tools, the mood in your office, your level of ownership, etc., etc..

I have been both subject and observer of situations where someone's performance was amazing in some cases and lacking at best in others. I have experienced being 10x when the situation was right, and 0.5x when it was wrong.

So how do you make a 10x environment on purpose? I've tried on teams I've led, and it is by no means easy. Can anyone with concrete experience share reliable tips?

>So how do you make a 10x environment on purpose?

I think there are two necessary parts:

1. A high level, well-known, agreed-upon plan. Everyone needs to know what they're working towards, why they're working on it, and how they'll do it. This lets people work largely autonomously but towards the same goal, reducing friction. I've been a 0.5x engineer because my manager told me what I needed to build but not why. So, I'd build something, and the feedback would be "no, that's not exactly right, just do it this way". What could have taken an hour would take days while I slowly figured out what he was imagining.

2. As few blockers as possible. Use tools and languages the whole team knows or can learn well. Create a collaborative environment where people can ask questions instead of spending hours working through tiny issues. The manager should make removing external blockers one of their highest priorities.

This is what allows people to work at peak efficiency. I think when there's nothing holding them back, most good engineers are "10x" engineers.

Great points. One thing I would add is to pay a lot of attention to your team's dynamics. One bad (or just not as engaged) team member could derail the whole team's morale. Friction should be dealt with immediately, even if it's really minor.

I think we should strive to avoid 0.1x environments. I work in a cube farm and there are plenty of days when my neighbors are so loud that my productivity goes to 0.1x or less. When I work at home on Fridays I often get more than than during the 4 preceding workdays.

Add to this constant meaningless meetings where everybody is late and unprepared.

I often hear "I will work tonight or on the weekend so I get things done". I don't understand why everybody seems to accept that the workplace environment is bad and nothing can be done. I have raised this to senior management quite a few times but they just shrug their shoulders.

I think it's a autonomy thing. People that care about their work will care about their work environment, and they're the best stewards for getting that kind of work environment in place. They've got the tightest feedback loops after all.

This seems to conflict with ease of management, which might be why this kind of autonomy is rarely granted. Cubicles are cheap and easy to manage, having 50 different environments in a 50 person office and resolving conflicts between them is not.

There's some approaches that partially address this problem, for example "Work from home", which whilst allowing some workplace customization has a number of drawbacks.

I guess the simplest way to go about it from a strictly physical (eg. excluding communication channels) work environment standpoint would be to give people a space and money budget, and treating them like responsible adults with it. "want to wall in and sound-proof your space? sure". "Need 2 different office chairs for your back problems? Put it on the list."

Set a suitable budget cap per person, divvy up available space, and optionally set up a position that handles ordering of things and tracking of funds spent.

Historically speaking, very senior employees get to do this with their own office to a degree. But the output and impact of good software engineers might warrant the same kind of autonomy.

It may be a considerable leap of faith from a management standpoint, but there's some absurdity in managers trusting engineers with business critical systems, but at the same time being concerned about their ability to pick a desk and chair to seat their butts upon.

Then there's the thing with open offices, but that's a cost of communication issue, signal-to-noise ratio kind of thing. Talking in an open office is broad-spectrum and cheap for some of the participants, but information conveyed is not necessarily valuable in the greater scheme of things, in addition to incurring attention costs for everyone else.

It's like radio without the FCC or everyone communicating over the broadcast address in a network.

Everybody deciding their own layout won't work IMO.You can't just put up walls as you like. There need to be fire escapes and stuff.

In my company senior employees seem to view offices as a reward not as a productivity tool.

You'd probably need to put sensible routes through these divvied up plots. You could even specify the location the door needs to be at, and veto things that aren't up to code. It's more of a thing of "default restrictions" and "default permissions". Default restrictions are easier to work with, and they seem to solve problems, but they impede things. Default permissions let things happen, but they also let things happen.

I do think that senior employees seeing offices as a reward instead of a productivity tool is not ideal. Depends on the organization though, a call centre doesn't follow the same rules as a start-up or an assembly line. Forcing any of these models on the other would result in sub-par results.

It might just be latency, where the structure and nature of a business changes, but the culture and processes don't quite catch up. Software engineers in cube farms like Skype trying to push P2P messaging to mobile. Some mix of sunk-cost fallacies and the slow momentum of behemoths, I'm sure of it.

I do have some opinions on how to achieve these changes, but it'd be hubris for me to suggest them to you, since I'm unaware of your particulars. But I still hope that you get to work in a 10x environment some day. We all should.

It doesn't matter if you're a 10x peanut butter sandwich maker; no one is 10x all the time.

There are projects, and there are chores. Everyone wants to work on the projects all of the time, but that is wasteful. When one is productive, they should work on the projects, and when one isn't productive, they should do the chores. That's a habit that can be learned.

The only person who knows what they should be working on is themself. So, autonomy is important. You can't have a person with a habit of using their time most effectively who also isn't in charge of when and how they spend their time. Self-management is a skill that can be taught.

I think that talking about a 10x engineer or 0.5x engineer misses the right optimization: good software is built in teams, so build a strong team. Cross-skilling, pairing, and blocker removal all help give people a collective sense of commitment and autonomy: you have the right to touch the systems you need to accomplish your job, and it's my job as servant-leader to remove whatever's stopping you. But you have less leverage and less resilience without that sense of collective ownership.

I've likewise experienced both 10x and 0.5x situations. The latter invariably arose from sitting in a corner, divorced from context or support. The former is extremely rare and I've only achieved it on personal projects. But I'll settle for a motivated and healthy team of 5xers any day.

Pair programming, I think, can lead to a 10x environment, if the culture is built around pairing.

How has pair programming worked in your experience?

i am infinity better with a pair (can solve problems i cant solve alone) but you have to build the company culture around it. i am a founder, I pair with my partner, we think we can scale the company this way. You can't force it into an existing company. You hire different types of people when you're pairing full time, and that's just the tip of the culture iceberg.

> You hire different types of people when you're pairing full time

Yes, extroverts, specifically. :)

Even if you've been close friends with someone for twenty-five years (as is the case with someone I pair with for some problems), there's still a fair percentage of your thinking that will have to be focused on social stuff: putting expressions on, conversational behavior, avoiding asides that take a second to think but would require a minute to explain, etc. These are things that tend to occupy the same mental space as where I am thinking about the context of the code I'm writing, and while pairing can bring back some of that contextual thinking in the form of the other person, the bandwidth is so much lower that pairing seems useful mostly for learning, or for sharing a problem that I've already struggled with (so that my deepest thinking about the problem happened while I didn't also have to run sociability at the same time).

I've had the same problems trying to pair with another junior engineer. I would seem as if you'd be better of pairing with a senior engineer/mentor where you're focused on problem solving but also it is seen as an apprenticeship exercise, which means less distractions.

Work with easy to understand frameworks, and don't try to link together tons of complex systems that are hard to configure and require outside support. Don't have nitpicking code reviews. Don't have complex and bureaucratic process rules for code check in. Don't have build and test environments that break all the time. Don't have too many meetings. Don't have deadlines or ETAs for engineers, this makes them stressed out. Allow for flexible work hours.

Culture/environment is a critical enabler, but alone it doesn't create 10x people.

I don't think being a 10x engineer is about engagement, work ethics, ability to code fast or anything like that.

It's about making great decisions. That includes using the right tools, using libraries instead of inventing everything yourself, not using libraries when not appropriate and pushing back on a product decision that does not make sense.

Right, which is why 10x engineers don't really exist in places that don't value some level of engineer autonomy -- you can't make great decisions if you can't make decisions at all.

Pick one of the following conjectures and argue both sides:

a. There are no 10x engineers, just environments where there is a 10x discrepancy in productivity.

b. There are no 10x engineers, just 10x yardsticks.

c. There are no 10x engineers, but plenty of .1x engineers.

C is self-contradicting. "10x engineer" means "an engineer that's ten times better than most others", and if most others are ten times worse than someone, then that person is a 10x engineer.

Also, I hate the term "10x engineer". Everything follows a normal distribution.

>Also, I hate the term "10x engineer"

Even if people were to use a new term such as "3-Sigma Programmer" instead of "10X Programmer", the ensuing debates would still be the same.

To make peace with the "10x" label, I suggest people just think of it as a figure-of-speech instead of a mathematical term. We don't get hung up when people say "Star Wars IV was ten times better than Phantom Menace" or "I'm not even 1/2 the football player I used to be."

Then what are we arguing about? Whether there are people who are much better than other people? That's trivially true.

>Also, I hate the term "10x engineer". Everything follows a normal distribution.

A normal distribution doesn't preclude the existence of a 10X, just describes the rarity.

It doesnt even describe the rarity without a mean and standard deviation

Nothing follows a normal distribution at the ends. Almost everything has fat tails.

Yes, absolutely everything follows a normal distribution. Everything.

> Everything follows a normal distribution.

Yes, this is why the 60 wealthiest people have as much wealth as half of the world combined.

Well, what if you don’t have “most others” being 10x worse than someone in general, but you have a few .1x engineers.

If you put them all on the same team as a 1x engineer, there will be the perception that one engineer is 10x most programmers.

> Everything follows a normal distribution.

Evidence suggests that technical talent is bimodal.

What evidence? There was a famous study by a college professor 10 years ago, but he retracted his research as flawed.

Can you back this up with some data? This might actually match my observations but I never considered the possibility that it might be a bimodal distribution.

Is there anything more to that than just willingness to learn (like how some people will ignore the instructions and then demand help because "it doesn't work")?

> There are no 10x engineers, but plenty of .1x engineers.

If there are plenty of 0.1x engineers, then an x engineer is actually 10 times better. The units doesn't matter if the ratio keeps being the same.

That’s true in a mathematical sense, but it’s not how some or possibly most brains work. For example, “plenty of .1x” engineers doesn’t have to imply a majority, it could be just enough that you run into them on a regular basis.

If you were interviewing and on Monday you have a 1x engineer and 9 .1x engineers, you’d assert you met a 10x engineer. Then on Wednesday if you had 9 1x engineers and one .1x engineer, you’d assert you met a .1x engineer.

Yes, and the actual 10x engineer will probably be compared to a 1x engineer who the organization currently considers their 10x engineer. This may cause the organization to reject the 10x engineer, simply because they don't know what a real 10x'er looks like.

I think that's kinda the point. It's saying the ratio is accurate, but it's not due to humans with some superpower. It's that there are many people in the field who underperform.

Is 10x in binary or hex?

The dial on a binary 10x engineer goes to 2.

The dial on a hex 10x engineer goes to 16.

I think the question of 10x engineers is actually ill-defined. There are developers I can consistently outperform by a factor of ten, do in half a day what they spent an entire week on and end up with a better solution. They are not necessarily fresh out of school but somehow managed to survive year after year even though they don't even know the language they are developing in. And I don't mean the ugly details of the memory model but basics for professional developers like generics or interfaces.

But what does that proof? I think nobody doubts that the difference between a bad developer and a good one can be a factor of ten or more. Outperforming a good developer by a factor of ten is a totally different story. It is certainly possible if you have some good insight, if you spot some non-obvious structure in the problem that you can exploit to make your life a lot easier. But doing this consistently is probably at least a rear feat.

So the question is to whom do we compare our 10x engineer candidates? The average one maybe, but the average of what? Your team, your company, the entire industry? I would argue that the age respectively experience structure is really important. When you begin you learn a programming language but it takes some time until you really learn programming, until you reach the point that the languages no longer matters and you are able to focus on mapping your problems to more abstract concepts and typing it out in some language becomes the boring but necessary part of your work.

It proves the industry pays people who are barely competent, and that the median professional standard isn't high.

Possibly related - it's interesting that everyone has heard of the 10X developer, but there's no equivalent concept of a 10X company or department, or even of 10X or 0.1X management.

It's not that the concepts aren't obvious once they're mentioned, it's that - unlike the 10X programmer - they're often mentioned.

Is it naive to wonder if management would improve if managers had to worry about getting tagged with the 0.1X label?

10x engineer is a relative comparison based on the engineers around you, not a universal ranking. Most of this can be explained by managers who dont know what they don't know. (Never hired or managed hundreds or thousands)

I have met, hired, and worked with engineers of all stripes and tend to think this idea is just a mental way of covering that "we have a guy our company or team relies on to a high risk degree".

10x engineers are a bad sign because it means she or he probably belongs with a better crew... And someday either they'll realize that or leave for another reason, exposing our over reliance on them.

I think it's sort of funny when people think 10x engineers don't exist. For most of us, it's pretty obvious because we've probably worked with one. (If you haven't: you might want to rethink your job choices :-))

If you think about it, there's essentially no physical or finite limit to how much you can get done in a day with software (outside of, like, typing speed), so it boils down to how fast and comprehensively you can think. So you might think, well, nobody is 10x smarter than anyone else, and that's probably true, but you could certainly imagine someone that has learned 10x more and has 10x more experience and given the right context can apply that effectively.

I strongly agree with the no-jerks part. I think, short term, you can be a jerk and still be effective, but long term if you're unpleasant you'll develop blind spots because people don't want to deal with you. Once you have significant blind spots, I suspect it's very hard to maintain the 10x pace. There is of course, a strong counter example here, which would be someone like linus torvalds (who is both extremely effective, and, by his own admission, kind of a jerk), but I think while exceptions like that exist they're not the common case.

To be a 10x engineer, you don't have to be 10x smarter. There are a lot of ways to get to an overall multiplier of 10x.

You can be 2x smarter and 2x more experienced and have 2x better research skills and 1.25x better administrative skills/support (time management, office layout, etc.) with the net result of 10x effectiveness.

You can be 12.2% better in 20 different but mutually-reinforcing skill areas.

Or, thought of a different way, an ordinary engineer might solve 90 problems easily but get bottlenecked on 10 challenges. You can approach 10x by solving 99 problems easily and only bottlenecking on one. Being an outlier isn't necessarily a matter of one big advantage, but can be about combining a lot of small advantages.

Yeah, I entirely agree. I think sports are a good example of this (because in most sports, it's much easier to measure performance than in programming).

LeBron James, for instance (arguably the greatest basketball player in the world), isn't really 2x better at anything compared to other top basketball players. He can't run twice as fast or jump twice as high. He's just slightly better at everything. Small things can stack to a large degree. Like, how many programmers know the important keyboard shortcuts in their development environment? Obviously it doesn't take a genius to learn keyboard shortcuts, but shaving 5 seconds off operations here and there can have a huge effect when you start thinking about how that multiplies in timescales of weeks or months. (Not that knowing keyboard shortcuts makes you a great developer, just saying, seemingly minor advantages can be huge multipliers)

I think the keyboard example hints for something bigger. Yes it's a small example.But it may allow you to stay in the flow(and optimal focus) better than someone who'se looking around menus. And the effect is probably non-linear to effort. And it accumulates. Now every month you get to learn more/better than the other guy.

So yes, similarly minor things can be huge multipliers , like you say.

It isn't about the total intelligence - it is about the excess intelligence. If someone has to have a programming intelligence of 100 to do some job, you might only need a pi of 110 to be 10x them, not 1000. Very similiar concept to climb performance based on excess power in a twin engine airplane.

As I've written before [1], I find it confusing that some people believe "10x" or "rockstar developers" are a myth. Are star athletes, artists, writers, and, uh, rock stars, a myth? Why would the programming profession be the only one where there are no major differences in performance?

[1] http://www.ybrikman.com/writing/2013/09/29/the-10x-developer...

There are a couple of hundred 10x footballers or artists or writers or what ever compared to.the millions of people who try to do it.

Somehow there are 10s of thousands of people who think they are 10x engineers or have somehow hired a 10x engineer.

That's why they aren't actually all these 10x engineers people talk about.

Okay, here's an extremely unscientific rebuttal to your sports analogy.

There are 13,700 professional athletes in the United States [0], compared to 670,000 amateur athletes in the Amateur Athletic Union [1] (there are surely many more outside of that particular group but let's go with it). That gives us a 2% rate of 10x athleticism.

Let's assume that 10x engineers occur at the same rate as athletic exceptionalism (yes, that's silly but why not). According to another questionable statistic, there were 1,114,000 software developers in the US in 2014 [2].

Now we've already established that outstanding engineers occur at the same rate as professional atheletes. What does that give us? Tens of thousands of professional 10x engineers.

[0] http://www.bls.gov/ooh/entertainment-and-sports/athletes-and...

[1] https://en.wikipedia.org/wiki/Amateur_Athletic_Union

[2] http://www.bls.gov/ooh/computer-and-information-technology/s...

Of course superstars are rare. But rare is not the same thing as "don't exist". And of course people will claim to be superstars even when they are not. But that, again, doesn't mean they don't exist.

The very last two paragraphs of my blog post:

> It’s important to put things into perspective. Star programmers, athletes, writers, and scientists are exceedingly rare. I wouldn’t recommend building a hiring strategy around solely hiring “rock stars”; you’ll end up looking foolish and lonely. Don’t let perfect be the enemy of good: hire the best engineers you can get and give them ample opportunity to develop and get even better.

> However, don’t fall into the fallacy that all programmers are created equal. There is a vast spectrum of ability in any creative profession. On one end are the type of hires that can sink an organization, actively increasing tech debt with every line of code they write. On the other, there are people who can write code that changes what is possible and have an impact that is an order of magnitude greater than the average.

I agree with a lot of the points, but..

> Most of the 10x factor is most likely explained by team and company factors (process, tech stack, etc) and applies to everyone in the team/company. Intra-team variation is thus much smaller than 10x (even controlling for the fact that companies tend to attract people of equal caliber). Nature vs nurture…

Definitely not true! I have been in companies where 1 engineer outperformed 10 others with everything else being the same and on the same team. It was really obvious too. It does happen. eg, he could handle 10 bug or feature requests in the same time it took some of the other engineers to handle 1.

>Definitely not true! I have been in companies where 1 engineer outperformed 10 others with everything else being the same and on the same team. It was really obvious too. It does happen.

I believe 2x, 3x maybe 4x but 10x seems far fetched. Are you normalizing for hours worked in your appraisal of performance?

Per the arguments laid out in Peopleware I am opposed to my team members working more than 45-50 hours a week outside of rare crunch times.

No, same hours worked. Often far less hours worked and more accomplished!

I've seen some people read through a bug report and have the area found and fixed in a couple of minutes, and the bug passing QA first time.

I've seen other people take almost the whole day just to track down that same bug in the code, let alone fix it or get it past QA. By that time, the first guy had finished a whole stream of other tasks.

10x definitely exists - hop around a few companies and you'll come across one pretty quick. They are rare, but easy enough to find if you've been through a few startups.

Maybe its just that I look around and I am more willing to label a poor performer a .25x coder, than I am someone who can really crank it out a 10x.

I think the x-factor we are talking about is too abstract to really have meaning. For example, besides speed, my x-factor takes into account things like test coverage, maintainability, code performance, etc. When you make it very multi-dimensional it tends to even people out as folks often have very different strengths and weaknesses.

Sounds like a case for specializing your developers into parts of the process that they are most proficient in.

However, I have seen developers who are incredible in all of those aspects and simply run rings around regular good developers. People who you can give a problem and they've already designed a fairly novel algorithm for best case complexity in 15 minutes to handle it. These people exist and they are not 1x developers, unless creating novel mathematical proofs in 15 minutes counts as 1x ....

Of course it happens, few things are written in stone

If there are things a 10x engineer can build, that no amount of 1x engineers can build, then "the 10x engineer" is actually a misnomer.

Yes. Spolsky has a better term for the same idea - he describes an engineer who can hit the high notes. http://www.joelonsoftware.com/articles/HighNotes.html

> I’ve never met the legendary “10x jerk”. Anecdotally the outperforming engineers are generally nice and humble.

Anecdotally, I have.

During the past 19 years in software I have had the pleasure of working closely with five different 10x engineers.

None of them have been assholes - the opposite actually - once you've gotten to know them. If I were to generalize: most of them are not particularly extroverted, so that may be a cause of misunderstanding.

Some of the 3-5x engineers (they also exist!) have a tendency to treat people as "idiots" until they have proven themselves worthy intellectually/engineering-wise.

That might be a social dynamic thing. Think of how say high school dynamics work. It's never the most popular person that puts others down (it doesn't do them any good), it's the kids that are popular, but not quite.

I would not be surprised if this also held true for engineers. 10x engineers already distinguish themselves through their work output. It's the 3-5x engineers that are good enough to tell themselves that they produce more than your vanilla engineer, but not good enough that they couldn't get lumped up with them. It's that uncertainty that produces viciousness in the attempt to remove yourself from that set.

Unless your show them that your are a "3+x engineer", they'll try to distance themselves from you to not be tainted by association. I guess it also follows that they will be the ones obsessed with 10+x engineers.

Kings aren't vicious, it's their courts that are.

Of all the observations of social dynamics in this thread; this one was so on point that I had to follow up with some sort of affirmation; it's a good point to think about and to watch for in people, whether that's yourself (and I've certainly had to) or your people as a manager, due to the symptoms this situation can breed.

To provide some context for while I feel this is important, when I first moved into BigCO, there was a period of reorgs in my org entirely out of the control of anyone not in "the powers that be". As such; there was a "generation" of new engineers brought in as juniors who were laterally moved multiple times in a few years. New engineers continued to be brought in, but due to the promotion structure of the org, a lateral transition essentially "resets" you, so new grads were coming in at the same level of people who had been delivering for years.

Now; there's another discussion if this relates to the "3x engineer" thing, which I wasn't even going to get into, but for practical purposes these engineers WEREon average performing multiple X better simply by nature of domain experience and rampup. This resulted in different symptoms from different people; the more zen of my peers simply got saddened about feeling looked over for promotions and started considering other options. Many left for other companies. The less zen (myself included) got more "fierce" as a sister post elsewhere put it, realizing that to "catch up" with the career track, high visibility, high impact projects were needed, and that required pushing harder.

To bring some sort of conclusion out of this rambling mess; I'm not sure your statement of "vicious" is the right word, but needing to stand out from that set seems to be an inevitable consequence of how many promotion structures are built, and being aware of this dynamic, engineers can be both better at their job by staying on top of their internal responses and keeping them productive (why I differentiate "fierce" and "vicious"; you can have the former without the latter I think), and Managers can better stay on top of their team dynamic and keep employees happy by realizing these emotions happen, since I find it's an oft under-appreciated dynamic.

Man that ended up being FAR more of an essay than I intended. Hope there was at least one well expressed thought in there.

A lot of people suggest that 10x programmers aren't jerks because they reflexively disqualify jerks from the 10x category. That's wrong and reflects wishful thinking. Do they think Linus is a middling developer because he's also a jerk?

What were they like?

I had typed up a point-wise list but decided against it.

In short, they bullied, insulted and did not inspire co-workers positively, instead demotivating them by acting impatient and making fun whenever interacting about work.

Vague statements, but don't really want to get any more specific.

Trying to recall/summarize how the 10x:ers I worked with behaved, particularly against people who hadn't proven themselves (or were.. well, doing stupid stuff):

Some patterns I have noticed:

They are really eager to share their knowledge if you invest serious amounts of time with them AND you are capable of intellectually challenging them. The only way I have made this work is in-person. It is really time-consuming, but also quite rewarding.

When communicating with random people/strangers in the company via email they can appear cold/hostile.

None of the people I've worked with have made fun of people. The more common (but still as disruptive) reaction when dealing with "stupid" people over email is to "shut down communication" - only delivering the minimum bare facts that a competent person would require.

I can think of two people who might fit this bill. Both have a propensity to jump to conclusions and not fully understand various perspectives before passing judgements and weighting their judgements significantly more than others who are more knowledgeable and familiar with a problem (aka big ego). Brilliant by themselves but very difficult interacting with others.

Imagine a quick thinker from an accomplished competitive programming and math background who has a raging ego and a chip on their shoulder. From what I've observed some companies see this in interviews and won't hire despite solving the technical challenges significantly better than others.

I work with people who, while smart enough, aren't mature enough. Common statements include why "(insert technology or platform or editor) is made by idiots" or whatever because they made a decision to look at certain design choices as strawmen in their argument.

HFS+ not supporting true case sensitivity was one example. Or "I hate spring/struts/etc." just because they once had to deal with a bad codebase.

A lot of it is just tripping over one's ego to me. I don't think you can become a mythical 10x by placing so many filters in front of your work.

Some of the people I've worked with who fit this description have this tendency to jump to conclusions. But they also love debating, and correctly feel no shame in changing their positions once proven wrong.

I have found that many people find debates uncomfortable. I love them. They create value.

(In fact, whenever I meet these people I've met from previous jobs, inevitably we end up arguing intensely about random stuff. And enjoying it...)

The no shame in changing positions is key; it describes the difference between humble and egotistical or science and religion.

I think you're right that many 10xrs like to debate, and that value can come out of debate. However the best 10xr Ive worked with was equally at home with a 3+ hour technical debate or collaborating with folks who don't give their best contributions during debates. Brilliant, efficient, effective, collaborative, quick, and humble.

Somewhat off-topic:

I'm not sure I can be described as "humble". I do however place extreme importance on sincerity, particularly in debates. (Being able to switch positions when proven wrong is another essential part, of course.)

Of course, we are.

The 10x thing is like some weird, less quantifiable, engineer analog to Mensa.

IMO a 10x engineer is, more often than not, just a well-positioned engineer - the right person at the right place and right time.

Someone working within their field of expertise, with the tools to get it done, and without the typical roadblocks that stand in the way. Hopefully you've been there and know how it feels.

And maybe you've also been at the other side of the spectrum, working with an ever-changing, badly designed and documented piece of technology, with many surprise problems biting you in the ass, ever changing goals, and bad management decisions.

I've been a 10x engineer at times. But I know I've also been a 0.5x engineer. The knowledge on how to solve a problem and how to find an answer doesn't change, but the perceived throughput of a person definitely does.

Same here. I have worked on projects where we had a very good understanding of where we wanted to go and had autonomy to make the right decisions. We cranked out a product in 6 months the company is still living off 15 years later. That was with 3 people who could be rated as 10x for this project.

And I have worked on projects where nobody knew where things should go but a lot of people had a say in what not to do. So we all ended performing at 0.1x.

Agreed, there are no 10x engineers, we all have 10x moments in time once in a while. We all have moments when we feel we can't tie our own shoelaces without help.

Of course there are outliers. Nobody disputes that Jordan was a 10x basketball player (probably closer to 100x when compared against the true mean and not just among professional players). Nobody disputes that Coltrane was a 10x jazz musician. Why would software be unique among all fields by not having any outliers?

You're talking about exceptional geniuses, of which there are maybe a few dozen in a given field across an entire generation of people.

Every two-bit company is demanding "10x engineers". That is what doesn't exist. There are not tens of thousands of genius software developers in the world.

I think this is the problem, and my main concern with the overuse of "10x engineer": they don't live in a vacuum.

If you hire a 10x engineer and get him to move a button two pixels left, and then tomorrow someone else tell him to move the button two pixels right, he won't be a 10x engineer, he'll be a 0x engineer. There's a lot more involved and it compounds. An engineer knowing what to do and what not do (a skill often overlooked) can help immensely, but everyone needs plenty of support to be at their 10x.

The "10x engineer" I worked for quit and left me with an extremely over-complicated piece of software to manage. He's a sweet guy and a good friend, but really left me holding the bag because he was not happy.

Did they build it? Because I dispute that someone is a 10x engineer if they build overcomplicated pieces of software. A good engineer builds according to the business' needs, maintainability, scalability, and a whole bunch of other considerations. Just building the cleverest thing you can build is poor engineering.

What looks overcomplicated to a 1x engineer may be quite simple to the 10x. This in fact the most painful point to overcome with them: that not everybody is as skilled as them so the software should be designed and written accordingly.

In my (limited) experience, those that don't learn this tend to do all by themselves "because the others can't do shit", get overworked and are unpleasant to work with. Those who do are able instead to focus on the most important (and interesting) parts while letting the others taking their boring share.

> not everybody is as skilled as them so the software should be designed and written accordingly.

I don't know if I'm a 10x dev, but I've heard this mantra few times.

It's most annoying when it happens because I actually strive to make something simple. Like I once needed to index members of some C++ STL container, so I used std::map<key, container::iterator>. It went like that:

  - WTF? A map of iterators? It's complicated! Remove it!
  - But the objects need to sit in this container and this extra index is also required.
  - But... but.. It's complicated! Remove it!
Man, I hate people at times.

I can relate to a situation where a container of iterators is the seemingly correct solution yet not necessarily the best thing to adopt for maintenance considerations.

Containers tend to persist over relatively large blocks of code, whereas iterator invalidation can be very tricky and most people get bitten by it at some point.

I think this is what code commenting is for, though

I disagree. The entire practice of development is making simple parts and linking them together in a simple manner to create more complex parts that are still simple to understand at their level.

Your computer is extremely complicated, but it can be broken down to parts that are simple to understand in each level. That's pretty much the entire benefit of a good engineer. They know how to make self-contained things whose purpose and interface with the rest of the system is easily understandable.

This is not strictly true, and happens when complexity is needed for some of the simple lower level parts or due to the libraries and tools available changing over time.

For example, lets say the 10x engineer wrote fast inverse square root [0]. Most people would look at the code and not understand what's going on. It requires a lot of domain knowledge but provided nice speeedups at the time. Is it more complicated than necessary for some problems? Absolutely. However when used frequently as originally intended that speedup allows for more compute to be spent on higher level components useful to the rest of the team. It would also be a pain to maintain for those unfamiliar with some of the details but can be well encapsulated into a simple function call in a math library.

Thw other case this illustrates is that code evolves and a solution available now to make a system simpler may not have been available in the past. Today the same code for fast inverse square root is outdated in favor of hardware calls, so if observing the code now it is certainly over complicated for the solutions available at hand.

[0] https://en.m.wikipedia.org/wiki/Fast_inverse_square_root

This is about optimizations, which are the exception to the rule. Optimizations are just a necessary evil, they aren't what we should base our coding standards around. As you also pointed out about hardware support, we tend to stick these in as lower a level as possible, so we can back to our simple and elegant abstractions as quickly as possible.

I find whenever some code is "simple", it's just not really doing anything at all and whatever it's actually doing, it's doing it badly. E.g. it's not handling anything other than some basic cases and performs horribly.

My advisor said to me "A really smart person isn't one who comes up with complicated solutions to solve difficult problems but someone who can make very simple and elegant solutions to complicated problems."

I'm inclined to agree with him.

No I strongly disagree. The better engineer should take a complex problem and create layers of abstraction such that any idiot can manage the problem. It isn't sufficient to just solve harder problems, they need to rotate the basis such that it becomes a simpler problem, or change the problem so that it is simple, or comprised of simple components.

No 10x engineer is a True Scotsman.

That's why this whole topic is stupid.

I am inclined to agree.

To be fair, it functions how it is supposed to, it WORKS on the platforms it is supposed to work on (not without bugs, of course), and is not likely to completely fail at any point. However, it is still a crazy, relatively unique mess for me to figure out alone. My life sucks until I can figure it out.

Yup totally agree. That was not a 10x engineer, that was a 1x at best and probably < 1x. Building overcomplicated systems is a sign of a bad or inexperienced engineer and nothing else.

An often overlooked point is made here. If you hire a 10x gal, then to replace her you have to hire 10 people. The question then is: long term, can you afford to hire 10x people?

That statement doesn't follow. See Brooks' law.

Ok, fine, 7 people then. Still, you have to plan on that 10xer leaving or getting hit by a train. Your company better be able to survive that loss.

It sounds like you're measuring the "nx engineer" factor by lines of code. That's not what makes someone a top contributor.

I think I have been a 10x programmer having being called that and I am like that because it suits my work style. Its hard for me to work slow. But its also not possible to be 10x all the time - I am mostly that way in the early phases of the project and the X multiplier gradually comes down to 1 or 2. For example - when it comes to defect fixing in somebody else's code, devops and monotonous stuff - I might be less than 1x.

However, I have noticed that whenever I am called 10X guy, something happens and I ultimately end up to being 1x or leaving the company. The following are kind of negative thoughts/symptoms that occurred

1. In most companies - it means doing 10 times work while getting paid just 5-20% higher instead of 10 times higher (here 10 is just an example multiplier).

2. It means I am a workaholic - and others enjoying the benefits of my work because of (1)

3. The above two can potentially result into toxicity build up within me and then within the team. It does happen occasionally and I have to work harder to avoid it.

4. You are not with your own kind (like species on a mental plane and not race/religion) and your growth is limited. I ended up leaving companies or teams when I was called out-performer consistently - not because I was an out performer, but because I was not learning much from the team. (On 4) - I tried to stay in one company like this, because it was hard for them to fire me for obvious reasons. Ultimately I got fed up after few years. I also unsuccessfully tried to get fired by deliberately underperforming, because the severance was too good - but they wouldn't derate me or fire me. Finally I resigned and left on good terms. Retrospectively thinking, I wasted those few precious years of my life

5. One gets used to elitism - and that is a very bad thing. It closes the persons mind. I remember how I disregarded an amazing solution from a junior team member because I was comfortable with my way of doing things. Unfortunately, I realized the mistake a bit too late.

6. If I am a rabbit I am constantly worried about the turtles - they will beat me with consistent performance over longer run because I will get bored of the race.

Also, I don't think having a 10x engineer in a team as a good thing. And if everybody is 10x, then nobody is - which can be good.

On #5: This same thing happened to me. A junior dev came up with an ingenious solution for something that would have taken weeks and been a major maintenance headache going forward. The team had been putting off developing it for months because of that. She proposed the idea to me and asked if it was an awful hack and my initial reaction was "yes", but then I swallowed my pride enough to add on "..but here's how we can make it work".

> The easiest way to be a 10x engineer is to make 10 other engineers 2x more efficient.

I thought being a 10x engineer meant being able to achieve a task which could not be achieved by 10 average engineers.

Does it mean the ability to do 10x the amount of work than everybody else? That doesn't seem extraordinary, that's mostly a case of focus.

In general I dislike the egotism attached to the idea that one engineer is the cause of other engineer's productivity. That's a lame way of self-congratulating.

but... Error establishing a database connection

Almost seem appropriate given the title.

I personally see my own productivity improve by about 4 fold given the right conditions - i.e. being able to focus on the one task at hand, not jumping between projects and not being interrupted with questions every half hour. Anyway that's my comment having not read the article.

I've been a 10x developer. But it wasn't all me that did it... it was those around me being .1x. So ya... it does take a team to make 10x programmer.

I can't claim I was 10x smarter than my coworkers. I wasn't. But I knew how to use tools that were at least 2x better and put in at least 5x the effort. Looking back it's amazing how little effort my co-workers (and boss) did put in at that place. Public sector for you I guess. I soon moved on to greener pastures. Some places value 10x. But other places it's better to do the bare minimum to avoid threatening anyone or raising the expectation bar. Sad working conditions best avoided by those with desire to create or improve. A good place for those who claim 10x developers don't exist to seek employment.

> The easiest way to be a 10x engineer is to make 10 other engineers 2x more efficient. Someone can be a 10x engineer if they do nothing for 364 days then convinces the team to change programming language to a 2x more productive language.


The article goes on to suggest that there are "1000x" engineers who can do things other engineers cannot do. The article intentionally obfuscates the point to try to disguise the idea that talent really does vary tremendously and that no amount of teamwork can match rare insight.

It's become politically fashionable to discount the contributions of individuals, because if we think about differences in talent and follow the implications, we're led to crimethink. There was even an article on HN a little while ago suggesting Einstein didn't really do anything important and that his discoveries were just a product of his time.

>The article goes on to suggest that there are "1000x" engineers who can do things other engineers cannot do.

It's a very easy statement to make but really hard to prove. I will probably never write a solid OS kernel, but I'm also not going to spend 5 years trying to learn all of the concepts and hard-won knowledge just to prove that I can when I really don't want to be doing it in the first place. Especially when you can back out of that original argument by saying "Oh, well you were 10x, you just didn't know it".

I also haven't read too much about career progression for engineers which plays into all of this, i.e., what percentage of 10x should I be after 6 months? 1 year? 5? 10? What skills should I possess on that career timeline? The answer right now is pretty much open-ended.

Yeah and Jeff Atwood is a 1000000x engineer because he wrote some blog posts that made other programmers more productive and then built Stack Overflow and made even more programmers more productive.

I feel that the most fitting medium for rebuttal to portions or whole, is a separate article.

Having said that, I have seen projects and management lean on one or two guys out of a whole group to deliver the quick and mostly working plumbing + base work. And then pass off the polish work to the 1x or 0.5x employees.

Also, I saw no link between output and 'being a jerk', and that is highly anecdotal.

This is a similar way that sports teams work, or certain skills propel you to a different rank in army. Office work seems mundane, but management is well aware of the ghost benefits for hiring multiple-x engineers at 1.15x the salary.

> There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x.

If it's your company then by all means you should listen to everyone's advice. But if it's not your company then you should give your advice, but if your employer doesn't want it then that's their issue. At that point there's no ethical imperative on your part to try to prevent your business from going bankrupt, so as long as the checks keep clearing I don't see the issue.

It's not about ethical imperative, but ...

1. It doesn't look good on your CV if you only worked on projects that don't have any business value.

2. If what you do does not have any value chances are someone will figure out at some point.

3. It's not fun to work on a project that has no value for anyone. This is the kind of thing that will create burnout.

If what you are doing is very intellectually challenging for you, or it has value other than business value then it might be different.

>1. It doesn't look good on your CV if you only worked on projects that don't have any business value.

I completely disagree. If you work on a really cool project that's very technically interesting, that looks great on a resume.

Do you really think your interviewer (at the company you're applying for a new job at) is going to call the old employer and ask them "Hey, did this project on this guy's resume delivery any real business value?" Of course not. They only go by what you write on your resume, so you can spin it however you like. If it was an interesting project but was shit-canned because of bad management or bad timing or whatever, you don't put that part. You talk it up in the interview when asked about it, talk about how technically interesting it was, what you learned there, etc., you don't volunteer that it ended up being a bust. Even if you have to spill that (because you're specifically asked), you concentrate on the good points, how it was a great learning experience, how what you developed should be useful on future projects, etc.

Prospective employers are looking for skills and experience you have which will help them in the future. How financially successful some project you worked on was is really irrelevant, since there's far more to the success of a project than just the technical aspects. Lots of companies have built technically superb products only to have them fail in the marketplace because of bad marketing, other bad management decisions, too much competition, etc. OS/2 was completely superior to Windows 3.1 and 95 yet it failed in the marketplace; that doesn't mean that you wouldn't hire a guy who worked on it.

Sure. My point though is that if an engineer is building something without value, it's only really fair to call them 0x if A) it's their project, and B) it's something where they should have been able to figure out if it had value.

The author wrote Luigi at Spotify, which is a pretty good example of a small amount of code with immense leverage on other people's productivity.

It's important to define 10x terms - what businesses care about is productivity and revenue, even if the code/structure/architecture/documentation/whatever isn't top notch.

And there are definitely people that can produce 10x the output and make far more meaningful progress for a company than others.

I have made my peace with this pernicious meme. I have decided that as a ok developer who can sometimes shoe flashes of insight and produce some good code,

I will do what ghostbusters recommend :

- when someone asks

- are you a 10x engineer?

I will reply

- yes

And not try to disabuse non technical folks from their nice comforting ideas about how development really happens

I'm a 10x engineer - under perfect conditions.

But I think focusing on this work is wrong-headed. As noted in the article, making 5 other developers twice as efficient is roughly equivalent. The difference is that I can't sustain a 10x rate (I do a lot of "research programming" where I'm probing a domain rather than producing production code), while there's a good chance that training other developers will translate into a 2x (or better) increase in the team's productivity.

This reminds me another piece I read some time ago (google cache to rescue as site seems to be down):


is this just another label to refer to someone more effective at what they do, i.e. "ninja" or "black belt" ? or is it based on Peter Thiel's 10x technology or innovation leap?

Oh yeah, the 1/10 engineers are a problem as well (and 1/20, etc)

Usually a mix of not knowing how to use docs, google things or just stick to their old ways (the 1/20 miraculously find bugs on well tested software used by lots of people - at least that's what they think)

10x engineers exist, and this post was submitted by one. Hi admp :)

By engineer he means programmer? developer?

"...if they do nothing for 364 days then convinces the team to change programming language to a 2x more productive language."

If you bike-shed programming languages then I'm throwing you out the nearest window.

I really think this list has a lot of truth to it.

"There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x."

I have found myself to work really well as a "value enabler" of 10x engineers. It's a symbiosis thing - my best work has been done working with a 10x engineer with our skills complementing each other (I'm strong on the business value/UX side, defining overall architecture/network protocols/optimizations etc, but weak in e.g. hardcore C low-level implementation.)

A challenge: Whenever I've stopped spending 20 hours a week working closely with these guys (in order to focus on building other essential parts of the business where there are no 10x engineers), their output value has severely decreased. They often fall back to like 2-3x. (Really nothing to be ashamed of, but...)

Things like this can make company switching challenging :).

Companies die when they lose their competitive spirit, and start valuing internal considerations over technical effectiveness. One symptom of this inevitable disease is denying the reality of the 10x engineer, or start to think that being a jerk somehow negates technical accomplishments. It's because every company inevitably succumbs to this disease that startups can frequently wreck established players; the latter forget what's really important.

Focusing on personality characteristics of great engineers is how lesser engineers try to maintain their position in the status hierarchy when they know they can't compete on technical merit. A healthy company recognizes this dynamic and shuts it down. An unhealthy company indulges it.

Focusing on technical merit is how lesser engineers try to maintain their position in the status hierarchy when they know they can't cooperate and coordinate as well as others.

Just look at LeBron James.

He's the 10x of basketball.

The team gets built around him.

Same goes for 10x anything. Steve Jobs was the 10x of CEO, company built around him, etc etc.

To say the causes are environmental is just to live in denial. There are people out there waaaaay smarter than you. Or way more athletic, way more X.

This doesn't negate the importance of getting along and being able to build teams around 10x people but make no mistake - id Software was John Carmack and everyone else. Same goes for anything else wildly successful.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact