Learning to program tends to center around, well, programming. When I first got into computer science, writing small programs from scratch served as my primary way of reinforcing the concepts I learned, and this type of practice proved crucial to my skill development. However, when I started my first real job as a software developer, I found that I spent the majority of my time on tasks besides writing code, tasks requiring a different set of skills.
Naturally, the exact skills required by different programming-related jobs vary. Data analysts writing scripts to process information will not spend their days the same way as technical services representatives working to solve problems for customers. Even two software engineers within the same organization could have wildly dissimilar day-to-day duties.
The skills described below are critical in many of these types of positions, though, so beginning to practice them now could give you a leg up in the job hunt and help you to succeed in your career.
Reading Other People’s Code
Whether searching for a bug or figuring out how to add a new feature to existing software, programmers spend a lot of time reading through other people’s code. This may sound like a relatively easy task. After all, writing code is harder than reading it, right?
Not necessarily. Major software applications can contain millions of lines of code, which often work in complex or unintuitive ways. Diving into one of these applications and trying to make sense of it can feel overwhelming, especially if the comments and documentation are inadequate (which isn’t exactly a rarity). Even small programs can be a big pain to read through if the logic behind them is unclear, or if they were written by the guy in the cubicle next to yours who names all his functions after Game of Thrones characters but knows the CEO as “Aunt Liz.”
Even simple functions can be difficult to read due to poor code organization and naming conventions, as well as a lack of any comments.
Learning to trace through code and glean the relevant information without getting bogged down takes time, and reading through small code samples will only do so much to develop these skills. Happily, open-source applications (such as those hosted on GitHub) provide a wonderful practice resource.
Completing some minor fixes on major open-source projects will help you learn how to approach a massive code base, as well as give you the opportunity to improve software used by multitudes of people. Or, if you don’t feel ready to contribute, just trying to figure out how segments of the applications work is a great learning experience.
As a bonus, struggling your way through a mix of open-source applications should show you the difference between good code and the not-so-good. Writing readable code will save your coworkers time and headaches, so learning by example what proper style and clear, informative comments look like makes you that much more valuable as a programmer.
Writing succinct-yet-informative explanations of what your code does makes your coworkers’ jobs significantly easier. While different organizations will have their own preferences regarding the specifics of documentation and comments, there are a few guiding principles to keep in mind:
First off, when describing the purpose of a new piece of code, make sure to explain what this code accomplishes that the preexisting code did not.
For instance, if there is an existing function that does x, and you write a new function that calls that existing function and reformats the output, your description of the new function should mention the reformatting (i.e. the new functionality added by this particular function), rather than just saying it does x (which it only accomplishes by calling the preexisting function).
If we don’t do this, then figuring out how a program works or where to insert code becomes more cumbersome. I once ran into a train of six functions (the first called the second, which called the third, etc) which all had identical vague descriptions, and I’m sure I’m not the only one who burnt through precious development time figuring out what each of them actually did.
Explaining the purpose of a non-intuitive line or algorithm can speed up the reading process, whereas just translating each line of code into English bogs readers down.
Comments like this can get tedious quickly.
Finally, keep all your audiences and their goals in mind.
If you are writing formal documentation of a new feature so that a client can approve it, a testing team team can validate it, and another development team can figure out how their project will interact with it, you should provide the particular information each of them needs. Keeping the purposes of your documentation in mind will help ensure it winds up fulfilling these purposes.
You can practice these skills while working through your Codecademy exercises. Add comments to your code or write up some simple documentation outlining what your projects do as you work through the lessons. Later on, once you’ve forgotten the specifics of these exercises, read back through them. Do your comments make understanding your work easier? Can you quickly glean enough information to know what each function or class does? Could you figure out how to test your code from the documentation?
Testing Your Code
A programmer’s job isn’t really done until their code is not only written, but tested and verified to work as expected. Even if you work for an organization with a designated team that handles testing, knowing how to run some basic checks can prevent you from passing off code with clear errors. Since getting back up to speed on a project takes time, this can prevent both you and the testing team from wasting precious hours handing the same project back and forth unnecessarily.
Testing can take many forms, from manually running your program to using thorough, pre-written test scripts. It can involve unit tests (which check if individual modules or functions work), integration tests (which see if different modules work together), and system tests (which determine if the overall system meets its specifications).
In all these various forms, though, it is important to take an organized and disciplined approach, and to think through the different possible inputs and ways of interacting with the program that we need to account for. List out everything you need to check before you start, and refer to this list throughout the testing process to ensure you don’t forget about anything. Also, make sure you check the edge cases and try doing things wrong. Users make mistakes, so it is crucial that our testing process explores how our software handles them.
Like most skills, we get better at testing the more we practice it. So, while many Codecademy exercises will validate your code for you, make a point of running your own tests. If you want more guided practice, consider taking Codecademy’s courses on the subject, Learn Testing for Web Development and Learn Javascript Unit Testing.
Communicating Effectively with Your Team and Clients
Programming often requires communicating with others. When writing software for clients or the public, we need to know about their needs and preferences in order to ensure our program will actually be helpful and intuitive.
When working as part of a development team, we need to make sure we are all on the same page about how the program will be structured, common conventions we will use, our timeline, and our individual responsibilities. When helping users encountering a software bug, someone in a customer support position might need to extract all of the potentially relevant information about the issue from the user and convey this info to a developer, who in turn may need to check with members of other teams to determine the nature of the problem and ensure that their fix won’t break something else. If this communication breaks down, it can mean disaster.
Effective communication involves more than just listening and saying what is on our minds. It requires asking probing questions to verify that we are all actually talking about the same thing, and being careful to avoid using jargon in the wrong context. It is surprisingly easy to accidentally talk past one another, especially if we are coming from different backgrounds.
I’ve been in a client meeting where my team asked if a certain piece of data needed to be “reportable,” a term we used to refer to items limited to a predetermined set of possible values. The client said “yes,” thinking that “reportable” just meant that they could access and print whatever value was entered for that item. If we had not asked follow-up questions that brought this miscommunication to light, our use of jargon could have led us to create a limited-option field where the client wanted an open-entry field.
Communication goes beyond just figuring out what we need to do and how we need to do it, though. It also entails managing expectations. If a client thinks we are going to implement an advanced AI feature that is simply outside of our capabilities, that’s a problem. If our coworkers expect we will have our interface ready this week when it will actually take another month, that’s a problem, too.
Managing expectations requires being honest about our uncertainties and proactive about reporting unforseen problems or delays. Sometimes, this can be uncomfortable. We might feel like we are letting the stakeholders down or admitting defeat. Or, we might just not want a client or manager to scream at us. Nevertheless, speaking up is likely our best course of action. Hidden problems grow and fester, whereas known problems can be addressed.
If you realize a deadline isn’t realistic, speak up before stakeholders make (more) plans that revolve around your work being completed on time. And if you need help, ask for it while there is still time.
Knowing When to Ask for Help
But when do we need help? Certainly, situations come up requiring reinforcements, a fresh set of eyes, specialized knowledge, or simply the benefit of advice from someone more (or differently) experienced. On the other hand, problem solving is a big part of programming, and if our go-to solution is “just ask the boss,” she might start to wonder what exactly we contribute.
Naturally, the proper balance between trying to figure out problems independently and seeking assistance will vary based on your particular role and organization, but following a few general guidelines can make finding this balance easier:
For starters, appreciate the value of everyone’s time, including your own.
Interrupting a coworker’s train of thought to ask a question you could find by reading relevant documentation isn’t respecting their time, but spending hours searching obscure corners of the web in vain hopes of finding an answer to a domain-specific question your coworkers would know isn’t respecting yours.
Second, keep the importance of a problem in perspective.
We all make mistakes, so getting a second (or third) opinion when you aren’t sure about something mission-critical is only prudent. Getting that third opinion about whether you should name a variable grades or grade_list? Not so much.
Be mindful of what falls under others’ areas of expertise, as well as what doesn’t.
If a coworker knows a lot more about a subject than you do, seeking their insight on a related issue can prevent you from making costly mistakes. If no one in your organization knows any more about that subject than you do, though, then asking them to figure out what you should do about a related issue starts feeling like asking them to do your job for you.
Finally, get to know your abilities and limitations.
Developing a sense for how fast you can realistically work makes it a lot easier to tell if a looming deadline poses a problem, and seeing what kind of problems you can solve on your own will give you a better idea of whether you are truly stuck on something or just need more time to work.
This last part, at least, can be practiced while working through Codecademy’s courses. Coaches and the Codecademy community are more than happy to lend a hand when you get stuck, but trying to work past snags on your own first will give you a better sense of what sort of problems you can solve all by your lonesome.
Conclusion
One skillset does not fit all when it comes to programming. An epidemiologist using a script to parse through patient data has a very different job from the developers of a new mobile app or a software engineer at a large bank.
However, the skills above are crucial to a large subset of coders, so developing them—whether by checking out large-scale projects on GitHub or writing comments and a test script for a Codecademy project—can put you in a position to succeed post-Codecademy.
