Ask HN: What are some bad developer habits?

https://news.ycombinator.com/item?id=20180909

by Austin_Conlon • 7 years ago

20 14 7 years ago

news.ycombinator.com

bradwood• 7 years ago

Writing code. More specifically, thinking of themselves as code writers rather than feature deliverers.

patatino• 7 years ago

- Going into details when the discussion is on a way higher level. Our mind tries to solve those puzzles instantly.

- Trying to create a solution which can be used in x different ways later even if there is no indication this will be ever needed.

- Overthinking IDE's and keyboards and monitors and editor themes and stuff.

- Forgetting that often the customer doesn't 100% know what they need, it is our job to help them getting there and not just blindly implement what they ask.

thedevindevops• 7 years ago

Writing tests after the code they will test

Ignoring Interface segregation

Assuming instead of asking

askafriend• 7 years ago

Writing tests after the code they will test

I hate TDD, to be honest. It's not enjoyable and it's not how my mind intuitively works.

I like to quickly prototype first and then mould solutions iteratively towards the final form. Then I cover the really important bits with tests for confidence.

quickthrower2• 7 years ago

Absolutely. Why waste time writing tests for a class you’ll end up throwing away? Just write the tests once you are done, but keep testing in mind when writing code.

tmaly2• 7 years ago

I often find relaxing the dogmatic approach to TDD gives better results. Write a little code, write a little testing, run the tests.

romanovcode• 7 years ago

Browsing HN instead of working during work-time.

codesternews• 7 years ago

Continuous checking the hackernews.

karmakaze• 7 years ago

Assuming that stated requirements are stable, thinking they are meant as interpreted, and that we understand the ramifications, imagining a simple solution (missing exceptions and edge cases), giving an estimate based on preceding without even taking into account validation/testing and deployment process.

tmaly2• 7 years ago

When business states the requirements or tech lead states requirements or some constraints and the programmer does not write them down.

I see this very often and the programmer either makes mistakes or comes back later asking for the same information

malux85• 7 years ago

- Wrong level of abstraction (too high level, too low level) either in verbal communication or coding.

- Intellectual violence (agressivness to people in meetings because they know the details someone else might not know)

- Hoarding knowledge - Incorrectly assuming it makes them more valuable rather than seeing the big picture that there's an infinite amount of knowledge out there and we are better to spread it as far as possible.

- Refusal to learn new tools and using the same old stack over and over again, even if it's an inappropriate choice

- Always leaning new tools, and never finishing / shipping

- Softare engineering anti-patterns https://en.wikipedia.org/wiki/Anti-pattern#Software_engineer...

- No README or build instructions. Not testing to make sure builds work off their personal machine

- Looking down on others that dont know X, even though they didn't know X 5 minutes ago.

- Getting defensive about the codebase rather than remembering we are all on the same team.

- Leaving the code in a worse state than they found it in.

- Championing a new technology choice because it's the new hotness, then refusing to take responsibility for it when it turns out to be unstable or problematic

- Never admitting fault or that they might be wrong

- Willful blindness to policy or ethical violations

- Sanctifying the code / sunk cost fallacy -- thinking that code is somehow sacred or deserves special treatment because it took them a while and effort to write : sometimes you have to just throw it away, rather than keep pushing resources into something that isn't working and refusing to give up because you've already put so much effort in.

apolymath• 7 years ago

Eating too much during lunch and then taking a nap immediately afterwards and slacking on the job.

fernandokokocha• 7 years ago

- acting like the ticket is done when it's pushed to code review (not taking review, QA, release, etc. into account). This implies a lot of miscommunication, think daily: "I'll finish this ticket today" -> ticket released 5 days later

- in case of communication, assuming that doing anything (usually one message in a convenient way - face to face, email, Slack) is the best they can do. No. In communication, you're actually responsible for the outcome.

- focusing on technical knowledge rather than soft skills (not to mention good sleep, diet and exercise)

- doing convenient job; not asking "What's important NOW?"

diehunde• 7 years ago

- Not writing tests

- Writing giant methods or functions

- Write "smarter" code instead of legible code

Ask HN: What are some bad developer habits?

Related Stories