- 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
- 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.
- 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.
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?"
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.
- 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.
- 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.
- 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?"
I see this very often and the programmer either makes mistakes or comes back later asking for the same information
- Writing giant methods or functions
- Write "smarter" code instead of legible code
Ignoring Interface segregation
Assuming instead of asking
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.