The most frustrating problem for me is "top performers" who are very technically knowledgeable, so seen as stars by their direct managers, but have zero interest in any solutions that they don't directly design themselves, and little interest in taking feedback or admitting that their internal mental roadmap isn't 100% perfect.

How do you get to be a "top performer" if you aren't willing to learn? In the context that I'm in now as the lead developer, I am sure that I'm the top developer. But as a lead developer, I'm the most inexperienced leader in my entire company and I'm constantly learning what being a leader means.

This could just be because I'm a mediocre developer (1X) but:

1) Mediocre developers have the ability to consistently produce all the basic non-architectural grunt work in a reasonable amount of time with a reasonable level of quality. Frankly, the "top performers" tend to want to work on high impact/high visibility projects and tend to shirk any grunt work they are given. (i.e. Even something as simple as a combo box that handles shipping I've seen "top performers" repeatedly f up despite me warning them and having to completely scrap their implementations. It isn't that the developer isn't a top performer, they just are not willing to do boring CRUD work and literally every "top performer" I've worked with does that. Management doesn't care because they deliver high quality results on other "new" things but basic maintenance work is simply beneath them both in attitude and the time they commit to the task.)

2) Places that tend to focus on "just hiring top performers" tend to have trouble holding on to top performers as they are usually bribed into leaving if they bother to look around. Mediocre performers might take 12-18 months to get bribed away when interviewing while working. Top performers tend to land a better offer in less than 3 months of interviewing. Places that hire mediocre developers can frequently throw $40k/year + a week of PTO to get them to stay. (i.e A top performer at my last job that I'm friends with got a $40k/year raise in cash, a week of PTO to guarantee they'd stay indefinitely.)

3) Top performers are very good at being an architect, breaking new ground, and/or working on novel problems. They also tend to naturally prioritize high impact/high visibility projects. However, that often comes at the expense of doing routine work correctly and the long term maintainability/stability (as they frequently move on). I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.

To me, it sounds like your company's definition of a top performer is someone who is good at gaming the system. I guess your company is not unique in that regard.

It also fosters a culture where obsequious bullshit artists figure out to worm their way into projects and come out the other side with kudos.

If that type of gameplay is effective, the company is playing the wrong game. If you ask your director who the highest performer is and ask your colleagues the same question, and the answer is very different, that’s probably what your company is doing.

If you're mediocre as in average, that makes you 4x, not 1x. The 10x developer is 10 times better than the worst performer who is still employed, or 2.5x the median.

I only point this out because lots of people get it wrong and end up unfairly underestimating their own competence.

I always tended to view "1X" as in "average" and then 10X as in "10X better than average" which I've seen happen in narrow competencies of a specific architecture/situation/business.

This can greatly benefit all of a project's/product's stakeholders in the medium-to-long term --- assuming the organization allows fully for this "performer instinct" to flower --- just as any garage up-start and foss/hobby project naturally would. Sure: there are likely-potential pitfalls implied here, in terms of scheduling/billing/accounting for such work. (Guess that's the part where non-developer team members such as POs/PMs/etc actually get to put in some non-janitorial efforts! =) But never insurmountable, and the "let's just keep some code-monkeys for the grunt-work" workaround/cop-out is mentally-cheap-but-otherwise-costly --- at least as soon as all the rockstars have been gobbled up by a single competitor! (Admittedly, that never seems to quite happen like that.)

I'm still kind of amused y'all think you can just magically automate and abstract things perfectly without consequences in all situations.

Countering my point by claiming you should automate and then backtracking with "Well, not everything" isn't particularly productive tbh.

I think the bigger issue is that you appear to be using the truth that you can't automate everything, to support the statement that you can't automate gruntwork, which I think depending on how you define gruntwork is false by definition.

While that definition focuses tightly on ops, you can extend it to general swe-ing. A manual, mechanical refactor is probably toil. The eng-time it takes scales linearly with code size. It can and should be automated.

To respond to the specific example in your linked post, you automate the f out of the process and then have the same person do it, but now it takes them minutes instead of hours, or hours instead of weeks.

[1]: https://landing.google.com/sre/book/chapters/eliminating-toi...

wget -r -nc -p --html-extension -k -np https://landing.google.com/sre/book/ -D google.com; mv ./landing.google.com/sre/* ./; rm -rf ./landing.google.com

> I understand that. It sounds like you're describing something similar to what the Google SRE book calls "Toil", and I would say that the goal should be to eliminate that kind of work.

Yes, to some degree.

You'll notice almost everything I point out is powerful automation handed to a user that doesn't really understand it is something to be avoided.

And when I say refactor, I don't really mean "code cleanup" so much as "removing technical debt that doesn't change the current buisness logic".

Keep in mind, my original definition of "Top Performer" was someone who resented even 10% Toil and basically would rather automate it shoddily than deal with it.

Well yeah, but in a lot of cases, at least when there's a build of up more than a minimal amount of technical debt, the maintenance of working around the debt-y parts can be a significant drag on development, and itself becomes toil-like. Reducing that isn't something I'd consider toil, and when approached correctly, can be an impactful change.

>Keep in mind, my original definition of "Top Performer" was someone who resented even 10% Toil and basically would rather automate it shoddily than deal with it.

Fair, although I would say that many positions and teams even, can be toil free (or nearly so).

Yes, and top performers try to move into those positions.

To be honest, in an engineering focused organization it may be possible that tackling technical debt might be viewed positively. Most of the managers I've worked for have been non-technical who don't fully grasp why they are losing momentum due to technical debt and assume its because of the developer(s) assigned being less skilled.

To be honest, I mostly use HN as a sounding board for my own experiences and to see how common/uncommon they are as well as whether there is something I'm legitimately missing.

I consider myself a "top performer".

Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.

But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.

Even worse, is an "experienced" developer who makes horrible architectural decisions.

I understand but maintenance/refactoring grunt work is technically necessary which is why I think going for 100% top performers is a bad hiring strategy for a business is all. Systems need to be refactored regularly to maintain business logic consistency between services, remain stable as the ecosytsem they communicate with changes, and be secured.

> Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.

I believe you. I'm not here to argue ability, just the strategic merit of focusing on top performers.

> But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.

Ah, and I think this might be a miscommunication partially as well.

To me there are basically 4 buckets of developers:

1) Top Performers (2X+ Developers. Highly skilled but tend to focus on personal growth. Tends to ignore long term pain points because they just will not be there that long.)

2) Mediocre (.75-1.5X Developers who should be used to do the non-architectural grunt work and refactoring. They tend to want to stick with an employer long term and tend to focus on medium to long term effectiveness because they'll feel the pain of deviation from that.)

3) Incompetent Developers (Experienced developers with little to negative net value who probably should really be looking for a new career. Or anyone who else who is substantially below the Mediocre range for their experience level / pay expectations. )

4) Inexperienced Developers (Little to negative net value who will probably need a couple years experience before you really know if they are a top performer or mediocre.)

> Even worse, is an "experienced" developer who makes horrible architectural decisions.

That is probably the single most painful experience in every software developer's career. Poor architectural decisions that cannot be properly refactored due to budget constraints. The number of times I've seen an incompetent developer break primary keys during a system integration/transition is too numerous to count.

You'll notice the people that consider themselves top performers that responded to this post lean towards moving on rather than doing primarily maintenance work for years on end. I've seen similar sentiments echoed by others, hence the distinction.

However, I would claim that if you never do maintenance work, you don't really know if what you're writing is crap.

Now I'm going to play devils advocate. What's wrong with doing grunt work and not being challenged? I know people who have been at the same job for 20 years maintaining the same system and not being challenged. They work their 40 hours a week, love the familiarity and stability, and go home.

I would die a thousand deaths doing that but sometimes I wish I had the type of personality that could deal with that lifestyle.

Realistically though, couldn't people say the same about me? I'm about 10% below the top salary I can get without going into management in my market. I should hit my top salary in about two years, except for cost of living raises. I'm okay with vertical moves being a "Senior Developer", "Architect", "Team Lead", "Consultant", etc. Some people would say why don't I want to be a manager or start my own company.

I have a friend who has been a mainframe systems programmer for 30 years. He’s a master of his craft, and has a tool in his bag of tricks for every problem that happens. Most of his work helping people integrate with his mainframe to eventually replace it.

He’s a great guy and loves the life he wants to live. The problem is, few things in tech will live that long, and guru knowledge of some forgotten mainframe makes your options limited.

> I've found "Top Performer" is really code for "Person who focuses on getting involved on the highest impact project they can at any given time." And then end up resenting grunt work when such projects are not available to them.

Isn't that a good thing? If I were running a company, I would want the best people to focus on the things that had that highest impact on the bottom line. If grunt work is all you have, grunts are all you need.

That is why its a dangerous idea (to me). The people making these decisions frequently misjudge the facts on the ground about what is the "highest impact" on the bottom line.

It frequently means its a good starter who has no real understanding of the medium to long term maintenance issues created by their work. They also rarely suffer the consequences of bad decisions that make it into production but "work" for the first few weeks until they've been moved to a new project.

Let me give you an example of this scenario:

A team of high performers who deliver on time and on budget are given a project to launch a new Project integrated from Frontend to ERP. And, amazingly, they look like they will almost make it despite only getting 80% of the resources they originally asked for 12 months ago!

Awesome right? They did it.

Then, you bring in the mediocre gal who handled maintenance on the old system in for the last couple months while Team Awesome was getting the job DONE! They needed her to help them figure out how to deploy to production tho (she is the devops gal as well as the maintenance gal).

And in July (about a month into this), she goes "Guys, guys. This isn't going to work. We need to do X, Y, and Z. I know its technical and not customer facing but we risk f'n up <insert critical path item X we use to generate money>. I know its a bit late, but are you sure you want to automate everything to work off excel spreadsheets handled by <insert arrogant business guy>? We need to do load / integration testing with a mirror of the real data. I am not sure what we've done to test it is enough."

Team Awesome goes, "We are cutting it close and its important to meet the deadline. We spent a year working on this and we are sure things will work out."

Queue two weeks after the August launch and some minor bug fixes, Team Awesome moved on to a new project.

Things are rocky but seem workable for all of Sept. Maintenance Gal rings alarm bells about some weirdness with payment processing, etc. but is told there isn't time to look into it because "super important feature was missed and needs to be put in ASAP!!!"

Accounting starts reconciling things in Oct and realizes we misplaced $125k of which $50k was due to a shipping promotion the "system did not handle correctly". A member of Team Awesome gets pulled off a "very important project" to "help" turn things around. They claim they do and go back to the "very important project". Maintenance Gal sounds less like she is crying wolf at this point but is basically ignored by management.

November rolls around, biggest month of the year, and by the end of Cyber Monday panic ensues when the "fix" turns out to have not worked correctly and Arrogant Business Guy "worked around it" again. $400k in unintended expenses are racked up. Integration falls over and distribution has to upgrade shipping on thousands of orders. Another six figure expense.

By Christmas, "Team Awesome" is deflecting blame onto the only person that has worked on the project since August (Maintenance Gal who has done little but ring alarm bells about launching it being a bad idea and working overtime to hotfix issues).

Non-technical stakeholders still think Team Awesome is Awesome. Maintenance Gal is called into a meeting where they planned to put her on a PIP where Management basically accuses her of pushing that particular unit of the Company into the red with her incompetence. She defends herself as best she can with the documentation of her concerns in July, August, September, October, and November.

Sometimes Maintenance Gal becomes Unemployed Gal. Sometimes someone else does.

----

I've watched this happen to multiple people at multiple employers at this point. Its left me a bit disillusioned with the idea of "top performers" who focus on getting involved on the highest impact projects they can at any given time.

I probably should mention at this point I've never been fired or laid off in my ~10 year career. The one time this particularly freight train was aimed at me, I started interviewing in August and my two week notice was in the Monday after I was called in for the PIP discussion. I had been just waiting for my background check to clear by the time the PIP came up.

You might think that is specific enough to work out my identity (if anyone cared too) but I've seen similar things happen enough times I know that isn't possible. Lol. :)

I designed our current system from scratch, hired people, mentored existing junior developers, etc. and my manager was constantly questioning me about scaleability, maintainability, fault tolerance, logging, devops, security, etc.

I also asked her to always question my decisions and keep me honest. I ask everyone on the team to question my assumptions.

If you're not being challenged in your job (i.e. doing grunt work), you either need to find a harder job within the company (it might be automating away grunt work), or failing that, a different company.

Honestly, the only serious challenge I have in my job is getting people to do stuff in a maintainable, reliable way despite the fact it costs a little more in QA of the automation (or manual change control processes that IT frequently resists). Automation is not the right solution when human QA and manual intervention is an order of magnitude less expensive than the potential problems created by a non-technical user.

You have to realize the only person who _really_ understands most heavily integrated systems are technical folks and automating abstractions to allow non-technical users to make sweeping system-wide changes is a bad idea (even if it is easier on IT).

> Top performers have usually crept towards the high end of the salary available to them, and they're aware that grunt work isn't necessarily a good cost / value tradeoff for the company they're working for, nor a good tradeoff for their human capital vs income earned.

The problem is, you can't always automate grunt work. For instance, matrix rate shipping is something that is (effectively) a business rule that is maintained manually across multiple systems. Someone, somewhere is going to have manually determine that business rule and apply it.

Now, lets say you are crafty and you automate the f out of this process so they just have to type some values into a spreadsheet and upload it. Or a form. Or whatever.

What happens if your validation is not 100% correct and you are relying on non-IT people to QA this update that impacts multiple systems?

You lose $50k before the defect is fixed because instead of having someone who understood the impact from end to end dealing with it, you gave it to a business person who found a novel way to work around your validation to "make it work". The cost of annual, manual updates by a 6 figure salaried programmer would have been less than $5k a year.

So the wise, automation oriented programmer fixes the defects in validation, writes some more unit tests, and so forth. Then, lo and behold, it happens a second time on Black Friday and you end up giving out 6 figures in $$ due to a "software error" that was due to a business person setting everything to $0.01 because they misunderstood something.).

Now, you might blame the business person but given this has happened for the Nth time before this person automated it...they should have known better and required some sort of manual validation step by QA/IT/whatever.

Some things you really, really must have a manual sanity check on because of how critical they are and the business risk involved and automating it to the point you hand it off to someone else for minimal manual work is not the right decision.

I've seen this with controlled substances, regulated products moving across borders, shipping, and a dozen other things. Non-technical people being handed powerful automated tools they don't 100% understand is not always the correct solution.

Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more.

Yes.

Its a situation where the individual's interests (focusing on being visible on high impact projects that hit deadlines and then moving on before the maintenance and/or technical debt issues crop up) are diametrically opposed to the business's interests (building maintainable systems that do not have 5-6 figure bugs that likely exceed the development cost of something as simple as executing on a critical path combo box).

I've never worked for a business correctly values the impact of the former on the latter.

I’ve worked in a shop that fired lots of people before, and the people doing the firing were some of the worst developers I’ve ever worked with.

If enough companies have been willing to hire you as a lead developer or an architect and you haven't gotten fired, you can can say with some confidence that you are better than average.

Better at going fast and turning left?

Now, after being a journeyman for the 9 years, I'm the tech lead for a small development shop. I consider myself the top performer because what I do has the biggest development impact on the company.