I've seen this play out in person several times. It's rarely that hard to have a set of fresh eyes clean up an old mess. In fact, sometimes that's exactly what you need to move forward. We had two...
I've seen this play out in person several times. It's rarely that hard to have a set of fresh eyes clean up an old mess. In fact, sometimes that's exactly what you need to move forward. We had two junior devs gut and clean up a massive multi-year project when the lead/sole developer got the axe. Took them less than a month to solve all of the problems the other developer had been stuck on for years - because what was in his head wasn't a reflection of reality, or the project requirements.
I think it's wise to move developers around between projects from time to time, to prevent these fiefdoms from forming in the first place. I've seen people intentionally try to build this sort of power structure for themselves, so they can become irreplaceable and guarantee their future employment. Creating intentionally bad docs (or no docs) so that it's all only in their head. Not sure why anyone would want to become a 'lifer' slaved to one single application for twenty years.
I think you're bang on the money in outlining this situation. I don't think it's down to poor management/hiring practices. This is a company strategy: We'll hire cheaper workers because that'll...
I think you're bang on the money in outlining this situation.
I don't think it's down to poor management/hiring practices. This is a company strategy: We'll hire cheaper workers because that'll surely be good enough for what we need.
An environment of excellence, a culture of seeking to push oneself and improve as a collective group comes at the cost of higher wages. That situation is only something a board seeks if they calculate the upside to be higher than the added cost.
In tech, average is often more than enough. It creates jobs that are terrible from day to day, but pay reasonably well. This hiring strategy creates all those desks filled with people who hate their jobs thoroughly. I think it's especially bad in many branches of tech because who really needs an environment where codes go beyond just pushing something average to market that mostly works?
I didn't experience it to anywhere near that degree, but this is the I left my last job. I had been there long enough to be more skilled than all but a few other developers, and people left for...
I didn't experience it to anywhere near that degree, but this is the I left my last job. I had been there long enough to be more skilled than all but a few other developers, and people left for other jobs at a fairly steady trickle. I could feel my own ego creeping up on me, which I didn't like either. Leaving for another job was one of the best decisions I've ever made.
I'm most likely starting a new job in a few weeks. Their entire codebase was outsourced, and the different pieces were written by different people who had no understanding of the whole, and it'll...
I'm most likely starting a new job in a few weeks. Their entire codebase was outsourced, and the different pieces were written by different people who had no understanding of the whole, and it'll be my job to make everything work right.
I'll also be the only actual programmer they have working for them. At least at the start.
From what I understand, they don't ever have proper version control set up. The person who interviewed me barely understood the difference between git and github.
Rick was not this company's "top talent". Rick could have been an incredible asset to the company if he'd been managed properly and people would have used his solving of complicated coding puzzles...
Rick was not this company's "top talent".
Rick could have been an incredible asset to the company if he'd been managed properly and people would have used his solving of complicated coding puzzles where appropriate.
Having Ricks can give a mature tech company a huge competitive advantage that realizes incredible profits on the margin.
There's a reason a lot of pure tech companies recruit people out of college in ways that target Ricks. Molding Ricks to fit your company without inheriting all the quirks of past projects and eccentricities left to their own devices can let you create products you simply can't code without Ricks. Just like there are science problems in every field of math, engineering, chemistry, physics, economics, medicine, statistics etc. that require raw brain power and analytical skills a crowd of slightly lesser brains won't ever solve.
This one really wasn't on Rick, even if things could have been much better had Rick been a different person. He wasn't, and didn't receive the social feedback and support to be able to change before it was too late.
If your workplace has a Rick, get out while there's getting out.
Rick could have been an incredible asset to the company if he'd been managed properly and people would have used his solving of complicated coding puzzles where appropriate.
It’s a vague term so we shouldn’t get too bogged down in the semantics of it that we lose track of what he’s trying to say. The point is that Rick was an asset who was managed poorly to the point...
It’s a vague term so we shouldn’t get too bogged down in the semantics of it that we lose track of what he’s trying to say.
The point is that Rick was an asset who was managed poorly to the point where he became a long-term liability. His personal productivity was high, but his shipping unmaintainable and uninterpretable code means he was dragging the rest of his team down and the company should never have allowed things to come to that.
One of the most important skills you can develop as a programmer is the ability to recognize when your code is accruing far too much technical debt and the willingness to scrap most--if not...
One of the most important skills you can develop as a programmer is the ability to recognize when your code is accruing far too much technical debt and the willingness to scrap most--if not all--of that code in favor of a complete rework.
I can't even begin to tell you how many times I've thrown away days of work because I recognized that the approach I was taking was a bad one. Every single time, it was worth it. There's not a single instance where I threw away my work and came to regret it. The only time I've ever regretted my work is when I insisted on continuing to work with bad code.
Sunk cost fallacies shouldn't be glorified. Technical debt shouldn't be glorified. A refusal to learn shouldn't be glorified. A refusal to collaborate shouldn't be glorified. A refusal to accept contributions from others shouldn't be glorified. Arrogance shouldn't be glorified. None of these qualities point toward talent, but rather a lack thereof.
Rick wasn't top talent. Rick was talented only in that he could manage a colossal mess and discern the functionality of complicated code. The real talent was in the other programmers who could recognize that it was a mess and cleaned it up into something that could actually be worked with. Technical debt is unavoidable, no matter what project you work on, but it's also manageable and something that you can pay down on. Those other programmers, the non-Ricks, recognized this fact and put it into practice. Rick will forever remain stunted in his growth unless he can learn to remove his head from his ass, but the non-Ricks still have a lot of room for growth and will almost certainly surpass Rick at every turn.
Just in case this hasn't been read, I think this is a nice perspective on what might have been going on. I was never a "Rick" (maybe other people would disagree?), but I was once tasked with...
Exemplary
Just in case this hasn't been read, I think this is a nice perspective on what might have been going on. I was never a "Rick" (maybe other people would disagree?), but I was once tasked with saving a thing, that unfortunately was a genuinely hard task (soft real time summaries of trillions of data points for making fraud decisions for a large payments provider). I ended up having to take it away from the team (I was the lead) because they couldn't get it right even with supervision, locking myself away for three months, rewriting most of it and emerging with a working product, which had been worked on for a year with zero success (I was a relatively new hire). My reward: essentially the same thing. They said I was responsible for the delays, I had the cost the company so much money, and they were outsourcing the future maintenance and development of the product. They didn't fire me, because I quit the next week and rolled onto other work. Best decision I ever made. I bet the "Rick" of this story was done a huge favour as well.
TL;DR:
Instead of the article being a story about how they stopped this man’s descent into burnout via intervention, outstanding teamwork, and competent management, something that IT, Infosec, and Developers REALLY need to hear, they decided to focus on the toxic environment and problems in which seemed to stem from Rick. Instead of tackling the root cause of the issue (hey man, whats eating you?), they opted for the quick and easy fix (Hey Rick, GTFO!). Par for the course, as far as I can tell.
The article says that they encouraged him to take time off as well trying to help him work with the rest of the team. It seems like they made an effort to try and correct the situation rather than...
The article says that they encouraged him to take time off as well trying to help him work with the rest of the team. It seems like they made an effort to try and correct the situation rather than just fire him right off, which is pretty generous considering the outburst he had at the beginning of the article.
By the time we get to the meeting with the outburst, this guy had apparently had the weight of the whole project pulled onto him years. Of course he pulled it onto himself, but no functioning...
By the time we get to the meeting with the outburst, this guy had apparently had the weight of the whole project pulled onto him years. Of course he pulled it onto himself, but no functioning company should ever allow that to happen. At the end of it having let the guy work himself into extreme burnout (people not crushed by pressure rarely have outbursts like that, even if their inner monologue might go that way) they toss him aside. Granted he obviously had his problems, but as the article mentions, all the management directly responsible also got fired, whose failures should have been 90% of the article, instead of some weird piece about firing "top talent".
I've seen this play out in person several times. It's rarely that hard to have a set of fresh eyes clean up an old mess. In fact, sometimes that's exactly what you need to move forward. We had two junior devs gut and clean up a massive multi-year project when the lead/sole developer got the axe. Took them less than a month to solve all of the problems the other developer had been stuck on for years - because what was in his head wasn't a reflection of reality, or the project requirements.
I think it's wise to move developers around between projects from time to time, to prevent these fiefdoms from forming in the first place. I've seen people intentionally try to build this sort of power structure for themselves, so they can become irreplaceable and guarantee their future employment. Creating intentionally bad docs (or no docs) so that it's all only in their head. Not sure why anyone would want to become a 'lifer' slaved to one single application for twenty years.
I think you're bang on the money in outlining this situation.
I don't think it's down to poor management/hiring practices. This is a company strategy: We'll hire cheaper workers because that'll surely be good enough for what we need.
An environment of excellence, a culture of seeking to push oneself and improve as a collective group comes at the cost of higher wages. That situation is only something a board seeks if they calculate the upside to be higher than the added cost.
In tech, average is often more than enough. It creates jobs that are terrible from day to day, but pay reasonably well. This hiring strategy creates all those desks filled with people who hate their jobs thoroughly. I think it's especially bad in many branches of tech because who really needs an environment where codes go beyond just pushing something average to market that mostly works?
I didn't experience it to anywhere near that degree, but this is the I left my last job. I had been there long enough to be more skilled than all but a few other developers, and people left for other jobs at a fairly steady trickle. I could feel my own ego creeping up on me, which I didn't like either. Leaving for another job was one of the best decisions I've ever made.
I'm most likely starting a new job in a few weeks. Their entire codebase was outsourced, and the different pieces were written by different people who had no understanding of the whole, and it'll be my job to make everything work right.
I'll also be the only actual programmer they have working for them. At least at the start.
From what I understand, they don't ever have proper version control set up. The person who interviewed me barely understood the difference between git and github.
That either sounds like a fantastic opportunity or a prologue to you winding up an axe murderer in a backwoods somewhere. Either way, best of luck!
Rick was not this company's "top talent".
Rick could have been an incredible asset to the company if he'd been managed properly and people would have used his solving of complicated coding puzzles where appropriate.
Having Ricks can give a mature tech company a huge competitive advantage that realizes incredible profits on the margin.
There's a reason a lot of pure tech companies recruit people out of college in ways that target Ricks. Molding Ricks to fit your company without inheriting all the quirks of past projects and eccentricities left to their own devices can let you create products you simply can't code without Ricks. Just like there are science problems in every field of math, engineering, chemistry, physics, economics, medicine, statistics etc. that require raw brain power and analytical skills a crowd of slightly lesser brains won't ever solve.
This one really wasn't on Rick, even if things could have been much better had Rick been a different person. He wasn't, and didn't receive the social feedback and support to be able to change before it was too late.
If your workplace has a Rick, get out while there's getting out.
....making him the top talent, no?
It’s a vague term so we shouldn’t get too bogged down in the semantics of it that we lose track of what he’s trying to say.
The point is that Rick was an asset who was managed poorly to the point where he became a long-term liability. His personal productivity was high, but his shipping unmaintainable and uninterpretable code means he was dragging the rest of his team down and the company should never have allowed things to come to that.
One of the most important skills you can develop as a programmer is the ability to recognize when your code is accruing far too much technical debt and the willingness to scrap most--if not all--of that code in favor of a complete rework.
I can't even begin to tell you how many times I've thrown away days of work because I recognized that the approach I was taking was a bad one. Every single time, it was worth it. There's not a single instance where I threw away my work and came to regret it. The only time I've ever regretted my work is when I insisted on continuing to work with bad code.
Sunk cost fallacies shouldn't be glorified. Technical debt shouldn't be glorified. A refusal to learn shouldn't be glorified. A refusal to collaborate shouldn't be glorified. A refusal to accept contributions from others shouldn't be glorified. Arrogance shouldn't be glorified. None of these qualities point toward talent, but rather a lack thereof.
Rick wasn't top talent. Rick was talented only in that he could manage a colossal mess and discern the functionality of complicated code. The real talent was in the other programmers who could recognize that it was a mess and cleaned it up into something that could actually be worked with. Technical debt is unavoidable, no matter what project you work on, but it's also manageable and something that you can pay down on. Those other programmers, the non-Ricks, recognized this fact and put it into practice. Rick will forever remain stunted in his growth unless he can learn to remove his head from his ass, but the non-Ricks still have a lot of room for growth and will almost certainly surpass Rick at every turn.
Just in case this hasn't been read, I think this is a nice perspective on what might have been going on. I was never a "Rick" (maybe other people would disagree?), but I was once tasked with saving a thing, that unfortunately was a genuinely hard task (soft real time summaries of trillions of data points for making fraud decisions for a large payments provider). I ended up having to take it away from the team (I was the lead) because they couldn't get it right even with supervision, locking myself away for three months, rewriting most of it and emerging with a working product, which had been worked on for a year with zero success (I was a relatively new hire). My reward: essentially the same thing. They said I was responsible for the delays, I had the cost the company so much money, and they were outsourcing the future maintenance and development of the product. They didn't fire me, because I quit the next week and rolled onto other work. Best decision I ever made. I bet the "Rick" of this story was done a huge favour as well.
TL;DR:
The article says that they encouraged him to take time off as well trying to help him work with the rest of the team. It seems like they made an effort to try and correct the situation rather than just fire him right off, which is pretty generous considering the outburst he had at the beginning of the article.
By the time we get to the meeting with the outburst, this guy had apparently had the weight of the whole project pulled onto him years. Of course he pulled it onto himself, but no functioning company should ever allow that to happen. At the end of it having let the guy work himself into extreme burnout (people not crushed by pressure rarely have outbursts like that, even if their inner monologue might go that way) they toss him aside. Granted he obviously had his problems, but as the article mentions, all the management directly responsible also got fired, whose failures should have been 90% of the article, instead of some weird piece about firing "top talent".