Ask HN: What makes you not want to work with a developer?
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.
62 comments
[ 4.7 ms ] story [ 141 ms ] threadMeaning 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.
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”
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 :)
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.
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.
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...
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.
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 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.
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.
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.
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.
- 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.
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.
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.
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.
* 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.
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.
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.
- 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.
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?
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 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.
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 ...
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.
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.
Right of the bat, if that developer isn't kazinator, demerit points are copiously applied. Alone is best.