Some hard lesson's i've realized while working in "professional" environments:
1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It's usually best to start by "doing your job"- whether that's issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you're "respected", implementing better solutions will be a lot easier.
2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers/sales/marketing do not care about your unit tests. Your users also don't care about your unit tests. Unfortunately this is a dilemma that's hard to swallow, because when things break, it comes back around.
You have to realize a team that's been there before you has done things in certain ways for certain reasons- whether that's good or bad, you must adapt to it before you go king kong on their shit.
Or you can just start your own company and make your own rules.
This is key. I see that there are two aspects of this story:
1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process.
2. Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It's a slow process, an not one you can win only by logic. The subject is huge.
That said, I agree that it was better for him to leave.
I will add that, as a new employee, the best possible way to gain the trust of your new managers is to make them look good. In the case where you can see some obvious improvements, that means working collaboratively with the manager so that they can take some credit for the improvements. Specifically it means offering criticism and suggestions privately, getting the OK before making changes, and letting the leader manage the broader communication about the changes.
This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above:
> Or you can just start your own company and make your own rules.
When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they're not unreasonable to expect some level of respect for that.
In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it's because they know of the shortcomings, and feel immense frustration that they have not felt able to address them.
If they are total assholes, you don't want to work there anyway.
But if it's just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will add frustrations, and undercut whatever good you're delivering.
> You have to realize a team that's been there before you has done things in certain ways for certain reasons
This is a fundamental insight that a lot of people don’t seem to get. I always refer to this quote to drive home the same point: “There is no such thing as a dysfunctional system, because every system is perfectly aligned to achieve the results it currently gets.”
"Excuses for why shitty code is in production are probably legitimate excuses"
Honestly, I don't think this is true in the general case. It's certainly true that there are times when deadlines mean code quality is going to suffer, but I think the incidence of this is probably lower than the frequency with which this is used as an excuse.
Your #1 is so true. The lesson I learned was that the guy who was there before me almost always developed what he did under the gun and took on technical debt to make it happen.
Now I just put a mental crosshair on the code I want changed and come back to it.
I've luckily managed to pick up on these lessons without learning the hard way.
At my current job, the quality of the codebase is frankly, quite shit. The unit testing coverage is fine, but the actual quality of the code isn't good. It's not clean, there's a lack of separation of concerns, it's poorly formatted.
Within the first week of starting the job, I had a laundry list of things that we should do to clean up the codebase. However, I've been slowly feeding this list to my manager, rather than just dumping it on him.
Forcing a new "unrespected" hire to engage in a broken system is such wasted potential. These are maybe the only people who can change the system for the better. Their unfiltered view can help identify inefficiencies in ways entrenched workers cannot. But instead companies force the most manual, annoying processes no one wants on them, until they are crushed by the weight of status quo and become part of the problem.
> Product managers/sales/marketing do not care about your unit tests
Only if they have no technical understanding of it. Once they understand how these prevent regressions and provide confidence that stuff works as expected, they start to value it.
It's our job as developers to explain the importance of unit tests, and why they're non-negotiable.
Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).
>Or you can just start your own company and make your own rules.
People need to stop saying this.
It is certainly possible to do if you are blessed with the right combination of resources, connections and luck, but the whole "put up or shut up mentality" is merely an invocation of the just world fallacy as applied to startups.
The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things.
Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules".
I wasn't. My runway would have been about 10,000x shorter than his.
>> You must earn respect before you trash the system
True, but in addition to that and I guess more important is to get the mandate to do that from the upper management. Make that mandate a part of your job role. Then whether the team likes it or not, truly respects you or not, an official mandate makes it doable.
The other side is while for very practical reasons teams create all kinds of debt to move forward, we also tend to settle into a working mode using the adage of don't fix if not broken, which can be very expensive if you need to scale or pivot, and this just does not apply to start ups. Most big companies that sink I think is because they have created all sorts of invisible debts and there are people who might have fixed it, but their passion not backed by a mandate never lets it get fixed!
Well said!
I think another equivalent "coping strategy" is realizing less than dependable designs often arise "organically" like weeds in an unkempt (code) garden, which involves no malice, might just involve being busy from being, as you noted, in production.
Cash Rules Everything Around You. The last developer I fired worked for me for 4 days. On day 4 he presented me a list of things I had done wrong in a tiny 2000 lines of business logic application with over $300,000 of revenue earned on it.
I’m included gems such as @client = Client.find(1) render json@client. I have dozens of applications in production and mostly gray hair on a good day. If you can’t understand why that code was the right code in the moment, you won’t last long in a results driven environment.
A common illusion that developers tend to have is the "I'm right, why can't they just see it" syndrome. Without knowing the full story, who knows what actually happened there. When you're working on a team, it's completely different from working alone because productivity at scale is totally different from churning out code by yourself
One of the best advices I've heard about starting a new job is that, shut up for 6 months and just do whatever you're told. Don't make any decisions, don't make any improvements to the company process, and don't argue with people. Be relentlessly curious and ask lots of questions and follow the herd. Learn everythig you can about the process - the pitfalls, who are the strongest and weakest teamates, who are the difficult ones, who are the influential ones, how do they resolve issues.
Once you learn the team's in and out, you have more leg to stand on when influencing decisions. That's when you start suggesting improvements, drawing on the solid experience and trust you've built over the past 6 months
From your story, it's clear you wanted to "do it my way" from the get-go and had no patience or respect for other people's way of doing things. It has nothing to do with like-ability or being right and certainly shows lack of professional experience and judgement. I would certainly not want someone like that on my team, no matter how technically gifted they are because an asshole player like that would derail any software team
Random thoughts:
1. Say if you are hired as a gardener. But let's say your skills are much stronger in Botany. You might be fixated on why certain species are not planted and why the folks who planted it are stupid to have the plants that they decided upon, and how you might have a better idea on which plants grow best in which weather. Remember, you are still a gardener. Maybe if you work your way to earn the trust and respect of the people, one day, you might have the support to express your other skills in a better way and actually make a difference.
2. If it's one person that you have a problem with, there is a possibility that they are the problem. With two,the probability decreases a bit. With three or more people, the probability goes the other way round - you are probably the problem.
3. Watch 'Jiro dreams of sushi'. The cook took several years before he was allowed to bake a simple cake. It is not just a matter of knowledge, skill or even passion. It's being accustomed to the environment, being useful in some area to the business and making meaningful contribution before other nice things materialize. You still need a lot of skills, passion, talent and work ethic; but those are not the only things.
Kudos to the author in spotting a blindspot. However the tone of the articld still left me wondering if they actually still felt that they were better than the rest or if they realized their limitations.
It's a little more complicated in this case than for a typical gardener. The developer works for their manager, their team, but also ultimately for the firm. The developer may well be pursuing explicit goals of the firm, while annoying their peers or manager. And the developer may be right!
Teams reach a kind of stable state. New hires may well represent a desire of the firm to change that stable state. The team may not be on board. Sandbagging is not so uncommon.
In this particular story, the review situation is what particularly raised flags for me. Obviously the author did not situate himself well, but I'm not sure he'd have been happy if he had been more adaptable, and that may be on the team and not him.
Love these thoughts. I think the code craftsmanship movement really speaks to your 3rd point, but the whole industry is incentivized against it. Especially in SV, if you don't get into a company, make a major contribution, and get out in 3 years then hiring managers start to see it as a red flag. I really love the cross-pollination of ideas this brings, but it also wreaks havoc on stability and institutional knowledge.
#2 is just not true. If you're in a room full of klansmen who are all going on about how whites are the superior race, and you disagree. Are you the problem? NO!
The same is true of anything else. Sometimes the whole team is totally wrong, and their way of doing things is detrimental to the overall goals of the company.
Some of the other comments here seem to exemplify the just-world fallacy. If all software teams were so functional, sites like coding horror wouldn't exist.
The dirty secret of software development is that the vast majority of it is done very suboptimally. Both in terms of time taken, and the approach taken to solve the problem. A technically skilled engineer is able to spot these shortcomings and improve on them. A politically skilled engineer is able to get buy-in from the rest of the team, in order to make things better. A well functioning organisation is one where the talents of the technically-but-not-politically skilled engineers, are harnessed to their fullest extent. Not as a favor done to that engineer, but because it helps the organisation itself.
From reading the story, it's clear that this team is even less technically competent than others. It's also clear that the author is very technically skilled, but not politically skilled. Unfortunately for him, the organisation isn't highly functional either, likely stemming from its very political team lead.
In such situations, you essentially have one of two choices. Quit and look for a better team. Or stay, accept that you're working with a bunch of dunces, and do the best you can while getting along and collecting your paycheck.
I can relate because I found myself in a similar situation at a previous job, with almost the exact same quarrels and frustrations. Luckily for me, my team lead was much less political and more open to outside suggestions. Because of this, I was able to ram-through what I thought was the right solution, even though I was constantly butting heads with others. Looking back, I realise how lucky I was to have an open-minded non-political team lead, and how rare that actually is.
Hmmm yeah it really does sound like this guy and the company were a bad fit.
There is an old joke that after an interview you should ask 3 questions:
1) can she do the job
2) can you work with her
3) is she an axe murderer
OP can certainly satisfy one of these criteria but even if they’re okay on (3) not meeting (2) is enough for exclusion.
When you find yourself in a toxic (from your perspective) situation you really only have 2 options. If you decide to stay you have to make the best of the situation and get on with people.
It sounds like OP responded to this situation in a way that probably wasn’t in line with this thinking. It’s all well and good being “right” but such accomplishments are marred quite a bit of you’ve annoyed everybody around you in the process.
I’m speaking as somebody who has been through this cycle a few times and finally settled on “getting on with people” vs “being right” after I got the feeling I'd changed job a few too many times.
The transition in this way of thinking was actually quite painful and I made many slip-ups whereupon people would presume I had slipped back to my old ways and couldn’t change - the scorn still rings in my ears. But eventually I did and now I’m one of those effusive hackers that gets on with people, and just drops into tricky situations as they arise. A highly prized resource it would seem going by how my salary responded.
Anyway, as poor old Janis would say “if you can’t be with the one you love, love the one you’re with”. You’ll be happier and your stress levels, blood pressure, social life and even maybe your payslip will reward you for it.
One question some eager beavers might be asking is how do I deal with things when I see something that is obviously wrong. It depends, but if it's something that's well established and everybody has learned to live with I note it privately. Then I know where the bodies are buried and if it does become an issue I can point it out pretty quickly.
If it's something that's more immediate usually nature will take its course, but if it doesn't usually a quiet word in a tester's ear can elicit the necessary dialogue.
With regards to other people being "lazy" and "not fulfilling their role" I prefer to take a position of unconditional positive regard and presume that everybody is busy ... my cardinal rule when making big changes is "cause as little extra work for other people as possible".
Keeping people busy is management's responsibility, and if I'm totally going to pull the rug from under something I'll get them on board. If they tell me to leave it alone I leave it alone but I've told them what the issue is and its their problem now, to weigh up and act upon as they see fit.
I get the sense that the author of this post is fairly young. It's pretty interesting, if you look at the graph from the Stack Overflow survey of competitiveness vs kinship with your peers, it drops pretty rapidly with experience: https://insights.stackoverflow.com/survey/2018/#connection-a...
While studying social psychology of what makes a kid popular vs unpopular (on Coursera), one significant factor was that an unpopular kid came into the group and tried to play a new game. Whereas a popular kid just went along with whatever the group was doing and then after a while suggested they play a different game.
Clearly there are some parallels with this story here...to be "popular", he should have gone along with whatever they were doing and slowly try to change things. Not saying that's right or wrong, but hey, that's apparently how you get popular.
This is basic human interaction 101. If you approach a gourd of people talking and try to change the conversation immediately, it won't go well. You need to listen and participate in what's already happening first.
It seems to me, being "popular" is more an attained status rather than any kind of quality. What I mean is, the kids who went along with the group gave the group an opportunity to evaluate the newcomer - and gave the newcomer a chance to build some level of likeability, trust, respect.
One may be all of those things, but without giving the group an opportunity to discover that for themselves, they aren't going to listen to your suggestions. Or one may start by going along with the group, but be abrasive and obnoxious, and no matter how much time they spent with the group, they won't be popular.
> While studying social psychology of what makes a kid popular vs unpopular (on Coursera), one significant factor was that an unpopular kid came into the group and tried to play a new game. Whereas a popular kid just went along with whatever the group was doing and then after a while suggested they play a different game.
I remember reading about such a case in Emotional Intelligence by Daniel Goleman. So, curious what is this course?
I'm currently in a consulting gig coming up on my one-year anniversary. I'm helping maintain an internal development tool that was written by the company's CTO over the course of the last 30 years. It's some of the most godawful code I have ever seen: functions that are many hundreds of lines long, lines that are many hundreds of characters wide, weird state dependencies all over the place. It is literally impossible to work on this code base on a laptop. My client has two enormous 5k monitors on his desk. (I have to muddle through with just one 4k monitor, and that's barely adequate.)
And yet... somehow, it all works, and at the end of the day, they ship their product on time and make a boatload of money. So my visceral reaction to this code is a very strange mixture of horror and respect.
My approach to trying to get this mess fixed is something along the lines of, "You're the boss, and it's your call, but if I were one of your investors I would be very concerned about the long-term maintainability of this system if, God forbid, something were to happen to you."
Does this approach work? Hard to say. No substantive changes have been made. But I haven't gotten fired either.
You are thinking like a junior programmer and instead you should be thinking as an investor. The investor gives little to no damns about your opinion of the underlying code base.
Investors do not make fortunes based off the opinions of junior programmers nor on their understanding of the nuances of codebases.
Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.
My advice to you is the age old adage, put yourself in anothers shoes, go and buy some stocks, etfs, mutual funds what have you and experience the other side of business, let your eyes really be opened before casting judgement on processes you have little understanding of.
The author doesn't pick his battles intelligently. His victories are at the expense of his team: instead of making his team members look good he makes them look bad.
Perhaps this explains why I often pass technical screening with no problems but tend to fail 'cultural' fit interviews. It seems that to meet jcadam is to hate jcadam.
I probably don't come off as a very nice person (my wife tells me I have a 'death glare' as my neutral face), until you get to know me. I once had a technical lead admit about a year after I had started a job that she had recommended against hiring me and was overruled by her boss. "You seemed like a jerk at the time, but now I realize you're just an introvert."
So, these days I try to paste on a fake smile when I interview, but to no avail. I suppose it might make me look a bit scary -> vacillating between "death glare" and "creepy smile."
Funny, I got (and turned down) a job offer earlier this week that was based solely on a couple of phone interviews. I turned it down because it was a large corporation and seemed very much like a butts-in-seats sort of place (hence, why would they care about culture fit and actually want to meet me in person?)
I thought of just going back to my previous job (the guys made it clear I was welcome to go back) but I was afraid it would make my Resume look like I am too much of a job-hopper.
If you even put it on your resume at all, it’s probably one of the easier ones to explain and helped by the fact that your old company re-hired you. “Would you hire this person again if given the chance” is a common reference check question.
Obviously, the amount of apathy and defensiveness displayed by the other employees is a huge red flag that I'm surprised didn't come up in the interview process at all.
However: Saying things like "I don't believe you," especially in a public setting, is a great way to come off as a jerk. Once you've decided to call someone a liar, the chance of them getting defensive (and thus poisoning your relationship) increases significantly. You've cornered someone instead of giving them an escape route.
Seems like it was a horrible fit on both sides: The author needs a significantly more accountable company, and the company needs someone with a much more delicate touch.
I am surprised that most of the comments here are actually advocating for navigating Dilbert-style office politics as an effective way of "getting along."
There is clearly too much conformism and flawed communication flow in this organization, which is a failure of leadership, and not of somebody who is "actually doing what [he] was paid to do."
The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."
If there is too much conformism, necessary conflict will be avoided and could not be utilized in a healthy way, leading to too much consensus resulting in "one-year old pull requests without review."
In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.
If a competent but "less socially aware" guy moves "too fast," why the team prefers to effectively mob this guy out of the organization, instead of just telling him to slow down?
No such context for constructive feedback, maybe?
This organization is just shooting itself from the foot.
Organizations that need to move fast cannot afford such conformism and dysfunctional communication.
This is just humans being humans. Some people have more capacity for openness and receiving criticism than others.
Wisdom comes from taking time and understanding why organizations fail as they often do, and not trying to just fight your way through all the time.
It won't work, and people will not suddenly stop being as they are to fulfill your desire for a place where people will immediately drop what they're doing to listen to what the new person has to say.
That's not to say that they shouldn't, and smarter orgs will retain flexibility and welcome new ideas. But if you just expect that or feel entitled to it, you're gonna have a bad time.
It's not Dilbert-style because there's no conclusive evidence of incompetence. When you are new, you should be giving people the benefit of the doubt, and tread lightly. Raise these concerns privately and gauge the situation. After a few months it will become apparent if the place is truly dysfunctional, in which case you would need to have left on your own.
> I am surprised that most of the comments here are actually advocating for navigating Dilbert-style office politics as an effective way of "getting along."
That's unfair. Most people who are advocating for deference when first joining a team.
And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". Therefore, sitting back and learning the social and technical history that led to the current system is actually the correct place to be in the exploration-exploitation axis during the probationary period.
Both for social reasons, as well as for technical reasons.
That's very different from "put up with office politics". The point is not that you should be likable during the probationary period. The point is that people who go way the hell too far to the "exploitation" side of the axis so quickly are demonstrating poor engineering judgment.
Characterizing that poor judgment as "well I guess I'm just not PC enough" is just icing on the cake.
> The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."
According to this account.
I submit that it's not even obvious that the engineer in this story was even making the correct engineering decision. Engineers are not scientists:
> In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.
I think the core problem in this story was wasting a bunch of the company's time arguing over a heuristic that's "good enough" in practice. Both solutions would have been "good enough"; the engineer put his ego above producing value for the company.
> Organizations that need to move fast cannot afford such conformism and dysfunctional communication.
Organizations that need to move fast cannot afford engineers spending time to prove they were correct when going with the established heuristic would've produced a good enough result with far less engineering time involved.
If the story included a thorough cost/benefit analysis showing that the change saved the company $N0,000 with N > (cost of engineering time) then you might have a more cogent argument.
Managers are often okay with incorrect employees because they can be trained easily. (Whether or not management actually trains them, that's another story - but managers like to believe that they could.)
Managers are less okay with employees that everyone actively dislikes because it's way harder to train someone on how to get along with people.
> In my first week, I was assigned ... I took the lead in implementing the solution
You took the lead on your first week???
Based on your explanation, your co-workers were morons, but you made one of the most outrageous socially-wrecking mistakes that one may do: you showed an unwanted truth to people you were not even acquainted yet. After that, the cleavage is too deep to even try and feel it. I think letting you go was the right decision, the environment was already toxic and it would have taken years before it returning liveable, if ever!
When you join a new group of people, first of all try and adapt yourself to your new environment, and only later try and adapt the environment to you. Otherwise, conflict is inescapable.
One very painful lesson I've learned in two and a half decades as a programmer - when people hire you to fix their problems, they only very rarely actually want their problems fixed. In many cases, they'd rather see the entire organization go out of business than see you fix their problems.
It's kind of a motto where I work. Others are surely familiar with it too. I'd also add that baseline levels of sanity, competence, etc. are all part of intent for the purposes of this admonition. It's a good rule, and the OP demonstrates exactly how things can go sideways when it's not followed.
Maybe others didn't recognize the author's good intent, but he clearly didn't recognize theirs either. As far as I can tell, he doesn't think they ever did a single thing right until he came along, which is a huge red flag. I doubt he felt that way when he accepted the job (why would anyone?) so it reeks of post-hoc rationalization. Remember, we're only hearing one side of the story. Chances are, even if he was right on the major points, he has elided how his first ten "you just need to" proposals had to be amended in a collaborative process for which he denies anyone else any credit. Counting the hits, ignoring the misses. If he had assumed instead that other people weren't idiots, that they had reasons for what they'd done and would be amenable to reason, there might have been a better outcome.
P.S. Yes, I know sometimes people really do lack good intent. Some people really are mean, stupid, crazy, etc. Believe me, I've worked with a few and I've called them out on it ... but only once there was incontrovertible evidence of those things. It doesn't change the fact that it's better to start by assuming good intent.
There is a difference, I think, between healthy and unhealthy conflict. This team was clearly averse to both. It was likely an awful team.
My advice to anyone in a similar situation: work on the classes of behavior that are actually problematic, namely blaming, defensiveness, contempt, and stonewalling. Then you can have a healthy argument about ideas.
If a team has problems listening to actual, clear evidence that what you did was correct, they are perhaps at fault here. Of course, if you show contempt, then the right thing for a healthy team to do would be to:
1) Address the contempt head-on, and then
2) Examine the data dispassionately.
It seems this team failed at both.
Probably a good thing to get fired from such a place, though it hurts to not be given an opportunity to move on on your own terms! This particular org appeared to be a pretty bad place to work anyway.
Every single one of the author's complaints was an opportunity that the author could have ethically leveraged to advance and gain job security, all the way to lead tech (assuming that's what the author wanted).
Is there an industry where people like me get paid to keep people like the author from self-destructing in a near-perfect job environment?
Team psychologist? It's a role that managers end up assuming, often for the worst. Unless you're the rock metal band Metallica, who actually use a team therapist, problems aren't usually sorted out other than by turning over staff, which Metallica can't do without destroying the cash cow.
Likeability is not in the mix here. Essentially you came in, looked things over for a few days, and then told everybody "You guys are all shit, and so is your shit code." Your actions provide meaning, and especially so when you are a new incoming team member.
[+] [-] OutsmartDan|8 years ago|reply
1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It's usually best to start by "doing your job"- whether that's issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you're "respected", implementing better solutions will be a lot easier.
2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers/sales/marketing do not care about your unit tests. Your users also don't care about your unit tests. Unfortunately this is a dilemma that's hard to swallow, because when things break, it comes back around.
You have to realize a team that's been there before you has done things in certain ways for certain reasons- whether that's good or bad, you must adapt to it before you go king kong on their shit.
Or you can just start your own company and make your own rules.
[+] [-] raphar|8 years ago|reply
1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process.
2. Second but key, he sucks at working in a team and also at communication. You don't change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It's a slow process, an not one you can win only by logic. The subject is huge.
That said, I agree that it was better for him to leave.
[+] [-] snowwrestler|8 years ago|reply
This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above:
> Or you can just start your own company and make your own rules.
When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they're not unreasonable to expect some level of respect for that.
In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it's because they know of the shortcomings, and feel immense frustration that they have not felt able to address them.
If they are total assholes, you don't want to work there anyway.
But if it's just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will add frustrations, and undercut whatever good you're delivering.
[+] [-] vincentmarle|8 years ago|reply
This is a fundamental insight that a lot of people don’t seem to get. I always refer to this quote to drive home the same point: “There is no such thing as a dysfunctional system, because every system is perfectly aligned to achieve the results it currently gets.”
[+] [-] sleazy_b|8 years ago|reply
Honestly, I don't think this is true in the general case. It's certainly true that there are times when deadlines mean code quality is going to suffer, but I think the incidence of this is probably lower than the frequency with which this is used as an excuse.
[+] [-] shortoncash|8 years ago|reply
Now I just put a mental crosshair on the code I want changed and come back to it.
[+] [-] toomanybeersies|8 years ago|reply
At my current job, the quality of the codebase is frankly, quite shit. The unit testing coverage is fine, but the actual quality of the code isn't good. It's not clean, there's a lack of separation of concerns, it's poorly formatted.
Within the first week of starting the job, I had a laundry list of things that we should do to clean up the codebase. However, I've been slowly feeding this list to my manager, rather than just dumping it on him.
[+] [-] kirykl|8 years ago|reply
[+] [-] WhyNotHugo|8 years ago|reply
Only if they have no technical understanding of it. Once they understand how these prevent regressions and provide confidence that stuff works as expected, they start to value it.
It's our job as developers to explain the importance of unit tests, and why they're non-negotiable.
Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).
[+] [-] crdoconnor|8 years ago|reply
People need to stop saying this.
It is certainly possible to do if you are blessed with the right combination of resources, connections and luck, but the whole "put up or shut up mentality" is merely an invocation of the just world fallacy as applied to startups.
The 'worst' professional environment with the worst code base I worked in was run by a authoritarian, although tenacious idiot who lost money consistently for roughly ten years. Some of that was because of how badly he ran things.
Were I blessed with millions in family money like he was I certainly would have "started my own company and made my own rules".
I wasn't. My runway would have been about 10,000x shorter than his.
[+] [-] deepaksurti|8 years ago|reply
True, but in addition to that and I guess more important is to get the mandate to do that from the upper management. Make that mandate a part of your job role. Then whether the team likes it or not, truly respects you or not, an official mandate makes it doable.
The other side is while for very practical reasons teams create all kinds of debt to move forward, we also tend to settle into a working mode using the adage of don't fix if not broken, which can be very expensive if you need to scale or pivot, and this just does not apply to start ups. Most big companies that sink I think is because they have created all sorts of invisible debts and there are people who might have fixed it, but their passion not backed by a mandate never lets it get fixed!
[+] [-] jjtheblunt|8 years ago|reply
[+] [-] fred_is_fred|8 years ago|reply
[1] https://en.wikipedia.org/wiki/The_Ugly_American
[+] [-] eeZah7Ux|8 years ago|reply
This is a symptom of an entrenched workforce and quite a red flag.
Juniors have to prove themselves - other should not: that's what interviews, CVs and experience are for.
[+] [-] purple-again|8 years ago|reply
I’m included gems such as @client = Client.find(1) render json@client. I have dozens of applications in production and mostly gray hair on a good day. If you can’t understand why that code was the right code in the moment, you won’t last long in a results driven environment.
[+] [-] volgo|8 years ago|reply
One of the best advices I've heard about starting a new job is that, shut up for 6 months and just do whatever you're told. Don't make any decisions, don't make any improvements to the company process, and don't argue with people. Be relentlessly curious and ask lots of questions and follow the herd. Learn everythig you can about the process - the pitfalls, who are the strongest and weakest teamates, who are the difficult ones, who are the influential ones, how do they resolve issues.
Once you learn the team's in and out, you have more leg to stand on when influencing decisions. That's when you start suggesting improvements, drawing on the solid experience and trust you've built over the past 6 months
From your story, it's clear you wanted to "do it my way" from the get-go and had no patience or respect for other people's way of doing things. It has nothing to do with like-ability or being right and certainly shows lack of professional experience and judgement. I would certainly not want someone like that on my team, no matter how technically gifted they are because an asshole player like that would derail any software team
[+] [-] mindfulplay|8 years ago|reply
2. If it's one person that you have a problem with, there is a possibility that they are the problem. With two,the probability decreases a bit. With three or more people, the probability goes the other way round - you are probably the problem.
3. Watch 'Jiro dreams of sushi'. The cook took several years before he was allowed to bake a simple cake. It is not just a matter of knowledge, skill or even passion. It's being accustomed to the environment, being useful in some area to the business and making meaningful contribution before other nice things materialize. You still need a lot of skills, passion, talent and work ethic; but those are not the only things.
Kudos to the author in spotting a blindspot. However the tone of the articld still left me wondering if they actually still felt that they were better than the rest or if they realized their limitations.
[+] [-] ianbicking|8 years ago|reply
Teams reach a kind of stable state. New hires may well represent a desire of the firm to change that stable state. The team may not be on board. Sandbagging is not so uncommon.
In this particular story, the review situation is what particularly raised flags for me. Obviously the author did not situate himself well, but I'm not sure he'd have been happy if he had been more adaptable, and that may be on the team and not him.
[+] [-] dasil003|8 years ago|reply
[+] [-] iamcasen|8 years ago|reply
The same is true of anything else. Sometimes the whole team is totally wrong, and their way of doing things is detrimental to the overall goals of the company.
[+] [-] whack|8 years ago|reply
The dirty secret of software development is that the vast majority of it is done very suboptimally. Both in terms of time taken, and the approach taken to solve the problem. A technically skilled engineer is able to spot these shortcomings and improve on them. A politically skilled engineer is able to get buy-in from the rest of the team, in order to make things better. A well functioning organisation is one where the talents of the technically-but-not-politically skilled engineers, are harnessed to their fullest extent. Not as a favor done to that engineer, but because it helps the organisation itself.
From reading the story, it's clear that this team is even less technically competent than others. It's also clear that the author is very technically skilled, but not politically skilled. Unfortunately for him, the organisation isn't highly functional either, likely stemming from its very political team lead.
In such situations, you essentially have one of two choices. Quit and look for a better team. Or stay, accept that you're working with a bunch of dunces, and do the best you can while getting along and collecting your paycheck.
I can relate because I found myself in a similar situation at a previous job, with almost the exact same quarrels and frustrations. Luckily for me, my team lead was much less political and more open to outside suggestions. Because of this, I was able to ram-through what I thought was the right solution, even though I was constantly butting heads with others. Looking back, I realise how lucky I was to have an open-minded non-political team lead, and how rare that actually is.
[+] [-] rusk|8 years ago|reply
There is an old joke that after an interview you should ask 3 questions:
1) can she do the job 2) can you work with her 3) is she an axe murderer
OP can certainly satisfy one of these criteria but even if they’re okay on (3) not meeting (2) is enough for exclusion.
When you find yourself in a toxic (from your perspective) situation you really only have 2 options. If you decide to stay you have to make the best of the situation and get on with people.
It sounds like OP responded to this situation in a way that probably wasn’t in line with this thinking. It’s all well and good being “right” but such accomplishments are marred quite a bit of you’ve annoyed everybody around you in the process.
I’m speaking as somebody who has been through this cycle a few times and finally settled on “getting on with people” vs “being right” after I got the feeling I'd changed job a few too many times.
The transition in this way of thinking was actually quite painful and I made many slip-ups whereupon people would presume I had slipped back to my old ways and couldn’t change - the scorn still rings in my ears. But eventually I did and now I’m one of those effusive hackers that gets on with people, and just drops into tricky situations as they arise. A highly prized resource it would seem going by how my salary responded.
Anyway, as poor old Janis would say “if you can’t be with the one you love, love the one you’re with”. You’ll be happier and your stress levels, blood pressure, social life and even maybe your payslip will reward you for it.
[+] [-] rusk|8 years ago|reply
If it's something that's more immediate usually nature will take its course, but if it doesn't usually a quiet word in a tester's ear can elicit the necessary dialogue.
With regards to other people being "lazy" and "not fulfilling their role" I prefer to take a position of unconditional positive regard and presume that everybody is busy ... my cardinal rule when making big changes is "cause as little extra work for other people as possible".
Keeping people busy is management's responsibility, and if I'm totally going to pull the rug from under something I'll get them on board. If they tell me to leave it alone I leave it alone but I've told them what the issue is and its their problem now, to weigh up and act upon as they see fit.
[+] [-] jmagoon|8 years ago|reply
[+] [-] breitling|8 years ago|reply
Clearly there are some parallels with this story here...to be "popular", he should have gone along with whatever they were doing and slowly try to change things. Not saying that's right or wrong, but hey, that's apparently how you get popular.
[+] [-] wmeredith|8 years ago|reply
[+] [-] peller|8 years ago|reply
One may be all of those things, but without giving the group an opportunity to discover that for themselves, they aren't going to listen to your suggestions. Or one may start by going along with the group, but be abrasive and obnoxious, and no matter how much time they spent with the group, they won't be popular.
[+] [-] thisisit|8 years ago|reply
I remember reading about such a case in Emotional Intelligence by Daniel Goleman. So, curious what is this course?
[+] [-] gaius|8 years ago|reply
Interesting parallels to newcomers to tech/geek culture in general too.
[+] [-] draw_down|8 years ago|reply
[deleted]
[+] [-] lisper|8 years ago|reply
And yet... somehow, it all works, and at the end of the day, they ship their product on time and make a boatload of money. So my visceral reaction to this code is a very strange mixture of horror and respect.
My approach to trying to get this mess fixed is something along the lines of, "You're the boss, and it's your call, but if I were one of your investors I would be very concerned about the long-term maintainability of this system if, God forbid, something were to happen to you."
Does this approach work? Hard to say. No substantive changes have been made. But I haven't gotten fired either.
[+] [-] jstewartmobile|8 years ago|reply
[+] [-] petraeus|8 years ago|reply
Investors do not make fortunes based off the opinions of junior programmers nor on their understanding of the nuances of codebases.
Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor.
My advice to you is the age old adage, put yourself in anothers shoes, go and buy some stocks, etfs, mutual funds what have you and experience the other side of business, let your eyes really be opened before casting judgement on processes you have little understanding of.
[+] [-] gizmo|8 years ago|reply
The author doesn't pick his battles intelligently. His victories are at the expense of his team: instead of making his team members look good he makes them look bad.
[+] [-] jcadam|8 years ago|reply
I probably don't come off as a very nice person (my wife tells me I have a 'death glare' as my neutral face), until you get to know me. I once had a technical lead admit about a year after I had started a job that she had recommended against hiring me and was overruled by her boss. "You seemed like a jerk at the time, but now I realize you're just an introvert."
So, these days I try to paste on a fake smile when I interview, but to no avail. I suppose it might make me look a bit scary -> vacillating between "death glare" and "creepy smile."
Funny, I got (and turned down) a job offer earlier this week that was based solely on a couple of phone interviews. I turned it down because it was a large corporation and seemed very much like a butts-in-seats sort of place (hence, why would they care about culture fit and actually want to meet me in person?)
[+] [-] mnutt|8 years ago|reply
If you even put it on your resume at all, it’s probably one of the easier ones to explain and helped by the fact that your old company re-hired you. “Would you hire this person again if given the chance” is a common reference check question.
[+] [-] wgerard|8 years ago|reply
However: Saying things like "I don't believe you," especially in a public setting, is a great way to come off as a jerk. Once you've decided to call someone a liar, the chance of them getting defensive (and thus poisoning your relationship) increases significantly. You've cornered someone instead of giving them an escape route.
Seems like it was a horrible fit on both sides: The author needs a significantly more accountable company, and the company needs someone with a much more delicate touch.
[+] [-] raldu|8 years ago|reply
There is clearly too much conformism and flawed communication flow in this organization, which is a failure of leadership, and not of somebody who is "actually doing what [he] was paid to do."
The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."
If there is too much conformism, necessary conflict will be avoided and could not be utilized in a healthy way, leading to too much consensus resulting in "one-year old pull requests without review."
In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.
If a competent but "less socially aware" guy moves "too fast," why the team prefers to effectively mob this guy out of the organization, instead of just telling him to slow down?
No such context for constructive feedback, maybe?
This organization is just shooting itself from the foot.
Organizations that need to move fast cannot afford such conformism and dysfunctional communication.
[+] [-] notabee|8 years ago|reply
[+] [-] dasil003|8 years ago|reply
[+] [-] throwawayjava|8 years ago|reply
That's unfair. Most people who are advocating for deference when first joining a team.
And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". Therefore, sitting back and learning the social and technical history that led to the current system is actually the correct place to be in the exploration-exploitation axis during the probationary period.
Both for social reasons, as well as for technical reasons.
That's very different from "put up with office politics". The point is not that you should be likable during the probationary period. The point is that people who go way the hell too far to the "exploitation" side of the axis so quickly are demonstrating poor engineering judgment.
Characterizing that poor judgment as "well I guess I'm just not PC enough" is just icing on the cake.
> The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement."
According to this account.
I submit that it's not even obvious that the engineer in this story was even making the correct engineering decision. Engineers are not scientists:
> In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality.
I think the core problem in this story was wasting a bunch of the company's time arguing over a heuristic that's "good enough" in practice. Both solutions would have been "good enough"; the engineer put his ego above producing value for the company.
> Organizations that need to move fast cannot afford such conformism and dysfunctional communication.
Organizations that need to move fast cannot afford engineers spending time to prove they were correct when going with the established heuristic would've produced a good enough result with far less engineering time involved.
If the story included a thorough cost/benefit analysis showing that the change saved the company $N0,000 with N > (cost of engineering time) then you might have a more cogent argument.
[+] [-] BrentOzar|8 years ago|reply
A: Correct
B: Liked by the team
C: Both
D: Neither correct nor liked
Managers are often okay with incorrect employees because they can be trained easily. (Whether or not management actually trains them, that's another story - but managers like to believe that they could.)
Managers are less okay with employees that everyone actively dislikes because it's way harder to train someone on how to get along with people.
[+] [-] pif|8 years ago|reply
You took the lead on your first week???
Based on your explanation, your co-workers were morons, but you made one of the most outrageous socially-wrecking mistakes that one may do: you showed an unwanted truth to people you were not even acquainted yet. After that, the cleavage is too deep to even try and feel it. I think letting you go was the right decision, the environment was already toxic and it would have taken years before it returning liveable, if ever!
When you join a new group of people, first of all try and adapt yourself to your new environment, and only later try and adapt the environment to you. Otherwise, conflict is inescapable.
[+] [-] commandlinefan|8 years ago|reply
[+] [-] ubermonkey|8 years ago|reply
Being technically competent isn't the only factor in job retention. I feel like this is an especially difficult fact to accept for some of our tribe.
[+] [-] notacoward|8 years ago|reply
It's kind of a motto where I work. Others are surely familiar with it too. I'd also add that baseline levels of sanity, competence, etc. are all part of intent for the purposes of this admonition. It's a good rule, and the OP demonstrates exactly how things can go sideways when it's not followed.
Maybe others didn't recognize the author's good intent, but he clearly didn't recognize theirs either. As far as I can tell, he doesn't think they ever did a single thing right until he came along, which is a huge red flag. I doubt he felt that way when he accepted the job (why would anyone?) so it reeks of post-hoc rationalization. Remember, we're only hearing one side of the story. Chances are, even if he was right on the major points, he has elided how his first ten "you just need to" proposals had to be amended in a collaborative process for which he denies anyone else any credit. Counting the hits, ignoring the misses. If he had assumed instead that other people weren't idiots, that they had reasons for what they'd done and would be amenable to reason, there might have been a better outcome.
P.S. Yes, I know sometimes people really do lack good intent. Some people really are mean, stupid, crazy, etc. Believe me, I've worked with a few and I've called them out on it ... but only once there was incontrovertible evidence of those things. It doesn't change the fact that it's better to start by assuming good intent.
[+] [-] firepoet|8 years ago|reply
My advice to anyone in a similar situation: work on the classes of behavior that are actually problematic, namely blaming, defensiveness, contempt, and stonewalling. Then you can have a healthy argument about ideas.
If a team has problems listening to actual, clear evidence that what you did was correct, they are perhaps at fault here. Of course, if you show contempt, then the right thing for a healthy team to do would be to:
1) Address the contempt head-on, and then 2) Examine the data dispassionately.
It seems this team failed at both.
Probably a good thing to get fired from such a place, though it hurts to not be given an opportunity to move on on your own terms! This particular org appeared to be a pretty bad place to work anyway.
[+] [-] jancsika|8 years ago|reply
Is there an industry where people like me get paid to keep people like the author from self-destructing in a near-perfect job environment?
[+] [-] Dowwie|8 years ago|reply
It's good, but rare, to be irreplaceable.
[+] [-] indigodaddy|8 years ago|reply