Live data from Hacker News

Ask HN: How to make fewer mistakes?

news.ycombinator.com

51–60 of 75 posts

Re: Ask HN: How to make fewer mistakes?

#51
1. Have an IDE that points out the most obvious mistakes. 2. Write test (unit and functional), when you forget about corner cases writing code in TDD style may help, because it makes you think about them before writing the actual code. 3. Write your mistakes down and why you made them. 4. Have githooks that prevent you from pushing code that doesn't pass test 5. Don't feel bad about your mistakes, that's how we learn.

You mind find this interesting: https://routley.io/tech/2017/11/23/logbook.html

Re: Ask HN: How to make fewer mistakes?

#52

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 ...

So, on the one hand, yes definitely.

On the other hand, it's worth digging deeper.

A lot of programming advice is these rules of thumb, and they're mostly good, but they're motivated by underlying principles (which you explain in this particular case). So it's useful to not just have these rules of thumbs, but also to dig deeper and look for underlying motivations.

Re: Ask HN: How to make fewer mistakes?

#54
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…

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!

Re: Ask HN: How to make fewer mistakes?

#55
post #34

You say that "there is always a corner case that i don't think about or some test that is trivial to the QA team but i didn't do, and my code end up being broke". Is the corner case that you missed a technical issue or is it that the QA team has a better understanding of the business problem that is being solved and that hasn't been translated into a requirement/user story that you would even know to code against.

Also known as "lazy QA team who do not automate tests" problem. This is because testers are paid to little and writing good automated tests is about as hard as writing the tested code in the first place.

Re: Ask HN: How to make fewer mistakes?

#56

I think it's something you learn the more experience you have. I think the more mistakes, errors and bugs you see through your career, the better you get at recognizing pitfalls when you write code. Also, I'm a big fan of and practice "defensive" programming. There's lots of articles written about that, but in short it kind of changes your mindset a little and steers it towards more robust code. What can fail? How ca…

There is defensive programming and there is bug hiding. Then there's also wasting performance in release builds.

Mixing the three is bad.

Re: Ask HN: How to make fewer mistakes?

#57
post #11

1. run the code through a debugger as soon as you finish it; 2. run the code and purposely try to break it with all the edge cases you can think of; 3. run the code as if you are an end user who knows absolutely nothing about it; 4. have your colleagues try to break your code before you commit it. https://wiki.illumos.org/display/illumos/On+the+Quality+Deat... https://davepacheco.github.io/se411/release/fcs-quality-a…

1.b. Not debugger, but a tool like valgrind or options like address and thread sanitizer.

2. And 3. Does not help when you miss the edge cases.

4. It's called code review.

And my own: run the logic through an automated theorem prover, for example Isabelle. They will instantly tell you if any invariant causes a contradiction (mistake, corner case) or it cannot deduce behaviour given prerequisites. (missing specification, probably corner case)

Since it makes you write and read the code twice and forces you to think of it as necessary conditions and invariants, that alone might help.

Re: Ask HN: How to make fewer mistakes?

#58
post #18
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?

Yes. I've been doing this for 10 years formally now, and absolutely yes. There is always something to learn and always ways to make things better, which combines nicely with the odds of being perfect the first time are low.

Re: Ask HN: How to make fewer mistakes?

#60
post #12

Earlier quoted context omitted.

Hands down the best book. Plus the authors are really nice guys! http://www.growing-object-oriented-software.com

I challenge your best book with the book of Kent Beck (founder of TDD) https://www.amazon.co.uk/Test-Driven-Development-Addison-Wes...

I was hoping someone would mention it! While it is a good book as well (and Kent Beck has many of them!) I tend to describe his book as 1st generation TDD. It certainly was a great breakthrough in 2002 but it misses some very good thoughts that only came later (and to give credit: probably only thanks to his book). So, GOOS for me is the 2nd generation of TDD. Especially part II is invaluable to give as a reading and thinking exercise for my new devs.
Post reply on HN