By George, I think he’s got it, programmer habits of course!

Whether we want to or not we need to pay attention

Details can be my undoing.

Rushing through a user story. Scanning a blog post.

Committing my changes to GitHub. Moving on…

Wait, is that a defect assigned to me?

Pay Attention

When I asked software development leader Geoge Dinwiddie about programmer habits, he said, “Pay attention to the details.”

Has he been watching me? Wow! How did he know that?

My approach has been “details, schmetails…” Of course, that led to a few defects.

George is right. We need to pay attention to details. Don’t rely on automated testing and Quality Assurance to save you.

Question your assumptions

If you ever validate an input field you must be careful. We assume people would only put numbers in the zip code field. A wily-testing veteran schooled me on this. Thanks, Miki:)

Another aspect is security. Things like XSS attacks are pretty common. Your validation should withstand that as well.

Question your habits

What are your daily habits? Are they serving you? As a big fan of Michael Hyatt’s productivity suggestions, I use the Workday Startup and Shutdown.

In Hyatt’s book Free to Focus he outlines these. Essentially they bookend your day. Similar to what a computer does on startup, the Workday Startup ensures we start on purpose.

George is asking us to audit our programming habits. Michael Hyatt agrees with this practice. We need to periodically ask if this habit helping.

Question your mistakes

Steve McConnell points out in his book Code Complete. “We need to learn the types of mistakes we make.”

Early in my Java career, I made the same mistake time and again. I would forget to initialize my variables. My co-worker Ken would laugh when he saw this repeated error.

State Machine

George also shared, “Consider a state machine to keep system responses decoupled and easy to modify.” Some practical design advice.

First, if you said, What is a state machine? “A state machine is a programming architecture that allows the dynamic flow to states depending on values from previous states or user inputs.”

Developers can wrestle with coupling items. Working on early internet applications this was a problem. A hack was to pass a lot of data around to emulate the state.

George shared some direct advice with us. First, he reminded us to pay attention to details. Understand them. See how this can shape our solution.

Then we need to question our assumptions. Ask your stakeholders to see theirs. Create alignment on them.

Third, question your habits. Do you need another round of testing? Or maybe the issue is you don’t understand the use case. Could you review it with the product owner?

Additionally, where do you usually make mistakes? As a novice Vue.js developer, I don’t understand a few things. Pairing with my co-worker Ryan helps me see solutions to my newbie errors.

Finally, George gave us the advice to keep things decoupled. We can use a state machine in our design. Simple and elegant advice from a software sage.