
Be likeable or get fired - gnulinux
https://sites.google.com/a/athaydes.com/renato-athaydes/posts/belikeableorgetfired
======
OutsmartDan
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.

~~~
shortoncash
Your #1 is so true. The lesson I learned was that the guy who was there before
me almost always developed what he did under the gun and took on technical
debt to make it happen.

Now I just put a mental crosshair on the code I want changed and come back to
it.

~~~
0xdeadbeefbabe
But "technical debt" may also means he didn't do it in your preferred way.
This double meaning really bothers me. It's like technical debt.

~~~
hinkley
I’ve become more aware (again?) lately of the differences between ugly code
and debtful code.

When hunting down a bug in bad code every method you read becomes a honey
trap. It could be here, so you have to stop and grok this messy pile and that
mental gymnastics removes parts of the todo list from your working memory. You
pingpng around and when you find the problem you can’t remember why you were
looking for it.

Then there’s code where you say “ugh”, take a breath and keep going.

If the smell doesn’t rise to the point of potential confusion about the
purpose or goals of the code, if it’s a small inefficiency you can’t (yet)
spot in the flame charts, then move on to bigger issues.

That said, I’ve paired to debug with people who defend their bad variable
naming choices and the source of their problem was that their own code (and
bad naming) confused them. You make them rename and they see the problem
immediately.

~~~
Terr_
The idiom that always comes to mind for me is "good fences make good
neighbors."

In the long run ugly _lines_ of code are so much better than a broken
architecture or too much coupling.

~~~
hinkley
True. If the blast radius is small it only matters if you see the same three
lines of code in twenty places.

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

~~~
falcolas
> shut up for 6 months and just do whatever you're told

I've found it better if I don't shut up, I tend to ask a lot of questions. I
still do what I'm told (that's what I'm getting paid for, ultimately), but the
chance to ask questions is one that shouldn't be passed up.

The trick is that you can't just ask questions as a way to enforce your own
will, "Why aren't we using Vault again?", but to genuinely try and understand
what's going on. "What's our configuration management strategy?" "What lead to
us using X?"

And, ultimately, every company is kind of fucked up. Each company is fucked up
in a slightly different way. Accept this as your starting point, try and
figure out why it's fucked up (your first 6 months), and then try and fix it
by working with your co-workers (who, despite working at a kind of fucked up
company are probably at or above the median for human intelligence).

~~~
SketchySeaBeast
> The trick is that you can't just ask questions as a way to enforce your own
> will, "Why aren't we using Vault again?", but to genuinely try and
> understand what's going on. "What's our configuration management strategy?"
> "What lead to us using X?"

Absolutely. Ask questions, all the questions. Just be smart about it. There
will be time later to discuss these things, and the company will have reasons.
If the reasons are ones you can't live with, get out, but you're not in a
position to affect real change at this point. But for me when a junior dev is
asking questions, it tells me they are actually invested.

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

~~~
iamcasen
#2 is just not true. If you're in a room full of klansmen who are all going on
about how whites are the superior race, and you disagree. Are you the problem?
NO!

The same is true of anything else. Sometimes the whole team is totally wrong,
and their way of doing things is detrimental to the overall goals of the
company.

~~~
erikpukinskis
> If you're in a room full of klansmen who are all going on about how whites
> are the superior race, and you disagree. Are you the problem? NO!

Well, yes actually, you are. By what mechanism does a group of clansmen become
one notch less destructive? Certainly not by having newcomers tell them non-
whites are equal.

They become less harmful by A) feeling like they have the institutional
support to take care of their own, so they have less need to lash out, B)
having safe, passive exposure to The Other, and C) having people they trust
question their worst ideas.

If you’re not making some similar constructive move, then yes: you’re part of
the problem.

Notice that we’re not saying you’re _wrong_. Of course speaking out against
white supremacy is _right_ , that’s a separate question from whether it’s
problem or solution.

It’s easy to be correct while contributing nothing to solving a problem.

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

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

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

------
lisper
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
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
_> 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-
dilige...](https://dave.moskovitz.co.nz/2016/08/29/technical-due-diligence-
checklist/)

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?

~~~
lisper
You both (@patreus, @throwawayjava) might want to take a quick look at my
profile before you start speculating about my financial situation.

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

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

~~~
xvilka
If you think in terms of pure performance - social interactions, adoption just
take too much brainpower, energy and time. If the management is smart, hiring
the people who lack (and do not spend the time to that) those social
interaction skills can improve the team performance to new heights. What is
tricky in that case - the synchronization of the tasks and progress in the
team, but this can be done externally by the manager and software.

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

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

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

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

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

~~~
dasil003
It's not Dilbert-style because there's no conclusive evidence of incompetence.
When you are new, you should be giving people the benefit of the doubt, and
tread lightly. Raise these concerns privately and gauge the situation. After a
few months it will become apparent if the place is truly dysfunctional, in
which case you would need to have left on your own.

~~~
iamcasen
The author states he stuck it out for 6 months.

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

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

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

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

------
commandlinefan
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
This. So true, it almost makes me want to cry. Why is our industry such a
mess?

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

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

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

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

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

------
jancsika
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
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
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
Employee-level strategy consulting?

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

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

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

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

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

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

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

------
codesternews
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/post...](https://sites.google.com/a/athaydes.com/renato-
athaydes/posts/stopversioninglibraries)

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

------
kaizendad
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-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/).

------
F_J_H
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-
wa...](https://steveblank.com/2009/06/25/convergent-technologies-war-
story-1-%E2%80%93-selling-with-sports-scores/)

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

------
endymi0n
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-i...](http://firstround.com/review/why-firing-brilliant-assholes-is-
required-to-build-a-great-engineering-culture/)

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....](http://www.brendangregg.com/blog/2017-11-13/brilliant-jerks.html) )
and he's just so damn productive and such a nice guy from the inside...

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

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

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

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

------
rambossa
> 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
I read it as "they test in production" (because they don't have good testing
environment similar to prod)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
chvid
Maybe it is just that “being likeable” correlates to “working well with other
people” ...

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

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

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

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

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

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

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

~~~
coatmatter
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).

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

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

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

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

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

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

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

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

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

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

------
pc86
> _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

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

------
ap3
>I noticed that the tech-lead was quite upset every time I criticized
something

Why was he criticizing anything at all?

------
vbezhenar
That's what happens when you put 10x developer with few 1x and -0.5x ones.

------
zpatel
Most of these issues are due to bad mgr/team lead.

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

------
tjpaudio
Smart people would love working with a guy like you.

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

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

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

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

------
WontLastLong
High School-driven Development

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

