Background I embarked on the journey of teaching myself to code about two years ago now. The motivation was simple: I was putting myself into school to pivot careers and needing something to support myself in the interim. Programmer friends had been telling me for ages to try code, so I decided it was the most reasonable option. I didn’t have the time or money for bootcamps or the like, and my social circle assured me that self-teaching was a valid path, so I went for it. I haven’t really met any others who did it quite as alone as me, so I decided that it may be constructive for me to share what I did, what I think worked, what didn’t, and what surprises I’ve found along the way. The venting should be nice for me, but I hope it’s able to help someone else on a similar path, too. The Beginning Once I decided to dive into programming, the first question was where to start. At the time I thought that meant just picking a language. Strangely, looking back it would seem that my programmer friends did too. I suppose that this will be my first piece of advice to anyone looking to go down this rabbit hole: There is no such thing as just learning a language in the normal programming career market. Maybe there is in some academic settings, but in the more regular job market, instead of knowing a language, there is some niche of task that you perform. The most common is web development. While the language of web development is generally JavaScript, knowing JavaScript will almost certainly not be enough for a job, as the vast majority of web outfits are coding with frameworks. You’ll need to know vanilla JavaScript (that means plain JavaScript without anything added) in order to really leverage a framework, but it’s not enough. In any event, I thought that picking a language was all I needed to do. Different friends had different pieces of advice, but the most convincing of them convinced me to start with . He also convinced me to learn SQL on this side. For those who don’t know, databases exist sort of on their own in the programming world. Even if you know a programming language, you will probably need to store data at some point, and will need a database (or something like it) to store this data. Interacting with databases has its own language, the most ubiquitous of which is SQL. There are a ton of different SQL databases, and they have differences in language, but the bare bones are pretty consistent across them. My friend suggested PostgreSQL. Python I haven’t regretted either of these choices. Python is a great language to start with, in my opinion. I think there are some overlooked reasons why, but I’m going to mention them in technical jargon. Most languages have some kind of mandatory or somewhat mandatory end-of-line character (usually a semicolon), and wrap tons of things in curly braces (that’s these guys: {}). As someone who has used English as a language and not a programming language, it’s daunting to see all of these things all over the place. What are they all doing? English doesn’t look like this. Python is certainly syntactic English, but it’s much easier to look at. The whitespace rules also make code more organized, which in turn makes it easier to look at. I think it was great to start with it. not SQL has also been a blessing. My friend warned me then that he felt that pretty much every programmer will need to deal with SQL, but that few know how. I don’t know about other developers, but I know that I’ve had to deal with it plenty of times, and I have very limited experience, as I plan on discussing later. I do feel the need to emphasize one point, which was the timeframe I was planning on. Friends told me that it was reasonable to assume that I would be hirable in 3-6 months. I plan on talking about how I was hired in about six months, but I would strongly maintain that this was a fluke. I don’t think that it’s normally possible for a self-taught dev to do this. The only times that it would work is where the autodidact in question is so naturally skilled at coding that they are able to build projects, I mean like working and useful projects, within this timeframe. How much time does one need? That’s a good question, but I’d give it between one to two years. On the other hand, I’m not sure how much full-time versus part-time learning makes a difference. So much of the beginning is absorbing concepts and sleeping on them, that I think that it might not need a full-time commitment. In quote form: I don’t think it’s normally possible to go from nothing to hire in less than a year or two, if you’re teaching yourself. That doesn’t need to be a year or two of full-time learning, though. Once I’d picked Python and SQL, the next question was how to learn them. This is a very non-trivial question. While there is an abundance of amazing material, the abundance itself can make it very hard to determine what is really geared for an absolute beginner. For example, installing Python can be complicated. It’s easy for someone with even little experience to forget that, and forget the feeling of needing help with something that basic, and not knowing how to find help. If they aren’t self-taught, they might have never even experienced that. There are numerous good sources for total newcomers, but I’m just going to share what worked for me. Before I do, I’ll mention that the same friend who recommended Python and SQL also recommended not overlooking gamification. Many of us have a much easier time learning through playing a game than in other ways. As such, there are a disproportionate number of games here. For Python: by Zed Shaw * Learn Python the Hard Way * codecombat.com For SQL: * SQL Island * SQL Zoo * Postgres Tutorial Despite the fact that there are three entries for SQL and two for Python, Python was my focus. SQL Island is short and cute – I actually still use it when I need a refresher. Code Combat, by comparison, is tens to hundreds of hours long. One of the nice things about this list is the budget. Zed Shaw’s books cost around $20 (or at least they did in 2017). Code Combat can be used for free, or more content can be unlocked for either a monthly fee or a lifetime subscription of $80. The SQL resources are free. One other thing I’d like to mention: podcasts. There are great development podcasts out there. The one that stands out from the rest for me is with Jeff Meyerson. He releases 5 one-hour interviews a week, and covers a really amazing breadth of topics. Don’t worry if you don’t understand things, and feel free to pick and choose what you listen to. It’s an amazing way to build up knowledge of what’s out there, and there’s a lot out there. (Though see the section on knowing when to dig deeper below.) Software Engineering Daily I recommend the game approach. If you’re learning languages other than these, or don’t like these options, search around on the internet. Just a note: Code Combat can be played in a number of languages. If I remember right, they supported Python, JavaScript, CoffeeScript, and Lua when I was playing. Something not to be overlooked in resources is the community. One of the real gains for me in Code Combat was that if I got stuck on a level, I could usually get a nudge in the right direction from the forums. This brings me to what I would consider one of the hardest aspects of self-taught programming: Getting Stuck Compared to any of my friends who code, I get stuck much, much more. I don’t know why this is. It might be a personality thing. It might, however, be a self-teaching thing, which is why I’m going to talk about it here. You will get stuck. Code will fail. It will fail in ways that you cannot comprehend. Moving forward is amazingly difficult. There is some moment of critical comprehension when you’ll accumulate enough general knowledge to know how to find resources on problems. Until then, life is frankly a nightmare. There are these massive resources like Stack Overflow which are designed for questions and answers, but many new users have a fear that they’ll be asking a silly question, and get shut down. As someone who tried, I can confirm this. I have memories of this project a friend had helped me start off for a text-based game, and later when I was coding on my own, I kept on getting an error called a SyntaxError. I looked over the codebase for a couple of hours, couldn’t find anything, and decided to post. If you know Python, you’re probably already cringing. SytaxError pretty much literally means that there’s something mistyped, though I didn’t know that at the time. After a mod brusquely informed me that the question was not Stack material, it got shut down. I don’t recall if I had a pile of downvotes by then or not, and I may have even deleted it myself. It was a pretty awful experience. (Side note: I’m not trying to blame Stack Overflow. One of the goals of Stack is for the questions to not be repeats, and for the questions to be evergreen type material. New learners have trouble identifying either of these. Slightly different parameters can easily make a coder think their question is different than what they found on Stack, without realizing that they’re essentially the same and that extent answers can be easily fitted – if you already know how to code. Stack has the right to decide the purpose of their site, and it does an amazing job at its goals; I’m just saying that those goals inherently make it not amazingly newbie-friendly.) I couldn’t get help from my friends all the time. They had jobs, and strangely enough, only one of them knew Python. Even the one who really urged me to learn Python didn’t know Python. Building projects was more or less impossible. I’d inevitably get stuck early in, on problems that would probably take me maybe half an hour or less now, but I could be stuck for days until I’d just give up. It is clear to me that the most undervalued, and therefore undertaught, skills in programming is knowing what the question is. If you know exactly what the problem is, it’s usually not too much work to get a solution. (The solution can sometimes take a lot to implement, but if you’re at that level of coding, there will be more tools at your disposal, and you can decide if you want to pursue an alternative route, or implement what you’ve found.) I’m going to make a quote out of the first sentence: The most undervalued, and therefore undertaught, skills in programming is knowing what the question is. The truth is that even the best programmers run into problems, or have to use a library they’ve never heard of, or other things similar to what can stop new coders. The difference is that the experienced developer can both locate answers, and understand an answer when he finds it. There are many resources that are more or less closed to new coders. Despite the common refrain amongst Python developers of RTM (Read the Manual, meaning to look at the online documentation), the Python docs were completely undecipherable to me then. I have never seen anyone focus a course on figuring out what is failing and understanding documentation, but there should be. If you plan on teaching yourself, expect it to be very frustrating until you figure this out for yourself. Things like having a friend who can sit with you for an hour a day are invaluable, but not necessarily enough. When you’re coding a project, especially towards the beginning, it can be very difficult to know how to move on when your code is failing. The only thing I can offer is to bear with it, and eventually it does actually start getting easier. Knowing When to Dig Deeper This was my other big issue. I’m going to try to describe it. You’ll see that it’s similar to the last one, but I think different enough to merit its own category. A programming language doesn’t exist in a vacuum, at least the languages that you’ll be learning now. At the very least, it will be running on top of an operating system, and in many situations, will be interacting with other programs and programming languages. Even inside the programming language itself, you’ll quickly run into the need to import libraries, modules, and/or frameworks. One pertinent example is starting with JavaScript and web development. You can’t just learn JavaScript for this – you’ll be learning HTML and CSS off the bat, too. Something interesting that happened with me was simply the amount of rabbit holes I fell down, for lack of a better term. I suspect that some of this is my personality, but I believe that self-taught developers are much more likely to experience this. We don’t have a class we’re following, and are largely forging our own paths, and I believe that it’s reasonable to say that there’s a large chance self-taught devs will dive into aspects of their tech stacks that many other devs don’t focus on. I’ll give an example, though I suspect that if anyone reads this, that they may argue with it. I had always heard that programming is easier in Linux, or that Linux is made for development, or something like that. I figured that meant I should be running Linux, right? As a result, I dove down the Linux rabbit hole. First, I had to figure out which distro I wanted. I wasn’t sure. I ended up sampling a bunch. Strangely, this means that I have limited experience with distros from the worlds of Debian, Fedora, and Arch. I do not know anyone who runs Fedora (or RHEL or any distro based on them) in their personal life, much less Arch. In fact, I think I only have one friend who runs Linux on his personal machine, and I can’t remember if that was his work machine or personal laptop. (It was Mint, by the way.) You might be asking why I’m talking about this like it’s a bad thing. You’re right, it’s not totally bad. You end up with some really cool knowledge this way, and can totally impress your geek friends at parties (if they go to them). There is a downside, though. The reason why none of your friends know about, say, different bare metal virtualization options, is because they can do their jobs just fine without it. Odds are that you will, too. The reason why the knowledge is niche knowledge is just that, it’s because it’s specialized and not really something you need to know. As a new developer, though, it’s hard to know what is more of a general and good-to-learn thing, and what’s boutique niche. That being said, I think every developer should have his pet interests. Linux, the example I gave before, I think was actually a really good idea. I’m only bringing it to emphasize that pretty much none of my friends learnt it, and even when I was working in a startup, everyone else was on Windows or Mac. These deep dives into more unique territory can create yet another friction point. When I was trying out a newcomer-friendly Arch distro, I had no one to turn to if the operating system was doing weird things, or at least things that I thought were weird. I wanted to install a GPU. (Don’t ask.) How? That was actually hard enough to get me to try other distros. So, while this is a blessing, it’s also a challenge. If you find yourself going down a rabbit hole, you may want to ask a more experienced friend about it. Describe what problem is sending you in that direction, and ask if they think it’s a worthwhile investment. That being said, I wouldn’t take such advice as binding. It’s good to experiment a bit. If you get too stuck, you can always back up and back out. Moving Forward I had made it through most of Learn Python the Hard Way and gotten reasonably far in Code Combat after a few months. I was starting to realize that I needed to commit to a further skill set. I realized that just knowing the basics of Python wasn’t really enough for anything. I found machine learning interesting, and also had just discovered cryptocurrencies. The first was at least connected to Python, as Ethereum (the blockchain platform that interested me the most) meant learning new tools, such as clients, and a new language (Solidity) for smart contracts. Above all, I was really, really not interested in web development. I felt web dev to be a flooded field, and also one that simply didn’t speak to me. I ended up taking a few machine learning courses online. They were a bit scary – I hadn’t seen trig or calculus for ages, and there was also a bunch of linear algebra involved. The courses had deadlines, so I needed to keep up with the pace. I began teaching myself the basics of matrices , and managed to hang on. I learned a lot about neural networks, though I feel like I didn’t have much by way of confidence in the subject at all. If anything, casual job searching seemed to indicate that employers wanted developers on the PhD level when they wanted a machine learning position filled. As a result, I ended up going all in on blockchain development (cryptocurrency, to some) in summer 2017. That was a great time to do so – cryptocurrencies were starting a bull run which would last until the end of the year, and attracted a huge amount of attention. As a result, there were a ton of newcomers to the space, and a lot of very newcomer-friendly resources. In general, the Ethereum community was very welcoming and kind. It also meant that since there was huge hype around blockchain startups, and a lot of money being thrown at them, that there were more openings than developers. This was very auspicious for me, as a startup picked me up, and I started with them at the beginning of 2018. Work I would like to back up a step before I talk a bit about my first job. It’s not like they were the first CV I sent. I had spoken with a couple of job coaches, and also listened to some great podcasts, and everyone agreed that job searching is a job unto itself, especially for someone like me who was coming in self-taught and with no experience. I was also looking for part-time work, so I’d be able to juggle it with school. There were days where I was putting up to three hours into locating potential employers and sending CVs. I had composed my base CV with a coach, and would generally modify it as I learned new skills, or tailor for specific job opportunities. I wasn’t picky about who I sent to, nor did I restrict myself to blockchain. I also sent out to data science and machine learning positions, and pretty much anything with Python in it. I tried finding blockchain meetups to try to improve my networking, since none of my friends were even remotely interested in it. It’s no surprise to me that it was blockchain that pulled through in the end. Like I mentioned before, the market was at peak hype, and there simply weren’t enough developers to go around. I suspect that for many, getting their first position is all about finding an employer desperate enough to take a chance on them. I worked as a Blockchain Engineer for most of 2018. I’m not going to go into much detail about the job, though I will say that the startup abandoned its blockchain interests in Q4 2018, leaving me and the one other blockchain dev out of a job. I’ll also say that I don’t feel like I learnt much on that job, which was a problem. I’d been counting on building experience up as I worked, which I think is a pretty normal expectation. Blockchain was a nascent enough technology, and shifting quickly enough that I feel like my employer spent quite a bit of time deciding what to do, and not so much doing it. They were a total pleasure to work with, though, and I left them on good terms. They put in a bunch of effort to find me a new position in the blockchain world, but to no avail. The hype of 2017 became the Crypto Winter of 2018. One thing that I will talk about is becoming part of a community. Different technologies have communities structures around them. The actual Python language, for example, has a community structures around the development of the Python language, the different libraries built on it, and things like that. While Python in particular is probably not the most newcomer-friendly, I believe that it is very worthwhile to keep an eye on communities to be a part of. It’s hard for me to quantify all of my feelings as to why this is true. The only one I can pick out is fairly mercenary: it looks good on the resume. I feel that there are reasons beyond this, but I’m having trouble picking them out. I did make strides to get involved in Ethereum. I contacted a number of the more prominent projects built on Ethereum, sometimes to see if they’d hire me, others just because I was interested in talking with them about what they were building and about Ethereum in general. I went to the official Ethereum conference, Devcon, in October 2018, and ended up joining a volunteer product management team as a result. That in turn has me in touch with a number of people more prominent in the space than myself, and gives me the potential to be in touch with even more. More than that, though, it’s an awesome space, and it’s awesome to be involved at that level. Unemployment Given the level of hype that I had seen around Ethereum, and also given that I had made strides to become involved in the Ethereum community, I anticipated that I should be able to find another blockchain position fairly quickly. I was mistaken. Even though I had been working a blockchain job for the better part of a year, I realize now that I had little to show for myself. By then I had discovered that, to my chagrin, there was hardly any way to disentangle blockchain development from web development, unless I would be working deep in the protocol layer, and perhaps not even then. If I had a cool idea for a blockchain project, what precisely would my user interface be? Wouldn’t they be using an app or a web page? I suspect that this is true of at least 90% of programming: The vast majority of programming eventually involves web development. Put differently: JavaScript, HTML, and CSS are unavoidable. Or at least shouldn’t be avoided. I fought this for a long time, and I’ve been unemployed for a long time. I don’t think that’s the only reason: Part-time beginner jobs are hard to find. I suspect part-time isn’t so easy to find to begin with, but for some reason employers don’t seem keen on giving newcomers to code part-time positions. Again, my portfolio was underwhelming. Being self-taught stings here, too. I can imagine a potential employer looking at my CV and wondering if I really learnt anything at all – there’s no real way for me to prove it if I can’t get them to call my previous employer. It took me about half a year, maybe more, to embrace that I needed to learn a JavaScript stack. I settled on React/Node, figuring that if I’m learning JavaScript since everyone else is, I might as well go for broke and pick the stack most in demand around me. I also finally have the ability to do coding projects with friends. I’m in the process of rebranding as a fullstack developer. Part-time is still a big deal, I can tell. The fact that I’ve been slowly populating a GitHub repo with beginner projects doesn’t seem to have noticeably helped me, either. I feel like I’m approaching a crossroads of either focusing on school, perhaps by taking the debt route, or dropping out to increase the chances of a hire. On the bright side, I find that I’m much better at figuring out problems by now. There have been some pretty extended periods of time of the last couple of years where I was barely coding. Still, it seems that the meta knowledge slowly creeps into the subconscious all the same. My personal experiences in getting things to work now as opposed to two years ago are largely what motivated my estimations above. I think this is it for now. My goals were to discuss what I see as the some of the unique facets of self-teaching programming, both in terms of career and the actual programming, and I think I’ve covered everything I’ve meant to. Was there something else you were expecting to see here, or any questions you have after this overlong dissertation? I'd love to see some comments, and will do my best to respond. If you've made it all the way down here, I'd like to thank you for bearing with me all the way. Bye!
