Ask HN: What are some bad developer habits? - Austin_Conlon
======
malux85
\- 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...](https://en.wikipedia.org/wiki/Anti-
pattern#Software_engineering)

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

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

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

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

------
fernandokokocha
\- 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?"

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

------
romanovcode
Browsing HN instead of working during work-time.

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

------
diehunde
\- Not writing tests

\- Writing giant methods or functions

\- Write "smarter" code instead of legible code

------
codesternews
Continuous checking the hackernews.

------
thedevindevops
Writing tests _after_ the code they will test

Ignoring Interface segregation

Assuming instead of asking

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

