Be likeable or get fired

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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

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.

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.

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

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

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-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.... ) and he's just so damn productive and such a nice guy from the inside...

This person lacked empathy and sensitivity, but at the end it sounds like he learned from his mistakes.

Oh boy. Concrete thinking is a serious issue.

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?

Funny how people never seem to be as grateful as you'd think for this valuable service.

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.

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.

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.

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.

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.

Most times this is not one sided, and it’s a combination of a toxic environment with a clueless or arrogant individual.

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.

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.

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.

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.

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.

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.

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

(a quick read)

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.

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.

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.

either way it's a chicken-shit ad hominem attack.

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.

It's quite ironic that author mentioned backpressure (in different context though): people were responding negatively to his pressure, but he kept on.

Right, accept opinions rather than researched facts substantiated with numeric data?

That environment is really not worth fitting into.

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.

Hmm ...

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.

Why was he criticizing anything at all?

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.

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.

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.

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.

That's you.

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.