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!

...

Mary...

Dive deep

When you're using a framework, library or language and you don’t understand something about it, take the time to understand. Read the source, play around in a REPL, read the documentation. This helps cement your mental model and makes you a surer-footed programmer in that environment forever.

Debug systematically

If you have a bug, form a hypothesis about what the problem is and then run experiments. If the results support the hypothesis, great. If they don't, use the observations from the experiments to form a new hypothesis.

Keep getting better at one programming language

This means you have a language to think with. You have a set of shapes that give concreteness to your ill-formed ideas. It means you can express an algorithm or a thought quickly without looking up syntax or APIs. It means you learn about the deep ideas in programming. Sometimes, you learn about these ideas by learning new languages. Programming in Clojure teaches you about concurrency. Programming in C teaches you about memory management. But using a language you know well keeps you in familiar surroundings. This lets you appreciate the subtleties of those fundamental ideas. You know: space, time, shit like that.

Don’t freak out

I know it’s overwhelming. It usually is. You’re starting something new, with few or no pointers, no orientation at all. But that’s ok, that’s just your lizard brain kicking in. Luckily, you know what’s best for you, so you can set your own rhythm and learn & build at your own pace. Forget about others here, and start where you feel most comfortable, and remember progress comes usually from slow but steady small steps.

Note to self: There seems to be a correlation between getting better as a programmer and getting better as a human being.

Time in the books and at the screen are important but not as important as the following:

• Be kind to people, just for the sake of it.
• Remember you're a people too and be kind to yourself.
• Are you still curious about the things you're doing? If not, get curious again.
• Teach, teach, teach. That's the best way to learn and contribute at the same time.
• Talk often about the things you love, regardless of whether the people listening know anything about it.
• Relax.....Really....I know it's annoying that your colleague used a bunch of nested if/else statements instead of a simple hash map, but it's OK. They'll learn in time, it's not worth dying young over.
• Be open with people about your experience in the world. Feeling like shit? Talk to someone. Feeling amazing? Let others feel it too.
• I know you probably feel like there's all these good devs in the world and you're always 10 steps behind, but the measure of your success is not about how much you know or how well known you got. It's not about how good you are at programming. Your worth is implicit and unbounded. Take that with you into everything you do and remember that everyone else is feeling the same as you.

• What matters today is to be better than yesterday, worse then tomorrow.
• Everything looks more difficult than it actually is until you actually take a stab at it.
• Sometimes it's brute force that actually works.
• What could have I done prevent this bug from happening?

• The only code guaranteed to work correctly is code which is not written.

When you're unsure where you're going (e.g. debugging, trying a new technique, brainstorming ideas): record what you're trying, even when it's not complete or doesn't work out. Write the steps down, or catch them in version control. It's good for retracing what you did when it does work, and can also help you avoid going around in circles.

• The amount of time you spend waiting for the right answer to magically appear in your brain would be better spent sketching out the flow of your data. Pick up a pen and paper and give it a hand.

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.