
Ask HN: What makes you not want to work with a developer? - arduinomancer
A big one for me is otherwise smart people who immediately start bashing&#x2F;complaining about a language&#x2F;framework that they just learned or aren&#x27;t familiar with. A lot of times they make mistakes due to not knowing it well and end up putting the blame on the language&#x2F;framework.<p>I once worked for a small startup doing React development. One day we hired a new developer who came from an Angular shop. Literally on day one he was questioning why we weren&#x27;t using Angular and suggesting that it might be easier to just rewrite from scratch. This guy complained for the next couple weeks and was super bitter towards using React despite the fact that most of his problems were caused by not understanding React well enough.<p>I guess it boils down to: just because you&#x27;re used to something doesn&#x27;t mean its better.
======
wrestlerman
A lot of things, my experience is based on working in startups: 1\. Suggesting
silly changes in CR - instead of A you could have used B. So what? I used A,
let's keep it that way, time is money. 2\. Long discussions in CR 3\. Too much
thinking like a programmer. I'm not coding, because I love it(although I like
it), I'm coding, because business needs it... 4\. Asking for estimates, when
we both know that estimates in this situation are impossible to predict. 5\.
Shitty written tickets. I don't know the app well enough yet, so one sentence
tickets won't help me much. 6\. Too much obsession over some technology.
Everything has some good and bad sides, so stop selling it, especially when no
one is paying you to do that. 7\. Also, I dislike when you can't get a simple
answer to your question, but you get funny looks that you don't know the
answer yet.

~~~
JoeAltmaier
Oh yes, so often the CR process becomes a hassle. Somebody positions
themselves at the door as some sort of guard, and harasses everybody going
through. So often just to feel like they're the boss or something.

My son just quit a startup because that had become epidemic. Couldn't get
emergency code committed; couldn't meet (artificial) deadlines for demos and
shows; every choice yammered over for esoteric reasons.

I suggest to everyone: when you make a comment in CR, also approve the commit.
Trust the engineer on the other end to do what is necessary and responsible.
If that become a problem, address it then. It seems like the minimum in
professional respect.

~~~
UK-Al05
I don't understand why people hate CR.

You're a professional you should be able to defend your code, and explain your
reasoning. If you can't, you need to change it, and you'll improve at the same
time.

I mean most changes in code review only take 5 minutes to rectify, so I often
don't buy the time argument.

If you getting bit architectural change problems in your code review, you
obviously didn't collaborate with the team very well... People should roughly
know what your approach is before the CR even arrives at their door

~~~
wrestlerman
I do think that code changes take more than 5 minutes, why? As a person, who
pushed the code: 1\. I have to read the comments 2\. Decide if they are
right/it's worth a hassle 3\. Sometimes you have to reach out to the author of
the comment to clarify some things. 4\. Change your branch 5\. Change your
(thinking) context 6\. Apply stuff 7\. Push stuff 8\. Notify the person that
it's done. Many times it's more than 5mins, more like 10/15mins+

I don't hate CR. Someone below explained it better than me, that different
people see the code differently. And you should respect that someone wrote it
that way and not try to force your way upon them.

> If you getting bit architectural change problems in your code review, you
> obviously didn't collaborate with the team very well... People should
> roughly know what your approach is before the CR even arrives at their door

I agree with it a lot. I think that would solve a lot of problems, but not
necessarily the small ones.

------
Someone1234
I think complaining about new stuff is part of some people's "process."

Meaning they hate/complain, work through their frustration, and once they're
quiet they're also happy. I think it is much more common than people realize,
many just don't leave their comfort zones.

There is a difference however between being internally frustrated and hating
the [new thing] and being toxic to everyone else. Shows immaturity, and can
often be mitigated by having a polite sit-down and discussing it.

Reminds me of the expression: "You can only change yourself no one else."
Which would have me consider what can I do as a coworker to help this new
employee fit in and to generate less friction. Not because you caused it, but
because you may have the power to mitigate it.

------
Tangokat
From a PM perspective:

1) Developers who don't challenge mine or customer decisions and then complain
afterwards that what we did was stupid and he had known better all along.

2) Related: Developers who answer every question with "no" or "that's
impossible" even though with a slight variation it would be possible or
attaining the goal would be possible in another way he knows about.

~~~
tomlagier
I see 1) quite a bit, and notice that I'm guilty of it as well. I think it
applies copiously to both product and code decisions and I always wonder why
that is.

I think it fundamentally boils down to insecurity - only by convincing
yourself that your decisions are the correct ones, even if it's given the
generous advantage of hindsight, can you be assured that you're as valuable as
the people who made the initial ones.

------
dare0505
I had this issue with a developer once: We were at a hackaton, and I made a
quick-and-dirty feature (we had less than 6 hours left). The other developer
on our team got pissed because the code "sucked" and spend a full hour
refactoring it...

While this is an extreme, I think every developer is a perfectionist in one
area or another. This can be a disadvantage when you're working in highly
unpredictable environments (read: business) and where a simple quick-and-dirty
MVP will do the job.

So their tendency to be a perfectionist (in situations where this is NOT the
optimal mindset) is my biggest struggle when working with developers.

~~~
mooreds
I find there's a spectrum of developers, from the

* must be perfect

to

* the code is ugly and works. Ship it.

I find that there's a good tension between the two, but that context is really
important. Certainly in the hackathon situation the refactor seems like a
foolish choice.

------
cbanek
Developers who make lots of broken things, then never fix or maintain them,
always wanting to take the new interesting thing and make a general mess of
it, while other people are cleaning up their previous messes. Many times these
developers feel that testing their own code, or fixing their own bugs or doing
certain things are "below" them.

------
AnimalMuppet
Bad personal hygiene.

Toxic attitude, _especially_ if they try to infect me with it.

Too loud/talkative. If I'm in a cube farm next to you, and you're loud enough
to interrupt my concentration, and it happens all the time, I'm not going to
be able to be very productive.

On the other hand, too _little_ communication is also a problem. If I need
information from a coworker, they need to be forthcoming with that
information, in a reasonably timely fashion, in a reasonably clear way.

------
sergiotapia
\- Vocal fry - It grates on me so much it's hard to concentrate.

\- Bashing the existing codebase immediately. You should at least have enough
time to discover why things were done a certain way before trying to suggest
improvements.

\- Adding significant changes without consulting ANYONE. One time this guys
was brought on and decided all by himself to convert everything to Typescript
and dockerize the app. Major red flag.

\- Being offended at code reviews.

\- Bad hygiene. If you smell like ass, please don't come into the office.

\- When they assume too much prior knowledge and don't explain things
explicitly. Like drawing blood from a god damn stone. Very frustrating. You
don't want this person to be in charge of onboarding you.

~~~
erulabs
While I agree with all of these, one employee _ought_ to be able to add
typescript incrementally, or write a Dockerfile... Those are pretty straight-
forward, incremental changes. I've seen entire organizations sit and bite
their nails when someone says "Hey, mind if I write a Dockerfile for this
app?". Same thing with types - while I regularly get into debates about
typescript versus flowtype - I very rarely add a type-comment (still valid
JS!) without a lot of hand-wringing over "maybe one day we'll all sit down and
do this RIGHT... until then, no progress on this, okay?".

~~~
gnahckire
I also agree w/ you on this one.

I'd like OP to expand on why that's a red flag. Dockerization and using
TypeScript seem pretty straightforward and logical additions to me.

Also, if they're only additions, I wouldn't consider them significant changes.

Using TypeScript can be a significant change but Dockerization? That seems
pretty standalone isn't it?

------
squirrelicus
I call it the sports team problem. I don't know how to fix it. We've been
fixing the same set of problems over and over for decades on the front end and
there still isn't a good solution. So everyone engages cognitive dissonance to
justify why their favorite sports team--err framework--is qualitatively
better.

------
dandersh
The worst dev I ever worked with was overly negative, complained about
everything, was indirect and passive aggressive, and was dramatic over the
smallest things. Specifically they would know what an issue was and who was
responsible before the fact, yet would cry afterwards and exaggerate the
effect.

Some examples:

Talking about issues they had seen to a dev that they knew was responsible in
a "This isn't good, how did this get here and from whom" type manner, even
though they already knew who and what was responsible.

Digging through newly broken tests, determining that they were the result of
update payload configs not being changed in the tests, and then proclaiming
"Now all tests are untrustworthy and thus useless".

Waiting until after features/architectural decisions were implemented to point
out flaws and provide solutions "If only we had used X this wouldn't have
happened."

Acting as if the product either was in a precarious position or that the
users/BA's/PO's were clueless and cause it to fail soon.

------
nlawalker
The tendency to instantly formulate an answer to every question and a solution
to every problem, and express it with the phrase "just do X".

~~~
vokep
What is bad about that

~~~
neverartful
It's a sign of being a know-it-all.

------
myjunkin
Designer here. I spend most of the days with the product owners taking their
desires for the web app. They sometimes even like to specify button labels to
correspond to language they use in business operations.

Then comes the dev. He changes buttons labels even because he doesn’t agree
with what the product owners — the paying clients — want. He even tries to
rewrite our user stories to fit what he wants to do. He doesn’t ask what the
client’s goals are, he just tries to change the stories to what he wants to
develop.

He has a general lack of respect for his colleagues and the clients.

------
drugme
Having strong opinions yet... basically not knowing what they're talking
about.

------
simonsaidit
Only person i ever had difficulties with would ask me to explain him something
then cut me off mid sentence, come up with some wrong assumptions and critize
and then not let you explain why his concerns were wrong before he got into
some defensive mode and stop the conversation with either that he dident want
to discuss about it or dident care about it.... really fustrating. Often it
would be solving Exactly What he was concerned about but it just never came to
a full sentence before he turned it to some kind of hostility or other times
it was just done another way that he wasent used to or dident see the full
picture.

------
IE6
Getting blocked. A few years ago I worked with a team who would hit a minor
roadblock and just completely stop producing code. There would be a lot of
energy spent on emails, ticket updates, creation of new issues, and
theoretical and academic discussions on the issue. In reality we were building
websites that had a short shelf life and not sending people to the moon. For a
time I spent some of my energy to unblock them until I realized that this
didn't actually solve the root cause.

------
inostia
Asking questions about things that could be easily Googled.

------
kazinator
> _What makes you not want to work with a developer?_

Right of the bat, if that developer isn't kazinator, demerit points are
copiously applied. Alone is best.

------
PopeDotNinja
Dogmatism.

~~~
neverartful
Yep, and narcissism.

------
quickthrower2
Bad manners or bullying behaviour, or being an asshole are the main things.
After that not being able to code, no attention to detail.

------
itronitron
a developer's addiction to initialisms and acronyms puts a huge drag on any
meaningful conversations related to the product

------
tacomplain
Oh hell where do I start?

some stories that bump up in my mind: (Initially I wrote 3 paragraphs but it
was quite therapeutic so I kept going)

1) I was working in a company I co-founded and was the tech lead (wrote most
of the codebase). After some time we had our product deployed and the team
(mostly juniors) were quite comfortable with the stack. I was invited to
participate in a very interesting project (personally) and had to move to
France for a year or so. After some months, the CEO wanted to grow some new
features. I couldn't work because of not having time and legal terms of the
current contract. I suggested hiring a senior dev to lead the new features.
They hired a brilliant guy (technically speaking) and all went well (in terms
of budget and deployment). After finishing the project there and not wanting
to stay in France, I asked to come back to my company (I still had lots of
shares) and both CEO and team were very pleased with my return. The new lead
was not. Comprehensible. I was really trying to not step in his feet and work
mainly as Ops and R&D, letting him do the Dev part. Äfter a while some strange
things started to happen:

* I lost merge and push permissions to the repositories without prior warning. * He started to CR my code and overwrite with his 'corrections' after office hours. It started with dumb stuff such as whitespace/identation and ended with major rewrites. * He started to profile my code and compare to his own version that he had done in the weekend. ( code that should be run once a week in a cron, should be correct, not fast) * started to convince people that I was slacking off when I went out for lunch earlier or something like that. * He tried to insinuate that I was interested in one of the programmers sexually. (In that moment, the CEO had to investigate this) (I wasn't doing anything wrong) (Later, some coworked showed private slack messages of him being extremely biased on finding bugs and errors on females code (or code that was wrongly commited in the name of females)) * And the last drop was him putting his own copyright header on EVERY SINGLE FILE in EVERY SINGLE REPO of the organization (I admit that I laughed when I saw the .gitignore and travis files with copyright). Probably scripted. When called out on this, tried to sue the company saying that we stole his code. In court we showed the git history and all was settled.

TLDR: Very smart people can be very mean and dumb when afraid.

2) Leading a 4 person team (me + 4) on writing the backend for a load
intensive project. We wrote everything in 6 months. Tested, optimized, clean
code. I was very happy. Close to launch date, we had a meeting with business
and frontend to show the state of the project. During my 2 hour presentation,
the frontend lead was coding furiously in his laptop. When I ended, he got up
and asked why we took so long, if he could make an mvp in node in 2 hours,
then demonstrating it working. I believe that I spent close to 2 minutes
speechless just staring him wondering how he could just be so cynical. The
business guys were in a mix of baffled about how genius this guy was and kind
of pissed off with me. I then explained about testing, deploying in scale,
performance, etc but for them it was just techie bla bla bla... very
frustrating.

TLDR: when you are working in a project, work with the team not against it,
please. let's focus on having the best product.

3) New company, working on building backend pipeline for intensive data
analysis. That jerk from 2) was hired as 'culture lead front end' or something
like that. His job was to give lectures on trendy frameworks and how they were
amazing, buying beer (???) and making the team tight together (ok, but wtf).
It started with hoodies and cups (ok), then going out for pizza or beers (ok
too), then hackathons from time to time (ok, but didnt like pressure to going
to them) (It would be better if it was paid time or the code was Open Source
or nothing work related). But then he started to make some college frat stuff:
going to clubs, pressuring the younger and nerdier guys to pick up women, then
most of frontend (15 guys) started to use the same style of haircut and
clothes. When I found out that they had done that zuckerberg thing of rating
women of the company, I sent a company wide e-mail denouncing it (it was a
company private repository and made during a company hackathon). The CEO
wasn't very happy with my vigilante attitude. The backend team was very nice,
still friends with them.

TLDR: please leave college level douchbaggery in college.

4) Working on the energy industry, doing network protocols. Knowing shit about
electronics. Had a quite tight schedule (6 months aprox). From time to time, I
needed the electronics team to test the protocols, give me some feedbacks, you
know, working with me... They did test but it took them 2 weeks aprox. for
every iteration. No answers/messages from the team until they finished
testing. I couldn't know if they didn't received the email, if they ignored
it, if they scheduled it for some day... I sent lots of emails and called and
everything, just ghosting... I complained a lot with their lead and later with
the CEO. The answer I got was always that they had stronger priorities. And
that I was responsible for that working, not them. Since the protocol was
written for the in-house electronics, I had to have their feedback. Their lead
living in germany wasn't helping either, since I was being called during night
(like 1-3 am) to do 'briefing meetings'. The pay was very good, only thing
that made me stay until launch.

TLDR: Maybe I am programmer/computer-scientist/agile and not an
engineer/waterfall. But ghosting is so mean. Like, so mean.

5) Current job(CTO and co-founder of a small startup): For heaven sake I don't
have any major complaints: Guy next to me don't stop shaking his leg and
making sounds with his hands and overreacting when something works or do not
work. The UX dev has this habit of just saying loud 'hey guys have you seen
X????' And starts to talk about X for 20 min straight. Junior devs asking
questions before I can even take my headphones out, making me ask them to
repeat the question and totally breaking my flow. Considering asking for a
private office ( not sure if possible).

TLDR: Thank current team for being so nice. We have in our 20 person team
people from work 1) and 3). The CEO is the same of the company 1).

~~~
jonaswouters
Very relatable.

I laughed with number 5 because I'm a leg shaker, but I can't break that
habit. Those things are minor and maybe not even something to complain about.

For the other cases, like 2. It's hard to deal with people like that, even
after reading "Dealing with people you can't stand" which helped, but it is
yet another effort you have to make yourself with unpredictable results.

