#Issue27
3 posts

Lessons from 13 years of tricky bugs

Some of the hardest bugs to track are those caused by code failing silently. Event order matters. Imagine all event orders possible while writing co
Read more

Lessons from 13 years of tricky bugs

  • Some of the hardest bugs to track are those caused by code failing silently.
  • Event order matters. Imagine all event orders possible while writing code.
  • Complicated if statements & missing else statements cause more bugs than you think.
  • Add enough logging so you can tell why the program does what it does.
  • Always test with zero & null conditions.
  • Reveal bugs by using random input.
  • Always check that an action that shouldn’t happen doesn’t happen.
  • Commit different changes in different commits and use clear descriptions of the changes.

Full post here, 9 mins read

Lessons learned from the Ruby Refactoring Kata - Tennis Game

Refactoring mercilessly is a great learning technique to learn about what different parts of the code do. Don’t trust the initial tests completely. There are great chances they may not give you complete coverage.
Read more

Lessons learned from the Ruby Refactoring Kata - Tennis Game

“There is a certain amount of Zen to refactoring. It is hard at first because you must be able to let go of that perfect design you have envisioned and accept the design that was serendipitously discovered for you by refactoring. You must realize that the design you envisioned was a good guidepost, but is now obsolete.”
  • Refactoring mercilessly is a great learning technique to learn about what different parts of the code do.
  • Don’t trust the initial tests completely. There are great chances they may not give you complete coverage.
  • Extract method is a no-brainer refactoring with a good IDE support.
  • Simplify if conditions with Guards.
  • Preserve the public API if you have no control over client calls.
  • “Code as data” sounds exciting in theory. It isn’t too great in practice.

Full post here, 12 mins read

What Google taught me about scaling engineering teams

Create reusable training material & use it to onboard new engineers. Agree on a set of standard coding conventions as early as possible.
Read more

What Google taught me about scaling engineering teams

  • Focus on building shared tools & abstractions across engineering teams. Dedicate people to it.
  • Create reusable training material & use it to onboard new engineers.
  • Agree on a set of standard coding conventions as early as possible.
  • Take code reviews seriously and use them to increase code quality.
  • Having lots of right data will solve many problems.
  • Automate testing to scale your code. Rigorously focus on tests during code reviews too.

Full post here, 5 mins read