Andrew Ritchie Stuff

home

What It Means to Know How to Code

15 Mar 2021

After a career change I have been working as a professional software developer for over ten years now, despite the fact I didn't study computer science or software engineering in university. In those ten years I've worked on projects for tiny startups that never made it, and big companies you've probably heard of like the New York Times, Axel Springer and Wayfair. Occasionally friends approach me for advice and perspective about how they can learn to code as a career change or just as a hobby. One of the big problems is defining what "knowing how to code" means. It's very easy to pick up a coding tutorial or two and after finishing still feel near clueless and unsure of what to do next. Some very boasty (and unrealistic) books & tutorials claim to be able to teach you to code in twenty four hours or a weekend, some less optimistic experts suggest it could take ten years. I have an alternate theory.

(I offer one caveat to the above, despite not being a coding major I had an interest enough in computers and coding as a young person to take two coding courses in high school and 1.5 coding courses in university at Reed College. The 0.5 being a digital art course that was half tools like Photoshop and half the programming language Processing. And in one of my pre-full time developer roles I learned the database programming language SQL as a researcher. So I had some experience before attempting the career change.)

The essence of most coding classes & tutorials boil down to one of three categories:

1) Teaching you the fundamentals of a particular programming language (data structures, control flow, variable assignment, etc).

2) Teaching you how to build a particular type of app like a todo list or shopping basket in a programming language or framework.

3) Some synthesis of categories 1 & 2.

When I was first starting to learn Ruby there were two particularly popular tutorials, the "Pickaxe book" which is category 1 and reads like a reference book that lists how to do everything imaginable in Ruby without a lot of structure. And Michael Hartyl's Rails tutorial which is category 2 and will teach you how to build a web application using the Rails framework and emphasizes software engineering values like writing automated tests. Let's say you read both of those, what then? After a coding tutorial or online course or two or four even you certainly don't feel like you know how to program (and if you do feel like you know how to program, you're probably not being honest with yourself).

My sense is, a lot of people get either temporarily or permanently stuck in this situation. And they ask themselves once again "how do I really learn how to program?"

So here's my big take: at this point after a few tutorials, you sort of know how to program but not quite. And what I mean by that is, you know enough to do a few things. You can probably write some simple programs or edit some existing code that isn't extremely complex. Especially if the task is well defined. You know enough to do something but you are not broadly confident and knowledgeable.

The key is to take those things you can do at that first point after the initial tutorial or several, and keep going. Gradually over time grow that little bit you can do into a broad knowledge base that someday through experience will be broad enough that you feel confident you can do most things, or damn near anything and you can also explain in simple terms how to do most things to beginners. You can call it the snowball theory of learning to program. You start with a small snowball, and keep growing it until it's a snow boulder. (This advice is also partially derived from an acquaintance of mine who is a comedy writer for Saturday Night Live who I once asked for advice on getting comedy writing jobs and he told me "what's important is what you can do now, make a project with what you can do now, show it to people and build on that. I know talented people who can't get jobs because they never have anything finished to show people and untalented people who work all the time because they finish projects and show them off." Being a bit foolish, and hopefully patient I started writing a novel, that was 18 months ago and I just now finished a first draft...)

The approach above to learning programming is also similar to the approach to language learning the German language school I attended takes. They tell students early on that the goal is to first speak German well enough to be understood despite the initial mistakes you will undoubtedly make. And the most important thing you can do is not be embarrassed by your mistakes, and keep speaking and writing German while growing your knowledge of the grammar and vocabulary. Pay attention to your mistakes but don't obsess over mistakes so much that your fear of being wrong impedes your ability to keep improving.

So another takeaway is that it's important that your desire to improve is greater than your fear of being wrong.

There's a question that often comes up, "can anyone learn to program?" and I don't have an answer to that, my gut is that most if not all reasonably intelligent people can learn to program. It helps a lot to be good at logical reasoning (so it might actually be better to have a background in something like analytic philosophy, which is based in formal logic and proofs, than it does to come from some fields that sound inherently more STEM adjacent). My best guess is to be a contributor on a development team or software program of significant complexity you first have to study programming for a minimum of three months to a year. The actual amount of time depends a lot on how much intuitive grasp you begin with and how much time you have to spend practicing.

I feel incredibly fortunate that I got my first programming jobs before coding boot camps became very popular. Most coding boot camps claim they can prepare you for a software development job in three months of training or so and tend to compete with each other over the intensity of the dedication you have to commit to in those three months. This system favors the people financially privileged enough to not earn income for three months and give all their time to one zero-income project. I never had the privilege of doing something like that after taking out loans for college and growing up with a single mother who was intermittently unemployed or on government assistance (I had other family support, like my grand parents, others had it worse than me but I wasn't anywhere near comfortable and I had to work straight out of college). I don't think I would have faired well in an intense "coding bootcamp" scenario. I ended up doing some Ruby tutorials, taking an in person course that met twice a week (the teacher later went on to create one of the first successful bootcamps, lol he saw where the money was, if not what most benefitted learners), doing a few months of a dev team internship that paid barista type wages and doing an IT support job that included building some pages with HTML, CSS & Javascript before finally getting offered my first full time job as a software developer.

Another big question that arises is "what does a good programmer need to know?" Because big companies that are competitive to work at, most notably Google, tended to ask interviewees questions about algorithms students learn in computer science courses (and maybe still ask those questions) some people assumed that algorithms knowledge is very important for being a good programmer. In practice, no programmer I've ever met, whether they worked at Google or Facebook or Amazon or Netflix has ever told me that being quick with classic algorithms is the most important skill to have as a programmer. Most programmers will say the most important skills of a programmer are managing complexity (usually by being very organized & detail oriented), writing code that can be understood by your colleagues (and yourself in 6 months when you no longer have the current context fresh in your mind) and communicating effectively with your colleagues.

Often someone will argue back: "but I worked with people that just can't code at all! Technical ability is the most important skill!" So yes, being able to consistently write code that works is literally the most important skill. But assuming you can code effectively in the first place, beyond just being able to ship working code, those other three skills are the most important. You probably have to learn some fancy algorithms and be good with calculating asymptotic complexity if you want to successfully apply at Google or Facebook or the like. I studied basic computer science algorithms a few times to help with job interviews but honestly I have never been great with them, and I am never very motivated to "win at the game" of something if the work I'm doing doesn't feel like it has inherent value. I hate work that feels like it its only purpose is to get over some arbitrary hurdle someone else created rather than work that feels like it has intrinsic value of its own. Which is one reason most of my career has been freelance jobs that typically ask me "are you available to work right now?" rather than giving you a battery of algorithms tests (if you have never tried to be a freelance programmer and you ask "really? it's just that?" yes it's usually just that, the other side of it is the client can and likely will fire you quickly if you can't deliver, intead of trying to train you up to the job). And even doing mostly freelance work I've managed to work on some interesting projects at big companies. But it's a completely different career path than working full time.

One other important skill for professional programmers is reading the documentation for the tools you use. All programming is done in a particular context. If you are writing Ruby or Python or Javascript you will need to consult the language documentation to check or double check how a standard library function or class works. If you are writing a command line program you might need to check the Linux or MacOS manual pages to see how native system functions work. If you are using an open source library you may need to check the library's documentation to see how that library works (and hopefully the project is a high enough quality that it has good documentation, Ruby projects usually did, now I mostly write Javascript/Typescript and Javascript projects tend to be poorly documented). One of the worst programmers I ever worked with, who happened to believe he was one of the best and carried himself that way, actively boasted about "not being the kind of dev who reads documentation." Developers that don't read documentation figure out how things work by guessing and checking (I assume???), and eventually they miss big things by being lazy and haphazard. Sadly "no reading docs" guy was my manager and the technical co-founder at a startup, it was not long before I quit that job for other opportunities (and it turned out not reading the docs was far from the only part of his job he approached chaotically and without purpose/organization).

The funny thing about that startup is it actually was quite successful as a business at the time. This despite the fact that it was hard to hire & onboard new technical contributors because the codebase was so insanely disorganized and complex. And the haphazard non-documentation reading technical founder was constantly working late hours fixing bugs created by his haphazard process. Weird lesson: you can sometimes build a successful business on a terrible, unorganized codebase but the bad codebase has a cost that you will eventually pay if you let it fester and/or pretend it's not a problem.

The last piece of advice I'd offer if you want to get a job as a software developer is to not try to "fake it until you make it." I used to have the "fake it 'til you make it" philosophy about job and opportunity seeking. Which meant to me exaggerating my experience in the hopes that exaggerating will help me get an opportunity that I then I have to work extremely hard to catch up to the fact that whoever hired me expects me to already be better and more experienced that I actually am. The thing is, like having a shoddy, disorganized codebase: sometimes faking it until you make it sort of works. And maybe there are some opportunities you will only get if you "fake it," and it certainly can feel that way if you hear "fake it until you make it" over and over. But it is a lot psychologically safer, and helpful to all parties to be honest about what you know and don't know and to find someone who will see potential in you and give you an opportunity based on what you already know & have experience with. Rather than having to be optimistically dishonest and feel pressure to live up to something you fear you are not.

It's also super important to not be afraid to ask "stupid" questions, I ask more questions that feel "stupid" now than I asked as a beginner. As a beginner I sadly felt like I had to appear to understand, now I am confident enough to be very honest when I don't understand.

Finally, if you read this and have questions or want advice about learning to program, I'm always happy to help. Don't hesitate to reach out. And here's a list of things that helped me grow as a developer along the way:

Andrew Ritchie
Writer, Comedian, Coder, etc
hello *at* andrewritchie *dot* info

@youngggkafka
ritchiea on Github
ritchieLeaks on Instagram