Ask HN: As a self-taught developer, what are your self-directed learning tips?

35 points by mcjoken ↗ HN
I consider myself self-taught, no CS degree, took some basic web design courses in college. I've turned that into a career as a largely front-end focused developer for the past 8 years.

Now I've started a family, I'm in my 30s and I'm feeling like I need to keep my knowledge and skills updated. But also have been feeling out of my depth recently, perhaps regretting my lack of solid CS background. But, above all I feel like I haven't been challenging myself enough and I've begun to lose interest.

My question generally is for people who have followed a similar career path, But I'm open to all perspectives.

What approaches or ideas to your self-directed learning have helped you break into more invigorating work.

Thanks!

71 comments

[ 3.9 ms ] story [ 267 ms ] thread
Every five years or so, my wife asks me, "What do you need to learn now for the next 10 years of your career?"

If you're self taught, you can teach yourself the next thing.

You don't have a solid CS background? You can teach yourself that. Go look at, say, the list of MIT courses for a CS degree. You don't have to take the MIT classes. But which of the things do you know, at least to some degree? The ones you don't know, do you feel the lack of any of them? Have they held you back at points in your career so far? Go learn those.

Your work isn't interesting any more? Look around at your company. What work there would be more interesting? What do you need to know to be able to do that work? Go learn that. If things line up just right, you can help out on a project in that area that is short-handed, and get experience on your company's dime. You may have to be able to say "I know a bit about that" first, though, so go learn at least a bit about that.

How do you learn if you don't take exams? I mean how do you know if you understand a concept if you don't have someone assessing your knowledge
Why do you need external validation of what you know? Is a test going to demonstrate that you know something? Is it going to demonstrate that you know what you need to know, or what the person who designed the test thinks you need to know? And all that aside, what use is the test score? Is that something you'd put on a resume?
As a self-taught programmer, musician, German-speaker... this question never occurred to me!

If it works, it works, I guess.

Build things! This solidifies knowledge in a way exams never will.
Very few exams I've taken tested anything but the ability for rote memorization.
Here's my example. I'm currently learning test automation. There are courses for that on Udemy, so I can choose "Test automation with Selenium and Python".

The next step is to google "demo projects for test automation", pick one, and apply that knowledge. If you still need more, pick another.

This will be your proof of basic knowledge.

I suppose the person that assesses my knowledge the most is myself. You know you understand the concept when you can use it and build on it with other learning.
Exams mostly don't assess knowledge and understanding, only snapshot regurgitation of facts and snippets. Additionally, when one takes an exam it's rare to require 100% correct to "pass" (and even when that does happen it's only 100% of the sliver of the total subject matter that was assessed). I know plenty of people (as I'm sure we all do) that can pass a test and still be functionally useless in a particular field. Not that I'm against exams (and I'll lump in certifications), I just don't think they're the silver bullet many make them out to be at least in the tech industry.
Same way you learn anything, read all about it then use what you read to implement something. When the something you implemented works and solves the problem, you've learned something! Repeat forever with different things (and sometimes with things you haven't done for a while). Each time you learn something new.

Exams are a hacky stand-in for actually using a concept to solve real world problems.

All knowledge, by definition, had to be first learned by someone. That person didn’t have an exams or someone testing their knowledge.

As a child I looked to exams and grades to validate my knowledge. However I got A’s on exams and felt like I still knew nothing. As I got older I care less about external validation and more about my internal “self grader”.

A few ways you can test yourself is building something. Take your knowledge and apply it.

Or try to teach someone. If you can’t explain the concepts clearly then maybe you don’t understand it as well as you think you do.

Or pretend your the teacher, write your own exams and take them. Ask yourself, “what questions would I ask students to tell if they know something?”

Lastly, and this one I like the least, find some tests or exams online, books that have questions at the end, etc.

work on things that go to production somewhere...
1. Learn data structures, but don't get overly pretentious about it. An ArrayList really is the right choice a lot of times, even though the CS mind might assume LinkedLists. :)

2. Learn neural networks and training them.

Do the DS&A stuff. Learn the common data structures and their big-O. Do some Leetcode questions. You quickly discover that there were things you could have done better, and you realize pretty fast that a huge swath of problems are actually solvable with a small number of solutions.

Other one is systems. Maybe less relevant for some people, but it's worth having a deeper model for how the OS works. How does virtual memory work, what does the scheduler do, threading, etc.

Finally perhaps programming languages and compilers. Gives you perspective on how the tools be use are constructed.

Very much agreed on both. Especially systems. There seems to be a hard cutoff in developer productivity and solution finding that is directly correlated to their level of knowledge in this area. There is just something about being initiated into the UNIX philosophy that helps immensely.
As a web developer, I'm curious - what kind of projects are you talking about and what kind of solutions did you witness being implemented as a result of the creator having knowledge in this area?
In backend dev, it's almost non-negotiable for what I would consider to be obvious reasons but I still see a learning curve for developers coming from self-taught or bootcamp backgrounds.

On the frontend, I guess you could make the argument that it's not as relevant but I still don't fully buy that after watching the last ten years in frontend development trends with React, etc. The whole thing just seemed like a way to escape the basics of dealing with web servers, basic HTTP, server-side development in "icky blue-collar" languages (anything not-JS or TS), deployments, SQL, etc.

Everyone has their biases and I'm no exception but this has been my experience.

Back in 2012, I hired a dev shop overseas to build a startup idea I had. I didn't know how to code, how product development worked, and got screwed over in the end with nothing to show for it. After that ordeal, I decided I would teach myself how to code with the goal that someday when I was ready again I could build my startup without having to pay others.

Like you, I started in web development and eventually expanded into full stack because I was lucky enough to really enjoy programming and craved learning more because it made me more confident, ultimately allowing me to shed my imposter syndrome.

Fast forward to today, and I'm still learning new things all the time. I recently learned C/C++ because I wanted to understand what dynamic memory was and how that worked. Whenever I want to learn a new language, I spend some time answering the same leetcode questions in that new language if I can't find something I want to build in it in that moment. I also have a startup where I'm the CTO and have the luxury of deciding what tech we use, how things are built, and it's a great learning experience because I have to understand things on a deep level.

That's just me, but thought I would share.

The best way to learn something is to do a deep dive and present/share it with others. Repeat this cycle. Make it a regular habit.

This could be in the form of a tech blog or giving a presentation to your team. There are also meetup groups, social media, and other outlets. Mentoring junior developers is another great way to stay current.

If you've been focused on front end for a while then try giving a talk at your company about something orm, db, or api related. In doing research you will learn, and you'll find yourself digging for more information to answer potential questions.

In short: help others learn. You'll learn a lot yourself along the way.

In my opinion (others will disagree), the vast majority of CS concepts are not very useful for most software developers. I don't think you should feel bad about that. I consider my time & money getting a CS degree to be almost entirely wasted.

If you're at a large company, look around for open positions that look interesting on other teams and talk to those team leads about what skills they would want. Maybe they'd even be willing to have you on board as a "trainee." If you're genuinely good at self-teaching, you will be an asset even without the skills built in.

If there aren't positions available at your current employer, you'll have to try to decide what skills are in demand and pick one, and you'll have to spend your personal time on it. My approach has always been to build something with the tech I want to learn. Usually just toys (a music player to learn GTK; many garbage video games and websites to learn various languages & toolkits) but sometimes useful stuff, too (a blog post demonstrating reverse-engineering a video game; many little unixy tools to make my dayjob easier; porting a Linux video game controller driver to macOS). In my opinion, just doing exercises isn't a good way to learn or demonstrate your abilities to an employer. Projects you own & and can talk about are way more interesting.

Also, consider that you might just be burning out on tech. I know I'm getting there. Ten-plus years in an industry is a long time, not everyone's built to do the same kind of work for their whole life. I'm keeping my eyes open for something in another field that grabs me.

> In my opinion (others will disagree), the vast majority of CS concepts are not very useful for most software developers. I don't think you should feel bad about that. I consider my time & money getting a CS degree to be almost entirely wasted.

I would agree for a web dev. But if you start getting more into backend, infrastructure, building distributed systems and APIs (which was the path I took), data structures and algorithms definitely start to come into play.

I started out self-taught on the web. Got a degree in design. Then learned web dev, then moved to backend, then to infrastructure, then devops, and now platform and cloud engineering. For me, I wanted to understand "the whole widget". And there are things I learned about UX that when applied to DevOps/SRE work, have elevated me as someone to listen to.

(As a fan of Avatar: The Last Airbender, I want to point to when Iroh was explaining how the 4 nations achieve balance. Same concept here. UX, engineering, infrastructure, and product need to work collaboratively together with mutual respect for the other disciplines to achieve the balance that leads to something great happening.)

I've picked up some data structures and algorithms along the way over the years, but I don't have college definitions of them. This hurt me when interviewing at Google, but I also have the ability to search the web and learn new things. So I do.

Just last week, I was working on tokenizing and building an AST for NRQL (New Relic's Query Language). As I was working through the tokenizer, I realized that this is what a linked list is.

I'm thinking about taking a single college course this upcoming semester about data structures and algorithms, just to fill in the blanks. But I've been building things for the web since 1997. For the most part, using anything beyond lists, maps, sets, queues, etc., is (relatively) rare, but again, it depends where you want to go next. Sorting large datasets efficiently, parsing things into trees, binary search, and making sure I iterate over things as few times as humanly possible will give you FAR more bang for your buck.

I’m one of those kids who have been programming since they were 10 years old. My biggest tip is to work on personal projects that you are genuinely passionate about or would use yourself. It’s a great way to experiment with new technologies with practically zero risk. For example, I’m currently working on a web app that started out as a SvelteKit SPA and with two backend “micro services”. I just recently finished rearchitecting the project into a monolith and using Hotwire for the front end. I was able to get experience using both of these technologies risk-free.

As a result of being curious and working on things that interest me, there’s practically no area of software development that I haven’t touched. I’ve written Windows device drivers, firmware for an IoT product, hacked on the LLVM source, wrote a (really basic) hypervisor, and made countless web apps. All with no CS degree.

What is your education background if you don't mind me asking? Like, did you study something else or forgo it (post secondary) entirely? Thanks for the insights
Pick a new and hot tool in an unfamiliar language or with technique requirements that are not in your comfort zone. Build something with it!

Try out a new IDE, or workflow.

Read some code in an open source project that you use a lot in your current work.

The purpose of all these is to gain a greater understanding of what is possible! This is something as a self-taught programmer I do often.

In software development, there is such a thing as "good taste."

There are ways of structuring code, of naming variables, of writing documentation, that simply are better than others even though functionality may be the same.

There is no way of acquiring this good taste except by reading code written by people with good taste.

If you're self taught, the easiest way to do this is by jumping into some code bases that have been written by people with good taste. Look at how they name things. Which private functions they define vs which things are inlined. Which bits of code merit a comment.

The best way to do this is to find some oss libraries that _you_ use, and just looking at the source code for them. You'll quite quickly realize which are easy for an outsider to understand and which are hard. You'll empathize with a 3rd party reader. And you'll learn more about how they work too!

Self-taught dev here, and I remember feeling similar things at a similar age. During a gap between jobs I wound up taking three online courses: Algos 1 and 2, and Andrew Ng's introduction to ML course (all at Coursera). This was just out of curiosity, I didn't have any particular goal or expectation for them.

At the time I didn't feel like I learned any One Big Thing, but in retrospect the courses demystified a lot of things, and I've never really felt out of my depth with development since. The other big thing I did was to tackle a much larger, more complex project than I'd tried before (a game engine). That also forced me to grow as a developer, but I don't know if I'd have managed it (or tried) without the footing I got from the courses.

I still got nothing out of NGs courses. I vaguely remember something about matrices, how to decide how many parameters to change when training, and some other very-vague understanding things. I don't really understand why they are "the gold standard", but I also don't do any ML "irl".
I took the Ng course when it first came out, but I hope it's been updated since - it was taught in a language I've literally never even heard of outside the course (GNU octave).

That said, if you want to understand ML stuff I learned waaaay more from Andrej Karpathy's famous video series. But I still found the old Ng course useful in a "ah, so this is what they teach in a college intro to ML course..." way.

When I was starting out I was then working in a different career. A lot of the work was analytical (Excel, GIS, etc.) and so I moved my work from those tools into Python.

I started small but eventually learned enough, alongside doing some online courses and personal projects, to get a job as a data scientist in a similar field.

The generals tips I have apply equally for self-taught developers and traditionally trained, yet are interestingly enough more often easier to accept for self-taught developers. Perhaps due to a willingness to acknowledge a _potential_ gap.

1. Be curious; allow yourself to say "I don't know" and go deeper

2. It's OK to be wrong; be humble and use step 1 to correct

3. Be aware of and try to discover and shed light on the things in your field that are your unknown-unknowns [1]); and then follow step 1

Links:

1: https://en.wikipedia.org/wiki/There_are_unknown_unknowns

Be open and curious about CS. There’s a strange mindset in some parts of the hacker community that considers CS to be wholly academic and divorced from the actual practice of programming. It isn’t. And it’s very rewarding.
> But also have been feeling out of my depth recently, perhaps regretting my lack of solid CS background.

I have a CS degree, and honestly the biggest practical value I got out of it was learning things that were cultural signals that let me part of the programmer "in-group" - I can talk about misc. cs stuff that will resonate with other programmers that have had a similar background.

In terms of things that I think are actually valuable like skills that help build things and write better code, there are much better alternatives than a universty degree. Just building things in my spare time and building things the way I want has taught me so much more. Sure, looking back, there are some things that I value highly that were taught in university, but it the signal-to-noise ratio was too low, to the point of being useless.

So I think the best thing anyone can ever do to improve their knowledge in software is to just build something that other people use.

If you're worried about fundamentals, I would say just shore up on some basic data structures (linked lists, hahsmaps, trees, maybe some graphs - this pretty much covers 99% of use cases). Rather than learning these as theory, I would strongly recommend just reading wikipedia, and writing code with them in a functional language like haskell. And also maybe some leetcode questions.

Similar path for me. The book The Effective Engineer by Edmund Lau was spectacular.

Push yourself full! Yet be kind with your progress. Best of luck fellow!

> But also have been feeling out of my depth recently, perhaps regretting my lack of solid CS background. But, above all I feel like I haven't been challenging myself enough and I've begun to lose interest.

I think you need to elaborate on this a lot in order to get relevant feedback. Speaking from experience, a lot of the answers you're getting here won't work for someone who's started a family—you need to be very precise in identifying and targeting the root cause, and you don't have tons of free time for side projects and after-work learning.

In what aspects of your work have you felt out of your depth? Is this sense in comparison to others around you, or to the work itself? When do you most often feel it?

How long have you been in your current company? Are you losing interest in your job, or in web development, or in computers in general?

What you need to do will depend a lot on how you answer questions like these. It honestly might be as simple as getting a new job that stretches and engages you more than your current one.

Thanks for the response.

4 yrs at current company, flexible job with a small team. family commitments definitely affect my ability to focus beyond my day job.

If I could summarize how I feel out of my depth. When I encounter something I'm unfamiliar with I often feel like I've limited my self and played it safe. I feel I should be diving into these uncomfortable feelings and learning new things but it also seems vast and intimidating. Which often has me questioning why I want to do this work at all in the first place?

As for a new job, I applied to some new roles recently and found the interviews challenging. Which obviously is it's own thing I need to work on.

I have a CS degree, but I had to teach myself the theory due to my school's sad excuse for professors.

Here are the two things I did that taught me the most about programming: learning how operating systems and programming languages work, and writing a raytracer and a software rasterizer.

The former two put all my years of tinkering on computers into perspective. The latter tested my programming and problem solving skills in a novel way. Both made me more well rounded as a developer. Not to mention they were extremely satisfying!!

This x1000. Back in the 90's writing software 3d rasterizers was right of passage of sorts. Writing parsers and interpreters too. At least that was my impression. Doing "hard" things like this can be very illuminating, it's kind of a super power to know how these things work. "Pulling back the curtain" on things that seem like black magic before.
I absolutely agree. You need to solve hard problems to strengthen your problem solving skills.

I want to implement my own interpreter next. I think I'm going to pick up Crafting Interpreter's whenever I feel ready to dive into my next project.

It's how I started too (before my CS degree). Ray tracing, fractals, IFS, demo scene effects. All good fun! Got me hooked. Now I write emulators for fun.
What worked for me:

I started out chasing my curiosity: wanted to make a simple video game, so I Googled my way to one as my first real programming project. I think passion projects are the way to start, because learning programming is frustrating no matter what (but totally doable, and totally worth it).

Some folks prefer guided courses; they're great, but they just don't work for me (I get impatient and bored). There are tons of very good free ones around these days.

Stepping away or switching to different challenges when stuck have saved me countless hours.

Focus on building a foundation of understanding as you go. Copy/paste is totally fine as you learn, but try to read the code, error messages, Stack Overflow posts etc. to garner deeper insights. A lot of it won't make sense at first...that's ok. Things start to click eventually.

I strongly recommend using ChatGPT as a tutor. It's already way better than Google or Stack Overflow, and you can ask specific follow up questions so you can understand the "why" better. I'm currently using ChatGPT to learn Swift (for a new iOS project I've started).

And, reading HN helped me a lot. At first it was mostly Greek, but I read the articles that sounded interesting and can't even describe how much I've learned from reading the comments on this site.

Most importantly, have fun with it :) This is probably the most important point. The field is vast, so pick the route that draws your attention.

Best of luck!

I know it varies by topic, but my experience asking ChatGPT about things I already know about (eg a smattering of topics in algebra) was bad. Like, bad bad. It got the intuition completely wrong, and asking for more explanation just got you complete garbage that ignored everything except the most trivial cases. Just be careful for anything outside of a 101 class!
Check out phind.com it’s a ChatGPT-like tool (says) that has updated models on documentation after 2021.
I got the Google Professional Architect cert about half a decade ago and it did help me understand the cloud quite well. It feels like "a marketable skill". I got more cloud certs from Azure and AWS later, but only the first "hit" in terms of learning because it's all the same after. But the first one really helped me understand the landscape.

For me, networking or security (mostly due to the networking part) are probably next to help understand something relevant and used by senior devs sometimes.

The other route is just to grind FAANG interviews for data structure. As much hate as it gets and as much as I haven't personally done it, it might also be the more practical way to go for job security.

Honestly, a lot of great front end devs don't know any of this stuff and are just amazing with React, know all the tools (Storybook, Figma, Contentful, Netlify) etc and are good with that.

P.S. Auth - you might want to learn Auth0 or Okta and the underlying principles. Comes up on every project.

P.S.S. You are going to get a lot of biased, personalized opinions here like mine, so really try to see the rationale and decide what YOU need. For example, I see IoT just in the post below - no one cares about IoT if you aren't specializing in IoT. He also wrote a hypervisor it looks like - no one will ever have him do that irl, unless he decides to dedicate his whole life to it. Etc - nothing against that guy, just convenient example.

I have an Applied Math & Computer Science degree, but was largely self-taught and working for computer manufacturers before doing the degree.

When I am learning something new or working on something difficult, it's important to keep motivation high to avoid getting bummed out, frustated, and quitting, especially if this is self-directed and not required for a job. The way I do that is to start with a working program, no matter how small, and then extending it in very small increments. After each increment you should still have a working program. You might spend a lot of time thinking about how you want to implement a feature (the design phase), but also spend time thinking about how you can get to a larger goal with baby steps. A good analogy for this is if you are contributing changes to an open source project: the maintainer doesn't want to see a 10K-line pull request that they've never heard of before. It's much more likely to be accepted as a series of smaller changes with a larger goal.

By doing these small increments, its much easier to isolate problems, because you haven't introduced much new stuff at once, and always having a working program keeps your motivation high. If you don't have a working program because of some changes, it forces you to be disciplined and fix things before continuing to add more new stuff.

Ten years into my self-taught software engineer career I ran across a statement "if you aren't seeing problems in your work that can be solved by graphs (or any advanced algorithms really), then you are likely avoiding those problems."

I thought he may be right, picked up an algorithm book and started a "coding club" at the company I was working at where we'd meet and go over the details of a specific algorithm.

I became a better programmer for it.

Also, check out all the free MIT OpenCourseWare CS classes. I listened/watched through a bunch of them a few times and then did some online exercises (leetcode, advent of code, hackerrank, et al) and it really helped me understand algorithms better and I also became a much better programmer for it.

I'd also suggest going through Network+ and Security+ study guides too. IDK if the certs are worth it because I haven't actually taken the tests, but the books alone taught me a ton of the important concepts at a high level.

This is a great comment. I was self-taught and then went back to school, so I have pretty good experience with both paths.

I hear a lot of time from developers "I never use those fancy algorithms!" or "I've never needed any math beyond HS algebra!" but I find that very often it's precisely because programmers aren't familiar with those solutions that they don't see the areas they can be applied to.

One of the biggest insights from my after-self-taught CS degree was that one class in particular stands out as a the dividing line between feeling knowledgable and not: Compilers.

To anyone wanting to improve their CS background: If you can't get back to school full time, try to audit a course on compilers (this is one area where having a structured course really helps). Pretty much all aspects of Computer Science are touched on in that one area: algorithms, data structures, graph theory, theory of computation etc. Plus it's just a lot of challenging programming to be done.

But once you see a high level program that you wrote compiled to assembly by a compiler that your wrote every piece of, you really feel like you understand both CS and software.

-> google drive: keep journals. such as a daily dev journal. or a daily <project> journal, where project = "learning journal" or an actual project you're building (and it might grow into a folder).

-> use chat rooms like IRC to have free Q&A sessions with experienced developers

-> check out www.roadmap.sh for ideas on which areas to grow skills in

-> ebooks at libgen.is

-> motivational speeches & music playlists (e.g. david goggins, motiversity, two steps from hell) -> video series at udemy.com (and other places, such as KodeKloud and ACloudGuru)