On Learning to Code in 2019
In the last 5 years there has been a push for people to learn to code and pursue software engineering as a career. Taking a look at Google Trends, you can see the growth begin around 2012.
From working on Coderbyte for the last 7 years, along with working as a software engineer at various companies, I had the opportunity to help people go through the process of learning to code and then watch them become professional software developers. Here are three things I learned that are important for people getting into the field to understand.
1. The initial programming language(s) you learn should align with your goals
You’ll sometimes see senior engineers encourage others to try and first learn a language like C because they’ll gain a better understanding of important computer science concepts. The problem with this is that you can in fact learn how to code and get a software engineering job without needing to know C.
If someone is learning to code so that they can design websites and get a better paying job, then they should not be introduced to programming through lambda calculus or Lisp — they should probably start with HTML, CSS, and JavaScript. If someone wants to become an Android developer, they should try and learn Java.
Yaron Minsky from Jane Street wrote an article that is very informative on what language he would teach in an introductory programming course. He makes the following comment:
In many ways, Python is the ideal interview language… But what I saw was that students who learn Python often walk away with a rather rough model of the semantics of the language. You might be surprised at what fraction of students who have programmed extensively in Python can’t guess how Python lists might be implemented, to say nothing of their ability to explain the semantics of language features like generators or decorators.
Based on this paragraph, it might seem to someone new to programming that for them to be a good programmer and get a job they’ll need to learn a language like C, and then if they do decide to pick up Python they’ll need to understand how generators are actually implemented or the interviewer will think that they’re not good programmers. This isn’t true though.
If your goal is to pivot your career and land your first software developer job, then you most likely do not need to understand those things in the previous paragraph (not that it wouldn’t help if you did). On the other hand, if you already have a programming job and your goal is to gain a better understanding of how a computer works, then sure, maybe learning C or Assembly is a good idea, but it all depends on your goals.
Here is a good article from freeCodeCamp about what programming languages to learn and the things you can do with each of them, and here’s the Stack Overflow 2018 Developer Survey which has a ranking of the most popular languages. Peter Norvig also has a good (but geared more towards CS students) essay on learning to code, where at the end he writes:
My recommendations for a first programming language would be Python or Scheme. Another choice is Javascript, not because it is perfectly well-designed for beginners, but because there are so many online tutorials for it.
Takeaway: Make sure you align what you’re learning with your goals. Don’t just choose C or Lisp simply because that’s what they teach in computer science programs.
2. Computer science ≠ software engineering
One could argue that a great software engineer understands some fundamental computer science topics such as data structures, memory allocation, how a parser works, caching, database indexes, etc. While these are all very important concepts in the field of computer science, when it comes to building software, some of these concepts matter less than you would expect. Chuck Connell, in his essay Software Engineering ≠ Computer Science,” writes:
Software engineering has an essential human component. Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system. The maintainability of software may be influenced by some formal notions of computer science… But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code.
This is why there are plenty of engineers and software developers that focused on solving a problem with a set of tools, even when they didn’t have a formal educational background, and now have engineering jobs at notable companies. Sebastian McKenzie, for example, created Babel without having a formal education in topics like language grammars, parsers, or programming language design.
Computer science and software engineering go hand in hand, but you don’t need to understand hundreds of advanced computer science topics to get a software development job (you’ll learn the most on the job anyway). I’ve worked with plenty of engineers that came from backgrounds in economics, art, and writing, and they were no less an engineer than someone with a CS degree who can solve binary tree challenges in their sleep. I would argue though that you should have a good understanding of the following topics:
- Basic data structures/algorithms
- Git/version control
- Terminal/UNIX commands
- How a database and indexes work
- MVC concepts (back-end vs. front-end)
Takeaway: Don’t become overwhelmed with advanced computer science concepts. It’s more important to build software and constantly be learning and challenging yourself. Don’t think you need to read through an advanced computer architecture book or TAOCP to call yourself a “real” software engineer.
3. Technical interviews aren’t perfect
There are countless articles on the internet about how annoying, bad, and flawed technical interview are (even still in 2018). Below are just a few:
- Developer Interviews are Broken, and You Can’t Fix It
- Are Technical Interviews a good measure of software engineering ability?
- Whiteboard Interviews Suck, Get Good at Them Anyway
There are also plenty of resources online that help you prepare for coding interviews, e.g. Coderbyte, LeetCode, Interview Cake, InterviewBit, and others.
The important thing though is that because technical interviews are just a hot topic among the community, and because companies do them differently, you need to understand that just because some companies reject you doesn’t mean you aren’t cut out to be a software engineer. There are countless examples of engineers being rejected from some top companies, and then they land a job somewhere else or they even start their own company.
There are some companies like Stripe that have changed how they conduct interviews to more closely align with how an engineer would actually work:
“We let candidates do their interviews on their own laptops,” says Raylene Yung, head of product at Stripe. That’s a lower-pressure format in which candidates can regroup quickly and privately if they make an early misstep. Once candidates are finished, then they show their work.
Takeaway: Technical interviews are riddled with issues of elitism (with colleges especially) and signaling, but being rejected doesn’t necessarily mean you aren’t a good software engineer. Keep practicing and learning and eventually you’ll get to where you want to be.
Thanks for reading! Let me know what you think in the comments :)
