How I Learn

August 30, 2019

I've been stuck on this question for a long time. I didn't really have that many chances to improve at my last job, and before that, I was a junior developer that had an endless list of technologies to get better at. I still have some technologies that I need to zero in on, but not as many as I used to. Now, I'm just haunted by this vague question of, "How do I improve and become the best developer I can?"

The answer is not to just build things. The advice to "scratch your own itch" is an extremely different personality type than I have.

I have no motivation to build things from scratch. I didn't get into programming to build the things I never had. When I've tried to fight my instincts and just do this because it was more "impressive", I got extremely frustrated with the amount of pre-work that went into getting the app idea coherent (design, writing, etc.) before I could even get to the software design.

I'm not really an "explorer-type" either. I don't like reading about new technologies without any practical usage at the end. I don't like learning technology for the sake of learning a technology.

My personaliy type is just, a finisher. I like the push. I like the problem solving. I like knowing what needs to be done and doing it. That doesn't mean I don't like refactoring or software design, it means I like to have a clear idea of what's lacking and going after it.

Again, my last job did not give me that. As I move into my next job at a big tech company, I think there will be lots of learning on the job, but I still feel an aching need to be proactive outside of work. I have a huge fear of getting stagnant.

I talked it over with some folks, and here's my new learning plan. It's not very sexy. But, I think it jives with my personality well.

The Improving Process

Step 1: Figure out what I need to improve.

This should be pretty simple. Keep a list on my phone of concepts, words I come across, things at work. Everyone has an ever growing list of these things, I think. Even if my list runs empty one day, I'm sure there a thousand folks willing to tell me what skills I'm lacking.

These can run the gambit from big to very tiny meta-skills. Just no soft skills. That's a different process entirely. We're not talking about that today.

Step 2/3: Learn about the concept.

Figure out if it's a small thing or something totally new.

If it's a new language or framework, start from scratch. Go through a full-on exercise heavy course (Udemy) or book. This will take like 100 hours. Just do it. Build tiny things along the way, as I always do anyway. I'm very good at doing this. I don't think this is the question I'm trying to ask here.

If it's a small addition to an existing piece of knowledge (eg. functional components in React, a new JavaScript design pattern), do a small video course (Egghead, YouTube) or just read about it. The idea here is to learn enough to be dangerous.

Step 3/2: Map out a stupid project.

Don't try to build anything useful or interesting. Build another todo list for the thousandth time, just build it using this GraphQL this time. Build another Spotify API search, but build it using entirely functional components.

These should be very small in scale, and should often repeat stuff that I've done a thousand times before. The key here is repetition and getting to the good stuff as fast as possible. It's not so small that it's exploring the concept in isolation, but not so big that I'll get overwhelmed by the "building of a full-fledged, production-ready app."

Large, complex problems are just the culmination of a thousand small problems.

The repetitive parts get smaller, faster, and better each time I add a layer. The concept of a "dead simple app I can map out in 2 hours" will go from todo list to full-on MERN stack app eventually.

Every app I make should just be pushing the envelope by 1 inch. That's it. Improvement comes from 1000 small steps, not 1 giant step. All the cliches here.

This is the equivalent of self-made code katas (and sometimes, using existing code katas is the way to go).

Try to improve the software architecture each time, as well. Make sure to do a full-on project management process each time. (I should get better at this enough that it won't be a huge barrier by my 10th app in.)

Step 4: Build it.

These apps should take less than 12 hours / 2 days of work. The scale of what I can accomplish in 12 hours will increase with time.

Put it all on GitHub. This won't impress employers, but when it comes time to look for a new job, I can pause and build an ambitious app for a month or two. This isn't really conducive to my sort of learning, though.

Step 5: Rinse and repeat ad infinitum.

The whole concept of this is to push one inch at a time. If I can build an app a week, I'll have learned 50 new concepts a year. (Probably less because there's probably going to be some bigger things I want to push for.)

I just need to keep a clear priorities list as I go along.

Thanks to Devin & Kenneth for knowing me well enough to both lead in a very similar solution, where both explanations were coming from totally different angles of insecurity for me.


If you liked this post, get updates about new posts by signing up to my infrequent newsletter.