Debugging is a critical skill. More important than the skill is the mindset. The debugger’s mindset is the attitude that you must always understand the why behind a problem; any ambiguities or unknowns are unacceptable. This mindset has the potential to carry you from debugging small functions to solving difficult organizational issues.
Creating a technical plan is a sign of professionalism and maturity as a software developer. No matter what you’re working on, whether it be a straightforward feature extension or a massive data migration, a technical plan must be written.
Why Should I Write A Technical Plan?
- A written plan forces you to think deeply about your work.
- A written plan facilitates communication. Review it, talk about it, reference it.
- A written plan serves as documentation. What did we set out to do and how did we do it?
- A written plan organizes your execution.
- A written plan invites collaboration, which begets technical thoroughness and stakeholder alignment.
- A written plan signals professionalism.
As you write your technical plan, here are some ways to ensure the process is as effective as possible.
Code reviews are an essential part of software development. To be good at the craft, we must be able to review the craftsmanship of others. The more books you read, the better you write; the more code you review, the better you code. The following 12-item code review checklist is a breadth-first traversal; each item is presented at an extremely high-level and deserves more of your attention.
Any developer, with any level of experience, can have bad habits. This is the junior developer neglecting the ripple effect of his changes. It could just as easily be the senior engineer rampaging through the codebase with her rewrites.
Bad habits are just habits; they do not define a person or their abilities. When your colleague’s code falls below your expectations, it’s unfair to point fingers and blame them for your company’s growing mountain of tech debt. With large-scale software development, success and failure are never attributable to individuals; success and failure are attributable to teams.
Bad habits can be replaced with good habits. Here are my top 10 bad habits for software developers. Watch out for these—we’ve all been guilty.