Go build a project, they say
In some ways this is the continuation of an article I published a while ago called Reflections of a Self-Taught Dev. It got some positive feedback and was even picked up by Better Programming (thanks!). You don’t need to read it at all to understand this, but if you’re wondering what got me to formulate these ideas (for some weird reason), check it out.
Why Don’t We Teach Practical Coding?
A recruiter called me a bit ago and asked me if I knew how to code Python. I said yes. She asked me if I had proven experience. I said that I was in the middle of a commit to an open-source Python repo. She told me that wasn’t enough and got off the phone pretty quickly.
One thing that more or less everyone I know in the programming world agrees on is that a degree in coding (whichever degree in coding) doesn’t teach you how to practically code on a job. I’m not saying this to complain about the system, by the way. Computer Science especially teaches some fundamentals, gives the building blocks of languages, and helps break down how programming works. I suspect that CS buffs make for better workplace developers once they get the practical part down.
To restate this, the value of a programming college degree in terms of employment isn’t that it proves you can code, but something more ethereal. It proves that you can persevere through years of classes and tests, and so you will probably be able to pick up how to code in production.
I suspect that bootcamp and online course certification probably work in a similar vein. Bootcamps especially are generally much more practical, but there’s still a gap between any bootcamp curriculum that I’m aware of and any workplace I’m familiar with. Still, bootcamp certification proves not necessarily knowledge, but perseverance, and the presence of basic skills. Someone with these, in all probability, can be a worthwhile hire. Or so the logic seems to go.
I’m neither of these. I learned to code in a small room, generally on my own. How do I prove anything to anybody?
Generally the first answer I hear is to build up a portfolio online, on GitHub or any similar platform. I personally feel that there is a bit of a fallacy with this, and I’d like to explain why.
Let’s start the other way around. Why don’t colleges and even bootcamps go the full length and teach totally practical workplace coding? There are a number of answers to this, I believe. Some are good, some not as much. One that I’d like to focus on, though, is that 100% practical coding is, in my opinion, impossible to structure courses around. I’ll explain this opinion with an example.
Programming languages alone aren’t enough to build pretty much anything in the real world.
No problem, you say, we should just add these to the coursework. Let’s throw in React and Express (I’ll just slip in Node with the Express). There are two problems already.
One. Well, the frontend and backend aren’t enough. To really leverage CSS, you should learn Flexbox and Grid. (Yes, and. Simple things like navbars are really for Flexbox, and anything with multiple rows should be Grid, not just according to me, but according to people who actually know how to code all over the web.) So, okay, put in Flexbox and Grid. Still, are you really going to be able to code a 2019 website with just Flex and Grid? You probably need at least some SVG hacking too. I think you see where this is going, right? There are already pretty much an impossible amount of things to take on in the beginning.
Just in case you think that the list ends there, just remember that if we’re teaching practical, you should probably know how to deploy and host. I won’t spam you with ten lines of things to learn for that.
Two. Let’s say we only needed two things: a frontend framework and backend framework. I wrote above that perhaps we’d go with React/Express. That’s a reasonable thing to say in September 2019. How much longer will that be true? I figure the Vue people are already saying that Vue is taking over, and Express could easily be unseated. Not just that, but React itself is a moving target. What I mean by that is that what React code looks like changes and it changes fast. Redux used to be the way to handle global state. Is it still? Classes used to be more popular, but now the general direction seems to be more functional. React code from two years ago versus React code now, at least to me, is not recognizable as part of the same framework.
The point being, the landscape of practical bleeds into the cutting edge, which is about a centimeter over the edge towards hipster. How can you pick your course syllabus when the landscape shifts so much during the amount of time it takes to teach a course? And then can you really change your syllabus constantly? Not really.
I think these two reasons necessitate that courses only give the first basic steps, a beginning that is hoped to allowed alumni to intuit next steps, or, more likely, will enable them to get trained in on their workplace’s stack. This brings up something close to a third point: the stacks in different workplaces vary so much that it is truly impossible to teach all of the tools one might need. It’s hard enough to learn the entirety of one stack, which is why most websites these days are built by teams.
We have reached a weird point in development, where the complexity of any given practical app or website is so great that the requisite expertise is unlikely to be found in any one person.
I’m not saying such people don’t exist. They do, and they’re awesome. They’re just uncommon. All this means is that you certainly can’t structure education in a way where it points to such an unlikely goal.
To change directions for a second, I’d like to define the term intermediate programming.
I feel like intermediate programming is the level of programming most non-senior professional programmers occupy. They have the requisite expertise in enough technologies to do a job, basically. That is a pretty vague definition, and it relies on intuition as to what jobs entail. I can’t entirely avoid it, and don’t plan on submitting the definition to any dictionaries (/s).
If you know enough technologies to be able to do a reasonable amount on a team professionally, be it frontend, backend, design, or whatever, then you have achieved intermediate programming in your area(s) of expertise, in my book.
Junior devs generally do not have this kind of experience. Why should a junior know how to deploy to Firebase? I don’t think it’s weird if they do, but I totally don’t find it weird if they don’t. Still, if they work in a workplace that deploys using Firebase, then they’ll learn however much they need to fit in the pipeline.
Tangent — that may be nothing, depending on how DevOps is handled, but it begs the question: do Juniors need to know how to use Git (or any other version control)? It’s difficult indeed to work in a team without version control (meaning Git), and I suspect Git is ubiquitous enough that it really should be taught at the education level. I’ve seen some places do this, but most don’t. My opinion is that it is easier to learn Git early than late.
Now, the question I’ve really wanted to get to is this: how does one become an intermediate programmer? I should put that in quotes to make it stand out and look cooler:
How does one become an intermediate programmer?
How Does One Become an Intermediate Programmer?
One option is listed above, and I suspect that’s is how most people who’ve achieved this got there. They were trained. This is great, it’s a very reasonable way to get there, but there’s a catch, or actually a paradox. I mentioned at the top that coders who don’t have a degree or certification get told to build projects to prove themselves. But if the expertise to do so only comes with getting trained in as a hire, then they need to get hired and trained before they can prove that they are hirable. There’s also the issue that you shouldn’t have to be a full-time professional coder to get to Intermediate. You should be able to teach yourself code because you think it’s awesome, and do whatever you want to do on your own. While this might not end up with building entire projects, if you have a few like-minded friends, it totally can.
I’m certain that there are other options. It would seem to me that people who start coding as kids tend to have gotten there on their own. I’m going to speculate on that for a bit. Most people I know who coded as kids were coding to build something as kids. Even if their fantasies were that it was going to be the best and coolest, they were able to learn whatever they could get their hands on. These production goals, if I can call them that, spurred them to learn enough to get to Intermediate level. Once you’ve reached the Intermediate level in something at a young age, I suspect it’s not amazingly difficult to get to Intermediate in something else, at least if it’s similar to the first something.
This would seem to be the path of self-teaching Intermediate coding. If you have a fire lit up underneath you for a website or app, you can probably do this at home too. I see these stories about people who just charged through and built something. I even met a guy once, a manager in a print shop, who barreled through Java in order to make an app that would figure out how to fit as many jobs as possible on one sheet of paper. Most things these people seem to share is massive bursts of energy. If I remember the story correctly, the print shop manager didn’t sleep much for a few months.
For the Rest of Us
For those of us who don’t live on the sharp edge of adrenaline, I’ll outline some other ideas. One is mentoring. You probably have friends who code at the Intermediate level. See if any of them will mentor you and just learn whatever they use. People are nice (at least some of them) and maybe your nice someone will also be at least OK at teaching. If one of your friends onboards at their place of work ask them first, since that may indicate that they are at least OK at disseminating the information. Not necessarily, unfortunately, since the state of onboarding is pretty bleak, but there’s at least an increased probability!
Similarly, if you know anyone at the same stage as you, work with them. Many people solve problems better when they’re working with someone else in some capacity. I am very much like this. Just today I was looking for a bug, and finally gave up and asked for some help in a chat channel, and then found it on my own. Something about asking really clears my mind. Some people simulate this on their own (this is known as ‘rubber ducking’ — if you’re having a conversation with your rubber ducky!), but I haven’t had much success that way.
You don’t even have to be building something together — you can share a chat channel and just bounce things off each other in a safe environment. Working together takes on many facets, as there are many modes of collaboration. Do you actually write code together? Do you work on different aspects of the same project? There’s no one right answer, but you should try to figure out the situation where communication works best. Some people need more space, some people need less.
Another is just picking stuff and going for it yourself willy nilly. FreeCodeCamp has a few tutorials on their YouTube that they labeled as Intermediate (like a 12-hour piece on React/Firebase which is probably why I picked on Firebase above).
A corollary may be open source. This can be tricky since an open source maintainer’s job is not necessarily to train the masses for free. Still, if you have areas or projects of interest, periodically look through their issues on GitHub (or wherever). If you see something you think you can take on, go for it. You may also be able to meet the team through services like Gitter and get a feel for how easy it would be to work with them. Be prepared for some rejection and disappointment. You may also find a friendly and understanding team. You may even be able to explain your situation and get some guidance on what to take on and how. If you have the courage, go for it!
I would strongly recommend podcasts. They can give you a huge amount of knowledge about what’s out there. Software Engineering Daily is absolutely amazing at that. If you can keep up with even a fraction of the podcasts they release, you’ll know a ton about what is out there. Pretty much every nook and cranny of coding has its own podcast(s), or at least podcasts about it, so if there’s something interesting to you, dive in.
For Those Seeking Employment
If you need to get to Intermediate in order to get hired, I should probably dispense some more unsolicited advice. All of the above routes involve coding something, obviously. Push it to GitHub or equivalent, and link to it in your CV. Even if you are just literally parroting that 12-hour goliath on Firebase line-for-line, push it. Being able to parrot extensive amounts of code would seem to carry a similar effect as degrees and certifications — it shows perseverance. It’s a weaker effect though, perhaps because it implies someone will click through and look around. Being that HR don’t necessarily know much about code, this is trickier than it may seem.
I have nothing to substantiate this, but I suspect a social media presence might help. If you write, blog, and/or tweet about code, and probably even if you just take ‘coding pictures’ and get a following on Instagram, it will make you ‘look more like a coder’. I feel bad suggesting this, as it might not actually have anything to do with actual coding, but if you’re self-taught and feel like the chips are stacked against you, you deserve some more options at your disposal. Plus, you can take pictures of your code when you need a break and feel like you’re ‘being productive’.
Lastly, try to get some help with your CV. I’m going to mention some personal experience as a self-taught. I would have never put that I know how to use Linux on a CV. I figured all devs are supposed to be at home on Linux, so why mention something that everyone is expected to know? A friend convinced me to add it and he’s been proven right. Even when I put Linux on, I would never have thought to put on Git and Bash. I mean, using Linux means using Bash and the occasional messing around with Bash scripts,— if you code, especially on Linux, you know Git, right? A friendly recruiter was kind enough to point out that I shouldn’t take that for granted. A friend of mine who hires freelancers told me that he interviewed someone who had written that they were experienced in PHP who literally didn’t know what the command line was. (It’s your terminal — Bash or PowerShell or whatever. I don’t mean that he didn’t know the technical term ‘command line’. I mean that when confronted with a command-line his response was ‘what is that’. Literally.)
You probably have more taken-for-granted expertise than you think. Have you built an API and used Postman to test it? Write that you know Postman. Did you pick up Emacs or Vim? Write it. You get it. This may be easier with a friend, though alternatively, you can try to keep track of every application, library, module, and framework you use over a week. I’m not saying that you need to write every last single one down, but you might. To bring an example from React, if you’ve set up a React app without Create React App, you have at least some experience with Babel and Webpack.
So, that was a lot. Let’s wrap it up.
We’ve talked about Intermediate Programming as job-level programming. You can get there by being trained on the job. This is probably the easiest way to get there for coders with a degree or perhaps even a bootcamp certification.
For those without a job to learn on, we outlined a number of tactics. These include:
- Finding mentors
- Finding friends and banding together on projects
- Picking Intermediate-level technologies that interest you, and learning them
For those looking to convince potential employers that they have this level of coding:
- Push your code, any code, even code you parroted from tutorials to GitHub or the like, and link to it in your CV
- Maybe a social media presence?
- Get some friends to help with your CV
I hope this has been an interesting read for you! Thanks for making it this far, and I look forward to whatever comments you might leave.