8 ms·

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

• PopeDotNinja 8y ago
  Dogmatism.
  • neverartful 8y ago
    Yep, and narcissism.
• squirrelicus 8y ago
  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.
• Someone1234 8y ago
  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.
• nlawalker 8y ago
  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 8y ago
    What is bad about that
    • khacking 8y ago
      “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”
    • neverartful 8y ago
      It's a sign of being a know-it-all.
      • zangetsu 8y ago
        What's wrong with being a know-it-all?
    • asfarley 8y ago
      "just figure out what OP meant"
    • deleted 8y ago
      [deleted]
    • PopeDotNinja 8y ago
      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.
• drugme 8y ago
  Having strong opinions yet... basically not knowing what they're talking about.
• wrestlerman 8y ago
  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.
  • nullandvoid 8y ago
    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 :)
    • wrestlerman 8y ago
      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.
  • nqr 8y ago
    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.
  • JoeAltmaier 8y ago
• dare0505 8y ago
  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 8y ago
    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 8y ago
  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.
  • 420codebro 8y ago
    This x100. Devs who do this deserve to die in a fire (just kidding, but seriously, you know what I mean).
• inostia 8y ago
  Asking questions about things that could be easily Googled.
• AnimalMuppet 8y ago
  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.
• simonsaidit 8y ago
  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.
• dandersh 8y ago
  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.
• sergiotapia 8y ago
  - 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 8y ago
    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 8y ago
      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?
• Tangokat 8y ago
  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 8y ago
    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.
• tacomplain 8y ago
  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).
• myjunkin 8y ago
  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.
• kazinator 8y ago
  > 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.
• IE6 8y ago
  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.
• quickthrower2 8y ago
  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 8y ago
  a developer's addiction to initialisms and acronyms puts a huge drag on any meaningful conversations related to the product