Why do we strive to write DRY (do not repeat yourself) code but fail to apply that technique in communications?

Bottom line — Manage your time and priorities. If you don’t, someone else will and you won’t like it. Keep your work public and visible within your team. Resist doing hidden work at the expense of your priorities. You ain’t gonna get credit for it.

I’ve been listening to more of Sandi Metz presentations and reviewing notes from her book Practical Object Oriented Designs.

Here’s why you might want to do this:

This is the article I wish I had when I started software development with Ruby.

Bottom Line - Ask for feedback after your rejection. Find the common threads, fix them, and get better at the interview game.

Bottom Line - Don’t involve the reviewer prematurely in product management / feature iterations.

I use Pry on a daily basis while writing / debugging code. I want to show you how to go beyond a simple breakpoint with pry. I’ll show you how I use it to learn about unfamiliar code and how to debug code.

I can’t be the only one who occasionally tries to start rails server and gets:

Bottom Line - Practice SQL by solving real problems.