25 ms·

Be likeable or get fired

• deleted 9y ago
  [deleted]
• BrentOzar 9y ago
  You can be: 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.
  • iovrthoughtthis 9y ago
    Culturally we also percieve people's personalities as fixed and unchanging. Where as many more of us percieve skills / knowledge as trainable.
  • eadmund 9y ago
    Not just managers, but team-mates as well. People generally would rather be complacent than challenged (I'm no different, of course). And when someone is really wrong about something, it gets really old when he is told so over and over. It's kind of like in a marriage. The man keeps on doing something wrong (forgetting to pay the electricity bill, perhaps) and his wife keeps on pointing it out — and, rather than pay the bill on time, he instead gets angry that she's nagging! Persuading people gently, leading them slowly but surely to realising for themselves that they've been terribly wrong, is extremely difficult and requires a high degree of social skills. Sometimes, it's simply not possible: sometimes a team-mate (or worse, team lead) has so much invested in an incorrect decision that he will never change his mind; the one's only choices are to live with the malfunction or leave the team.
    • hyeomans 9y ago
      100% agree, through the years I've learned that, as you said, it might be impossible to change and what has helped me is to stand in the shoes of the other person knowing how much they've invested. Related: https://en.wikipedia.org/wiki/Sunk_cost https://en.wikipedia.org/wiki/Sunk_cost
    • JustSomeNobody 9y ago
      Sometimes I'm wrong. It's great to have a team that can point out why I was wrong and discuss a fix. But I know that I'm not always wrong, so when a developer is constantly telling me that I am wrong about everything, it's really annoying. Those types of people are only doing that because they have to be the smartest person in the room. Usually, however, they're not. They're just the person who has to be. Everyone else understands that different does not equal wrong.
  • Spooky23 9y ago
    "Liked" isn't the right term IMO. I've worked with plenty of people whom I don't particularly like at a personal level, and would not have a beer with given a choice, yet were able to connect with at a professional level. Honestly, this blog post had a "nails on chalkboard" sound, although it was written by the protagonist from his POV. My guess is that his co-workers would have said that he was a bit of an asshole, and made it clear that he was the "smartest guy" in the room. You can only pull off that bullshit if you are part of the tribe; when you're an outsider, that behavior lights up the organizations' immune response.
    • moate 9y ago
      "You can only pull off that bullshit if you are part of the tribe; when you're an outsider, that behavior lights up the organizations' immune response." This, this, one thousand times this! When I first started with my current job, I had lots of free time, a technical background, and a desire to carve a place for myself. So in the first week I went through the whole website and invoiced where I felt there were some easily fixable UI/UX problems that could make things feel better and possibly get us more clients. Sent that list up the chain of command. Nobody cared. Fast forward a year: I've learned the culture, how to work with the people involved, and I'm being shifted to a more hands on role with the product decision making. I've learned how to work in the system, so now I'm able to expand my sphere of influence.
• xiphias 9y ago
  From the article it seems to me like you're not an asshole (critising work is ok as long as it's comstructive and the focus is on how to improve the code base), which means that the problem was with the team. Don't worry about it, just find a new job.
• firepoet 9y ago
  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.
  • norealidea 9y ago
    While I agree with you, reading this showed and ego coming from the writer, but in his place probably should have handled it better in a new environment. What I was reading felt more skewed towards "I was right and got fired, but made no attempt to communicate sans telling people they were wrong".
  • ebbv 9y ago
    > There is a difference, I think, between healthy and unhealthy conflict. This team was clearly averse to both. It was likely an awful team. I didn't draw that conclusion at all. It didn't sound like he was advocating healthy discussion. He came off to me as being brand new to a team and insisting on his way, while not being open to any explanations of why that either wasn't a priority or wasn't viable at the moment. Walking into a team as a new member and immediately insisting on sweeping changes is never a good idea.
    • iamcasen 9y ago
      The practices the author describes are actually horrible, and objectively bad practices though. Truly, obviously, inescapably bad practices. Do you just go along with it? What do you do? I personally try and avoid places like that like the plague because it will mean my technical skills will vanish with the wind the more time I spend working in such a code base.
• rusk 9y ago
  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.
  • rusk 9y ago
    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.
• mnutt 9y ago
  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.
• _pmf_ 9y ago
  > But I don't like to criticize without showing a better way, so I decided to immediately start fixing the most glaring issues that I had observed during my initial contact with the micro-service I had been working on. Hmm ...
• mirceal 9y ago
  Too long, too much introspection coupled with guessing basically. You don’t just get fired out of the blue - this probably started and ended as a conflict between the new guy and the rest of the team (or key people in the team) Most times this is not one sided, and it’s a combination of a toxic environment with a clueless or arrogant individual.
• endymi0n 9y ago
  My sympathy for the guy, stuff like this sucks deep on a personal level and he should have gravitated towards a higher level team that values his contributions more. That being said, I've worked with my share of brilliant jerks and couldn't say it any better than this Firstround article: http://firstround.com/review/why-firing-brilliant-assholes-is-required-to-build-a-great-engineering-culture/ http://firstround.com/review/why-firing-brilliant-assholes-i... I'm tolerating exactly one brilliant jerk in my team right now, but it's just because he's the rare "selfless brilliant jerk type" ( http://www.brendangregg.com/blog/2017-11-13/brilliant-jerks.html http://www.brendangregg.com/blog/2017-11-13/brilliant-jerks.... ) and he's just so damn productive and such a nice guy from the inside...
  • commandlinefan 9y ago
    Well... one thing about the whole "brilliant jerk" notion. Although I've learned the same lessons as the author the hard way, and am super mr. helpful these days, always treading carefully not to hurt anybody's feelings, I may have been considered a jerk by some in my past. (I'll leave it to others to decide whether I was a brilliant, mostly competent, or completely useless jerk, but my time was always in demand). I've worked with people who were definitely considered brilliant jerks, to the point where they were fired for being brilliant jerks. Yet, invariably, I found those people by far the easiest to get along with. Every time. They knew what they were doing. I didn't have to explain to them that TCP and HTTP were two separate things and yes, if there's no key involved, you're not encrypting something, just obfuscating it. If they asked me to do something, it was something specific and they actually described what they needed done. They provided enough context that it was obvious whether it was done or not. I can't say that about most others - regular jerk, regular nice guy or otherwise.
• wgerard 9y ago
  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.
• gizmo 9y ago
  Win the battle lose the war. 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.
  • JustSomeNobody 9y ago
    This is an excellent point. A lot of times, our personal pathway to success is by clearing the path for someone else to succeed.
  • partycoder 9y ago
    There is a bigger war, though. Other teams, other companies. You want to keep what works, change what doesn't work. If your team doesn't do it, another team elsewhere will. Then, people never stay in the same job forever. If you use your power/team to stay mediocre, you are just acting against your own self interest.
    • snowwrestler 9y ago
      When things aren't working their best, the #1 thing that has to change is the team, not the technology. Change the team and the technology change will happen automatically. Try to change the technology while alienating the team, and the tech changes won't get done or won't stick. One way to change a team is firing/hiring, and I bet many readers' minds probably went there first. But firing and hiring are very expensive, especially in a time-constrained business, because time has a cost. And only a few people have the power to do that. Another way to change a team is to alter or improve the people on the team. The value of influence--the ability to change the minds of people around you--is underrated by a lot of people, especially engineers who spend most of their time in a headspace where things are quantifiable, black and white. A new person coming into a team that builds technology, who wants to change the technology, needs to focus first on changing the team via influence. This is a skill that anyone can learn, but it has to first be a skill they recognize and value. The lowest person on the totem pole can't fire anyone, but they can certainly influence people. In fact, the ability to positively influence the people around you is a key skill for anyone who wants to grow into a leader in their profession.
• breitling 9y ago
  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.
  • peller 9y ago
    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.
    • hn_user2 9y ago
      It doesn't mean anything if you are "right" but nobody will listen to you. To effect any change you have to not only be "right" but also be able to convince others around you of what you are trying to do.
      • jdbernard 9y ago
        This used to be one of the great ways that tech was different. You didn't have to convince people through social means. Often there were purely technical merits that could be objectively proven. And people cared about the code more than "being right." Obviously that's not a blanket statement, but it did used to feel representative of the overall culture. Over the years we've backed away from considering the value of things on their technical merits. I'm not saying we shouldn't be thinking of business value, but you have to admit that's far more subjective. I'm not always sure it's a good thing. I'm convinced that maximizing business value and ignoring technical value is one of the main reasons so much modern software is crap.
• matt4077 9y ago
  The title seems to imply that there’s something wrong with sympathy being a factor. I don’t think there is. Working with people you enjoy being around is probably the single largest factor for my productivity, and ignoring it would be a catastrophe, long-term. There is, however, a certain obligation to try to get along, to help new hires to become part of the group, to overcome all the biases we all have etc. I’ve also not seen too great a tendency to streamline personalities for the sake of “getting along”. Indeed the most fun and productive groups were rather diverse sets of characters, including the stereotypical “asshole genius”. Somehow, they managed to keep insulting peoples’ work yet showing enough self-awareness to make their subjects not feel personally hurt.
• jcadam 9y ago
  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?)
  • oblio 9y ago
    Here's a trick for introverts. During those culture fit interviews, as soon as possible, try to have the interviewer let you speak about something you're passionate about. Few people can speak about things they love with a deadpan face or a frown on their faces. And a smile makes everyone look nicer and friendlier ;) Especially an authentic smile! (Note: Don't go on a half-hour story, though, a few minutes should be enough to lighten the mood.)
    • deleted 9y ago
      [deleted]
    • maxxxxx 9y ago
      Good comment about not going on for half an hour. I have failed interviews by going from introvert mode to super excited mode and going on for way too long. I see that in a lot of engineers. We are just not good at reading social situations.
      • exodust 9y ago
        Think of it like engineering a lightweight anecdote. If efficiency with words is the key, then you know what to do. Now that I'm a bit older than a young eager 20 or 30's something, I'm better at capping my stories before they get boring or repetitive. Leave them wanting more, or at least give them the talking hat back, they probably want it.
• OutsmartDan 9y ago
  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.
  • sleazy_b 9y ago
    "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.
    • Retric 9y ago
      I find the common cause of bad code is changing requirements. If someone is given the choice of a change that takes 1 hour or 1 week it's very hard to stick with clean code. Make a change and then undo it more than once, and it's easy to leave a few if (false) bits hanging around that don't break anything today. Next biggest issue is a changing team. If you don't really understand some bit of code it's often safer to code around it than mess with it.
    • coldtea 9y ago
      If the code works and produces money for the company, no excuse is needed. Perhaps the founder had better things for his time than perfecting some code that was already good enough to get clients/VC money.
• agentgt 9y ago
  There is a well known affect when joining a new group with some studies behind it: https://en.wikipedia.org/wiki/FNG_syndrome https://en.wikipedia.org/wiki/FNG_syndrome Anytime I deal with new employees I am constantly focused on this bias. EDIT and here is more of a general theory/subject on this: https://en.wikipedia.org/wiki/Group_cohesiveness https://en.wikipedia.org/wiki/Group_cohesiveness (a quick read)
• mapcars 9y ago
  Well, one needs to understand that coding and architectural standards are different from company to company. One can't expect the highest quality everywhere. Another thing is how people react to changes, even good ones, can also be different. Just try little by little and observe if it's ok to go full-on or not. After all, by choosing a job, we agree to accept a certain state of things which might go against what we want/used to.
  • xigency 9y ago
    This is maybe the most important point. This developer clearly did not know how muddy the technical stack was at this company when joining. Sure, every organization has different standards, but related to that is what the desired standards are. In this case, it's clear that internally those were the desired standards. I think that raises the issue that during interviews, it's important to reliably find out a) what the state of code is and b) what the real standards are. It would probably be better to work at an organization with no testing that wants complete unit test coverage, than to work somewhere with a test environment that is happier with poor coverage.
• ebbv 9y ago
  I used to be like the author when I was in my 20's. I had to learn some lessons the hard way just like he did here. Take these to heart young know it alls: 1. Things aren't always black and white in terms of right/wrong or better/worse. Things usually have tradeoffs, and what might seem like an obviously worthwhile tradeoff to you might not be to everybody else. 2. You're wrong way more than you think you are. Be more open minded about others' views, and don't take one instance of being right delude you into thinking you're right about everything else. Stay open to being wrong. 3. Be nice! I still have to work on this one. Even if you are 100% factually right, don't be a jerk about it. Don't be insistent that things have to go your way. There's other factors (like time and resources.) It may be unsatisfactory to hear "We don't have the time and resources to do things the Right Way(tm)." But it's reality. Every organization has to deal with that. And yes, being liked by your coworkers is as important or even more than being technically proficient. If I hate working with you, that's probably not something that can be fixed. If you lack technical skills, I can probably teach you. So I will always choose the person who is pleasant to work with over the Ultracoder 3000 who's always complaining and miserable.
• volgo 9y ago
  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
  • 0xcde4c3db 9y ago
    No kidding. As someone who has a good bit of difficulty with social interaction (no diagnosis, but it overlaps with issues that ASD and ADHD people often report), I've failed a likability check or two in my time. I've had conversations where someone seems to be offended or otherwise put off and I have no idea why. But even having those problems, I don't discount other people's opinions and priorities so much that I'd just go in and refactor an existing system without first being pretty clear on who's responsible for it, what problems I'd be solving and risks I'd be creating for them, and that they're okay with it.
  • maxxxxx 9y ago
    "shut up for 6 months and just do whatever you're told. " I like this one. I see a lot of contractors come in and write code that doesn't fit with the rest of the code base. They don't make any attempt to understand why we are doing things a certain way. I know there is plenty room for improvement but first make an effort to understand the current situation and only then make suggestions for improvement.
• dorwi 9y ago
  It's a nice reminder that being technically proficient is not enough. In the end this is a team game, reminding everyone how shitty job they do is not going to help you estabilishing your place there. Also, acting as a leader, when there is no one to lead is pointless. As someone said before me, earn their respect first, and then try to change them.
• kamura 9y ago
  This post resonates deeply with me, explaining exactly how my experience at some points as been working with people. I am still in the early stages of my professional career, so I am nowhere near a stage where I think I am even close to know pretty much anything to the standards that I have mentally set for my self. But I have found the share amount of employees, which just bloat confidence in anything they say, even if it is the wrongest thing in the entire Universe. Always prefer to lower the bar around the quality of code, translating into more problems with future requirements, readability and so on. The reason? Self-preference to bad habits, but also the "no time" excuse, which in some cases might be the appropriate choice, but in others simply translates onto an obvious lack of ambition, but also a mind-blowing lack of respect for the programming art. And I say this knowing that I am nowhere near the level which I want to be and very far away to actually produce code that I can consider to have met the standards of anyone with level of expertise in the same subject.
  • ryanobjc 9y ago
    You are so lucky! You have a huge chance to note the experiences of the author, and _change course_ now before you end up unemployable years down the road! (like the author, who is going to be one of those aging coders who can't seem to get a job) The author clearly seems to know computers, but in general from reading his post, he is a bad engineer. He collaborates poorly, he offers solutions without context, and does dangerous things without even realizing it. (eg: the use of BATCH without consideration for the negatives of such) One thing to realize is you are holding an absolutist view of programming as an immutable art form. Programming computers is an engineering discipline. It exists to serve an external purpose - help people, make money, solve problems in the real world. Like every engineering discipline, it involves a trade off. Marking off your coworkers as "obvious lack of ambition" and "lack of respect" in their efforts based on your own judgement of their coding skill is intensely disrespectful. That's the kind of attitude that is inherently pre-judgemental and is what can get you fired, not hired or just edged out. Having worked with truly intelligent individuals, one thing I have noticed is their endless humility and lack of ego. They are kind, think well of others and endlessly question their own intelligence. The author falls short on every metric.
• pif 9y ago
  > 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.
  • nmeofthestate 9y ago
    >based on your explanation This is an important point. This guy may in fact be annoying to work with (I don't want to pass judgement, but I started to suspect that while reading his post).
    • 0xffff2 9y ago
      This guy is definitely annoying to work with. The question is whether he's also the extremely knowledgeable and competent person he paints himself as and whether his coworkers were the bumbling and ineffective people he paints them as.
• Smushman 9y ago
  One guy on the inside cannot change everything - you are not Batman, and even he couldn't. I am going through this exact same right now too and expecting to be let go any day. Want to start a company? There are two tectonic plates in a job - the culture and the work product (the code in your case, efficient infrastructure in mine). Rarely these plates are aligned and moving together; usually they are not. You can get ground to a pulp hanging out between these plates. On one side you feel your not doing your duty if you don't try to fix some of these things, and on the other side the team, the company, or both may not really 'want' them fixed! If you feel duty bound to improve things like I and some other personalities do - this can make for a very painful situation for you. Try to remember that you can't change people, you can only show them things, and only in your area. Try to scope down your solutions when you have any doubts of their ability to catch on (particularly when it may negatively affect your motivation). Specifically, you did well with your code fix at the start; but it was up to either the team to cheer you on (change from the inside) or the management to champion your cause (change from the outside). Once neither of these things happened you probably should hang back and wait for more opportunities rather than cleaning up more of the mess you saw. Set your expectations properly when you do that - another opportunity may not come for a long time; but thats the safe route. You do deserve better, and I would love to work and probably argue constructively with you. But hopefully misery loves company and you feel a little less lonely knowing you are far from alone.
• whack 9y ago
  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.
  • iamcasen 9y ago
    God same for me. I read this post and thought I had written it myself. I'm a very pleasant person to work with, I will never belittle others or be harsh about anyone as a person. I will absolutely say when code/architecture/system is poorly designed, and I will say why. This should be a good thing in our industry, but unfortunately it's not. If a civil engineer came to a team building a bridge and noticed everyone was building something dangerous, he MUST say something or people will die. Imagine a world where the rest of the team poo poo's him for "not getting along."
• F_J_H 9y ago
  Sad that this happened to the OP - some good coaching would have helped to smooth his transition into the team without raising hackles. >>"But I don't like to criticize without showing a better way, so I decided to immediately start fixing the most glaring issues...that involved quite extensive changes" Is where things probably started to go awry. As soon as I read that, I knew exactly what happened and why. If anyone else faces similar struggles, take 5 minutes to read this fantastic Steve Blank post. Although it is related to selling, it provides great insight on how Engineers, (who win arguments by "being right" and "clearly showing a better way"), can use other tactics to influence and "win over" a team: https://steveblank.com/2009/06/25/convergent-technologies-war-story-1-%E2%80%93-selling-with-sports-scores/ https://steveblank.com/2009/06/25/convergent-technologies-wa...
  • iajrz 9y ago
    A hamfisted approach to team code on centralized repos, I agree with you on seeing the problem. But building a proof-of-concept in my branch is way less invasive. I've bought many a candy bar to people who've proven me wrong. And he seems to have done things by the book (do the work, take the measurements). On the other hand, can't agree more with the coaching - and that's what pains me. Sometimes people in leadership positions aren't as strong in leadership skills as they could be. Nothing is more delightful for me than having someone prove that things that could've taken a month can be done in a week with no sacrifices - means we've low hanging fruit and can devote time to improving _more_ things in the time we've available. Maybe even write pretty documentation or other things that are usually neglected. I must say, though - I've seen that "this is going to take forever!", "this is _SO_ complicated!", and "we'll have to code A LOT for this!" attitude before. So much so, that the very wording makes me suspicious. When I see that in an org - as opposed to "with this timeline, we'd have to change the scope so and so to deliver", or "Let's make sure we achieve what we want", or - basically, there are wordings that match what you'd do were you playing victim, and wordings that match what you'd do if you were a competent person doing their best for the company. > The Steve Blank article Brilliant. I've learned similar from watching my own father _learn_ that :^) I recommend using Monica (monicahq.com) and applying those lessons in all areas of life.
• Tepix 9y ago
  From the article: > This accusation lead to another confrontation where I became aggressive (the guy attacked me personally), which probably was the last drop for them. This leaves a lot of room for interpretation. If he got physically agressive he would be fired on the spot pretty much anywhere.
• ubermonkey 9y ago
  Wow, that was hard to read. The writer really doesn't seem to understand any of the fairly huge missteps he made that led to his dismissal. 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.
• vinceguidry 9y ago
  Software development can get political in ways that individual contributors don't foresee or even cognitively understand. There is often no established metrics for how fast a department is supposed to work. Managers engaged in department building need to manage expectations for how much work is going to get released. Working too fast in these situations can and will cause cohesion problems. In this situation, if you have a fix for something that will save weeks of work, don't take a sniff test of the general atmosphere, and just charge forward guns blazing, you will make yourself an organizational pariah. The easiest way to tell if you're in this situation is to get in a closed door meeting with your middle manager and explain the difference between what people believe about the situation and the actual situation. Maybe even do the work first so you have some solid proof that you're right. Your manager will know the political atmosphere and how to navigate it better than you will. In most cases, he'll give you political cover to implement your fix and because it's coming from on high, you won't get resented for it. Of course, if this starts happening a lot, then you need to have more discussions with that manager about a promotion.
• 11235813213455 9y ago
  I'm often acting like OP, I feel like constructive criticisms, honesty, fighting opinions are great.. But not for everyone apparently
• commandlinefan 9y ago
  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.
  • nybblesio 9y ago
    This. So true, it almost makes me want to cry. Why is our industry such a mess?
    • volkl48 9y ago
      Human nature. While it may be worse in our industry, these issues can be seen in almost any organization, it's just a matter of the degree. For an example from a totally different direction, consider something like "Kitchen Nightmares". People with a failing restaurant, who know it's failing and have gone out and solicited the help of someone who's considered good at both cooking and turning around restaurants. And at least 50% of those people still will resist many of the changes they're asked to make even though they acknowledge that they're failing. They don't really want to change, they want him to make them successful without changing. --------------- That said, I'd suggest these issues are much more common in industries where measuring results is hard and where results aren't an automatic result of work put in. "This thing will improve production on the assembly line". Great, try it on a line and see if output improves. Hard to argue with the results if it does, even if it's just 5%. "This thing will make better code/software". We can argue about this for hours, we can trial it, and unless it's a massive leap forward it's unlikely you'll get such a clear-cut result that a person biased against it/against change will be swayed.
    • cocoablazing 9y ago
      This business requires many to be confronted with complexity at scale. I think these problems are universal but few encounter them due to the distribution of employees in organizational hierarchies.
  • iamcasen 9y ago
• davidhyde 9y ago
  Joining a new team is an exercise in humility. The better you are (or think you are) the more difficult this is. When I start at a new job I never criticize the code because you don't yet know who wrote it. If teammates grumble about the code base I pick parts to praise. This is counter-intuitive because foreign code and practices are almost never appealing. It is far more important to judge the team culture and fit in than demonstrate your technical ability immediately. Unfortunately the author does not seem to have learned his lesson as most of the article is about what he did 'right'. When I interview candidates I attempt to engage them in technical argument where I purposely make some questionable statements. How do they attempt to correct you? Do they leave the door open for their opinion to be incorrect. You can learn a lot about what someone will be like to work with just using this simple technique.
  • wwwater 9y ago
    > When I interview candidates I attempt to engage them in technical argument where I purposely make some questionable statements. How do they attempt to correct you? Do they leave the door open for their opinion to be incorrect. You can learn a lot about what someone will be like to work with just using this simple technique. This is a very good idea! Thank you very much.
• Rotdhizon 9y ago
  This article is really conflicting for me. Their are valid points from both sides of the comment section. Against the writer: Since you were new to the company, of course people are going to be leery of your experience and input. Rampant in IT is the sense that seniority directly equates to skill, no one wants to listen to newer, younger employees. Now I've never worked with programming, I'm from the security sector but the same type of mindsets are in place here. People who have done the work and set up systems absolutely get offended when you critique their work. When experienced devs put time and effort into coding something, they aren't going to tolerate the new kid coming in and saying "This is all wrong, here's 50 minor changes to make it slightly better". >>"But I don't like to criticize without showing a better way, so I decided to immediately start fixing the most glaring issues...that involved quite extensive changes" ^ As others have pointed out, this was a huge factor in why things went the way they did. Although it's not ideal and I despise it, the mantra of "If it ain't broke, don't fix it" rules IT. If you were assigned to work on a security issue, the sole focus should have been on that. Sure you can take notes and document the sloppy surrounding code, but making the decision on your own to start correcting other peoples work will not sit well. It extends to you trying to help other teams as well, you made that decision on your own without trying to consult your own team first. In the end, this job just wasn't for you. It seems like it was filled with complacent, older employees who just wanted to do their job description and nothing more, as shown by new code not getting reviewed. For the writer: You come off as ambitious and confident(maybe too much so). This type of business isn't for you, you'd be much more successful at a startup filled with younger talent where everyone is striving to pump out code. That type of environment would be much more open to things like peer review and code cleanup. If you're going to work in a team, you have to work with the team, not for the team. Don't try an outdo your peers, work with them to achieve a common goal. Ultimately it seems you just drew the short straw on jobs. This is why it's always recommended to have an updated resume. I'd be in the same boat as you if I was a developer. I wouldn't want to wait around for months to gain respect, or have to just accept working with bad code. If something can be improved, why not improve it? Unfortunately that's just how the world is. It might be a bit hard to find a job that completely accepts your proactive nature, but eventually you will.
• indigodaddy 9y ago
  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.
  • gnulinux 9y ago
    This is very true, note that his very first action in the company was to conflict his coworkers' opinion as to how long a fix can take. The author went to that company, after barely checking the code and the team, decided he's the superhero this company has been waiting for years.
• draw_down 9y ago
  You shouldn’t review a PR that’s marked as WIP, because whatever you’re about to critique might change or go away. And there are a couple reasons to make a PR before you want it reviewed. Besides that though, this place sounds bonkers. Who tells developers to slow down?!? And getting defensive about the shitty stuff in the codebase rather than getting excited that it’s finally being fixed... bad news.
• rambossa 9y ago
  > That was a second red-flag for me - I've always worked extremely hard to establish a staging environment which reliably reproduces the production environment, so that great confidence could be had that if the released code passed the unit tests, system tests and some final manual tests in the staging environment, that it would be very unlikely that serious/obvious issues would only happen in production I don't get why this is a red-flag though. Unless everywhere I've worked is highly flawed. Unforeseen production issues are a given, no? Like how do you actually mimic your IaaS?
  • lazyant 9y ago
    I read it as "they test in production" (because they don't have good testing environment similar to prod)
• mindfulplay 9y ago
  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.
  • dasil003 9y ago
    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.
  • ianbicking 9y ago
    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.
• deleted 9y ago
  [deleted]
• emh68 9y ago
  ‘at which point someone complained I was reviewing his PR before it was ready for review (it had WIP in the title)... but I'd always thought that you just don't make a PR before you want someone to have a look at it!! Why would you do that?!’ Oh boy. Concrete thinking is a serious issue.
  • holtalanm 9y ago
    submitting a PR then getting annoyed when someone reviews it is also a serious issue. Don't submit a PR until you are ready for eyes on it. End of story. That is literally the entire point of a PR.
    • watwut 9y ago
      Meh, respect whatever process is in place now. If team does WIP PR, treat them as WIP. If the team never does WIP PR, keep unfinished work on your machine. If you don't like the process, talk to people. However, don't make damm mess with team process. Slightly odd process (and this is a small thing) that is followed is much better then situation where everyone follows different process. This is level of conformity that is absolutely healthy.
    • huehehue 9y ago
      Also want to point out that stacking work on an unreviewed branch isn't a terrific idea, either. I've been asked to review PRs that totally missed the mark, only to find out that there were already a dozen more branches relying on that PR's approval. I'm sure the context is different here, but that's an easy way to set yourself up for redoing weeks of work if you didn't get it right the first time.
    • emh68 9y ago
      People definitely misuse PRs though, and while it's common for engineers to go "well that's their problem, I'M logically correct!", I think that's the wrong approach. One very common thing that I've seen is opening a PR just to double-check the way the PR looks on github. Ideally they mark these PRs with "WIP" either in the title or as a tag. It's implied that those PRs aren't ready for review. If you weren't expecting critiques of your code while you were in the middle of developing it (perhaps you have placeholder code all over the place), it could be jarring and distracting. This goes against the purpose of PRs, but at some point you have to put engineering culture flexibility above strict letter-of-the-law guidelines. If someone didn't pick up on this phenomenon, I'd gently inform them. There would be no need for getting upset... unless they continued doing it in spite of the commonly agreed-upon behavior of the team.
• Mashimo 9y ago
  I'm working on a product with a 10 year old codebase which is .. not always pretty. Gui classes thousands of lines long, UI and logic mixed together. DB with date + minutes after midnight that breaks every year during daylight saving time. Anyhow, we got some new architects. They slowing turn things around, but they first started doing so after a few month. Might help that the worst parts where not implemented by people still working here.
  • iabacu 9y ago
    Sometimes, it can be actually worse if the worst parts were implemented by people who still works there. Because you might need to battle the technical issue AND people being defensive about it.
• whataretensors 9y ago
  This is true. It's even more interesting if you think likability has genetic origins and might not be a choice. Curiously all this gets dropped for superficial differences like skin color when talking about diversity. Of course by taking one of these soul sucking jobs you are lining up to have almost the entirety of your royalties taken from you to begin with.
• everdev 9y ago
  As much as companies are about money and profits, it's also where people spend about half their waking hours, so environment and culture are important. There are many ways to make suggestions and offer feedback that build trust and leave both people feeling better and more connected. Unfortunately in school we focus on getting the right answer, Wich is only half of what needed. Getting to the right answer in a way that makes everyone feel heard and respected is the key. As a developer, it's easy to go into programming more and get critical of the way something has been done, but it's easier on everyone if we switch that part off during human connection and find more understanding and patience and save the critical thinking for actual development or code reviews.
• squozzer 9y ago
  >so... so long and thanks for all the fish. This is the second time in as many days that I've heard this ref, after a 30-year drought. Yesterday's ref was a song by A Perfect Circle.
• WhyNotHugo 9y ago
  TBH, I don't think it's a matter of being "more likeable". This person simply wasn't the right fit for this team, and there's no way around that. His exact behaviour would have been very well received at some of the places I worked and, but poorly received in others. I don't think that putting an effort in "not being oneself" is really the key here. The key here is finding a team that's the right fit.
  • tildedave 9y ago
    I thought this was very well and succinctly put, thank you. Having made many similar mistake to those in the original article, it's obvious to me when looking back at those situations that the real issue was team fit. Individual acts get washed over but fundamentally you need to be compatible with the people you work with.
  • coatmatter 9y ago
    Yep; being likeable doesn't automatically mean being easy or productive to work with and that title possibly indicates the author doesn't understand that aspect yet. It's somewhat common for people who don't like each other to be able to still function as an effective team - all that is required is respect. What respect truly means is a little harder to describe in words - I believe it's best for each individual to find a way to work out what everyone else means when they say respect (paying lip service isn't enough).
• jellicle 9y ago
  This reads like a guy who has "not invented here" syndrome. You know, the guy who starts changing all your code from tabs to spaces or vice versa, and won't play along no matter what. Every person should have the humility to accept that they may not be the best person in the room, that there may be very valid reasons why something is done the way it is, and that "I know better" isn't a magical sudo statement. Here's some questions: 1) Can you see any other human beings from your workplace? 2) Do you have a boss? If the answer to either one is "yes", your job is about getting along with human beings, not about being technically "right" and berating people until they see your glorious correctness.
• jkereako 9y ago
  This reminds me of a quote I read in the 48 Laws of Power: think as you like, but behave as others. This person lacked empathy and sensitivity, but at the end it sounds like he learned from his mistakes.
  • wolfgke 9y ago
    > This person lacked empathy and sensitivity It is hard to empathize with people who work less hard on understanding the programming topics, that occur at work, deeply.
    • Raphmedia 9y ago
      > It is hard to empathize with people who work less hard on understanding the programming topics, that occur at work, deeply. You are describing lack of empathy and sensitivity... Empathy isn't easy. It shouldn't be easy. It is a skill like any other skills and you must consciously train it to be better at it.
• forkerenok 9y ago
  I think he had to give people time and stir things up gradually, if he wasn't happy with their ways and pace. It's quite ironic that author mentioned backpressure (in different context though): people were responding negatively to his pressure, but he kept on.
• qrybam 9y ago
  Perception is everything. At least in the beginning. Eventually, people get to know you, your skills, and your boundaries, but in the beginning it's all first impressions. Be good and fair to the people around you.
• crabasa 9y ago
  From 18 years in tech, through both my own experiences and observation the key is not likeability, it's relationships and empathy. You can build relationships and trust people who don't like. It's more a matter of both parties understanding and empathizing where the other is coming from.
• raldu 9y ago
  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.
  • throwawayjava 9y ago
    > 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.
• deleted 9y ago
  [deleted]
• mmcnl 9y ago
  PRs are not getting reviewed. Solution? More PRs. That doesn't sound like the right solution. Seems to me the author didn't bother to get to know his team at all.
• mattnewton 9y ago
  Life is too short to spend trying to fix a team when you don’t have the power or political clout to do so. He should have left at one-half of this blog post; the story up to that point should be sufficient to convince anyone you want to work for that you had made a simple mistake in judging the opportunity and moved on.
• lisper 9y ago
  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.
  • petraeus 9y ago
    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.
    • throwawayjava 9y ago
      > Investors do not make fortunes based off the opinions of junior programmers nor on their understanding of the nuances of codebases. Investors can lose money on bad code bases. Technical due diligence is a real thing. And getting a third-party opinion on "if your CTO dies, does your business also die?" is EXACTLY the sort of thing that comes up in those conversations. E.g., https://dave.moskovitz.co.nz/2016/08/29/technical-due-diligence-checklist/ https://dave.moskovitz.co.nz/2016/08/29/technical-due-dilige... If a technical audit comes back with "the CTO is the only person who can maintain this code base", and if the code base itself is a major asset the buyer is interested in, that can kill or substantially modify the terms of a deal. > Demonstrating such a lack of awareness and understanding does explain why you are a junior programmer and not an investor. (e: removed silly speculation) > ...go and buy some stocks, etfs, mutual funds This provides zero insight into what technical due diligence looks like or how that plays into the overall decision to purchase or invest in a company?
• deleted 9y ago
  [deleted]
• lmilcin 9y ago
  I found that some environments foster the atmosphere of terror where any person voicing any concern is a threat to others and especially to the person that is responsible for the component being criticized. This is of course completely wrong approach, if people are not free to voice concernes the problems will not be detected and corrected. Over time this inevitably leads to the kind of problems that you have experienced. It is probably good idea to observe and try to understand before you start really interacting within your new environment. It is easy to break some unwritten rule and each company and team has its own, sometimes very surprising ones. In your situation I would probably observe for a bit and note without voicing any concernes. As soon as you start being critical you run the risk of people stopping being honest with you (if they ever were) which will greatly impede your chances of achieving any success. I would try to earn their trust by helping instead of criticizing noticing that in this particular environment, criticizing is not a tactic that will get you anywhere. Help them, let them take some credit. This is probably the best way to make some trust credit which you will need later. Do not criticize ANYTHING unless you are prepared to fix it, yourself. Always highlight there is a difference between bitching and constructive criticism. Under no circumstance direct your criticism at people. They are already feeling unsafe. This is the surest way to make enemies. Do try to talk to them to figure out a way out of the problems but always 1:1.
• pc86 9y ago
  > But from this initial experience, I had learned that things were far from perfect and decided to start pointing out things we needed to improve. Don't ever start pointing out things that need improved two weeks on the job. Even if you're Developer #2, you simply don't have enough background knowledge of the systems and processes in place. The absolute best case scenario is that you're 100% right and come off like a know-it-all ass. Worse and more likely scenarios involve you missing key aspects of the business, or regulation, or something else that everyone is already aware of, and you end up coming off like an incorrect know-it-all ass. > But I don't like to criticize without showing a better way, so I decided to immediately start fixing the most glaring issues that I had observed during my initial contact with the micro-service I had been working on. So now you're getting paid to do work nobody asked you to do... > I broke up the work in separate pull requests and hoped for some help from the guys to make sure the assumptions the tests were making were valid. And taking up other folks' time in the process... > That's when my relationship with the team started to degrade. Not the least bit surprising. > his knowledge of the Java runtime was clearly very limited. This lowered my confidence in his general expertise significantly. I know Cassandra is written in Java but do you need to be a Java expert to also be a Cassandra expert? > I started responding like "This is just not true", "I don't believe you" > I could not imagine a database that does not provide such basic functionality as paginating over the whole data in a table! > if he was so expert, maybe he should be writing the code > that from someone who did not write a single line of code to help us > like any civilized database client would > I was accused of being stubborn and never changing my mind > Well, I AM actually stubborn!! > This accusation lead to another confrontation where I became aggressive There's a saying about right-of-way with regard to driving, something along the lines of "you can be wrong and alive, or right and dead," the point being it's sometimes best to let someone else go when you have the right of way if they're not paying attention, etc. The author seems much more interested in being right than being a good teammate and good employee. The language in this post makes it clear that he was smarter than everyone else, they're all idiots, and their code is garbage. I don't care how smart or technically skilled he is, I'd never want to work in the same building, let alone the same team.
  • smartician 9y ago
    > "This is just not true", "I don't believe you" Those sentences stood out to me as well. Maybe I'm too conflict-averse, but in a professional setting I would rarely use sentences like this. Something like "Are you sure about that? I've read differently. Let's verify/look into that." gets the same message across and everyone saves face. And I'm coming from a cultural background that's known to be very direct and blunt...
• petraeus 9y ago
  I actually took the time to scan the OPs long winded story about his firing, and the TL;DR version is nearly an copy/paste of a story we've heard a thousand times if not more. A junior lone-wolf junior programmer who knows everything and always has the "best" solution unilaterally decides to become the CTO of a company he is unfamiliar with and places so much stress on the existing personnel he is escorted out of the building. Even his closing paragraph demonstrates he has learned very little from this ordeal he orchestrated himself and will most likely hop from job to job until he reaches the level of maturity and the amount of wisdom required to move beyond anything but a junior programming role.
• keredson 9y ago
  in my experience someone claiming you're being defensive is a last-ditch (but effective) effort to shut down a conversation they feel they're losing. it's impossible to prove you're not being defensive (and if you try you only prove them right), or you give up making your (prob. legitimate) point. either way it's a chicken-shit ad hominem attack.
• chvid 9y ago
  Maybe it is just that “being likeable” correlates to “working well with other people” ...
  • coatmatter 9y ago
    I don't think there's really any correlation and believe the OP doesn't quite grasp that[1], based on the various work environments I've seen. [I replied just before on this point at https://news.ycombinator.com/item?id=16887247 https://news.ycombinator.com/item?id=16887247 ] [1] There are various things he could do to improve his "cohesiveness" with team members, without needing to modify likeability. Ideally though, being both likeable and a "team player" would be best but that is more difficult to achieve in the short term than simply getting on with the rest of the crew. Likeability means being able to join in on the after work drinks fun. It has little to do with being able to help others stay productive at work.
• asdf1234tx 9y ago
  If a sizable company has to pick either 1) the existing dev team that is semi-functional and sort of handles the load, or 2) a new, highly experienced and bright individual that has personality issues... I think the choice is clear.
• PeterStuer 9y ago
  I get where you are coming from: you meet a team that for whatever reason is working on a level below your expectation and you want to 'help out', lifting them up. So far so good and your intentions are excellent. Problem seems to be your people skills are not up to your tech skills. You need to 'seduce' people and coach them if you want to lead. Your actions seems to have the predicable effect of alienating them and making them feel bad. A good lead/manager knows that you do not 'lead by example', ou lead by getting the people 'want', even 'like' to do the things you want them to do. I'm very sympathetic to your cause, but to be very honest, from the way you wrote this up, I'm not sure you realy did learn that much.
• phibz 9y ago
  A clear description of what happens when you fail to recognize the unspoken social rules of the group. Ive done this before and paid dearly for it. The team doesnt like being told they're incompetent, lazy, exaggerating, or cutting corners. Doing a grossly better job than the rest of the team without gaining their respect first will only cause them to turn on you. Many people are petty and selfish. When I tried this I ended up becoming the scapegoat. Its not a good place to be. If you're in a situation where you are vastly more talented than the team, do yourself a favor and socialize yourself more. Learn how to recognize how your actions impact others and what their impression of you is. Hold back at first and work on being reliable and trustworthy. Then once you have their respect make criticisms. The alternative is to 1. work alone or 2. work with people at your level.
• jancsika 9y ago
  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?
  • Dowwie 9y ago
    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. It's good, but rare, to be irreplaceable.
    • jancsika 9y ago
      No, I'm talking about consulting for the employee as a kind of ethical Machiavellian. Otherwise the interests don't align. It may just be the examples this author gave that made me think of this. An initial temporary team where everyone is clearly less skilled than you are? Dear lord, feed them the answers so that they get credit for fixing the security issue. Everyone will then sing the praises of working with such a team player. Work closely and non-combatively with the tech-lead to get a full picture of their knowledge and level of defensiveness. Then stay out of the tech-lead's way while you slowly begin building up a robust testing system. Make sure each pull request is short and easy to read. Space them out so you don't make a pile of work for your colleagues. Pretty soon you'll have a bunch of allies, probably including the tech-lead. Or if the tech-lead is still defensive, you'll have a big, fortified wall of unit tests between the two of you. They'll be forced to argue with failed tests instead of with you directly, which is one of the few (and perhaps one of the only) benefits of technological progress.
      • Dowwie 9y ago
        Employee-level strategy consulting?
• notacoward 9y ago
  Assume good intent. 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.
• codesternews 9y ago
  Read this but I think OP communication style is very bad and he might not be good player. Read this blog also but can not go half the page. https://sites.google.com/a/athaydes.com/renato-athaydes/posts/stopversioninglibraries https://sites.google.com/a/athaydes.com/renato-athaydes/post...
• kaizendad 9y ago
  This illustrates something that many people in many disciplines, definitely including developers, do wrong in interviews: it's not just you interviewing with the company, it's the company interviewing with you. Just as you're asked probing questions about your technical skills, ask meaningful questions about the company's technical practices. Don't just let them interview you for fit, try and determine if they'd fit with you. It's legitimate to get a good offer and say "no, this is a place I wouldn't like to be." OP describes the tech stack of the company as interesting, which is great, but things like "PRs stay open for long periods with no review" and "extensive review is required before many changes" are things that can be learned by an inquisitive interviewee. And, as others have pointed out, gain respect before you try to make dramatic changes. Unless you're hired to make drastic change, your job is probably not to make drastic change. Especially if you lack domain knowledge (this was OP's first step into payments -- a technical area with complex business/legal requirements). Especially if you're more junior and haven't been around the block enough times to get a nose for what thins are more risky. 6 months is a long evaluation time, but a short time to get comfortable with a new codebase and stack, it's good to provide positive feedback but it's also easy to not be able to see _why_ things are they way they are, early on as one learns about a codebase. Sometimes things are crap because bad decisions, sometimes things are crap because tech debt... and sometimes things that look like crap actualy aren't, see https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-....
• ap3 9y ago
  >I noticed that the tech-lead was quite upset every time I criticized something Why was he criticizing anything at all?
• Skunkleton 9y ago
  I notice that this write up doesn't really touch on any way you might be responsible for this situation. The reality is that the only thing it this world you control is yourself. Other people have different conflicting priorities, and it is up to you to get them on your side. You failed at that. I would say you should take a lesson away from this experience and place more value in relationship building in your future endeavors. Technical capability cannot stand alone.
• deleted 9y ago
  [deleted]
• tjpaudio 9y ago
  Smart people would love working with a guy like you.
• marshray 9y ago
  > clearly he had been involved personally in most of the things I was criticizing: code of poor quality with no validation of inputs, lots of partially finished modifications (see the lava flow anti-pattern), lack of unit tests, obvious differences between production and staging environments, developers releasing from their own machines rather than the CI server... things that, in my opinion, would be irresponsible to ignore. Funny how people never seem to be as grateful as you'd think for this valuable service.
  • iamcasen 9y ago
    Right? I would be so happy to hire someone smarter than me who can teach me how to be better. Sure if someone was telling me my code was shitty, but their solutions weren't any better or smarter, I would get pissed. I suppose some people aren't smart enough to know when they are wrong?
    • marshray 9y ago
      Seems like 'smart' is unrelated to the ability to give or receive feedback, or maybe even inversely correlated. Another aspect of this: Say person B is smarter than person A, and A realizes this. Now person C, who is smarter than person B, joins the team. A can usually tell that C is smarter than B, but he can't realistically judge by how much because both B and C are playing above his level. A consequence of this that when C joins the team, the working relationship with B will usually be established without issues. But A is likely to feel his own status is being disrupted because his uncertain perception of the relationship between B and C is going to challenge the status quo he had worked out with B. When A observes spirited discussion between B and C, A may have trouble recognizing healthy debate on the merits and may erroneously perceive it as some type of interpersonal conflict.
• Raphmedia 9y ago
  How is this surprising to anyone? If you are a pain to work with, you will get fired. End of the story. Especially after a mere 5 months. You should be in seduction mode that early on. Trying to rock the boat that people have been riding for years will simply make you unlikable.
• zpatel 9y ago
  Most of these issues are due to bad mgr/team lead.
• WontLastLong 9y ago
  High School-driven Development
• watwut 9y ago
  It strikes me that the author does not know what "likeable" means. As I read the way conflicts were handled, the issues seems to be much deeper then just lack of likability. There are unlikeable people who can handle disagreements better, notably without yelling "I don't trust you" on everything collegue says basically because he was wrong in the past. Even if the team was toxic on itself, the communication was clearly completely failing and further cooperation was impossible. Unless he is able to replace whole team by himself, he has to go. That situation can arise without the person to leave being bad or unlikeable, sometimes people are just incompatible. However, the way he wants to frame the issue as "likability" as if the problems were caused by him not smiling enough over beer and the way he puts emphasis on likability as if it would be something bad makes me thing he was indeed part of problem. And not just because he was unlikeable - because he was unable to function in environment where people disagree with him.
• kazinator 9y ago
  > The list of things I was told I should improve on included listening more to other people and accepting their opinions Right, accept opinions rather than researched facts substantiated with numeric data? That environment is really not worth fitting into.
• vbezhenar 9y ago
  That's what happens when you put 10x developer with few 1x and -0.5x ones.
• CodeWriter23 9y ago
  My feedback for the author, you assumed the culture of the company was a meritocracy. I certainly don't fault you for your assumption, it is a common structure in an engineering organization. Your first clue was with that first security bug and people losing their shit over solving a simple problem. That was your chance to challenge your preconceived notions and start to learn about the company's culture. Can't fault you for that either, it's easy for me to critique your choices with the benefit of 20/20 hindsight. But going forward, something to think about. I recently walked away from a good engagement at a "Technology" company. I was the only technology person there. As much as I worked to properly set expectations, I had no idea about their bizarre and unspoken expectations. I should have spent more time investigating the culture of the company. My take away is, don't do work for a technology company that doesn't have technology people.
• beavisthegenius 9y ago
  You seem like a know-it-all asshole. Not once did you ask permission to change the processes of the organization of which you were on probation. Imagine if someone came to your house and changed the furniture layout. Then imagine if that person told you they changed it because that's how they have the furniture in their house and it's so much better. That's you.
• toddlerme 9y ago
  Like WTF, it's clearly your mistake you didn't invest time in understanding people you work with. It doesn't matter where you work, it's universal that even if you are a superstar work on the right problems, and before that influence people in a nice way that this is the problem worth doing. Checkout "First 90 days" book you will know what I am saying.
• tom-_- 9y ago
  I agree with the author that he comes off as unlikeable... But he probably got fired for his lack of professionalism, poor communication skills, toxic fingerpointing, and a lot of other issues he probably left out of his one sided rant.
• karmakaze 9y ago
  I've been through similar, though less extreme journeys. My finding is that it's not about likability. Some people fly under the radar doing practically nothing at these same companies. The key thing is making people uncomfortable. This is what is not tolerated. If you re-read the article with that in mind everything makes sense. It doesn't matter if you're ultimately correct if you made everyone else uncomfortable beforehand. As others have said here, the important thing is to see how things run and introduce changes at a comfortable rate. After a number of successes, the team will be eager to try more. I too can be confrontational in the face of an obviously better solution and have noticed that there's a break-in period. Knowing this, I do still try to push the envelope a bit. If the company is not fast paced, there might not be much left to learn after a couple years. It also always feels good to leave the system in a much better state than when you found it.
• vermooten 9y ago
  All I see here is: I I did this. I did that. Not much mention of the team as whole. Author tells us he's cleverer than the team, and how weird! they don't like it. I hope the lesson learned is to put your ego to one side when working in a team.
• rayascott 9y ago
  You need to very weary of people, especially someone who is your direct superior, telling you to slow down. I was in this situation, but luckily used it to my advantage when the time came to leave. They can easily turn around and throw it back in your face, which is what happened to me. Some have suggested waiting 6 months before rocking the boat, but in my experiences, they don’t take kindly to being outperformed, especially when it’s a subordinate. Just quietly leave, and don’t look back. Some situations/companies just aren’t worth working and fighting for.
• BuckRogers 9y ago
  I blame the manager at the company. Whoever was in charge of that development group, and every personnel manager above him. Everyone thinks because it's not a skill you can test for, that anyone can manage. It's not true. It should be viewed as a profession (emphasis on being a professional in the segment) no different from any other. Teaching is often treated the same way. Requiring intensive study, and expertise in many aspects including psychology. Simply because anyone can stand in front of a classroom, everyone thinks they can be educators. There's authors of programming books where someone who knows nothing about the profession of education, is trying to educate and it shows. The manager should have had the awareness (and care), to sit down the author and explain to him you can't go 0 to 100 in a new organization on day one. You have to build credibility, slowly. Over time you'll make a bigger impact, after you've gained the respect of your peers. Instead, they just allowed this to continue and grow. Coming in as a new guy to a pond trying to make the biggest splash is going to gain you resentment, in most places at least. That's just a psychological reality, whether it makes logical sense to the author or not. I think he understands all of this now. I don't blame him, or his coworkers that he addressed. I think he still has a lesson to learn, that the manager of these folks failed miserably, as most do. That's who should be fired along with their superiors. Management is almost always at fault, and very rarely gets the blame they've afforded themselves.
• iamNumber4 9y ago
  I have found myself in a similar situation. The caveat though is that when hired in I was the replacement for the individual everyone liked. So from day 0, I was disliked. This, put me behind the eight ball with not ever having even the slightest chance to ever get to share my knowledge and experience to anyone. I found myself labeled with having a communication problem, due to my other coworkers gossip and hearsay spread behind my back. The truth of the matter, is even if you are more technologically ahead, on par or behind you counterparts in a company you are screwed when you are not liked. There are only a handful of people I have met that are truly honest, with themselves and others. In which leaves everyone else never being capable of accepting new or different ideas, or to the point any type of criticism because they honestly can not do a self reflection. People are more likely to believe in lies, than the truth. If you find yourself not being liked, regardless of the reason you became not liked it is time to go. Be it on day one, or day 999+ If you find your suggestions, comments, criticism, are not received, do not argue with idiots and try win your case with a follow up. If they were not receptive with a feel-felt, or pathos,ethos,logos forms of communication then your going through and exercise of futility. My suggestion for anyone before even thinking of accepting a new position, during the interview ask the following, 1.why is the position open? Growth? Replacement of a but in a seat? If the later; ask was it a resignation or a termination. 2. Ask could I have or see a employee handbook? You can gleam a lot about company culture just by reading. Red flags on things like dress code restrictions (when the position my not ever be public facing). Ie a long exhausting list of can not wear. Unfair things like banning shorts, but not banning skirts. Dress code should be just stated by job role, business professional, business casual, relaxed business casual, casual. Look for phrases/wordings that might lend towards management deciding to not deal flexibly per employee, as that the management/leadership has taken a stance that a past employee ruined it for everyone style. Look for anything that will make you uncomfortable working there. 3. Ask for their SDLC documentation/process/methodology, coding style guidelines, and the technology stack they use? If the can’t produce or speak in detail or are vague on details. another red flag, that they might be cowboy coding, silo building, bus factor of one per process, etc... you want to make sure you are not walking into a environment with a nightmare scenario where it is a one to one of a single dev to a project and only that dev touches/knows anything about it. As that there is typically resource constraints, poor to no time allocation for code revise,testing, documentation. As well a the technical debt/corner cutting that goes along with not having good project/sdlc management practices. 4. What is the process for changing the any of the current sdlc, methodology,practices, guidelines,etc...? Explain that you’ll be the fng (freaking new guy/gal) and that you will be bringing your knowledge in, as well as absorbing the new to you sdlc,process,yadda yadda and you want to understand how new and possibly different ways of doing things (innovation) is incorporated. You are trying to spot what the parent article fell into, by avoiding becoming the unliked team member. You also want to know if the think the word “standard” means etched in stone, never changing. Standards do change, and are revised. I have never seen a standard that does not have a revision number. 5. Blantently ask; what is your stance on open source software? Followed up with what is your take on Microsoft moving to open source and being a Linux foundation member? You want to make sure you know if they are current in the tech news and events. You want to make sure they are not using dead technology stacks, or SSIS for things beyond it’s intention,or have drank the MS kool-aid from 10-20 years ago and missed the memo that they were wrong about Linux being a cancer. Your also trying to spot the I got a tech job mindset, I know only XYZ and have lost the ability to learn and stay up to date with current trends in the industry. IE there is no such job title as database admin, database administration is a hat/role the devOps, software engineers wear when needed. You do not want to find yourself having to use ssis for application development when it is a database management tool, or having to maintain sql stored procedures that on average 5000~ lines long because they only learned t-sql. You are trying to spot if the company is a right tools for the right job, or we spend 200,000 on a hammer so everything is hit with the hammer. Final thoughts; to avoid the problems I once encountered as well as what the parent post went through. Walk-in to any interview you get with the mindset of “You are interviewing them, they are not interviewing you.” Go in with good questions about the company, culture like I suggested above to see if they are a good fit for you and the working conditions you want to work or work best under. Be honest, be humble, don’t bullshit, and it’s ok to say I don’t know I would have to research and learn. End of the day, If the answer seems like a no, then it’s a no, don’t waste your or their time.