The road to becoming a self-taught developer is a long and arduous one. Sometimes, when I reflect on all the hurdles and frustrations I faced along my journey, I wonder whether I would’ve embarked on it — knowing what I know now. Ultimately, the answer is absolutely.
While the learning curve is steep for someone (like me) who starts completely from scratch, I do believe that the long term benefits vastly outweigh the uphill battle one most overcome. That is, as long as you are finding some enjoyment in the things you are learning.
It took me several years to learn that being a good software engineer takes more than just being able to build something quickly and with ease. Don’t get me wrong—checking in changes efficiently and expediently is an important part of the job, and something you get better at over time. Still, what a lot of beginners don’t realize is that learning the ropes of software development requires more than just getting your program up and running.
With all of this in mind, here are five things in addition to coding that I didn’t realize I would need as a beginner developer!
1. Collaboration Tools
A lot of the popular self-teaching coding platforms focus on learning crucial syntax and data structures of a particular language. Some allow you to create basic programs from scratch — maybe a fun tic-tac-toe game or a simple “To-do” list tracker. These lessons are invaluable for getting started on your programming skills, but they don’t really mimic the environment you would realistically work at in the industry.
Developers, after all, must collaborate on large products, and sometimes on several different code bases. In the same way that other teams use tools like Google sheets or Invision to collaborate, developers also have their own industry-standard suite of collaboration tools. At my company, and at tens of thousands of other US companies, we use Github.
I will never forget the day I was introduced to Github by my coworkers. First, I was told to open my computer’s terminal — something I didn’t even know existed on my machine. My coworkers then began typing what seemed like a bunch of gibberish inside this mystery window on my screen. That gibberish seemed to do magical things, like populate several folders on my computer with all sorts of files full of code. They began talking about “branches” and “pushing up”, and about something something “remote”. Everything seemed to start with the word git. I knew they were speaking English, but I couldn’t wrap my head around what they were talking about.
If you’re a beginner who has never collaborated on a coding project with others, learning the ropes of collaboration languages and tools (such as git and Github) will inevitably become a part of your learning process. It may seem overwhelming, especially if you’ve never explored the command line on your computer. Eventually, though, it will become second nature to you.
2. Error logging and handling
Now you’re comfortable collaborating with other engineers and merging your code into your project. It’s truly an exciting feeling to see something you’ve written get used by thousands or even millions of users. Still, if there’s anything that you learn with experience, it’s that unanticipated errors happen in code all. the. time.
Perhaps a variable that you expected to get set never ends up with a value. Now you’re calling a method on a “nil” value, and your program doesn’t know how to handle it. So it breaks and now the user can no longer access the awesome page that you built. When you test it yourself, everything seems fine, so you might not even know it is an issue. Maybe this particular error only happens 5% of the time — but 5% of 100,000 users is still a significant amount.
Learning how to log, handle, and anticipate errors in your code is a core skill that you will need to sharpen. While learning to anticipate issues is an instinct that you develop over time, as a beginner it’s important to keep in mind that errors are an almost sure thing to expect. Learning to safeguard your code with different types of error logging can save you major headaches down the line, especially when you’re tasked with debugging a problem. Additionally, it might help to catch issues that you didn’t even realize were issues in the first place. Your program is not useful if it’s silently failing for thousands of people out in the wild.
These days there are several error-logging products that make it easy to track errors in your codebase. One of my favorites is Sentry, which buckets each issue into a nice UI and lets you see when the issue first started and how often it’s occurring. Some others worth mentioning are Logentries, Rollbar, and Instabug. Some programs track more system-wide data and issues, such as New Relic and Datadog. It is likely that you will encounter some combination of programs like these throughout your career as a developer, and it’s worth learning how to use them to your advantage.
3. Test coverage
As I mentioned earlier, honing your skills as a programmer is about more than just pushing out lots of code. You want to make sure that your code is understandable by other engineers, and that someone two years down the line is able to open a file you worked on, get a general lay of the land, and get moving to make their changes. In addition to building features and designing systems, you’re also aiming to write logic that can be understood and reused for several years to come.
Still, sometimes, your logic is inevitably going to be complex. Perhaps the business logic itself is flat out complicated. Maybe you’re on a time crunch. The reality of working as a software developer for a business is that you will have deadlines, be forced to make less than ideal technical decisions, and won’t always have every use case clearly defined before you start building.
One way to add in a safety net for your code is by writing tests to accompany your changes. Most programming languages have complementary testing packages that you can install. In Ruby, we use Rspec. For React, Jasmine is often used. There are different types of tests, including unit tests (for testing smaller sections of logic) and integration tests (used to test more end to end flows). Often, all tests in a given codebase must pass for you to merge in any changes to your team’s codebase. By learning how to write these, you are adding in automated “checks” that the functionality you’ve written isn’t overridden by future changes.
Test coverage also helps to define expected behavior, since many test “cases” are written using descriptions in plain English. I can’t tell you how many times I’ve gone into a file that was written several years ago, though I understood the expected behavior, and added in a change only to have that change break 10 tests because I misunderstood what I was reading. I’ve even messed up functionality that I myself wrote several months before that my unit tests thankfully caught.
Test coverage is something that I often see left out of pull requests for both simple and complex changes. I myself am guilty of this, especially when under tight deadlines. However, I can think back on several projects where adding in a fix ended up breaking four other things; adding stress and extra work to our deadlines. Situations like these could have been avoided if we had taken the time to write unit tests. Learning how to write these can be taxing, especially for a newer developer, and they definitely slow down your overall development process. But the earlier you start accounting for them in your work, the more headaches you will save yourself and your team down the line.
4. Code reviews
This relates to my first point about collaborating on codebases. Often, when you want to merge changes into the main branch of your codebase, you will create a “pull request” or visual summary of your changes, and other developers on your team will review it before you can merge it. Different teams have different requirements for “accepting” a pull request, but in general you should expect to run your changes by at least one other engineer on your team.
On the flip side, learning how to review others’ code is going to be an intimidating yet important skill to develop throughout your career. When I was first starting out, I didn’t fully understand what I was looking for when others asked me to review their pull requests. My first assumption was that I had to be looking for bugs. A few years later, I see the code review process as more of a sanity check than a thorough investigation. Ultimately, it is up to the developer who makes the pull request to make sure that their changes are tested and are safely added with test coverage. It is not necessarily your job as a reviewer to catch sneaky issues.
These days in my code reviews, I check for things like readability (for example, are these variable and method names and self-explanatory?), organization and structure (could the code be better organized to make sense to a new onlooker?). Of course, the more familiar you become with a given codebase, the easier it will be to pick up on any potential issues. Still, sharpening your code review skills is something you can start on even as a junior developer. In fact, it’s also a good way to gain exposure to the code patterns of some of your more senior coworkers.
5. Googling the right things
No single developer knows everything there is to know about programming, or about their coding language, or even about their codebase. When I was first starting out, I assumed that everyone but me knew which methods, queries, and strategies to use right away. However, the more people I paired with, the more I realized how much googling was actually going on, even among some of my most senior teammates! There’s simply too much detail in our industry to carry around in our brains. Soon, it became clear that what I needed was not to have everything memorized, but rather to know the right question to ask.
Stack overflow is going to be your best friend. Chances are that if you’re stuck on something, someone else has also been there before. When it comes to getting stuck on problems, work on defining exactly what it is that is going wrong, putting it into words, and committing those words into Google. Learning how to define the issues you are seeing will help you exponentially more than a bunch of memorization.
Conclusion
Ultimately, your journey into software engineering is bound to bring you moments of immense frustration. That never truly goes away. But the more you can utilize the tools and strategies that have been built to alleviate these frustrations, the better you will become down the line, and the more rewarding your career will feel. Stay the course, and don’t give up.
