The Importance Of Technical Planning

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?

  1. A written plan forces you to think more deeply about your work.
  2. A written plan facilitates communication. Review it, talk about it, reference it.
  3. A written plan serves as documentation. What did we set out to do and how did we do it?
  4. A written plan keeps your execution organized.
  5. A written plan invites collaboration, which begets technical thoroughness and stakeholder alignment.
  6. A written plan signals professionalism.

As you write your technical plan, here are some ways to ensure the process is as effective as possible.

Continue reading “The Importance Of Technical Planning”

Software Essentials: Code Review Checklist

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.

In this post, I’ll be sharing a 12-item code review checklist. This is a breadth-first traversal; each item is presented at an extremely high-level and deserves more of your attention.

Continue reading “Software Essentials: Code Review Checklist”

10 Bad Habits For Software Developer

Any developer, with any level of experience, has the potential to be dangerous. This is the junior developer having trouble grokking the ripple effect of his or her changes. It could just as easily be the senior engineer rampaging through the codebase with rewrites.

Before diving into this topic, a manager’s perspective must be given. Bad habits are just habits; they do not define a person or their abilities. When your colleague exhibits bad habits, it’s easy to point fingers and use them as a scapegoat. However, this kind of thinking is unfair; with large-scale software development, blame should never be assigned to an individual.

In the rare case where an individual’s presence at an organization becomes a disservice to the business, then that person needs to go. Bad apples aside, we must always remember that responsibility is bubbled up through management. It’s not your fault if your broken code gets through to production. Incidents in production are your team’s fault, your boss’s fault, and ultimately, the company’s fault—so in effect, no one’s fault. At a company, success and failure are never attributable to any single individual; success and failure are attributable to teams. It’s important to remember this.

With that said, here are my top 10 bad habits for software developers.

Continue reading “10 Bad Habits For Software Developer”