A Developer's Daily Checklist

October 23, 2013

Below is a list I am going to read everyday before I start working. Some points are repetitive, because I need to hear them over and over. This list is in no particular order.

Communicate early, and often. Don't be afraid to ask questions.
If something isn't clear or a proposed solution doesn't seem right, say something. At best you've discovered a blind spot in your team's approach, at worst, you will have learned something. So you win either way.
Assume nothing. Take the extra time to confirm or refute your assumptions by asking a team member.
Program defensively. Assume users will break things and enter bad data, or that the worst will happen.
It's ok joke around and shoot the breeze every so often, but at the end of the day, this is your job. Be serious about it.
Every moment is a teachable moment. Learn, soak in as much as you can from others. Again, ask questions: "Why are you doing it that way? What does that method do? What are some others ways to do the same thing?" Pair programming offers so many opportunities for this interaction, which is why I think it's the best way to level up.
Test your code thoroughly. Ask others if there are blind spots in your tests.
Understand that, even though every PR is reviewed by others, there's a level of trust in you as a developer. Own the code you write, and take pride in it. Make sure it works, don't assume others will catch a mistake.
Never. Stop. Learning.
Ask about blind spots: "What other parts of the app might break if I change this? What are some "gotchas" about the process I am working on that are perhaps not apparent? Can you just go over with me what's happening here?"
Document useful things you discover.
If something is broken, fix it.

The biggest takeaway for me, especially as a remote worker, is to just speak up if you have a question or are unsure about something. In my experience, colleagues are very understanding about getting someone up to speed with how the app works, or to just go back and forth talking about the merits and demerits of a particular approach.