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