5 Tackling the personal side of coding

This chapter covers

• What it means to “learn how to learn”
• The importance of side projects and why you should consider having at least one
• How making mistakes is good for you
• Why writing is great for developers

The previous chapters have covered what I think are the minimum requirements for starting your journey toward becoming a successful software developer. We’ve touched on everything you should worry about getting right and what you should focus on versus what you can ignore for the time being.

However, soon you’ll start noticing that software development starts taking over your life (if it hasn’t already). This happens to most of us. If you’re into development, you almost certainly love problem solving, and there is nothing worse than going home and leaving an unresolved problem.

As you’re eager to improve and learn more, you’ll start spending more and more time reading and watching tutorials, working on side projects, catching up on #TechTwitter (a popular hashtag on Twitter for discussing tech-related topics) or many of the other activities that can make you feel connected to your journey outside of work. And while these activities aren’t bad per se, they can definitely hurt you in the long run. Ironic, isn’t it? How can the thing you do to improve work against you? This chapter is dedicated to answering that question and to showing you ways of improving your skills in all important aspects.

And I don’t want to spoil the fun or anything, but most of that revolves around a very loaded term: work/life balance. I know, it’s a buzzword, but not everyone knows exactly what it means. Because it’s such a loaded term, I wanted to cover it in this chapter, among other things.

5.1 How are you learning?

You’ll never stop learning. I’ve covered this point before, but sometimes people think I’m exaggerating, so it’s good to reiterate it. Learning will be a constant for as long as you consider career improvement a must, so it’s crucial that you have a sound learning strategy. Not only that, but you should also normalize the fact that you’ll need it every day.

However, let’s focus on “now” for the time being. You’re probably either just getting started or working in one of your first job opportunities, and you’ll likely find yourself Googling the most basic concepts. Every few days, you’ll have to remind yourself how to use the forEach method of arrays, how the scope works for that private variable with the closures in JavaScript, or even why you would want to have private properties in your classes.

After a few months of this, that horrible voice in the back of your head starts sounding louder and louder, making you feel like you’re doing something wrong: “You better hide this from your teammates, or they’ll discover you’re a fraud.”

This is a very common scenario—so much so that if I were a betting man, I would bet that 99% of all developers go through this at the start of their career (and some still feel this way years later). It’s called impostor syndrome, and we all have to deal with it at some point.

How you’re learning can help you mitigate that voice to some degree, so let’s analyze two very different learning practices: self-learning and formal education.

5.1.1 You’re not supposed to know everything

The school system taught us that to solve a problem or to be deemed “worthy” of a good grade, we had to be able to answer questions without help from anyone. While this situation might vary from country to country or from school to school, most “standard” education revolves around memorizing facts that you can later use to solve problems or answer questions.

The real world is different, however. The real world is focused on results, and not so much on how you get there, so the first thing you need to accept is that you can ask for help. That can take many forms:

• Asking a teammate to help you solve a problem or to explain how a piece of code works

• Googling for examples of how to solve a particular problem

• Buying an online course for a set of technologies that you’ve never used before

And there are many other ways for you to learn by yourself. That’s the key: by getting this help, you’re learning. Nobody expects you to know everything you need to know on your first day of work. This is true at all levels, but especially if you’re just getting started.

The learning process, which can take any shape or form and is unique for every developer, has one main objective: to give you autonomy. When you’re starting out as a developer, you’ll be dependent on others. Your manager will have to give you detailed instructions on what you need to do, and will be checking up on you often. You’ll want to ask your more experienced teammates about the tasks you’ve been assigned and how they would solve them (or have solved them) to get ideas and examples you can use on your own. This is both normal and expected.

But everyone will expect that you will become more and more autonomous over time. Once you’ve solved a type of problem a few times, everyone will expect that you’ve learned how to do it without asking so many questions or needing so many detailed instructions. Now, I know what you’re thinking: “This section is called ‘You’re not supposed to know everything,’ but I’m being told I need to learn and know things quickly.” However, that’s not what I said. Yes, you need to become more autonomous, but remember what I said before: the real world focuses on the results, not on the journey.

Becoming autonomous can mean anything—only you know what that means for you. I personally recommend focusing on learning how to learn, instead of focusing on memorizing the details your teammates give you.

The expectation will be that every time you’re asked to solve a problem, you first exhaust all self-learning options (within a reasonable amount of time) and only then resort to your colleagues. Why? Because if you can solve problems on your own, you’re showing you can tackle new tasks without using others’ time to do so.

Learning to learn can involve learning the best sources of information for the technology you’re using. It can also mean learning to distill problems to basic (or focused) questions so you can better research the topic at hand.

For instance, suppose you’re asked to build a microservice with Python to handle purchase orders on an e-commerce site your team is building. This is your first time doing so, which means you have two options:

• You ask for guidance from a teammate.

• You bury your head in Google and try to figure out how to build a microservice using Python.

The second option may sound better to that little voice in the back of your head, but the query is too generic: “how to build a microservice using Python” can return way too many unrelated results. You’ll discover that there are multiple frameworks you could potentially be using and many standards to follow, so you’ll have to start making assumptions, making decisions based on them, and, probably, making mistakes.

Instead, if this is your first time, the first option would be the right choice. Ask someone else who’s done this in the past, but ask with the intention of learning. Ask for things such as these:

• A code walkthrough of an existing service so you can see the internal structure and frameworks used

• A written guideline, if there are any, detailing the standards to follow when building a microservice within this project

• A list of standards and technologies used to build other microservices

That approach will give you the tools you need to use, and you can then learn how to operate them on your own.

In contrast, you might ask for things such as these:

• A copy of the code so you can modify it to meet your needs

• Help coding the basic structure so you can fill in the rest

• An example of code that shows you how to solve one particular task inside your microservice

These are all solutions, but while they might yield faster results, they could also harm you more than they help you. Don’t get me wrong; a lot of people can learn from examples, as long as they use them with the right intentions. The key is to focus on growing your autonomy. With that in mind, which of the following do you think will give you more autonomy in the long run?

• Learning from these examples and then working on a solution on your own?

• Copying and pasting these solutions, and then making quick changes to get them to work without really understanding why they work.

The second option definitely will get you your results sooner, but which approach would you go for? Results are important, but ultimately you’ll have to get there on your own as much as possible.

The right answer, in case you were wondering, is the first one: learning from examples will provide the autonomy I’m talking about. This process will take years rather than weeks. As long as you tackle problems this way, learning will become second nature, and the autonomy you’re looking for will come on its own. Eventually you’ll learn a key secret that all senior developers know: there is no problem you can’t solve, because you have the internet on your side. It’s a compendium of all human knowledge, so all you need to know is how to find the right answer. You need to learn how to learn, and that’s a skill on its own.

5.1.2 The internet is great, but so is a formal education

In chapter 1, I mentioned that one of the most common “requirement” misconceptions for starting out as a developer is having a formal education. You don’t need to wait three or four (or more) years to get your first job—not when you can get the basics directly from a bootcamp or the internet. However, once you’ve started on your journey, there is definitely something to be said for going through formal education.

Everyone learns differently. Some people learn by doing, and others need to watch how things are done to understand them. Some will be more comfortable learning at their own pace and following their own interests, while others might require the constant pressure and follow-up of a teacher.

The internet is great, and it contains everything you need to know about anything, but you also have to be your own teacher. If you’re the type of person who learns better when there is someone in front of you—someone you can ask a question or ask for help when you need to—a formal education is something you should consider.

I’m not making this up. I learned programming on my own with a very limited internet connection when I was 14 years old. By the time I was 20 and got my first developer job, I started realizing that my self-learning program had been full of holes. I knew how to write code, and I was doing my job well enough, but others around me were talking about design patterns, MVC, and common best practices, and I was looking at them trying to keep my jaw from dropping.

It took me five years, but I eventually decided to get a formal education. I felt I needed to learn about things I had never deemed worth it, and I was right. After five years of work experience, I joined a three-year program, and by the time I was 28 years old, I was a programming analyst. I wasn’t an engineer, but I had learned the core concepts that I had skipped over while learning on my own.

And you know what? The core concepts were important, but not for the reason you’d think. Yes, three years later I knew things I didn’t before, and that was useful. But by learning those concepts, I had managed to do something a lot more powerful: I had silenced the voice in my head telling me I wasn’t good enough. I was now able to talk about the same concepts my colleagues were discussing, and while the quality of my code had improved, I had also gained the confidence I needed to tackle bigger and more complex problems. I had become more autonomous.

I also picked up other skills I had never thought useful for our profession, such as technical writing. I had to write so many papers during those three years that I realized I liked writing. That eventually led me to writing technical articles, and it helped me improve my communication skills.

So, yes, a formal education might not look like it’s worth your time, especially an expensive education, but it might be just what you need to take your career to the next level. The specifics in your case might be different; maybe you don’t need to know about the core concepts, but you lack formality in your study process. Maybe you’re trying to learn everything, but you don’t know if you’re going in the right direction. A formal education can help solve all those problems and give you the tools you’ll need in the future to keep learning on your own. Or maybe you’ll discover that you need to keep going back and trying higher forms of education (such as getting a masters or a PhD). Don’t discard formal education; not until you’ve tried it, anyway.

5.2 Side projects

Are you even a developer if you don’t have a GitHub account filled with unfinished side projects? Yes, you are, no matter what others might say. As long as you’re able to write code, you’re a developer, and don’t let anyone tell you otherwise.

Side projects are not mandatory, and because they’re done outside of working hours, they can eat up hours of personal time. The more time you spend on side projects, the less time you’ll have to relax, spend time with friends and family, and do all those other things humans are known for.

So why are we even discussing side projects? Well, they do serve a purpose. Consider the scenario from the previous section, where you find yourself Googling the most basic concepts. To get past this stage, one of the things you decide to do is to work on side projects, hoping that you’ll be able to practice those things you’re constantly Googling.

What kind of project can you build? How can you decide what to work on and for how long? Let’s talk about this.

5.2.1 The case for side projects

Let’s step away from the coding world for a second and take a look at Olympic athletes (stay with me, it’ll make sense in a minute). Olympic athletes are the best in the world. They take their sports to the limit by breaking them apart, analyzing every bit of them, and then working on their skills every single day. Their sport is their life; it’s not a hobby they picked up last year, and it’s definitely not something they do as an afterthought. They breathe it while they’re awake, and they dream about it when they’re asleep.

If you’re hoping to be the best developer you can be, you should consider applying a similar training program to your programming skills. I’m not talking about forgetting life and focusing only on coding, but rather about doing learning in a smart way. Optimize the time you have, and train smart—become an Olympic coder, if you will.

This is where side projects come into play (it took a while, but we got there). Side projects are a fantastic way of improving your skills (especially if you haven’t had any work experience thus far):

• They allow you to work on things you haven’t worked on before, thus expanding your figurative horizon.

• They give you a repertoire of projects to show to potential employers. This comes in very handy when you have little or no work experience to put on your resume. Someone looking to hire you for a developer job will want to know what kind of code you can write, and while they can get you to do some coding tests (something we’ll cover in chapter 6), you can provide them with samples as part of your application.

I’ve suggested side projects to many new developers, and, more often than not, the answer I get is along the lines of “I can’t think of anything interesting and original to work on; everything’s been done already.” That’s where you get it all wrong. Side projects aren’t meant to be original, innovative, or groundbreaking. You’re not looking to disrupt the software development industry; you’re looking to learn a new skill, so focus on that.

That means you don’t need to be original, so copy someone else’s project for instance, or their idea. In fact, I would argue that trying to reproduce someone else’s project is a great way to start, because you’re not under pressure to come up with every feature that needs to be included or to decide what each one should do. That work has already been done by the owner of the project; all you have to do is reverse-engineer their implementation. After all, you’re doing this to improve your tech skills, not your product design skills. That’s the beauty of it—it allows you to focus on the code without having to worry about anything else.

If that doesn’t sound appealing, maybe try some other options:

• Are you looking to get into game development? Pick up a game that can be modded, such as Minecraft, and start whaling at it. It’s a great way to learn Java while you’re also learning how to code. Other games that are great alternatives if you’re not into open world LEGOs are Civ5, XCOM 2, The Sims 4, and Skyrim, to name just a few. Modding is the perfect way of understanding how game development works, without having to do the whole game-design process.

• If you’re more into web development, building a blogging site is an alternative. There is a lot more than meets the eye when it comes to building a blog. You have to consider the ability to create content while being authenticated as a valid user; you have to understand how to deal with content formatting; you have to learn about search engine optimization (SEO) and how that affects your HTML code; and lots more. Consider building a full blogging platform if this is something you’re interested in, because you’ll also have to learn multiple technologies that are very relevant in today’s market (JavaScript, HTML, CSS, HTTP, and some form of backend language, to name a few).

• Are you into robotics? What about getting a cheap Raspberry Pi and some servo motors? You’ll be able to code in Python and control physical elements. It’s a fun way to get into this field. You could even get some sensors and build some interactivity into your project.

Whatever you work on, make sure it’s something you’re passionate about, because you’ll be using personal time to do so. During that process, you’ll face challenges you’ve never faced before, and you’ll grow your skills by problem solving your way through them.

Make sure your code is published somewhere. If you have access to GitHub, open up a public account and push your progress there. If for any reason you can’t do that, find a way to share your progress, such as publishing on Medium.com, creating a free site on Wordpress.org, and so on. There are multiple ways for you to share what you’ve done and how you’ve done it without spending a dime. By sharing your progress, you’ll be able to show others what you’ve done, how you work, and what you know. This is a fantastic business card that people can get to know you from.

The other, often overlooked, benefit of having side projects to show is that you’re also showing others you’re capable of finishing something. This is no small feat, trust me. Anyone can start a side project; it’s as simple as creating a folder and a readme file with some basic description of what you’ll be doing there. Hardly anyone, however, is disciplined enough to close a project. They forget that closing a project is not just about coding. It also includes the following:

• Closing all pending features (which, yes, requires coding)

• Documenting the intention of the project well enough for others to understand

• Releasing a final version of your library (whether it’s a compiled DLL file, a JAR file, or whatever form it may take)

Bonus points accumulate if you also create some articles, videos, or some form of content that others can benefit from. Your learning experience can enlighten others as well as you. Explaining problems you’ve dealt with and how you managed to solve them is also a good way to cement your learning and even help you deepen the understanding you have about the topic.

5.2.2 What’s wrong with side projects?

How can you accomplish everything I just mentioned without completely destroying your personal life in the name of improvement? That’s the key, isn’t it? The first thing that goes down the toilet is your “me” time. That leaves you with less time to relax and more likelihood of burning out.

Burnout is real. You can think of it as the exact opposite of how you feel the moment you decide that your personal time is not worth keeping. Right then, you’re so excited about your side project and everything you’ll accomplish that nothing else matters. Then, when burnout hits, anything else is more important than coding. You just don’t have the energy for it, whether it’s your job, your side project, or helping a buddy. It doesn’t matter, you’re done with it. And if you had a timeline to keep, that timeline is in trouble because there is no way you’ll stick to it.

What can you do? Pace yourself. Don’t think that you have to go all in or it won’t work. As I mentioned before, be smart about it:

• Keep track of your time—There are many tools out there that can help you keep track of the time you spend doing something. Use them, set yourself a reasonable time limit per week (make sure you leave time for noncoding activities), and stop when it’s time to stop.

• When you do work, work like there is no tomorrow—Focus on what you’re doing, and don’t work while watching TV or Netflix. Close your social media, put your phone on airplane mode, and focus on your current task. That way, you’ll make the most of your time.

• Working every day for small amounts of time is a lot better than doing it all on a single day—Thirty minutes a day, every day, won’t kill your free time, and even if you feel like you’re not making any progress, you’ll feel a lot better than if you work four or six hours on a Sunday. You’ll probably make the same progress project-wise, but in one scenario you’re not compromising your mental health, and in the other you’re probably neglecting other activities for the sake of finishing your pending work. This can only lead to you not enjoying your weekends and eventually skipping the only day you wanted to work, because by then you’re just tired and burned out.

Side projects are great. They can help a lot, especially for new developers, but they’re also a double-edged sword. It’s very easy to get carried away and compromise your personal time. Keep an eye out for that, and be smart about it. Work on your side projects and improve your skills, but don’t pay for it with your free time.

And if all of this sounds like too much or it just doesn’t appeal to you, that’s fine too. Side projects are not mandatory. You’re perfectly fine if you’re only coding during your working hours.

5.2.3 What about working on open source projects?

Open source is probably one of the best things to ever happen to our industry. The way developers collaborate with each other, making their projects better and more robust, is something that you don’t see in any other industry. However, many people consider this to be a waste of time. Why spend time and effort working on someone else’s project? That’s a fair question to ask, but there are certainly some benefits to doing so.

A word of caution though: there are good places for you to contribute and learn, and there are also bad places, where your contributions and questions won’t be well received. Just because a project is marked as open source doesn’t mean its creators are eagerly looking for outside help. Be careful where you choose to spend your time trying to help.

That being said, there are easy ways to spot the good projects that are looking for help, and even ones that are open to new junior contributors, so let’s focus on those.

Why contribute to open source?

From the perspective of someone who’s just getting started and looking to learn as much as possible, contributing to an open source project can bring benefits in several areas. From a technical point of view, you’ll face challenges such as these:

• Reviewing someone else’s code—Learning how to read code is very important. Through this practice, you can learn what easy-to-read code looks like and what spaghetti code looks like. I’ve been saying it throughout this book: your code needs to work on a computer, but it also needs to be read by humans. This exercise will show you examples of that. You will also pick up on techniques and methodologies you weren’t aware of by reading code from others more experienced than you.

• Getting bug reports that you never thought about—Whether it’s your own project or someone else’s, you’ll be looking at bug reports as a potential source of contribution ideas. You’ll see problems that you’ve never encountered before, like memory leaks, race conditions, and other things that happen when you take a piece of code to the very limits of its design. If you’re just working on your own side project without real use-case scenarios, you might never encounter real-world problems such as these.

• Getting your code reviewed by others—Just as important as knowing how to read code is knowing how to take criticism and how to accept a recommendation or an idea about how to improve your code. As much as you can help a project with your contributions, the project itself will benefit you by pushing you to grow as a developer, to apply better standards, and to learn new techniques. This is one of the major benefits of contributing to open source projects.

• Following coding standards—For your contributions to be accepted, you’ll have to follow certain project-wide standards. That’s reasonable, considering that whoever is going to review your code needs to know how to read it. In the end, even though the project might have hundreds of contributors, the code should look like the same person wrote the whole thing. This is great preparation for working as part of a team in a company.

• Git, Git, and more Git—Currently, Git is the version control standard that most open source projects use. This means that for you to be able to work with them, you’ll have to learn about Git. Guess who else uses Git? Almost every other software company in the world. By learning Git, you’re not learning a new skill that you’ll only use outside of work; rather, you’re getting used to working with one of the main tools in any development project.

From an organizational perspective, you’ll get the following:

• Insight into running a complex project—This won’t happen from running your own side projects. However, you’ll experience organizational hazards by contributing to large open source projects. Some of them have committees to evaluate who gets to contribute and who doesn’t, or what the project’s future looks like. Some of these projects are 10 minutes away from suddenly turning into companies on their own, so their internal procedures resemble a lot what you’ll find working for someone else.

• Autonomy—Open source projects don’t really have managers who will spend their time following up on you and checking how you’re doing. You either work on your contribution, following all standards and guidelines, or you don’t. Nobody really cares if you quit mid-feature; someone else will pick up where you left off, or will start over. It’s kind of a swim or sink situation, so you’ll have to push yourself and learn by yourself—that’s a skill every manager wants their team members to have!

• Flexibility—If you like the experience and start contributing to several open source projects, you’ll have to be flexible when it comes to the way you work. Not every project will require the same processes or the same coding standards. The more alternatives you see, the more flexible your process will become. This, in turn, makes you a great asset when it comes to finding new profiles for new projects within a company.

You will be helping projects by contributing your work (in whatever form that work might take), but the one getting the most out of this interaction will be you. You get to learn, you get feedback, and you get to experience new ways of working.

It might be scary at first, thinking you’re not good enough to contribute to a big library or framework, but anything you can bring to the table (even a simple typo correction in the documentation) will be received with an open mind and the intention of making something great even better. This is the main philosophy behind open source and why I always recommend new developers try to contribute to at least one project if they have the time. It’s an experience you have to go through.

How to pick the right open source project

Once you’ve made up your mind and decided you will contribute to a project, you have to find the right one. The internet is filled with open source projects because pushing code to a public place is easy and free. That said, not all projects are looking for contributors. Some developers will clearly let you know in their main documentation file (usually called readme.md) that they’re not looking for external help, or what the process for contributing looks like.

If there are no guidelines, I recommend staying away from trying to contribute, unless, of course, you’ve identified a bug in their code and already have the fix for it. In such a scenario, I would try to directly contact the author and ask for permission to create a pull request (essentially a merge request of your branch into their main branch). That is the bare minimum etiquette you’ll have to follow in such a situation.

If, on the other hand, you do not have a particular project in mind, you might want to look at some of the libraries and frameworks you use in your daily work. Most of them will have a contribution process in place, and some will go so far as to tag issues and bug reports specifically for newcomers. Tags such as “good first issue” are indicative of a project that’s perfect for a newcomer like you. The Node.js project, for instance, does this (https://github.com/nodejs/node/issues). If you see something like that, consider reading it. Sometimes these will be very focused changes, or even documentation updates. The point of those issues is to get you started in the process. Once you know how that part works, you can start looking for more interesting and relevant contributions.

Finding such projects is not easy, but luckily for you, there are people who have already been through this and decided to create some online help for developers like you. The main place where you can get the information you need is “First Timers Only” (www.firsttimersonly.com). It contains a list of different places where you can find the perfect first open source project to contribute to.

Wherever you end up pushing your code, always remember the following:

• Be polite. You’re getting as much (if not more) out of this interaction as the code owners are.

• Understand that getting a response might take time. They’re not sitting there waiting to get contributions. The owners of these projects have lives too.

• Follow every single point in their guidelines. If they’re there, it’s for a reason. Don’t try to skip steps because you think you know better.

• Have fun throughout the process. You’re doing this mainly to learn and improve your skills, but it doesn’t have to be boring. There are plenty of projects out there that are looking for help. Find one that makes you want to help out.

Whatever you decide to do about this, remember, there should be a balance between how much work you put into these projects and the rest of your life. If you put too much effort into these projects and neglect other areas, it’s not going to be worth it in the long run.

5.3 Asking your online friends for help

We as developers can’t function without access to the internet; it’s just not practical. The internet has all the information we need, and when we can’t find it, we can ask others for help. Unfortunately, not everyone out there is willing to help. The anonymity of different social networks sometimes brings out the worst in people and makes them think they’re better than others.

Sadly, a common scenario I faced multiple times while learning how to code was finding a community of developers who were sharing information with each other but would not accept newcomers. Instead of helping newcomers, they would laugh and make jokes about the lack of knowledge I had. Back then, they were forums; today we have communities on sites such as Reddit, Hacker News, Twitter, and even Facebook, where many developers still indulge in such terrible gatekeeping against newcomers.

This is one of the reasons why some developers are not inclined to publicly share their work while learning—many others will laugh at their mistakes instead of focusing on the great progress they’re making. This is yet another way in which coding can affect our lives, not because it takes too much time, but because we’re leaving the door open to that kind of negative energy.

A lot of newcomers joining online communities are told they’re not yet a developer. The excuse may be lack of professional experience, or lack of knowledge, but whatever the reason, it’s wrong. If you can write a line of code and make it work, you’re a developer. Period. Own it. Don’t let anyone else online determine your future by digitally stepping on you. They have no right to do so, so ignore them and keep pushing.

5.3.1 Making mistakes

Everyone learns differently, but a very common way we humans learn is by blundering. Making mistakes and suffering the consequences shows us what not to do, so that next time we face a similar situation, we know what to avoid and to try something different.

Mistakes are not a bad thing. In fact, they’re a teaching mechanism, and if we learn how to take advantage of them, we’ll be constantly improving, even when we break things. The trick to taking advantage of mistakes is not hard. Thomas Edison said, “I have not failed. I’ve just found 10,000 ways that won’t work.” Is that the statement of a loser or a genius? He literally flipped the meaning of failure to be success. Every single “no” put him one step closer to the final “yes” he was looking for.

If you want a more contemporary and on-topic example, take a look at Elon Musk with SpaceX. He wanted SpaceX to be the first company to land a booster rocket after a successful mission (previously, boosters would land uncontrollably in the ocean). This meant pushing the current state of technology to its limits and then going further. Every failed test meant a rocket would be destroyed, but there was no other way of testing, so they took advantage of that. Every test was measured from every potential angle, and every sensor in place was giving SpaceX telemetry about a particular system.

According to interviews, the first Falcon booster to land correctly was the very last attempt that SpaceX had money for. Had it failed, they would have had to close their doors. However, after every failed attempt, they corrected their mistakes (thanks to the telemetry they had received) and tried again. Every “no” put them closer to landing that day, because they were smart about it. They were learning from their mistakes in order to avoid them in the future.

That is why we, as developers, need to make lots of mistakes (being smart about it too), because that is one of the best ways for us to learn. The key here is to fully accept that failing to meet our end goal is an option, because we’re making small gains along the way. Every time you get a compiler error, or every time your algorithm doesn’t work exactly as you had expected, there is always something to gain. You have to avoid listening to your internal voice telling you that you’re never going to make it, and you also have to ignore those online gatekeepers who think they have the right to tell you if you’re good enough or not.

The term gatekeeper, in this context, refers to people who consider themselves the absolute owners of the definition of the word “developer.” They think they know enough to decide who gets the title and who doesn’t. That, of course, is nothing more than an illusion, but gatekeeping is sadly a very common practice in our industry. The anonymity provided by social networks allows for people like that to reach those who do not know better (like new developers). The best way to fight them is to ignore them. Do not engage with them, and do not accept what they tell you—just do your thing, and keep learning and finding ways to improve. As long as you do that, you’ll solve every single challenge you face.

5.3.2 Avoiding the naysayers

Some online communities are better than others. In general, my online experience has been positive. I’ve met a lot more people who wanted to help than those who didn’t. And, eventually, I also learned to ignore or even block the gatekeepers, since there is no point in listening to what they have to say.

If you have the chance, getting yourself into a nurturing community will provide a lot of benefits. Sadly, there is no whitelist of communities you can use. You’ll have to test them out and see for yourself. For example, local meetups are all the rage right now, and they’re usually very focused, small groups of developers who have similar interests. And while there might be one or two gatekeepers in there, the majority will be interested in helping others, so they’re a good option. If you don’t know whether there are any such groups in your area, you can go to Meetup (www.meetup.com) and find something nearby. Local conferences are also very good places to network and meet other developers in person, but they’re not as common, and some of them can be very expensive to attend.

When it comes to online spaces, I’ve personally had good luck with Twitter, especially around the #TechTwitter hashtag. Many developers following that tag are eagerly looking to help others, either with online moral support or actual help with code. That community is very aware of the perils of gatekeeping, so it is a very safe place for newcomers to ask questions and get help. If you’re not there yet, give Twitter a chance.

In any case, the point of these communities is to help each other to learn and grow. As a general rule of thumb, if the feedback you get is not constructive, ignoring it is probably the safest bet.

The same goes for you: do not become a naysayer three months into your journey. Keep your ego in check and try to give as much feedback as you would like to receive. Try to be as constructive as you want others to be with you. Otherwise, you’ll never find a community that suits your expectations. Everyone is looking for the same thing you are, so the only thing to do is to all contribute in the same capacity.

5.4 Learning to communicate with others

Throughout this chapter, I’ve talked about learning, places to learn, the attitude you should have toward learning, and how to make the most out of your learning experiences. The last thing I want to cover, which will also help improve the way you learn, is getting better at communicating with others. Hear me out.

Knowing how to communicate with others is a skill you need to learn. Having great communication skills makes for great developers. Someone who can explain the development plan to a nontechnical person so they understand what’s at stake, why the timeline looks like that, and why they have to pay twice as much as they thought is a great asset on a development team. And there is no better way of developing these skills than jumping into the communication waters.

There are two main types of communication: direct and indirect. Direct communication involves you being in front of your target audience, whether that’s a single person or a room filled with hundreds. We’re talking about internal technical presentations for other tech teams in your own company, or coaching a colleague who’s just getting started, or perhaps presenting a talk at a programming conference. These are all great ways for you to practice communicating complex topics in simple terms. It’s not an easy thing to do, but by doing it, you’re showing what you know about a particular topic. Whether you’re an expert on the subject or you research the heck out of it for the presentation, you’ll look like an expert to your audience. And if you don’t think so, consider the last time you were on the receiving end of one of these talks. Did you consider them experts? You did, didn’t you? Good direct communication skills can help you achieve this.

Of course, if you’re introverted (like me), you’re probably having a small anxiety attack just reading this. And I get it, I was there too. But trust me, while presenting might not be something you do regularly, you need to be able to step up and explain a complex concept when needed: your team might need it, or your manager might request it. Whatever the reason, you need to be ready.

On the other hand, you might prefer to try and work on your indirect communication skills. Don’t think that just because you’re not in front of people it’s less relevant or less difficult to develop. You can work on this skill by writing articles, creating videos, building online courses, or however you like. My personal recommendation would be to try blogging. Why? Because it’s the cheapest way of starting—you don’t need a lot of software, and you can get started and publish your first article in two hours (or less).

Either way, by taking the plunge, you’ll start working on a skill that most developers ignore. This will, in turn, set you apart from the rest. And the best part of it? The more you write and the better you get at it, the better you’ll also get at speaking. Explaining complex concepts orally will be easier, thanks to your writing experience. So while you’re focusing on your indirect communication skills, you’ll indirectly improve your direct communication skills as well. As long as you focus on developing your ability to explain technical concepts to others, you’ll be improving all aspects of your communication, both direct and indirect.

Don’t underestimate this communication practice. This is as important as working on your coding skills. I think that every developer interested in improving their career must work on this. I’m not saying, “Go and become an online influencer.” All I’m saying is, “Get a blog or come up with a technical presentation.” The more you do it, the better you’ll get at it. Kind of, anyway.

The caveat is that you’ll have to find ways of getting feedback; otherwise, you’re working in a vacuum. Direct in-person presentations allow you to see the reactions of your audience and the engagement you get from them, and you can reflect on that for the next time. However, when you’re building indirect communication skills, you have to find other means of getting that feedback. People might find your content by chance, and they might give you feedback. If they do so, use it to improve. You’ve got to start somewhere, and it won’t be easy, but take advantage of social networks and share your work there. Use your colleagues as guinea pigs, and send your work to them. The topics you cover will most likely be interesting to them as well. Take advantage of places like Reddit, Hacker News, or even Dev.to, where you can reach thousands of developers without having to spend years building an audience. The goal here is to understand the problems you’re having when it comes to explaining complex concepts to others and correct them for the next time. Think of it as bug fixing the way you communicate. The more feedback you get and the more you iterate over it, the better it’ll be.

Summary

• Work/life balance is crucial to having a healthy career. The more time you spend coding, the less time you’ll have to do other things. Avoid burnout by keeping a healthy balance between coding and other aspects of your life.

• You can learn however you want, whether through self-learning on the internet or through more formal education. Either way, what you learn should work toward giving you autonomy in your work. Your focus should also be on becoming better at learning rather than knowing who to ask for help.

• Side projects are great ways of working on your skills, and they also help you create an updated portfolio ready for potential employers. Don’t worry how original these projects are. Focus on finishing them and on what you’ll learn through the process of building them.

• Open source projects are also a fantastic place to learn about real-life problems, without having an actual job just yet. Consider going through the process of contributing to at least one of them.

• Understand that making mistakes is part of our job—you’ll be making mistakes as much as you’ll be learning for as long as you’re a developer. The point about mistakes is to understand that every problem is a learning opportunity waiting to teach you something.

• Finally, write, write, and then write some more. Keeping a blog as a developer is a must-do if you care about improving your career beyond coding. Writing will give you the practice you need to develop better communication skills through the process of explaining complex concepts in your articles. Remember, developers who can explain themselves are developers everyone wants on their team (trust me on that one).