Ask HN: What are some bad developer habits?
14 comments
- 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.
- 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.
Writing code. More specifically, thinking of themselves as code writers rather than feature deliverers.
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.
- 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?"
- 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?"
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
I see this very often and the programmer either makes mistakes or comes back later asking for the same information
Browsing HN instead of working during work-time.
Eating too much during lunch and then taking a nap immediately afterwards and slacking on the job.
- Not writing tests
- Writing giant methods or functions
- Write "smarter" code instead of legible code
- Writing giant methods or functions
- Write "smarter" code instead of legible code
Continuous checking the hackernews.
Writing tests after the code they will test
Ignoring Interface segregation
Assuming instead of asking
Ignoring Interface segregation
Assuming instead of asking
> 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.
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.
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.
I often find relaxing the dogmatic approach to TDD gives better results. Write a little code, write a little testing, run the tests.
- 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.