Reminders to myself to help me get better at programming. I don't always manage to do these things, but I try. Please feel free to add your own reminders to yourself in the comments below!

...

Whenever you change a piece of code, have an idea about what it will change ("tests X, Y, and Z will now fail", or even "it should blow up in a different spot"). If you make the change and something ELSE happens, go find out why: that's evidence that your understanding of the system is incomplete, and changing things in that state is a great way to get more confused.

Addendum: before making a significant change, apply this philosophy and make a trivial change (drop a raise 'yup' or equivalent in the place you're thinking about editing and verify that things break in the way you expected. Nothing worse than editing code that isn't actually involved and trying to decipher why nothing's changing. :)

Committing all the time (and having mastered the main git functionalities) helps me get better at programming. I love it that I don't even have to think about "the perfect" commit message, given that I can rebase -i and squash commits, as well as amend commit messages and descriptions when I'm ready. It gives me the freedom to go ahead and not worry about the "very best" way of doing something, with the confidence that I have clean code waiting for me right at the prompt with a quick git command. This gives me the freedom to branch out into different things (to be merged later if I want to), which leads me to fail and learn fast, all the while not loosing productive work, which is, in the end, what concretely leads me to become better.

And 👍 for all the comments on this thread.

Don't be scared to make mistakes.

Don't be afraid to admit when you have.

Hey, @maryrosecook! These are great. One thing I need to keep reminding myself – that I hope would be helpful to others – is: prove it. There are so many times when something seems to be the case, and I tend to be satisfied by my hypothesis, but I've been wrong a lot in ways that have sometimes been costly. The learning here is to build a case for why you think something is the way it is: get support from the server logs, or some code in the REPL, or the console. Don't just assume that the most likely answer is the right one. Show factual evidence to support it.

Dear Future Sean,

First off, sorry for all of the bugs, poor design choices, and overall sloppy code. I couldn't prevent that, I was still learning. I'm especially sorry for all the technical debt I've accumulated. I could have prevented that, but chose not to for whatever reason.

While you are fixing my mess, just remember that the only reason that you can is because you are better than me. Remember how hard we thought that first programming interview test was while we churned on it for 3 days? We could probably do it in a few hours now; you might be able to do it in even less. (Reminder: You should try doing that!)

So keep learning, keep writing code, and keep writing about code. I'm really excited to see where we end up going.