I think one of my strengths as a programmer is that I actively try to learn new things and stay abreast of my field, which is not easy. When I am not procrastinating by writing blog posts, I follow a fairly systematic method.
First of all, to be an employed software developer nowadays, you have to have a specialty. You can be pretty good at lots of things so long as you are very good at one thing. My specialty is front-end web development. Your choice of specialty informs your study decisions.
I maintain a notebook for my programming study activities. It’s a letter-size bound book of un-ruled paper, basically a sketch book. It’s not a journal. Instead, it’s full of mind maps and check lists.
On a given day if I have some time for study, I usually begin by brainstorming what my current “weaknesses” are. There are topics that are important for my goals but about which I don’t know enough or I need practice. The ones I focus on today —that’s a decision based on what I hear people talking about, what I see in job posts, which things I’ve had on the back burner forever.
I also maintain some broad, long-standing groupings of my study to-do task—kinda like self-study courses where I make up the assignments as I go. My current self-study courses are Databases, Current Events, Literature, Full Stack, and Front End. My “Current Events” course, for example, means browsing the web to see what programming stuff people are talking about, what libraries are trending, etc. “Literature” means studying the big (important, popular) libraries to understand them better. “Full Stack” is a hands-on course I designed for myself to build some full-stack web application including a backend and a database—just one after the other, using a variety of tech stacks. Each one might take a while.
After I have made a broad and current map of my weak areas, I try to distill that into a list of concrete to-do items that will help me improve. Sometimes a task is something very simple, like “write an HTML template file by hand”. The goal for that one was just to remember that stuff, because most of the time I copy-paste it.
Some days, I feel utterly at a loss to decide what my best next step would be, so I end up writing a blog post. It’s always easy to think of things I don’t know. The hard part is making a to-do list of concrete stuff that will actually help me improve somehow—and which doesn’t sound horribly tedious (learning Gulp).
I do have an interview later today, so maybe I’ll familiarize myself with CodePen, which I’ve never used before. And it wouldn’t hurt to remind myself how to write a Vue widget from scratch using the Vue function. (I usually build larger projects where the Vue function only appears once in a small snippet of the index.js file.)
adamcross.blog 