Ask HN: What makes you not want to work with a developer? | Hacker News Reader

Ask HN: What makes you not want to work with a developer?

40 pointsarduinomancer58 comments

A big one for me is otherwise smart people who immediately start bashing/complaining about a language/framework that they just learned or aren'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/framework.

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

I guess it boils down to: just because you're used to something doesn't mean its better.

View on HN

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.

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.

People's live are more dependent on software, even a simple website can leak info that has devastating effect on folks. Treating software development casually is a big problem. If we are going to be professionals, then we need to be professionals, most folks love to call themselves "software engineers", then let's act like one. Would you like if the same approach was taken on the car you drive, elevators, planes, medical equipments, buildings? Building great software is a science not an art. If you wish to express yourself, go code demos, design levels and game play.

Let me say this because I don't see it often said. Coding guidelines & Code review are a balancing act. One without the other is useless. Code review is where the correctness of the code is verified and we make sure that the guideline is followed. Without a guideline, the review process is just opinions. A guideline but without peer review is just a waste of time too. Guidelines must be reviewed often, it's a living document, that must be continually revised if need be to match the team and development process.

If your guideline calls for indentation by 2spaces and you use 4, it's not harassment, it's a violation of understood principles.

Now I must agree that the CR process should not be a bottleneck, if it is, it's a symptom of a bigger problem with the team and leadership. It's the leaders job to identify whatever it is and clear it so it can be fast and efficient.

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

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.

Yes, but that's not what happens. Folks say "you tested for an empty pointer wrong" meaning not how they prefer. Or "This could be coded another way that I think is clearer".

Here's a litmus test: if the comment has nothing to do with the correctness of the solution to the ticket, then don't comment. Instead write another ticket to address {whatever}. If it doesn't rise to the level of a ticket then guess what - you're being pedantic.

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

I've noticed this outside of the CR process as well. When people are tasked with providing a critique, it's as if they feel obligated to say something because they're treating the task as "find something wrong with X" not "determine if anything is wrong with X". Sometimes it seems like people trying to exert their power, but often it's more like people are just trying to prove that they're adding value.

> Sometimes it seems like people trying to exert their power, but often it's more like people are just trying to prove that they're adding value.

If you work with people like this a lot, try introducing a shit sandwich to your company. Before you call your caterer, let me explain what that is...:)

My Dad taught me that when you have to criticize/correct something, do so in a shit sandwich. Start off with positives, then express your criticism and then end with positives. Thinking about positives tends to ground people and get them to evaluate the situation, not merely come out with negativity to prove their worth...

This is common enough that everyone would know what you're doing and think you only said the nice things so you could say the negative :P

Good point - sincerity is a big if in this process. If the good is genuine, this is an acceptable tradeoff, especially because thinking about positive things often makes the negative more gentle and more constructive.

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

I agree wholeheartedly with this. One of my biggest pet peeves right now is having PRs delayed from merging because I can't get the required approvals over tiny non-vital changes.

IMO a code review should only ever be rejected / not approved if it a) will bring down prod upon being committed, b) contains easily correctable but serious oversights (bad run time algos, potential NPEs, etc), or c) is built in a way that is not easily transferable / maintainable / goes against establish patterns by the team.

Too many people use CR as a way to gatekeep and show off. I'm all for discussion, possible improvements, exchanging opinions, and learning - but not at the cost of leaving PRs in CR status for days on end.

I can't personally agree with that viewpoint. If I know you're going to introduce a problem, it's my responsibility to say so then and there. If they're professional they need to respect that. Especially if it's CR from a junior.

It's not a viewpoint; its a process. Comment and approve. Don't comment if its unrelated to the ticket being address; then write another ticket if the issue warrants it. Otherwise, save it for around the water cooler.

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

When we do code reviews, we try to make things explicit. What needs to be changed, and what am I just commenting on to illustrate a different way to do it.

Sometimes code is just wrong (either at the micro level--you forgot to remove that debug line--or at the macro level--you forgot this edge case) and a second set of eyes is a great way to catch it.

But I agree, treating the original developer as a professional is a good idea.

A "why aren't you doing it this other way?" comment is appropriate when:

- You understand both options.

- You understand the tradeoffs between them.

- You have a reasoned argument for favoring one approach.

- You suspect that the other person is missing some of this information.

I love getting comments that teach me about a language, API, design patterns, or potential bug, and make my code better. Even if I'm going to stay the course in this particular case, I'm happy to have received the comment, and always try to let the commenter know that. An okay code review gets my code landed fast, a good code review is one I learn from.

But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious, or have weird taste, or are otherwise putting me through the exhausting exercise of fighting for every little choice without providing value in return.

> But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious,

Often times when I'm reviewing code, I'm learning as well. If I ask a question because I don't know and am curious, I'd think that's a good opportunity for knowledge transfer. Why can't you fucking stand it?

edit: it occurs to me that this comment is extremely meta, hah.

Code quality is an aesthetic sense. It's easy to look at some code and render an opinion. With a certain level of maturity, you can intuitively come up with code that feels right. But offering a rational explanation for each minor decision between mostly-equivalent alternatives is disproportionately hard. Usually there isn't one. Trying to get more experienced engineers to knowledge-transfer the decision trees they're following is a seductive but wrong model for getting better at software engineering. If such trees even exist they are subconscious.

Observe, reflect, try stuff out, solicit feedback. Run that cycle with the highest quality and quantity inputs you can find. It's absolutely your senior colleagues' duty to help you develop the aesthetic sense, but the higher quality and more cost effective way to do that is by giving feedback on your work.

Whilst I agree with a lot of the points you made I'm not sure on #3 - I don't see that as a negative when compared with the opposite ( devs who don't care or 'think like a programmer' as much as they should ).

Similarly on point 7 I get very excited about new tech ( or similarly with cool old stuff i've only just discovered ). Who needs to be paid to be passionate about what benefits new tools may bring for me or the team :)

I don't think it's wrong to get excited about new tech. But from what I have observed it's mostly that one dev that pushes for new stuff and after they get sick/leave someone else has to take care of it and many times it means a rewrite of that functionality. Also many times with new tech, you can't really tell its bad sides, because it takes some time to know if it's solid or not.

This list kind of makes me want to work with you! And I didn't even work in startups... I guess that experience can be very widespread...

Agree with most of your points. For 1 and 2 it depends on what constitutes silly and the situation. I've seen some terrible code go through CR in the name of speed. For loops in for loops in if statements in for loops with breaks and continues abound. It worked, but be damned if I wanted to see it again.

What is CR?

Thanks for #3. Writing code is my profession. I don't love it, in the same way that a plumber doesn't love unclogging your toilet. He has to do it because he needs to buy food.

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.

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.

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.

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.

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

* must be perfect

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

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.

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.

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

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

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?

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.

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.

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

What is bad about that

"just figure out what OP meant"

In my experience, when one has an immediate answer to every problem, that is a sign that one does not understand the problem. Every non-trivial story needs some ugly code to account for a pathological edge case that the "just do X" developer isn't thinking about.

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

“Just do...” is oversimplification.

If you can explain how to do something that others are finding difficulty in, it’s a. Arrogant and b. Probably not understanding it fully to say “just do X”

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.

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

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.

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.

Asking questions about things that could be easily Googled.

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

Dogmatism.

Yep, and narcissism.

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

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

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

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.

I had to live something very similar to your 1st history. Is really hard to understand where's the flaw. Perhaps a profound sense of insecurity.

Man you've seen some shit. You definitely deserve your own office.

Wow some of these are insane. Sounds like quite the ride.

This. Is. Amazing! Best read of 2019.

help i cant bulletlist

Reply on news.ycombinator.com