Hacker News Reader

Comment by scarface74 | Hacker News Reader

Fire people whenever you can. There’s often someone to fire, but not many opportunities to do so. When you are given a lot of opportunities to fire people

I like this. Put another way "we are a team not a family."

https://www.slideshare.net/reed2001/culture-1798664

View on HN

That may sound nice to some people on paper, but the reality is that it creates a negative feedback loop. Consider the following review of the company from a senior software engineer. This review is not unique in its opinion:

I worked at Netflix full-time (More than 3 years)

Pros

They pay a ridiculous amount of money.

Cons

Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with.

Advice to Management

Stop with all your nonsense pitch deck, it's dated, old and you aren't hired the best talent away from Google, FB, Amazon....the sooner you realize you are just a content company, and maybe pay reasonable salaries with reasonable fostering environment the better. Just ask yourself: how many employees would leave if you cut their salary. Probably every one.

Above I mentioned "goal subordination" and claimed that there were good examples suggested in the OP. Well here

> Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with.

Classic goal subordination.

Company talk about "we are a family" is a red flag for a work environment where people may be pressured to work overtime ("it's more than a job; we're family.") or overlook inappropriate behavior ("that's just how Bob is; we can't fire him because family has got to stick together."). People on a team don't need to be "family" to be respectful and supportive of each other.

Companies like Netflix have the cachet and can retain people despite an anti-worker culture. It's also a self selecting group of over-achievers who may like the environment.

I'd argue most above average but not stellar workers would not put up with Netflix's implicit demands.

I would gladly work for a place like Netflix for a year or two, bust my butt, put it on my resume and move on. My market value would make it well worth it.

Word of caution from doing exactly that: you're signalling to future employers that that's who you are now, and forever. It's a pathway to burnout if you're not careful.

If companies don't want good developers to jump ship, it's simple. Pay them market value and keep paying them market value not 2-3% wages when they know if the employee leaves, they are going to have to pay market value and they are going to lose the person with institutional knowledge.

As a long time employee and employer in this industry all it signals to me and people like me is that you managed to survive that environment for two years. The name brand on the resume -is- worth something. Maybe more than it ‘should’ be, but that’s reality. Work at Google for two years and I mostly know you got through a Google interview and you can probably code. Work at Yahoo for 10 years and I know you’re good at politics. Etc. ;)

There's something depressing about your comment that screams dystopic to me. You're effectively reducing someone's hard work down to notches on a belt. I realize why you do it, but it still rubs me the wrong way.

What a boring future we live in. :)

When I compare opportunities for mobility that we have as developers, I'm grateful for the industry. I can't imagine being "stuck" at a job I don't like. In the last 20 years it's only taken a month to find a new job once I started looking. One time, I quit a job on Monday without any job in the pipeline, I hadn't interviewed with anyone when I quit and by that Thursday, I received an offer from what was then one of the 10 most valuable companies in the U.S. (not a tech firm) making 10K more.

I'm not claiming to be a special snowflake. I'm just a regular old "Enterprise Developer".

But the thought of working 30 years at one company and receiving a pension, horrifies me.

Just like we are just "resources" to an employer, they are just resources for us to make money. No loyalty either way, no expectations.

They give me a paycheck every two weeks and I work hard and do my best work for those two weeks. Nothing more, nothing less.

Thank you for your candidness. Your experience matches my own. It's a bittersweet grace, I suppose.

That said, I come from an area where for whatever reason, there was a large population of undocumented or otherwise illegal immigrants. One of my good friends, then and still, was able to get a work permit through deferred action. Her experience transitioning into a legal workforce has been nothing but depressive frustration to the exploitative and apathetic practices that her employers are able and willing to get away with. We both agree that the same practices happen in and out of tech.

While her struggle is strong and her ambition gets around a lot of niggling motivation problems. I can't say the same for many of my other friends in the same situation whose lives are irrecoverably fucked before being adults, despite their bleeding passion for what they do and care for.

Point is - peoples' lives are complicated and others' apathy only makes it worse. Your paycheck every two weeks and the decisions that follow can make or break a person's life. Please grow some empathetic balls, consider the power you have over others and try to look past lines on resumes and try to see the person behind it. "That's life" is not an excuse for your selfishness.

Thank you.

I hate to say this but I have mixed feelings.

From a personal standpoint, I always put family first and will go to bat with my manager all the way up to chain for anyone who has personal obligations that reports to me.

On the other hand, technology is more black and white. I don't expect anyone to know everything but I do expect a certain level of competence and being able to work independently based on your hired skill level - especially for contractors.

When I'm hiring contractors, I don't expect to have to handhold, mentor, etc. I'm not making a long term investment in them and they are getting a premium for it.

I don't see myself any differently. If I'm applying for a contract job, I know 90% of the job requirements. If I'm going in as a permsnent employee, I'll try to squeeze in with 50-70% of the requirements and bust my butt to get up to 90% proficiency.

Having worked at a “name” company is not the big boost to your value lots of people think it is. That’s a lie that those big companies use to get people to accept bad working conditions.

You can't just "work" at the company, you have to produce.

There was an anecdote about Netflix about how a group of engineers who were top performers were let go after they did their part in transistioning Netflix's data center to AWS.

So should we feel bad for the people that got laid off? They will be some of the most sought after people in the industry.

That's exactly it. And the thing is no matter where you worked, if you did great things and have great skills, you're going to get opportunities and recognition. If you don't have the skills and don't do the work, it doesn't matter where you filled a seat.

In my experience the HR people think more highly of resumes when a big-name company is on them. Maybe they shouldn't, but they do.

HR people have to market candidates internally, many times to hiring managers who tell their bosses “Your recruiters don’t bring me quality candidates.” To protect themselves, the recruiters go after brand names. (“Is it my fault they didn’t like someone from Cornell who worked at Google?”)

The reality is this is suboptimal for the company, but can still be rational for HR.

Is it really sub-optimal for the company? Consider that the goal of HR is not to hire the best, but to avoid hiring the worst.

I'm no different as an an architect. I don't always choose the best technology. I sometimes choose the most popular. The practical reason being its easier to find people who know it and there is plenty of documentation. The CYA reason is that if things go south, It's much easier to say it came highly reccomended. "No one ever got fired for buying IBM."

Right, but look who is stuck with IBM technology now.

It was an analogy. But, you'd be surprised.

https://www.serverwatch.com/server-news/ibm-mainframe-revenu...

It’s not the revenue that I’m knocking. It’s being stuck with obsolete legacy technology that you can’t get rid of. Better things are out there but you are stuck because someone else made a decision that wouldn’t get them fired. (I’m at a place that is going through the painful process of showing IBM the door)

Why work for a company that you wouldn’t like to work for for those 2 years rather than work for the company you want for the same time period and gain seniority?

What does "seniority" buy you as a software developer? I stayed at one company for 9 years and between bonuses being cut and 3% raises my pay at year 9 was only 8K more than year 2. Over the next 9 years and 4 companies, I'm making $70k more. This isn't anecdotal:

http://www.forbes.com/sites/cameronkeng/2014/06/22/employees...

There is a term for it "pay compression"

https://definitions.uslegal.com/p/pay-compression/

I'm not surprised. As far as I'm aware, larger companies don't top up your on-hire stock award once it has fully vested.

That’s true nearly anywhere your strongest negotiation position is during pre-employment.

But money isn’t everything and those pay rises suck I get 5-6% p/a without asking, must have been a heck of a bonus cut then.

This was between 1999 - 2008. Our quarterly bonuses started out at 20% and the yearly raises were 3%.

But even at 5-6% raises, that doesn't compare to the roughly 11% "raises" I've received by jumping jobs 4 times since 2008.

As far as money isn't everything. Yes there is a trade off between how much I'm willing to accept and commute times. All in all, the only reason I go to work every day is for the compensation.

As far as I can tell, the gravy train is over as far as being able to make 10K to 20K+ to switch jobs if I still want to be an active developer and I'm not willing to relocate. I'm okay with that. Now the criteria for jobs are what new skills I can learn, comparable compensation, new challenges, and work life balance including the commute and work for home opportunities.

parent didn't say s/he wouldn't want to work for Netflix. just sayin'

It doesn't necessarily self-select for over achievers. It could very well self-select for people who don't recognize their own (flawed, not empirically justified) biases with regards to what "high performance" means. Most of that Netflix deck is the same kind of vague "we hire only the best" and "our values are (list of over-broad, meaningless but impressive looking jargon)" expressed in different words.

If a company has to constantly fire a lot of people - supposedly for not performing well enough - then the company might want to investigate why it's so bad at making people reach their potential.

Note: a constantly looming threat of being fired might be involved in it too.

Unfortunately, "fire fast" is now known widely enough to become a business fad / cargo cult. Which means, people are going to do it because it's the thing to do, and not because there's a good business reason to do it.

As a consequence, a company could strategically use "fire fast" by claiming it as a policy but not doing it. This would attract the people who perceive themselves as high performers, with minimal impact on employee morale.

This is true. Sometimes you have to let go of problem employees, but this should really be a last resort. Fire fast doesn't take into multiple considerations, such as the amount domain knowledge does this person possesses. If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them.

Constant firing can also negatively affect your personal reputation. As a manager your job is to get people to succeed. Firing someone means that ultimately you failed in that. Sometimes this is unavoidable; there are times when people just aren't redeemable. Sometimes it's not. Good managers know the difference, but you have to remember that every time you let someone go for cause, that person probably didn't see it that way. That person has friends who work other places and all of them have a long memory. If word gets out that you quickly remove people who you can't seem to handle, people will want to stop working for you.

If the person you want to get rid of has been there for 5 years, and knows certain systems in and out it may not be so easy to replace them.

One of the biggest mistakes a company can make is keeping a toxic employee around because of their domain knowledge. The company I mentioned that I worked for for 9 years made that mistake. The employee had plenty of domain knowledge but was toxic, insubordinate, and displayed a poor work ethic. I know they had to be glad when that employee left on his own accord.

That employee was me. I look back on those days in horror.

I've only had a couple of longer term jobs, but at both employers, I noticed that the lowest level workers had a comprehensive oral history of every firing and interesting HR incident that had ever occurred, like an Icelandic saga. And of course it was told from their point of view. So you have to be aware that every firing will be remembered, you will never handle it perfectly, and you don't control the story. A firing has to be worth that price. That's a high bar.

I've learned a really, really bitter lesson in life about people. When I was about 23, I did have a good view of people although not supported with much data. Soon, I guessed that my view was wrong. Nope, I had been right. Net, after a lot struggle, I concluded, about people, in a nutshell:

There are a lot of seriously hurt, confused, uninformed, misinformed, damaged, hurting people out there who are so badly lost they are seriously constrained in what they can do.

Now, to be more clear, where they are constrained can be quite narrow and not broad. So, day in and day out, they can look fine. But for some real work in some well defined context, they can flop -- really be just unable to perform. Again, this can be tough to see without a lot of experience with them.

So, for firing, if you have a person who seems okay or even good in many ways but, still, somehow just can't do the job, with explanations, help, training, discussions, counseling, guidance, leadership, etc., then don't (A) be too surprised, (B) blame yourself or say that the fault is that of the organization, (C) conclude that you should try one more effort to fix the problem, (D) conclude that, of course, you should be able to fix the problem, etc.

Maybe reassign them to some work they can do, if can find that -- and sometimes it's possible.

Otherwise, just go ahead and conclude that they are unable to do the work, at least any of the work you have for them to do; don't be too surprised at this situation or conclusion; and let them go. Give them back to their families, the mental health community, the welfare system, or some such.

The big point is: Such broken people are surprisingly common.

For one level deeper, an explanation can be that their problems are not really cognitive or rational but emotional. And the main emotions can be fears, commonly from their being misinformed, uninformed, having had bad experiences, confused from what they have been through, etc.

I think that's reasonable, with the proviso that you could fire that employee with a tolerable effect on employee morale if you haven't already used up all of your "credits" on a policy of routine firings.

You have to be careful. I am currently in an org that has embraced this philosophy. Instead of making the survivors feel valued, it has motivated most of them to move into more stable environments. These employees have dependents and don't like the idea of having their health insurance in play on a daily basis.

People read Glassdoor. If your company earns a rep for rapidly and casually dismissing people, you will see good resumes dry up. In our case, the quality of candidates has nosedived. It's not clear why a strong candidate would join a company that opts to fire people so casually.

Surely. (Too many) firings have a negative impact on morale. Especially if not done once. I think the point being made though is that it is very uncomfortable to fire people, so managers tend to avoid it, even if it's the right thing to do.

That was the problem at Yahoo. It's better to have one mass layoff and be done with it instead of having multiple small layoffs.

Yahoo had a hundred other problems.

Ive been at a company with multiple rounds of small layoffs. Each time they didn’t want to cut too deep or thought ‘maybe this will be enough’. It wasn’t.

It was a total moral DISASTER.

If you need to cut, cut. But multiple layoffs will kill you.

On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers.

A good developer is not necessarily one that knows everything but has competence and can learn fast. I've worked with smart junior developers and developers with years worth of experience that couldn't cut it when given a novel to them problem.

> On the other hand, if you feel you are a top performer and want to work with other top performers, you wouldn't want to work at a place with mediocre developers.

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.

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.

That is fair.

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.

Some people are starters. Some are finishers. Some are maintainers. Few are good at all 3. Most people seem to label fast starters as "top performers". But you can be a "top performer" in any category.

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

I agree with you on that last bit as I'm basically a sysadmin/dev that gets stuck maintaining the systems when "top performers" move on to the next project. ;)

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.

That's a fine rant on the trade-offs of automation vs manual intervention. It's one reason I used the word "might".

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.

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

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.

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.

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.

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

https://news.ycombinator.com/item?id=16031849

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

Magically? Without consequence? In all situations? I wouldn't ever (and didn't) go that far in my statements.. guess I'm not part of "y'all" =)

Yet you are arguing grunt work shouldn't exist and the fact it does means you should automate it. This may just be a sore point for me because of the number of times I've had to clean up messes created by people with the "automate all the things" attitude when they automate something they really, really shouldn't have.

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

Grunt work isn't everything though, it's more often than not highly manual, highly repetitive, low skill work. That sounds like a great candidate for automation.

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.

By grunt work, I mean "low skill" for a software developer / white collar professional with a similar income. I don't mean like, minimum wage data entry type work.

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.

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

The first thing that came to mind with that link was:

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.

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

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

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

You can't automate everything, but it doesn't make sense from either the company's standpoint or the employee's standpoint to spend year after year doing work that an "average" programmer can do. Either the company is overpaying or the person is getting underpaid.

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

It sounds to me like your definition of "high performer" is really "good politician." I know plenty of high performers who follow through all the way to deployment, monitor the program in production, and take full ownership of the entire thing.

Yes. I've seen that too. But that's a result of poor management.

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.

IME there's a fine line to balance between burning out your best people and over-pressuring them, vs being too accommodating of adequate-to-good people more interested in protecting their own turf/stability or playing political games than in getting the product as good as possible. In my ideal world I'd rather be in a pay-for-output-quality (not pure quantity or attention-getting) higher-pressure-but-not-insane-hours environment than in the latter, but sadly that doesn't seem super common.

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.

I've observed that some engineers are competent, but too insecure to rely on anything but their own internal feedback.

80% of drivers think they are better than average. Something to keep in mind.

Yes and I addressed this. If you are a Nascar driver, you can confidently say that you are a better than average driver.

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.

Depends on scope. The last place NASCAR driver is below average in his peer group!

Definitely its context. I stayed at one company 7 years longer than I should have and then started being more aggressive about my career in 2008. I was an average to slightly below average developer from 2009-2016. I chose jobs that between my interview skills and technical skills, I knew just enough to get into the door, learned all I could from people who were much better than I was and once my skill set outpaced the salary they were willing to give me, i left for another job.

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.

> If you are a Nascar driver, you can confidently say that you are a better than average driver.

Better at going fast and turning left?

I have no idea why this was downvoted. It was funny and perfectly timed.

Compared to what? The other lead developers at that company? That’s not how objective comparison works.

I did agree it was contextual whether you are a top performer within your peer group (in my case, I'm the developer lead for the company). But we don't just compete for jobs in the company you work for now, you compete in the entire market. How you define your market is based on location and willingness to relocate.

This!

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.

His statement could be read both ways. If you keep low performing people, it can suck the life of the team. I've personally seen teams where the top people lower their standards and outputs because they have low performing members in the team, and if the management doesn't care enough about the impact they have on the team, they will not work hard to make a good product.

OTOH, I do think firing is a bit of a last resort. A lot of people can be coached to perform better. I support firing as a last resort when other reasonable methods have failed.

I thought "coaching" was the answer to. I came in as a tech lead where one "developer" hired by a previous regime didn't know how to write a JavaScript function and just couldn't logically figure out how to debug an issue and the other just couldn't focus on a problem and went way out in left field on the simplest tasks.

We got rid of both of them as part of a "restructuring". I've had to cut a few contractors short because they just couldn't handle what for all intents and purposes was a startup environment where everything was up in the air and we needed people who could adapt, figure things out, and learn fast without holding their hands.

In a place like Netflix, everything is brand new. No one in history has ever had to deal with the scale that they have to.

This is where I stopped reading. Maybe if you work for Netflix-tier company which swims in the new candidates this makes sense but otherwise it's a great way to get a bad fame and make remaining employees focus only on KPIs to avoid getting fired(Goodbye good code quality, mentoring etc.; Hello "please create a ticket before asking any questions").

Besides, a good organization hires mostly right candidates. Firing should be really exceptional.

Reply on news.ycombinator.com