The Biggest Mistake I Ever Made
medium.com
medium.com
I've changed companies a lot as a software engineer and I noticed that whenever I join a new company, I usually feel like the dumbest person in the company at the beginning - For example, other developers might mention specific features of Linux which I had never come across before or they might make references to certain technical concepts which I didn't know about. But a couple of months in, I usually feel smart again and then I get bored... (This cycle happens every time when I change company).
What I realized is that knowledge doesn't flow very well between companies - Each one tends to get specialized in very specific ways but they don't realize it. The developer who has been around the longest is the most knowledgeable when it comes to the technology surrounding the project in its current state - So it's very difficult for another regular developer to 'win' an argument against them - This is bad because the most senior developer is often too deeply set in his ways (it works best for him) but in reality, you need the whole team to take a few steps back to find something which works best for everyone.
The first company I worked for claimed that most new employees took 6 months to ramp up to the internal tools & processes, which sounded absurd to me until I actually started ramping up myself. Holy cow. And the people who were entrenched in this company's particular way of doing things seemed like absolute geniuses until I realized how much of their knowledge came from years and years of doing the same things over and over.
I think the best way to combat this is to recognize that tools, techniques, processes, and technologies are all an inherent part of your product and your business. Much like you take the time to refactor code and combat technical debt, I think it's pretty crucial to also devote time to combating "process-debt" and/or "tooling-debt" -- all of that extra cruft that piles up and starts becoming "the way" to do things at your company. Because, just like with code, there is usually a simpler, more practical and/or elegant solution just waiting to be discovered.
The thing is - if you zoom out, "experience" is nothing more than overspecialization in the particular environment you found yourself. That applies at the industry, society, evolutionary, and planetary levels as well. Organisms adapt to the particular circumstances that they live in. Usually these adaptations are beneficial, because otherwise they get pruned out and people adopt different ways of doing things. But sometimes the environment changes in a way that makes all that accumulated knowledge irrelevant, and you end up like the dinosaurs. Extinct.
I've found that most of the time, people's knowledge is the product of hard-won experience, and if you tear it down, you will encounter the same problems that led to them coming to those conclusions in the first place. But occasionally, something changes in the environment, and you need to tear things down to adapt. If you want to build off existing knowledge, become an employee, and join a company that's busy figuring out all the corollaries of the premise that founded it. If you want to challenge existing premises, become a founder, and look for areas where the environment has changed in a way that invalidates existing knowledge.
If you try to build something totally new and different by learning all the existing ways people have built stuff, you will probably fail (believe me, I've tried several times). Similarly, if you join an organization hoping to tear down all the wisdom they've accumulated and replace it with an outsider's perspective, you will probably meet significant resistance. Sometimes organisms have to die to learn.
And there were people who said that working with me was the best part of their job, but they were hard working and smart. And I really liked to work with them too. Every story has two sides.
I don't mean that Jason (OP) is not right! He probably is. But you can't generalize this as easily as the article says. Sometimes not the mean developer is at fault but the stupid management (even if there is more of them).
I bounced out of a big company for that and other reasons. I just could not deal with the culture. I work at a smaller company now, and am much happier, though it's still not a perfect fit.
The reality is that it's almost never a perfect fit. In these cases you have to realize that it's you that has to adapt to the company and not the other way around. I have an idiom that I use for these situations. "It's the job". It's the part of the job that they're paying you to do, that you don't like to do, but you do it anyway because that's the job. Make a rational decision to either get along with others or leave the company.
You can't have it both ways, they are paying you and not the other way around.
Now, I'm not saying you should give in to every idiot who wants you to change how you do things. You should definitely fight back against stupidity. But you have to learn to pick your battles and recognize when it's you that's being dumb and not them. And also realize that the apology is the cheapest and most effective career tool you have at your disposal. Nothing smooths over bad feelings like a well-worded apology. Try to do it even when it's not your fault.
I've spent a fair bit of time consulting now, and one of the key things to remember is that in a functional relationship, the employer is extracting more value than they're paying the employee! If it's the other way around (as an average), the company is going to be bankrupt.
My go-to catch phrase is: If you don't like how things are run, you can "change your organization" or you can "change your organization". I.E. you can either put effort into fixing things, or you can put effort into finding a new job.
You can plan your strategy based on the value that your team is providing. If your team costs $X and you're making $4X, you've got pretty solid leverage to state that you guys know what you're doing and want to make things better (or you'll leave). Alternatively, if you're at $0.9X ROI, you can probably make a good argument that you can turn things around from losing money to making money.
Every story has two sides. But I really appreciate your comment.
But your story also sounds very different from what the article is about. The parable in the article is not a story with two sides. The basketball team's performance was objectively measurable thanks to the championship games, and the team performed objectively worse with the skilled but hard-to-work-with player, and performed objectively better without him.
In your story, you say the other team members "didn't add ANY value to the project" and "try to make [your] work harder than it already is". In the parable, the semi-pro player, in spite of being the best player in the league, was adding NEGATIVE value to the team.
If you were hardworking and smart and completed your tasks while your teammates were lazy and didn't accomplish anything and just complained about not being able to work with you, then they (and the person who fired you instead of them) are the problem, not you.
What I didn't realise (and I'm sure a lot of people who keep on these individuals in paid jobs don't realise), is that it starts scaring off other qualified members/employees. By keeping on one bad individual, you drive away your other skilled users or employees.
But there are other kinds of high achievers who should not leave because, after all, talent is talent.
You don't say, "Bob wrote 70% of our product, and he's head and shoulders above the rest of the team, so he's got to go!"
You should say, "How are we best utilizing our in-house talent? Does Bob engender resentment from the lesser programmers? Maybe Bob should have the role of chief architect, and get Bill to be team lead since Bill's more of a people person."
It's complicated, and every case is different, and the size of the company is also a factor. Part of the art of management is the ability to get the most out of each person on the team. It's hard, it takes years to learn how to manage, and it's not for everyone.
Technology work isn't exactly like basketball. In team sports, you have to work with a team; it's not like you can just play the game all by yourself. The whole point of participative sports is that everyone has to participate.
But in technology, often it's the solo contributors that drive innovation by making a brilliant but messy system that the regular guys/gals have to clean up and maintain.
Once in a while, you see a brilliant solo contributor who makes a clean, maintainable system, and documents it nicely, and politely and sensitively hands it off to more junior staff to maintain while he/she moves on to the next big thing -- and what a joy that is! But more often they're the brilliant asshole that you have to deal with, both their professional work and personal foibles.
This question definitely captures more of the nuance that I felt was naggingly lacking in the original post. It's easy to justify firing someone in very black and white terms, but it's a lot harder to take such an employee and turn them into a valuable member of the team again, even though that might be the best outcome. Not saying it can always be done -- I've seen managers try for too long and fail, but I've also seen managers start making cuts at the first sign of trouble.
The 90s were such fun; long live distributed source control.
The guy coding a little slower but who customer success always talks to about problems. Great, he’s enabling communication between teams.
The girl who cleans up behind the “flash” programmer whose prototypes are awesome but doesn’t quite finish.[1] Great, she’s creating production code to be maintained by a team.
The list goes on. People provide value in ways that are not always apparent. I think Peopleware talks a bit about this although I may be mistaken, about the one team member who didn’t seem to fill a role but made everyone happy.[2] If the team wins everyone wins (hopefully in a good org).
The most exceptional teams have people filling roles. Every role is important and provides value. It’s why teams with a ton of exceptional people often implode, because they are all exceptional at only one thing and no one is filling the other roles. So all the members may appear exceptional, but the team is weak. It's a value systems problem.
[1] http://firstround.com/review/how-to-spot-and-magnify-the-pow...
[2] http://www.amazon.com/Peopleware-Productive-Projects-Second-...
Make sure you're not proposing your personal One True Way. Be trustworthy.
At some point, people have to experience failure for themselves. You did, probably. Remember how that feels.
Ask to help, but that's a learned skill as well. You can't yank the wrench away from them. Set it up to where you can come in when they're in trouble, but be humble and "in the spirit of service."
I think being self-deprecating helps. Give ideas away. Make any conflict between (the collective) you and the problem, not you and them.
If people are defensive, learn to defuse that or accept responsibility for that, even if it's not your doing. And if all else fails, excuse yourself politely.
Sadly, a lot of this is basically charming or selling people. It has Venn overlap with seduction behavior.
I've had jobs where I was performing much better or much worse than other jobs simply due to fitting better or worse professionally with the personalities of other people I worked with (this is to a significant extent not dependent on me liking these people or getting along with them on a personal level).
From the talented person's perspective, everyone else is at fault. They haven't put in the time to know x, or they're just envious of said talent, or they're standing on pride in refusing to follow the talented person's lead.
This is exacerbated by the possibility that these things are actually true.
The antidote to this, that worked for me, was forgiveness. Maybe you shouldn't have to do bookkeeping tasks that take you away from more important work. Maybe others are not giving due acknowledgment to the level of skill you've attained. If you decide to forgive them and put up with what you see as their bullshit (and it may be!), then you can move forward.
There is more than one way to be difficult to work with. For example, some can have anger problems. In these cases, mindfulness coaching can be useful. Why are they angry? Are they angry at perceived incompetence? Are they angry when they don't get their own way? Are they angry because of the argument with their parents the night before?
Another is contempt. If someone treats their teammates with contempt, it is often a sign of someone having a "fixed" mindset. They believe that some people are good at programming, and some people are just bad, and it can't be adjusted. These people are often also terrible teachers, which means they need to be taught that skill.
Some are inconsiderate. They have terrible hygene and controllable body odor. They listen to their own music on speakers in an open office. This often takes coaching on behaviors from management.
If you are working for a boss who has contempt for his underlings, I would suggest leaving, if you want to be productive in the future. Working under that sort of manager is absolutely hazardous.
A way you can spot someone who has contempt is to notice if they put down people, even if in a backhanded kind of way, or assuming the worst about someone. I have found that showing contempt for people in a 'lower socioeconomic status' is a strong sign of them showing contempt for everyone else they can put down to elevate themselves.
If they are your manager then they are likely to go up the organisational hierarchy soon, because they are really good at self promotion if they are already your manager.
This has come from my experience in the workforce.
Sure, he can do any task better and faster than anyone else, but in doing so he's robbing the less talented team members of tasks that they could worked on. The overall team productivity might be higher if he sits back and pays close attention to what his teammates are getting stuck on and only spends his time filling in those little gaps that nobody else can fill.
It's too easy to have the best members of a team do everything that's even remotely complex or 'difficult', and end up causing the others to stagnate as a result. The reasoning often becomes 'why learn something new when the smart guy will take care of it much faster?''
So you end up with one or two great programmers/designers/employees/whatever doing the 'tricky' stuff, and a large group of others basically doing the same grunt work day in, day out.
Then all you need is the top 'talent' to leave, and well, the company is in deep trouble. The other team members end up struggling to continue work that they never needed to learn how to do, or never got the chance to learn how to do.
Thinking you're in the right - that's when you need to eat some humble pie and recognize aggravating people is almost never a good idea. If you are in a do or die situation, sure, hurt some feelings. Otherwise, it is not going to work out for you or them long term. Long term, people want to be happy. If you're preventing that, you're the biggest problem in their life :)
If you're oblivious - then... There is no answer, you'll simply learn through the hard knocks of life.
I was being difficult once - in hindsight, people do the best they can and if the circumstances you're in can only result in a shitty product getting shipped unless you put in heroic efforts, opt for the shitty product. It's like 'the wire' (great hbo show) - when the system is broken, the one trying to do the right thing is going to get squashed.
Seriously, that's what you should do. People in this category (as everyone realizes) are "assholes", or more accurately, on the spectrum.
A team full of average neurotypicals is not a good situation for someone on the spectrum, nor is it a good situation for the neurotypicals. It's best to leave and find another early stage startup where the primary problem isn't "teamwork"; you'll be a lot happier at your new job and so will everyone else at your old workplace.
Excellent point in any case.
My son is autistic. He's 8. We had him tested when he was 5. He also has ADHD. If ever anyone cares about working with non-NT folks and those on the spectrum it's me. We moved to where we live specifically so we could get early intervention for him.
My five year old daughter might be on the spectrum, we are having her tested. She does have expressive/receptive language disorder.
Our youngest daughter, now 2, seems NT so far.
For the record on the original material. There's a chance the person was non-NT, as you suggest. However, that same percentage chance exists for at least three, maybe four, of his co-workers as well, the ones that were effected by this person.
I'm not dismissing your original statement. I do think it is harder for non-NT folks, even in tech. It's why my style is the way it is. If anything, I'm likely overly sympathetic to the non-NT folks given my situation.
I've written two other things that I often reference when talking about these topics that might be interesting. I hope you can appreciate my side knowing more about my personal situation and how that influenced and shaped my current views.
https://medium.com/@jasonwarner/no-one-is-the-villain-in-the...
https://medium.com/@jasonwarner/just-one-weird-trick-95fe7b5...
And similarly, most people I might characterize as slightly autistic are not assholes. I've worked with some really awkward folks, and people who were really bad at picking up social cues, and people who were unable to express themselves well. I don't think any of them were assholes, even if they weren't always easy to work with.
I think it is really insulting to people with autism spectrum disorders that you would assume anyone characterized as an asshole is autistic. I also think this attitude contributes to some of the asshole behavior on our industry. We write some unacceptable stuff off as "geek behavior" when it's just people being assholes, which is an activity exclusive to neither geeks nor autistics.
"The founder and I made the most classic of mistakes: putting up with someone because we were afraid to lose their ability. I’ve since come to learn over and over again, it’s almost never worth it."
Perhaps just me, but I don't like this style of writing. It takes pages of reading to arrive at a fairly simple point.
Authors, please make your point first. Elaborate all you like with long winded stories afterwards.
> [...] you are actually holding back everyone else at the expense of this person.
"[...]I made the most classic of mistakes: putting up with someone because we were afraid to lose their ability. [...] it’s almost never worth it."
edit: shortened it.
Using non-descriptive titles on HN?
So because the managers couldn't do a decent job of managing their employee, he loses his job and all associated benefits?
Seriously though, every company has had to deal with one of these people sooner or later. The cost to team morale always outweighs the talent of the difficult developer. Let them go, let them learn, and hope they fix their act at the next company. It always hurts to throw away talent.
Different cultures have different expectations of the relationship between employer, colleagues and the employee. Guessing op is from a place where being right is more important than everyone being on the same page but being wrong.
Guess there's room for all types of sanity in a world this big.