Lessons from Google's engineering teams, tricky bugs & Ruby refactoring

Arpit Mohan - Oct 29 '19 - - Dev Community

TL;DR style notes from articles I read today.

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


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

“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


Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player