Comment by 0xfaded | Hacker News Reader

Comment by 0xfaded | Hacker News Reader

Parent Full thread

When I was getting my pilot's license, multiple times I started up without unchaining the tail. I joked about it with another instructor, and he basically said that it had literally never happened to him and that I should be doing a final walk around. I'd done even more embarrassing things, sitting at the runway ready to go and the tower tells me my baggage door is open.

Since making that final walk around a habit, nothing. I started doing final everythings, one last check of the radios, one last check of the instruments, etc, etc. It's amazing how many times you pick up on something so obvious that is wrong.

The key is to change your mindset before doing the final check. Acknowledge you are done, go get a tea, and go through the motions.

Somethings I do related to code.

Use `git add -p` to go through changes one by one. Remove stuff that shouldn't be there.

Do a self code review before submitting the code for others to review.

Obvious one, but always run tests.

For what it's worth, I find the same things with maths. I've been working on SLAM systems, so lots of differential geometry and matrix calculus. I'll spend a morning with my notebook trying to figure something out, go to lunch, then come back and go over what I've done.

In university I was horrible at maths exams, because like you I knew everything but made so many stupid mistakes. I think the problem was that during an exam, I could never dial down my mindset from OMG I need to triple check everything right now!

I was hoping someone would mention being a pilot in this discussion.

If you learn to fly, you will learn to follow checklists. Many, many checklists.

A good instructor will tell you that while you do need to follow the checklists, it never hurts to do one last check. One final walk-around before getting in the cockpit, one last check of radios/transponder, one final scan across your engine instruments before takeoff, etc.

If you do these things enough times, you'll find the occasional instance where you forgot something obvious, or accidentally skipped a checklist item.

To OP, as you miss each edge case or QA thing you should have found, you add it to your checklist. Before you check in a new piece of functionality, run it through your checklist. Also, do one last walk-around of the code. How will the user interact with it, what are the API dependencies, etc.

You're not second-guessing yourself, but you always verify even your own work before calling it done. Over time, you'll learn to follow both the best practices, and your own intuition built from years of learning from your mistakes.

I came here to say basically this. Checklists are unreasonably effective. And if you can automate them with some form of metaprogramming, even better!

Example?

Here's a good one: A few years back, I had a quick stint as a wordpress PHP magician. The php community has a tool called php code sniffer. The wordpress community has a collection of "sniffs" (rules) to enforce coding conventions[0]. One folder of rules is called "Security"[1]. Set up a git precommit hook to run phpcs with whatever set of rules you like and it will give you a list of things you need to fix before your code can be committed. Automatically.

In the JS/webpack/react world, there's eslint. You can write custom rules to automatically check for and enforce whatever you have on your checklist.

[0]: https://github.com/WordPress-Coding-Standards/WordPress-Codi...

[1]: https://github.com/WordPress-Coding-Standards/WordPress-Codi...

I am notoriously absentminded. I would constantly forget my lunch, leave the lights on, whatever. Since writing down checklists for my morning and evening routines, I don’t miss anything. The fact is that we’re human beings. As the book “Getting Things Done” says, your mind is for having ideas, not for holding them.

Reminds me of the book - "The Checklist Manifesto" by Atul Gawande

That's a helpful post. We do a similar thing in scuba diving: run through a checklist and then do "one final check" to make sure there's nothing obviously out of place.

Changing your mindset is another good piece of advice. When you're done coding, stop thinking like a programmer and think like a user - a bored, fed-up, malicious user who's going to have a go at breaking your software. He's not going to do the things you expect him to, he's going to try to enter ridiculous data, in the wrong order, press stuff that he shouldn't, etc. Be curious. "I wonder what happens if I do this..."

Offer to buy a beer for every bug your colleague finds in your code. Don't want to pay out? Make it hard for him to find any, and any that he does find will be well worth the cost.

I've been coding for nearly 40 years and still manage to write some crap on occasion!

I haven't often got the time for this, but one thing I find helps immensely when I do is to prepare a rough draft of my changes, and then go back and retype the entire function. (This will also encourage you to write short functions!) The act of retyping is a lot like the final walkaround: it forces you to see everything another time before sending it on its way.

The final walk around habit is great. It's even better if routine checks like these are part of a checklist you follow. When performing habitual actions it's possible to get a minor interruption/daydream and accidentally skip some check. Having an actual list of bullet points to go through helps against this.

My advice would echo yours. Only thing to point out is: time. You can do all these things if you start early and don't rush.

As you mention, mindset and habits are key. My mindset for tasks theses days is "focus, and dont be lazy". That allows me to not half ass the checks/checklist.

I will implement the "final walk around" in my dev/thought process, this is a really valuable advice, thank you.

PS. `git add -p` is amazing, thank you for this too.

I think additionally it helps to turn off sources of distraction. Cell phone I am looking at you.

Reply on news.ycombinator.com