On Being a Self-Taught Programmer

Now that I’ve been in my new role as a Software Developer for a few months, it’s pretty clear that being a self-taught programmer has its advantages and disadvantages. That is not to say that being self-taught is better or worse than a traditional education. I believe they are just different. I thought I would outline the ones that I’ve experienced thus far.

Advantage: You know how to grind.

One thing you learn pretty early on is: programming is a lot about grinding. Especially in the bug-fixing phase, it can often be summed up as iterating over the same information multiple times. This is true even when we have a really solid idea about what the problem is. The first set of iterations is usually around reproducing the bug itself. I usually try to do this manually, at least once, just as described in the bug report. Depending on the quality of the bug report, this may happen on the first try or may take more work. Once it has been done manually and there is proof that the bug exists, the principles of test-driven development require us to do the same thing over again, but in an automated fashion. Another iteration occurs (sometimes multiple). Then it’s time to start changing things in the “real” code. This could be one or two iterations if we’re clear on what the problem is. It could also be far more iterations if we’re not sure where the breakdown is occurring or the best way to solve the issue. Then we submit the fix and potentially iterate again if for some reason the full test suite finds an issue caused by our change.

All that to say: programming IS grinding. Luckily, as a self-taught programmer, this is par for the course. When teaching yourself, there is often nothing you can do outside of attempting a solution and then attempt another when something doesn’t work as expected. From the early days of getting two strings to concat together, self-taught programmers are used to doing things multiple times in order to get it right.

I’m sure this is true of traditionally educated programmers, too, but I’d be shocked if the order of magnitude wasn’t different. The traditional educational environment typically allows for more opportunity for collaboration and mutual support. Not to say that everyone experienced that or was able to take advantage of it.

Disadvantage: You don’t know what you don’t know.

Easily the largest disadvantage to being a self-taught programmer is that you don’t know what you don’t know. As in, the measure of how much a language/framework/concept we know can only be made in comparison to the parts of those things that we are aware of. One of the advantages of a traditional education is that you’ve likely heard/seen/been taught about most concepts even if you didn’t really get into the nitty-gritty of what it meant or what it was.

For the self-taught programmer, there are constant peaks and valleys that arise when you stumble upon these new concepts. As an example, one my earliest programming tasks was to pull API data from a project management platform that one of my previous employers used to help them track the output of their employees. At the time, I was learning the basics of using functions and “organizing” code to make it easier to read. I remember thinking to myself “holy cow, I’m like a real programmer now! This is what everyone else is doing!”. I probably put myself at like 30% knowledge of how to write code in Python. The problem was that I was writing everything procedurally. EVERYTHING It was one huge function of if/elses and mutations but since I broke it into functions, I thought it was “good”. Of course, about two weeks later when I started reading about OOP and how I had just created a completely unmanageable code-base (and probably committed a war-crime or two in the process), this 30% confidence that I had was pushed back to a much more reasonable 5%. I just didn’t know that a huge gap in my knowledge even existed.

This plays into the next disadvantage of being a self-taught programmer.

Disadvantage: You are more susceptible to questioning your own ability.

Having been trained in the field of the History of Christianity over the course of two degrees, I feel at ease entering a conversation about the history of Pentecostalism in America since the Second Great Awakening or early theories of what should be deemed canonical texts in the early church. These are things I’ve studied and I have the paperwork to prove it. I still feel at ease getting into these conversations even though I haven’t studied (or been interested) in that field in nearly 10 years. I’m much more hesitant to enter a conversation about programming with other people in the field. Why? Well, I’m not sure that I’m fully capable of not looking like an idiot in these situations. As I mentioned before, I’ve had a lot of bouts with unearned self-confidence and later looking back at myself as misguided and foolish. It’s easier for me to take someone else’s word on something they may know more about.

This is a feeling I often try to challenge. First, by doing my own research. It’s perfectly alright to not speak up right now, but it’s even better to research what doesn’t pass the smell test and come to your own conclusion. Second, ask questions. There have been a few times where I’ve done the research and asked a Senior dev “why are we doing it this way when it may be more efficient to do it this other way?” Sometimes, it’s just because it’s always been done that way. Sometimes its because before version X of some library, that wasn’t possible, but version X hasn’t been used since the dot-com bubble burst and no one thought to change it.

The disadvantage is the feeling that you’re not allowed or capable enough to be part of the conversation. Luckily, there are plenty of ways to combat this.

Advantage: You know how dumb you can be and still get away with it.

The flip side to the two above disadvantages is that you realize how dumb you can actually be and still get somewhere. For instance, my completely procedural API interaction code worked. It was completely unmanageable, but it WORKED. Once you learn all the concepts, you can sometimes get paralyzed by the thought that you’re getting a concept wrong. “Is this really the most OOP way of doing this?” you’ll ask yourself. “Should I be using inheritance here?” and you’ll sit with that for a few hours. Getting things working is often the first step. Even Uncle Bob says as much in Clean Code.

I often see senior developers online mention that they still look up simple things like how to get the current time in the language they are most comfortable in. The subtext to these jokes is often that they are ashamed to do such a thing. For a self-taught programmer, this is just how things get done. If you need to know how to do something and you don’t have it memorized, you look it up. No shame needed.

Disadvantage: Networking and Job Market

Easily one of the downsides to being a self-taught programmer is possibility of lacking the networking connections and resume builders that could land you a job. This has been particularly difficult for me. No one I know (outside of work) is a programmer. Due to my work schedule (which is due to my family’s child-care needs), I don’t have an opportunity to attend meet-ups or other events in any meaningful way.

The only reason I was able to get my foot in the door as a programmer at my current employer was because I went out of my way to solve bugs as they came in while fulfilling my role in the support department. If a ticket was logged, I went and look at the code and added in my bug-reports: “It looks like line 45 of /path/to/file needs to be X instead of Y”. Additionally, I wrote out a build system for documentation in the company’s language of choice (PHP), a language that I had no experience in at the time. This was noticed, along with my skill with some dev tools like git, and the developers basically said “stop writing that we need to change line 45 of /path/to/file and just fix it and submit it”. Thus my career as a software development engineer began.

Without going well beyond my job description to prove that I knew what I was doing, I would have never been able to get a developer role. Even with that, there is still a concern in the back of my mind about whether my next employer will accept the things I’ve accomplished as valid. Not many people start their career in software development this late in their life and I’ve seen more than one article saying that you should plan for your development career to end right around the next big milestone in my life.


I’m really happy that I’m a developer. I’ve put thousands of hours into learning programming over the last few years, so it’s nice that it’s finally paid off. Having said that, if I were to do it all over again knowing the person that I would become, I would have probably gone the traditional education route. First, because I learn really well in that environment. Second, it would have kept me from spending a bunch of money on degrees that are only really applicable due to the soft-skills they provided me.

Category: General Musings

Tags: career