Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to make fewer mistakes?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Ask HN: How to make fewer mistakes?

#41

Post by Strom »

tw1010 wrote: post #18
PhilipA wrote: post #17

If you aren't embarrassed by the code you wrote 6 months ago, you haven't progressed enough.

Does that actually happen for really senior developers though?

I have 18 years of programming experience and it's definitely still true for me. [1] Unless I get some brain degenerative disease, I fully expect to keep improving at least until I'm 80 years old.

I've also seen this echoed by even more senior developers, e.g. this tweet by John Carmack: It is scary to look in some old code that hasn’t been touched in years, and see a completely non-thread-safe static global variable used. [2]

--

[1] My code quality is improving all the time. However I'm more accustomed to my emotions and fully expect progress, so I'm not exactly embarrassed.

[2] https://twitter.com/id_aa_carmack/status/339406631613890560

Re: Ask HN: How to make fewer mistakes?

#42

Post by godelmachine »

Haul4ss wrote: post #33
0xfaded wrote: post #20

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, n…

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,…

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

Re: Ask HN: How to make fewer mistakes?

#44

Post by appleiigs »

0xfaded wrote: post #20

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, n…

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.

Re: Ask HN: How to make fewer mistakes?

#45

Post by noxToken »

I'm not quite sure this would apply to you, but maybe it will help someone else: Slow down! You'll likely add more value by being 10% slower with more correctness than 10% faster with more mistakes.

If you go by average time spent on a given task, I'm one of the slowest developers in my shop. I'm pretty sure I'm in the bottom 25% for speed. What I lack in speed I make up for in correctness and readability. Rarely is anything bounced back to me for a bug, defect, or missing edge case. If I start getting sloppy, I have no leverage, because now I'm one of the slowest developers who make just as many (or more) mistakes than everyone else.

Start by fully understanding the problem. If you ever have any doubts about anything, stop and ask. As you're breaking down the problem, create a set of abstract notes. You could write it in paragraph form, a set of steps with checkboxes, sticky notes[0] - whatever helps you get the problem from plain business requirements to something a bit more concrete and actionable.

Then start writing code. Try to stick finishing in the order of your notes. It doesn't have to be pretty, but make sure it works according to spec. Constantly execute your code to test, because it's possible to add a conditional that renders one of your passing scenarios as a failure. If you can get a specific lists of tests that will be ran, use that as your framework. Your number one priority would be ensuring that the entire list passes deterministically.

After you've got working code, clean it up. Make sure your variables and functions have good names. getValue() is a very generic name, while getTotalCost() indicates much more without looking at another line of code. Use a linter, formatter, and static analysis tools to search for common bugs. If there are any glaring optimizations, make them.

[0]: https://news.ycombinator.com/item?id=16212374

Re: Ask HN: How to make fewer mistakes?

#46

Post by AndrewDucker »

tw1010 wrote: post #18
PhilipA wrote: post #17

If you aren't embarrassed by the code you wrote 6 months ago, you haven't progressed enough.

Does that actually happen for really senior developers though?

Unless you are rewriting the same code over and over you are always trying new things and expanding your knowledge. And that means learning new things, and making mistakes doing so.

Re: Ask HN: How to make fewer mistakes?

#47

Post by hutzlibu »

itamarst wrote: post #13

Gary Klein wrote a great book about how to learn from experience, based on research in naturalistic decision making, kinda stuff firefighters and NICU nurses do, but also e.g. design engineers for many decisions ( https://www.amazon.com/Power-Intuition-Feelings-Better-Decis... ). His advice for learning from mistakes is basically to look for the cues or patterns you missed that caused your mistake. That way you find…

"write readable code."

I think it doesn't matter if you give the source code or not, but you should allways "write readable code".

Sure there is a difference between throw away code and a library, but also for youself it is a good habit to understand later, what you have been doing. And so much more for other people ...

Re: Ask HN: How to make fewer mistakes?

#48

Post by _nalply »

0xfaded wrote: post #20

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, n…

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

Re: Ask HN: How to make fewer mistakes?

#49

Post by sevensor »

0xfaded wrote: post #20

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, n…

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.

Re: Ask HN: How to make fewer mistakes?

#50

Post by stinos »

Like others said: experience. Training for a correct mindset.

For me, for basically every line of code written, and also for bigger pieces of code, I'll try to think of all possible corner cases which might prevent the the pre- and postconditions from being established. And make as few assumptions as possible.

It takes a while to develop that mindset, and it takes even longer to learn to write code which doesn't have problems in the first place. And I wouldn't even consider myself being really good at it.

Note that once you get a hold of it, you'll automatically start to write code which adheres to most 'best practices' like DRY, proper naming, short functions, you name it. These go hand in hand with fewer mistakes. In the beginning this will cost you time. But that is not wasted, as it'll teach you to do the right thing in the first place, and once you do that you'll have to spend less time debugging and the code will be clearer in the first place so less time lost reading and understanding it.

As a simple example take code from a person who does lack that mindset (despite having programmed decades more than I have) which I reviewed just today: if you just write bar[1].Foo() and don't have a strategy to either make sure bar does have enough elements, or else a strategy to properly deal with the error (as in, not just segfault, unless it has been established that is the way to deal with it) which will occur if you try to access that element anyway, the code is not good. So when I write even the simplest thing like bar[1].Foo() I automatically will wonder about that, ask myself 'can this occur'? If it's supposed to never happen I'll likely insert an assert. If it can be totally acceptable, wrap it in an if statement. If it's a user error, complain. Etc. But never ever just assume it'll be ok. And to do that, realize you must always reflect about everything you can think of.

Post reply on HN