I agree with all of your characterizations. I couldn't spend year after year doing maintenance grunt work. Luckily, I get health benefits through my wife's job so I can jump back and forth between full time and contract work with abandon.
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 agree with all of your characterizations. I couldn't spend year after year doing maintenance grunt work. Luckily, I get health benefits through my wife's job so I can jump back and forth between full time and contract work with abandon.
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.
I question the association between maintenance and mediocrity. It’s much easier to start a new project than to work effectively with a large codebase you didn’t write.
Could you elaborate on what you mean by "break primary keys"?
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.
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.
> 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.
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.
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.
There is no dishonor in that grunt work. It’s just that your work product will have limited impact.
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.
The downside to doing it, for the people who do it, is that they will have a hard time finding another job if they get laid off. Their skills are likely outdated if they have been doing unchallenging grunt work for years.
> This could just be because I'm a mediocre developer (1X) but:
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.
That is a fair criticism. :/
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.
If you can do competent work and add value to the company, you're already ahead of many developers, I've interviewed. Heck, you're already better than some "architects" I've worked with.
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.
How many companies ignore your projects’ business impact when evaluating performance? I’d guess none.
How is it "gaming the system"? It's best for my career to be on the highest impact project. Either the company is going to reward me for succeeding or I can use that success on my resume to find another job.
Because the company is confusing project impact with individual impact. An ambitious idiot on a high ROI project is still an idiot.
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.
To anyone mildy deserving the title "performer", anything that sounds or smells like "grunt work" is merely an interesting candidate for (intelligent, self-contained, sustainable, documented of course) elimination-automation.
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.)
Asking your best performers to do grunt work is a waste of their skills and may eventually drive them away. Let them add value by doing things that lesser performers are unable to do.
> 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.
> 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. :)