7 Working as part of a team

This chapter covers

• Interacting with your manager and understanding their expectations
• Being part of a development team and working to benefit the team, not just yourself
• The importance of improving your skills and how to do it

You are never alone as a developer, even if right now you’re working on your first project by yourself in a dark room. That code may be intended as part of your portfolio, or perhaps it’s a new product you’re hoping to release, but the moment you need advice or help from others, you’ll stop being alone. It’s just a matter of time.

No matter how much you try to work on everything alone, you’ll soon realize that there is a lot more to a software project than just the code. And you know what? That’s good! Accepting that you’ll never be alone is the perfect first step to start learning how to be a good team player, because sooner or later you’ll be working as part of a larger team. If you don’t know what that means for you, the whole experience will go as smoothly as swallowing a smoothie made from rocks. This chapter will outline the social and technical tools you need to make that first team experience a success.

7.1 Getting your manager to love you

The development team you’re going to be a part of is not only composed of other coders like you; it’ll have multiple roles, and one that you’ll want to pay special attention to is your manager.

Suppose you’re starting your very first job as a developer. You’re introduced to your team and your project, and now you’re starting to deal with your manager. You quickly figure out that one potential way up in your team is with the help of your manager. You just have to impress them—take their breath away, if you will. So what can you do, other than kicking them right in the gut when they’re least expecting it? (Please note that this is intended as a joke. The author of this book does not condone kicking your manager in the gut for any reason—especially your current manager.)

Let’s look at some options that will help you achieve this without raising many strange questions.

7.1.1 Task-tracking software is not the devil’s tool

Task tracking is not evil, even when sometimes it might feel like it is. I know, we all want to code and forget about the world for eight hours straight, but that’s not only impossible, it’s impractical as well. Coding is going to be your main task during your work iterations, and it’s definitely going to be your focus. It just can’t be your only focus. Task tracking is one of those noncoding activities developers tend to either hate or underestimate to the point where they’ll leave it to the very last day.

The first thing to understand is that task tracking is not meant for you. You already know what you’re doing, and if you are somewhat organized, you also know what pending work you have. So why does your manager keep asking you to update the task-tracking tool every day?

Put yourself in the shoes of your manager. You have a team of developers working on the next release of a feature. You’ve made a commitment to the stakeholders (be it the company owner, a potential outside client, or any other person who has a stake in this release), they are counting on you to meet the deadlines, and they’re basing their business strategy around that fact. On the other side, you have your team, wailing at their keyboards, trying to finish the feature on time.

When your stakeholders call to see how everything is going (because they will), how will you answer them? Your job as a manager is to always understand how the project is going and to know if there are any blockers or delays and why. To get that information, you have three options:

• Assume—You assume your team is doing the best they can and that everything is going smoothly, because, otherwise, they would have said something. Of course, this is completely wrong. Not all developers will say something when there is a problem, and if their initial estimates are wrong and the task is too complex to finish on time, you’ll never know until it’s too late.

• Ask repeatedly—You go one by one, having a quick talk with every developer, asking for a status update. This will take between 10 and 30 minutes per developer (depending on the task and the developer). In an 8-hour work day, 30 minutes doesn’t sound like a lot, does it? Wrong, it is because you’re not just taking 30 minutes of their time; you’re breaking their concentration and asking them to switch mental contexts. That is, by itself, a huge effort, and it’ll take them more time to get back into the flow they were in before your interruption. And to top it all off, you have to take notes and then summarize them to produce some sort of overall report.

• Track—Get the information from a summary report produced by the task-tracking tool you and your team are actively using. Yes, this is absolutely the right way to do it. Of course, this can only work if your team is actively updating the tool, which is why you have to remind them, every day if it’s necessary, that they need to do it.

Step out of your manager’s shoes now and back into your own. Is your manager still pesky and annoying? Or are they only trying to do their job, and you’re not really helping? A quick status update can be as simple as dragging a card from the To-Do column to the In Progress column. Or it can mean entering a comment mentioning that you’ve hit a blocker, or perhaps adding, at the end of the day, the approximate number of hours you’ve worked on a task. It takes you a minute to do, and your manager will love you for it.

Let’s take a look at another area where you’ll need to focus: meetings.

7.1.2 Meetings!

Meetings are feared and loathed by many developers because they see them as a big waste of time. In fact, you can even get T-shirts on Amazon that say “I survived another meeting that should’ve been an email.” I’m not saying developers coined the phrase, but it’s definitely a common catchphrase in our industry. Whose fault is it, though? And are all meetings unnecessary and a big waste of time?

No, they’re not, especially now that remote work is becoming the norm for some companies. Meetings are required, and a well-organized and -executed meeting can provide a lot of value. The key is to focus on the meeting’s purpose and try to keep the conversation on topic the whole time.

As a developer, you’re expected to join multiple types of meetings:

• Status updates—Usually you’ll have to join a quick call with the whole team (unless the team is big enough that it merits submeetings) every day. This meeting is supposed to end quickly, and you usually need to speak about your tasks from the day before, any potential blockers you may have, and the tasks you’ll be working on that day. This is known as “daily standup” in practices such as scrum or agile, because it happens daily, and it’s meant to be performed while standing up, so everyone will hurry up with their updates. Other methodologies may implement variations on this daily status update. The point is that you’ll likely have meetings of this sort.

• Ad hoc meetings to resolve a blocker or answer a question—These meetings will usually involve you and whoever can give you the solution you need. You’ll have to prepare for these meetings by being capable of explaining what you need and why.

• Demo meetings—If you’re working on a product, you’ll usually have to join demo meetings to help answer any specific technical questions about the feature you worked on, or perhaps to show what you’ve done and how it works. Depending on your project, your team’s composition, and the way your project is handled, you might not be required in these meetings, especially if you’re just getting started. Eventually, though, you’ll be joining them as well.

• Retrospective or postmortem meetings—These may be called something else where you work, but the point of these meetings is to review past work, understand what went well so you can double down on it, and what went wrong so you can try to fix it for the next work iteration. These meetings are usually less technical and more social in nature, but their focus is still your project and your work, so don’t be fooled by the lack of tech jargon. Some teams tend to ignore these meetings and power through any issues they might be having. That’s not ideal, and if you find you’re seeing a lot of problems and not having an opportunity to discuss them, it might be a good idea to bring this type of meeting to the attention of your manager.

There may also be other meetings where you work; it’s really up to your team and your manager. However, there is one consistent characteristic about all of them: they’re meant to serve a purpose. Notice how I said “meant to.” If the participants do not take the meeting and everyone else’s time seriously, the purpose might be lost, so consider meeting etiquette important when joining one (either in person or online):

• Be there on time. That doesn’t mean joining the call or getting to the meeting room exactly when the meeting is supposed to start. Being there on time means arriving or joining a few minutes early. That way you’re ready to get started when the meeting starts. Joining at the moment the meeting starts means being late, because people will say “Hi” to everyone and you’ll all lose a few minutes from the meeting. The more social you’d like to be, the sooner you should be there so you avoid wasting the time of those arriving closer to the starting time.

• Avoid chitchat during the meeting. Whether it’s an online or in-person meeting, remember that you’re all there for a reason. Unless this is a social meeting, you have a limited window of time to cover the topic (or topics) at hand. Chitchatting or having small conversations in the middle of discussing a topic will only delay the meeting and waste everyone’s time. If you join a few minutes early, you can catch up with people before the meeting starts without interrupting anyone.

• Prepare for the meeting, don’t just “wing it.” The best way to take advantage of a meeting is to show up prepared. If you’re going to ask questions, have them already written down. If you’re demoing something, make sure everything works and that you’ve done a predemo meeting to practice. If you’re presenting a complex idea, try to have a presentation that you can share, so others don’t have to follow your explanation to understand it. With proper preparation, you’ll avoid having dead time while you figure things out.

• Make sure there are actionable items at the end of the meeting. This may be optional, depending on the meeting type, but if you’re trying to solve blockers, ask for requirements, or identify things you or someone else will need to take care of, summarize them at the end. This will help people with tasks to remember them and make sure they understand what the next step is. Through this practice, you’re can also plan the next step in the process you’re going through. If you skip this step, the meeting might end with everyone going back to their usual tasks without knowing what they have to do next. If that happens, the meeting was, indeed, a waste of everyone’s time.

• Align with everyone in the meeting by sending the meeting’s minutes afterwards. The minutes of the meeting should summarize what was discussed:

  • Who joined the meeting? List all joiners by name.

  • What points were discussed? Bullet points will be enough; just make sure you capture every topic covered.

  • Were decisions made during the meeting? If so, list them here as well.

  • Action items. This goes hand in hand with my previous point. If at the end of the meeting people left with homework, list those items here and who is responsible for each item.

By sending the minutes via email, you’ll make sure that everyone is aligned on the outcome of the meeting, giving them the option to speak up otherwise. If there were misunderstandings, and nobody noticed them, your minutes will highlight them. Without minutes, if those misunderstandings, cause problems, it’ll be your word against theirs, and that is never a good way to solve a problem.

Some of these activities might not be your responsibility at the beginning, especially if your manager is involved in the meeting. But your manager won’t always be there, and by showing you know how to get the most out of meetings, you’ll show your manager you are organized, respectful of others’ time, and action-oriented—three sought-after qualities for any developer.

That leads me to another ability every developer needs to develop over time: planning.

7.1.3 I plan, therefore I code

Coding may be second nature to you. Maybe you’re used to thinking through a problem while writing the code that solves it. Perhaps that has worked for you so far, because there is one key thing you probably haven’t had to do until now: estimate your work.

Estimating their work is a skill that most software developers are lacking when starting their first job. This is completely expected, since the ability to estimate comes from experience, and you have none (or close to none). And to your dismay, this is one of the things every manager will ask you about. They might help you in the beginning, if they know a thing or two about what you need to do, or maybe one of your more experienced colleagues might jump in and provide some guidance. That will be fine at first, but you’ll have to start understanding how to provide this information yourself. Being able to estimate your work shows experience—it shows mileage, if you will; the inability to do so shows you’re new and inexperienced. Being new and inexperienced is perfectly fine, but not being able to estimate your work a year after you’ve started working as a developer is a big sign of problems.

Now keep in mind that estimations will always be wrong. I’ll let you in on a little industry secret: estimating is not about getting the number right, it’s rather about who gets the closest number. You can’t predict life. You might be trying to estimate a task that you’ve done 100 times already, but the minute something doesn’t go according to plan (a family emergency may force you to take a few days off, there may be a missing external dependency, etc.) your whole estimate is no longer valid. While your estimates can become quite accurate over time, it’s unrealistic to ask a junior developer to provide accurate estimations. What can you do, then, to solve that problem?

Plan your work. Stop your irresistible urge to code for a little longer, and grab a piece of paper and a pen and start writing, drawing boxes, or whatever necessary to somehow lay down a plan for your work. Try to estimate everything you’ll have to do. Don’t worry about the time right now, and just focus on breaking down the big task into smaller chunks—sub-goals, if you will.

For example, imagine the task says “Create the login page for users of the application with React” (React being a JavaScript framework used for UI development). Start by breaking it down into steps like these:

1. Create the React component to hold the code that interacts with the backend service used to verify credentials.

2. Write the HTML for the page.

3. Create the CSS for the page to mimic the design.

4. Insert the new component into the routing configuration of the application.

5. Visually test that the component looks right.

6. Test if the component is interacting with the service properly.

I could go on, but you get the point. I went from a single directive to six smaller ones. Can you now estimate those? Are there some that you still don’t know how long they will take you? If so, keep breaking those up into even smaller chunks. The trick here is to keep breaking down the complex tasks until you’re able to estimate, and then start adding up those numbers. You can probably create a table like table 7.1 to review your estimates.

Table 7.1 The final estimate numbers

Task	Estimate (in hours)
Create the React component to hold the code that interacts with the backend service used to verify credentials.	12
Write the HTML for the page.	4
Create the CSS for the page to mimic the design.	4
Insert the new component into the routing configuration of the application.	1
Visually test that the component looks right.	0.5
Test if the component is interacting with the service properly.	1
Total estimate	22.5

You went from not knowing how to estimate your work to having a reasonable number: 22.5 hours. This translates to almost 3 days of work (assuming 8 full hours of work every day). You can use 3 days as your estimate, instead of saying 22.5 hours, because it’s more realistic and adds a small buffer for dealing with things like coffee breaks and the occasional distraction.

Being able to provide this estimate, even if in the end it is off by 2 days, is a great start, and it’ll look great in the eyes of your manager. It shows you’re capable of analytical thinking, and you’re showing that you’re basing your decisions on logic instead of picking random numbers.

I know the preceding example is simplistic. Maybe your tasks are so complex that they’ll take a few hours to split into manageable chunks. That’s fine. This is an exercise you’ll be doing for a while, but with time you’ll start seeing repeating patterns. Maybe you won’t have to create a login form next time, but you’ll have to create a contact form. You’ve already built a similar component, so you’ll only need to focus on the differences to come up with an estimate for the new task. It’ll be faster, and because it’s based on past experience, it’ll be much more accurate.

Over time you’ll be able to estimate whole sprints or even several months of work and eventually a full project. Granted, the bigger the estimate, the more error prone it’ll be, but there’s another trick you can use when you think you’re a bit over your head: use assumptions.

When you’re estimating a big chunk of work, you’ll sometimes see holes in your plan. There are things you don’t know or that you’ll have to research to understand. In this situation, one option is to make an assumption about what that section of your plan will look like, and then carry on with your estimate. Instead of doing that, though, you can write a note about each assumption you make during the process. That way you can go to your manager and show them your final number, but you can also point to the list of things that need to happen in the right way (your assumptions) for your estimate to work.

Going back to the example in table 7.1, you’re making the assumption that the backend service for validating credentials is already working, but what if it isn’t? And for the CSS task, you’re assuming you’ll have a finished design by the time you start this part of the work, but what if it’s not there? Add those assumptions to your list. Mark them as dependencies, and make sure that your manager is aware of this.

By going through this estimating process, you’ve not only created a reasonable estimate without having a lot of experience, you’ve also highlighted dependencies and risks. You’re on fire! That is pure value added, and, trust me, not a lot of developers know to do that. Instead, they’ll silently assume the best scenario for their estimates, and they’ll see it all burn to ashes when the dependencies aren’t met.

7.1.4 Don’t reinvent the wheel

Just because you can develop some functionality doesn’t mean you necessarily have to. This is highly dependent on your field of work, but unless you’re the very first developer trying to do something within that field, others have probably created libraries and published reusable lines of code somewhere for you to take advantage of. With that in mind, why would you want to recode a piece of logic yourself?

Going back to our login-related example, imagine you’re tasked to create the login logic on the backend, so your users can use their Google account to sign in. That is called single sign-on (SSO), and it’s been done to death in every possible language. So what do you think would be the right approach here?

• Take this opportunity to read up on how SSO works, and implement the mechanics yourself.

• Consider the project’s timeline and use one of the recommended libraries.

You don’t have to be a retired cold-war spy to read between the lines and figure out what my suggestion would be, do you?

While learning how things work is a major part of your career development, you can do so on your own time or in smaller chunks with guided help during the development of a feature. Going all in and fully implementing a solution just so that you can learn how it works shows you’re not taking into consideration the quality and timeline of your project. I’m not saying you’d be doing this on purpose, but it is the message you are sending your manager. Going with the tried and tested library will save time on one hand and ensure the quality of your work on the other.

When is a good idea to reinvent the proverbial wheel? Reusing external libraries is definitely the way to go in most situations, but there might be times when it’s perfectly okay to re-implement someone else’s function. Some companies or projects require you to avoid having external dependencies, because you don’t have direct control over them. If, for example, the feature you’re working on is core to your product, and you’re basing it on a third-party library, you’re running a huge risk if its owners decide to stop maintaining it. Or perhaps they have a roadmap that is not aligned with the features you need to develop in the future. There are many reasons why having your own implementation makes sense.

Another reason is security. In 2018 the owner of a very popular npm repository was running out of time to maintain it, so he gave it away. Little did he know that the person who offered to take care of it was a hacker who went on to add malicious code and release a new version. Every project that depended on that library and had not frozen the version they depended on received the new update and started leaking private information. The library in question was called copay-dash, and while you can still install it, you’ll get a deprecation warning stating: “npm WARN deprecated [email protected]: This package is deprecated, and has a unfixed event-steam vuln. Do not use.”

Given that, you can probably understand why some developers might want to avoid depending on external libraries. This type of security issue is not that common, though, and writing all your own code will considerably increase your project’s timeline just because of a “what if” scenario. This type of problem can also be avoided in many ways, such as by locking a version of the library in your dependency definitions so you’re not surprised by new updates.

Don’t get me wrong, this is a big issue when it happens. Allowing malicious code to run on your servers can have catastrophic consequences. However, there are less dramatic ways of avoiding this problem than taking a full start-from-scratch approach.

In the eyes of your manager, being able to understand the impact your decisions have on the timeline is already a huge deal. If you can decide whether or not to reimplement something based on logical and well-founded reasoning, you’ll gain a few extra points right there.

7.1.5 What you should never say to your manager

Let me begin by stating that I’m a firm believer that your work should speak for you when it comes to your managers. Through the work you do, they should be able to understand if you’re adding value to the team or the company overall.

With that out of the way, I think it’s also important to understand the types of messages we might be indirectly transmitting through our behavior—not necessarily through the actual tasks we close or the solutions we come up with, but rather through the way we handle everything around our work. After all, while our work can be very important to us, we’re also going to have to deal with other personal activities and priorities. The way we handle them, and the way we let them affect (or not affect) our interactions with our team, will also show a great deal to our managers.

We could cover this from many perspectives, but here I want to look at this form of communication from the point of view of a manager. I want you to learn how to read between the lines of the classic excuses and justifications we tend to use, and to understand why they’re not the best thing to say.

Note that this is not meant to be a cheat sheet on how to come up with valid excuses. This section will demonstrate that in some situations, it’s better to understand the impact you had on your team and to accept the penalty (whatever that might be) than to try to justify your actions with an excuse that will actually make things a lot worse.

Sorry I’m late, I went out partying last night

I’ve heard this one, multiple times, and I personally don’t understand it. Maybe it’s because I’m not the partying kind, but I tend to believe that life and work should not mix, and this means that whatever you do in your spare time should not affect your work or your performance at work.

Don’t get me wrong, your personal life always needs to be more important than work. And if you do happen to have an emergency, I would argue you’re more than justified to come in late, or even not come in at all. However, if you’re coming in late with the excuse of a party or a late hang-out with friends, you’re telling me that you don’t care enough about the project to show up on time. Not only that, but you’re also saying you don’t really care about or are oblivious to the effect your actions have on others. Your team will have had to pick up the slack while you weren’t there, and don’t even get me started if it was a deployment day or if you missed an important meeting.

I know, that sounds a bit harsh, and I’m not here to be your dad. I’m just explaining how others might read the message you’d be sending—even if you’re late because it was your brother’s 18th birthday. Think about the message you’re sending.

In moments like these, an excuse is probably the worst thing you can give, especially if you’re not asked for one directly. Own up to your mistake, appreciate your team, and accept that what you did to them was not ideal. That will show your manager that you’re mature enough to be aware of what you’re doing and that your actions have consequences. That might sound like a given to you, but trust me, this amount of common sense is not exactly ... common.

But we’ve always done it like that

Imagine saying that to your manager when you’re presented with a bug. Just because you have a predefined way of working, and it’s been successful until now, it doesn’t mean it’s fail-proof. Being this closed-minded to change can send the wrong message.

Every time you receive a bug report, you should review it, even if it goes against everything you know (or think you do). Even seemingly perfect systems might have some hidden flaws, and you won’t find them by blindly trusting the creation of another developer. No system is perfect, and every bug report, no matter how crazy it might sound, needs to be reviewed, checked, and confirmed before disregarding it as “not valid.”

Saying a bug report is “not valid” as a reflex response is the sign of a closed-minded developer. Saying “Let me review it and I’ll get back to you,” shows an open-minded individual ready to learn and grow. That’s the image you want your manager to see and the message you want them to receive.

Not my fault!

When a problem arises, it affects all team members. Even if you’re not directly responsible for the problem, saying “not my fault” shows you don’t really feel you’re part of that team. At least, that’s the message you’re sending.

Instead, there are many ways you can help someone solve the problem. You can help them troubleshoot and find the cause of the issue, or you can help them debug the issue. Even if you’re a frontend developer and the problem is in the backend, or vice versa, chances are you have some kind of value to add or ideas to share. It’s all code, after all!

In the worst case scenario, you can be their rubber duck—I discussed this idea in chapter 6 (section 6.1.1). The ”rubber duck” term comes from a famous technical book called The Pragmatic Programmer, by Andrew Hunt and David Thomas (Addison Wesley, 1999), in which the authors told a story about a developer carrying around a rubber duck and using it to debug his code by explaining his ideas to the duck. Of course, the duck is merely anecdotal in the story, since the real power comes from the actions of the developer. By explaining things out loud, he was able to hear himself and his ideas and look at them from an outside perspective.

That’s the key. Have you ever thought you had a great idea until the minute you spoke it out loud and realized it was terrible? That’s the power of this technique. Whenever you come up with an idea and don’t run it by anyone, you create assumptions about it, and your solution becomes biased by them. By externalizing these ideas, even if it’s just with a rubber duck, you’re able to hear the bias and course-correct your solution.

This is essentially the long way around to saying that even if you’re not capable of helping by coding the actual solution, you can still help.

Whew, that’s a lot of work!

Do not complain about work being too hard. That’s it, that’s the advice.

Alright, I’ll try to elaborate a bit here. You may now be in a position where you’ve got everything handled, you know exactly what you have to do, and you know how you’re going to do it. That’s your comfort zone, and that’s a terrible place to be. If you get assigned a new, harder task, and you immediately complain about the work that it represents, you’re showing you’re not willing to learn. You’re showing rigidity. This is not only bad because of the way it looks, it’s terrible for your own professional growth. You’re literally fighting to stay inside your comfort zone where you don’t do anything new. You might be the best at what you do, but you’ll never be good at anything else. Getting new work is not a reason to complain; quite the opposite, it’s an excuse to learn something new. That’s how you grow.

Every time you sigh about your assignment, your manager is going to make a mental note: “He’s not happy about doing this.” If this keeps on happening, eventually there won’t be any new work you’re actually excited to do. Can you imagine what that would look like?

Instead of sighing and complaining, accept that you’ll often be faced with unknown tasks and that figuring them out is part of the job. There’s no way around it.

I’m bored, I don’t know what to work on

Never tell whoever is managing you that you’re bored. That single word has a lot of negative connotations—it tells everyone that you lack proactivity, you find yourself without work, and suddenly you stop, you freeze. That’s not the right attitude. Raise your hand and explain that you’ve run out of work and you’re open for new tasks—that’s a very proactive attitude. Or find a way to create your own tasks, as long as they’re relevant and don’t go against your current work iteration. Be proactive; that’s the key takeaway from this point. Proactive is good, whereas reactive (waiting until others tell you exactly what to do) is bad.

Mind you, you can get bored even if you do have tasks to work on. It’s important to accept that you won’t always like what you have to do. Sometimes the task ahead seems boring as heck, and you have no way to avoid it. You’ll always have two choices when confronted with one of those tasks:

• You can be miserable and do it anyway. Get the job done, and move on to the next task.

• Find an interesting way to take on the task (maybe find a new framework you’ve never used before, or a new scripting language you’ve been dying to try).

Both options yield the same result for the outside observer (your manager), but I like the second option a lot more. With that option, I’m not only getting the job done, I’m also learning something new while doing it. Win-win!

It’s a random bug

We covered the random bug mystery in section 2.4, but it’s such a common excuse that I thought I’d mention it again. Computers are not random, so bugs can’t be random either. You have to learn to use root cause analysis to determine the causes.

But that’s not what I want to discuss here. I want to cover the other side of the coin: not how to solve a “random bug” but why believing that a bug can be random sends the wrong message to your manager. Declaring a bug as random shows two things about you:

• You believe the product is not important enough to merit your time debugging it. With that approach, the root cause, and the solution, are not going to be found anytime soon.

• You’re accepting that the user, your most important stakeholder, will have to deal with this problem from time to time.

Neither of those messages is good.

Instead, see this bug as an opportunity. Finding a potential solution is not enough; you also have to understand exactly what’s causing the problem and find a way to ensure that it never happens again. This is the attitude you want your manager to see: a proactive developer (I’ve mentioned proactivity before, haven’t I?) who worries about the quality of the product. This shows you’re committed, and that’s the right message to send.

We’ve now covered the attitude you need to make your manager happy and show you care. Let’s move on to your team next.

7.2 Being a good teammate

We’ve talked about your manager, so let’s focus on your team now—all those other developers and non-developers who are there working with you to get the project ready for production.

If you’re reading this while working on your first job, you may be wondering what the point of this section is. “Why do I need to be a good teammate? How does this make me a better programmer? I just open my laptop, write some code, and at the end of the day I’m out. I don’t need to interact with anyone for that.” With that in mind, let me give you the TL;DR version: you’re wrong. Let’s elaborate.

7.2.1 Make peace with your testers

Just like cats and dogs, the idea of developers getting along with their testers seems unnatural for some reason, which is crazy if you think about it. They are two sides of the same coin—why would they have to hate each other? There’s no reason. This might sound obvious, but it took me years to reach that realization, and that’s a bit embarrassing, to be honest.

Why wouldn’t you hate them? They’re constantly finding defects and problems with your logic and with how you build the product. They’re making you look bad. That’s usually what goes through developers’ heads, but it couldn’t be further from the truth. Testers are responsible for their own piece of the software development lifecycle, the testing part. Figure 7.1 shows the full cycle, but step 5 is highlighted, which is where the testers’ involvement is most relevant.

Figure 7.1 The software development lifecycle

There are seven steps in the software development life cycle:

1. Requirement gathering—This is where you listen to your client and understand what they want.

2. Defining—This is where you and your client settle on the product to be built, based on the requirements you gathered.

3. Designing—Before writing any code, you need to have an idea of what you’re going to be building. This phase is not only about UI design, but about overall architecture as well.

4. Coding—Now we’re talking. This is where we write the code that makes everything defined so far a reality.

5. Testing—This is the validation of the coding work. This is where the quality threshold is set, and if your work does not meet that threshold, it won’t move forward.

6. Deployment—Here you move the tested work into the hands of the users.

7. Maintenance—When your deployed code is no longer going to be heavily changed, you might keep adding to it or fixing small problems, but the overall feature is done.

Those are not absolute steps, and every project will go through them multiple times, which is why it’s a cycle and not a straight path from start to finish.

Of these, step 5 is where our work, which we deem ready, is validated by the actual experts. We can’t do it ourselves—we’re too biased. We built it, after all, and just like parents will shout to the seven winds that their kids are the most beautiful in creation (even when they’re not), we can’t see the problems with our own code. The true test of quality comes from the validation of an objective party: the testing team, sometimes also known as the quality assurance team or the quality control team.

What if they end up finding problems or bugs in your work? That’s fantastic! I know, I know, you wanted to close the task and move on to the next one. But consider the alternative—those problems would have been found by the users instead. That’s not a thing you want to happen.

Imagine being a tester who’s handed a feature that, according to the developer, is “ready for production,” only to find out, based on the requirements that originated the feature, that only 3 of the 10 requirements listed are indeed ready. That would be frustrating, wouldn’t it? Now imagine going through that process several times a day. Learn to appreciate the work of others, even if they don’t write code for a living. If they’re part of your team, that means they have a role to play, and it’s just as important and as relevant as yours.

The moment you start getting along with your testers and taking their work seriously, you’ll start seeing your productivity increase. You’ll deliver fewer faulty features because you’ll know what they usually look for, and you’ll be able to fix those before moving the code to their testing environment. Remember, testers are not out to get you. They’re actually there to stop you from screwing up in front of everyone, so appreciate them and treat them with the respect they deserve.

7.2.2 Leave your ego at the door

I’m a firm believer that ego is a part of us all, as humans, but developers tend to have this particular trait overdeveloped. I think that’s because, as developers, we’re creators, small-scale gods, at least when things work out the way we want them to. We tell these cold, lifeless machines what to do and how to do it. And if we practice enough, that can take the shape of a 3D game or a new algorithm that can detect cancer early on, or it can potentially even mimic human intelligence. With enough time and grit, we can do anything, and that sensation is intoxicating.

As we grow in knowledge and understanding, our egos can grow out of proportion. But as you’ve probably realized by now, the best developers are the ones who recognize that they’ll always have something new to learn, and that can’t happen with an ego that’s out of control.

This is why developers with huge egos are effectively shouting to the world that they’re really inexperienced children playing grown-up. Note that I’m not using the word “experience” here to refer to the amount of time they’ve worked in the industry. Instead I’m referring to life experience, which definitely takes years into account, but also lessons learned and the wisdom that comes with them. This is all to say that you can have developers who have worked for 10 years but are still inexperienced enough to run around with their egos unchecked. It’s a phase we all go through, but it’s also important that we learn enough to outgrow it.

Let’s look at several symptoms that can help you identify this problem, both in you and in others.

You think you know everything

You don’t. No really, I’m not guessing here, you don’t. I’m 100% sure of it.

The key is that you realize it too, and sometimes that’s not straightforward. You know what happens if you consider that you know everything about a topic? Two very bad things:

• You close your mind to others teaching you or correcting you when you’re making a mistake. That means you’ll be screwing up, and you won’t even recognize help from others.

• You’re officially done learning about the topic at hand, because, after all, you know everything about it. So you’re making the conscious decision to not look for further information about this subject. This might sound the same as the previous point, but here you’re not ignoring other’s help; you’re incapable of recognizing that you’re missing information to perform your task.

This affects you, and it affects the way your team deals with you. How can you work with someone who’s incapable of accepting that they’ve made a mistake, or that they’re not doing their best work?

Don’t get me wrong; there is a big difference between confidence and ego. You can be completely confident about what you know you can do, and if your ego is in check you can know the extent of those capabilities. In contrast, an egocentric developer will cause a weird team dynamic, and other developers will try to avoid working with them. Honestly, why wouldn’t they? Remember, you’ll always be learning, so anytime you think you’ve finished learning everything about a topic, think again. Be open to being corrected, and every time you are, double-check the facts before disregarding the suggestion as incorrect.

The ideal developer’s mindset, if you ask me, is that of an eternal student, always learning and always humble enough to recognize they can’t know it all, ever.

You think you can do everything

Being self-sufficient is not necessarily a good quality in software development. Or rather, let me rephrase that: just because you can do everything doesn’t mean you should. Being self-sufficient is good if that translates into you being flexible, capable of taking on different tasks throughout the duration of your project. However, that is miles away from trying to do everything yourself.

As developers, sometimes we fall under the illusion that because we can code, we can code everything, and there is no need to depend on anyone else, not even on third-party libraries. That’s a dangerous route to travel, since in theory it’s true. You could take the time needed to code a zero-dependencies project. However, in practice, it can become a time sink, increasing the timeline of your project exponentially, and even worse, your code will become a liability. Let me explain why that is:

• You’re wasting everyone’s time. Yes, you can code every piece of software related to your project, but take a second to look past your own ego. What is everyone else doing? Do their tasks depend on the completion of yours? What about the project’s deadlines? Are they still in line with the time it’ll take you to finish everything you suddenly seem to have to do? These are all questions that you always need to ask yourself, unless, of course, you’re looking for your teammates to hate you and your descendants for the next three generations.

• You’re not contributing to the stability of your project. Consider how long you’re planning on taking to complete these extra dependencies you want to build. Then add the time it’ll take you to make sure everything you build is stable enough for production. How can you be sure that what you create and the tests you make are as good as the testing and hardening that the third-party libraries you’re replacing went through? Those libraries have been public potentially for years, and users have tested them in unforeseen and uncommon scenarios. It’s really hard to top that level of stability, and thinking you can do it all on your own is nothing short of foolish.

You may have the skills to work on every single piece of your project (congrats, you’re great!), but that doesn’t entitle you to do so. You’re part of a team for two reasons, one of them being that tasks need to be parallelized as much as possible to decrease time to market. The other is that you can’t be great at everything. You may be good enough, but that doesn’t make you great; there is a reason why people tend to focus on particular technologies or skills. Testers will be much better than you at finding problems with your own creations, designers will be fantastic at putting a visual representation to your application, and frontend developers will be much better at writing efficient visual transitions and effects. The experience that they have and that you don’t makes the difference. Don’t ever forget that.

You think you know more than others, and it’s your job to correct them

Probably the ultimate form of ego we’re always fighting against is the idea that not only are we better than others, but that it’s our job to correct them. I’m speaking from experience—I’ve had to deal with developers like that, both as teammates and as a manager myself. They are very hard to work with because you either work the way they want to or they won’t let you work. They might even go so far as to raise issues around the quality of your work until you comply with their ideals.

There is always a chance that some of their corrections are valid, and you should take them into consideration. However, they take it to the next level by turning every suggestion into an important one. The problem with this is that they’re giving you the solution already completed; you didn’t get to it on your own, so the associated learning that comes from the lesson is missed. Your problem is solved, but the next time you face it (or a similar one), you won’t know how resolve it yourself.

As a rule of thumb, you should pursue the eternal student mindset (something we already covered in this chapter), so give these suggestions the benefit of the doubt and try them out yourself. However, if instead you’re the one insisting others take your suggestions, consider that you’re not really helping them. In fact, you’re hindering their progress. We’ve already covered how making mistakes is something every developer needs to do—they will learn a lot from them—but if you keep calling them out and solving their problems before they even see them, they’ll never outgrow you.

Mind you, I’m not suggesting you just turn your head whenever you see someone about to make a mistake. But consider the following:

• Be respectful when pointing out a mistake. Just because it’s obvious to you doesn’t make it obvious to the other person. Getting exasperated and angry at others because of what you consider to be an obvious mistake is not going to help them. Instead, it’ll reduce their interest in getting help from you in the future.

• Let them work it out for themselves. If you want to, point out the problem (respectfully, of course), and leave them to solve it. Offer your help, and let them decide whether or not to take it. Let them come to you, if they choose to.

If you actually want to be helpful to your teammates, be open and mindful of their different skill levels; don’t expect them to know everything you do. Your ego could be the downfall of your career, so be mindful of it and learn to keep it under control. The sooner you do so, the faster you’ll grow.

7.2.3 Learn how to work remotely

In this day and age, the tendency is to allow for some kind of remote work in all programming roles. This can range from one or two days a week to companies that work fully distributed. And even if you go to the office every day of the week, chances are you’ll still be working with colleagues in other locations. Given the current speed of the internet in most countries, it makes little sense for companies to limit themselves to local talent when they could be employing people from the entire world market.

Working remotely could make a lot of sense for you as well, because it will enable you to work for companies that are either far away in your country or even on another continent. Working remotely will also save you a lot of time that you would otherwise spend traveling to and from the office, even if it’s only a local commute. That is quality of life right there, and if on top of that you manage to organize your working hours, you can also be involved in your family’s daily routine or meet with friends while still doing your full eight hours daily. As I mentioned in chapter 6, a few years ago I worked remotely from home, and I was able to take my kids to school every day and pick them up with my wife. That was only possible thanks to me being able to save a full hour’s commute from my home to the office every morning. Otherwise, I would have missed all those little moments with them.

Being able to work remotely can be a great plus for you and your employer. However, it’s not as simple as having an internet connection. I’ve met many developers who simply could not work remotely, not because they didn’t like it but because they weren’t capable of focusing enough on their work. They would get distracted by things like the TV, people passing by, or just their regular house chores. In fact, there are studies that have found that, indeed, factors such as children passing by, distractions such as the TV, the lack of human contact with colleagues, or simply a lack of physical activity from not having to get out of the house can cause both physical and mental health issues.¹ So keep the following in mind when applying for a fully or partially remote position:

• Even if you’re not physically present, you need to be available. This is especially true if you’re working on a remote team that relies on synchronous communication. If you all share a time zone (or close enough, anyway), the chances are you’re likely to be expected to reply if you receive a chat message. That would be the equivalent of a colleague nudging your shoulder in the office. If, on the other hand, you’re working with people from all over the world, your team is likely to rely on asynchronous communication (such as emails and persistent chat messages). In this scenario, I wouldn’t say you’re expected to reply immediately, but you are expected to reply when you’re supposed to be working. This means you can’t really decide unilaterally when and for how long you’re going to be working simply because you’re “working on your own,” because you’re not. Not feeling that you’re still part of a team while working remotely is a big red flag that you need to be aware of.

• Being available doesn’t mean 24/7. This is the B side to the previous point: you need to understand when you’re not working, and avoid replying during that time. Keeping a healthy life/work balance when working remotely is not easy, and the temptation to answer quick emails or to send information with just two taps on your mobile phone is always there. But if you go down that rabbit hole, there is no coming back. By the time you realize you’re always working, you’re so deep in the hole that there is no coming out again. Don’t overwork (at least not for free).

• Respect everyone’s time. This is crucial for all teams, and it shows that you acknowledge everyone else and respect them. For remote teams, this is even more relevant, considering that not everyone might share your time zone. For meetings, communications, and any other type of interaction you may have, consider the other person’s schedule. If you’re sending an invite to meet with someone, check their public calendar if you have access to it, or ask for several available slots for you to pick from. If you’re sending them a direct message, consider their working hours; sometimes other developers might be drawn into working extra hours due to this practice. Their time is just as valuable as yours is, and if you’d hate it if you had to answer chat messages at 9 p.m., they probably do too.

• Learn to draw the line between the office and your life. As I’ve already mentioned, just because you’re working from home (or remotely in a nearby location), it doesn’t mean your work and life need to be the same. You’ll need a way to unplug from your work and connect to your personal routine. This can be as simple as closing the laptop, going for a walk, or stepping away from the home office (if you have one) and relaxing on the couch. However you unplug, your mind needs to relax and disconnect. Working remotely does not equate to working more than you’re paid for, so don’t blur that line and don’t let anyone blur it for you, either. If you get a message outside your normal working hours, it’s perfectly fine to ignore it, even if you’re just sitting in front of the TV not watching anything. You have every right to do so—it’s your personal time, after all.

• Respect your company’s security policies. Working from the office used to make this a lot simpler. The company network would have everything unwanted or untrusted blocked, and your workstation would be directly updated whenever required. Under a remote regime, however, you can get away with a lot more than when you’re using a company workstation, since you’re working from within your own house using your regular internet connection. However, companies do try to establish security policies that you should learn and follow, such as keeping your OS updated, or resetting your password after a certain number of days. Sometimes those requirements can be annoying, but it’s a lot easier to follow them than to have your workstation blocked and need to be sent physically to IT because you didn’t comply with your employer’s security policies.

A successful remote working environment requires the company to instill a remote-first approach. However, you also need to do your part, and the preceding tips will give you a good start.

7.2.4 Be social

Developers aren’t social animals; they’re lonely nerds who sit in front of a computer 20 hours a day, aren’t they? That, of course, is not true. One of the keys to a successful working environment and a performant and tight team is socialization.

Yes, there are days I wish I could just open my laptop at 8 a.m. and close it later at 6 p.m. without having said a word to a single individual. However, that’s not only not possible, but it’s the worst thing I could do for myself. We’re developers, but we’re also people, and by nature we’re social animals. That doesn’t mean you have to go out and party or talk to strangers in clubs, unless you enjoy that. All I’m saying is that you should acknowledge that your team is composed of other people with their own interests, their own problems, and their own aspirations, just like you. If you don’t make the effort to get to know them, you’ll never truly be part of that team.

On your first day at a new job, assuming you’re all colocated, it’s normal tradition to invite the new member out to lunch. No, they’re not going to pay for your meal, but at least you’ll eat with the group and get to know their names and personalities. If that happens, make the effort to go through with it. Sharing a meal can help you connect with them more quickly. Let them get to know you and answer questions with details—don’t just stick to the classics of “no” and “yes.”

If, on the other hand, you’re joining a remote team, getting to know people can be more difficult, but these are some tricks that can help you connect with others faster:

• Enable your camera on all meetings. If you don’t like having the camera on, make sure you do it for the first few days to give everyone a chance to see your face and your reactions. Then update your avatar with an updated picture and disable the cam.

• Be active in your team calls. This is especially important if you don’t have a camera or you don’t want to enable it. If you’re quiet in a virtual meeting, you’re not there. It’s that simple. Speak up and let others know you’re there. Just make sure you have something meaningful to add to the conversation. On remote-first teams, you’ll likely have some sessions with the team so that you can get to know each other. Speak up, and don’t be afraid to show a bit of yourself—give details, share your hobbies, and so on. You never know what will click with others.

• Join the social virtual meetings. I know, you probably hate meetings. But if you’re working remotely, the only chance you have to socialize with your teammates is through these types of virtual calls. Enable the camera, get a cup of coffee, tea, or whatever you like to drink, and join the conversation. You may not participate a lot at first, but these meetings will probably be hosted by HR people looking to integrate new joiners into the company culture and into their own teams. Chances are you’ll get some help from them as well. Don’t be shy, join!

• If you have chat channels for sharing personal information or even jokes, participate on them. Maybe you don’t have anything to share there, but at least you’ll interact with others. A “that’s funny” here and a “LOL” there can go a long way. Trust me, these random channels help a lot to alleviate the stress of the daily routine, and they help you see who’s the clown of the team.

Socializing is not strictly part of your tasks, but it will definitely help you integrate into a team as a new joiner. Not only that, but by taking you out of your working mindset, it will also help you release stress, diminish burnout, and battle the feeling of loneliness (even if you’re just socializing remotely). The simple reason why it’s so good for our mental health is because it’s the natural thing to do! We’re social animals, whether you like it or not, and your mind and body are asking for it. So my recommendation is that you consider it to be one of your tasks. Don’t ignore it, thinking that you have more important things to do. This is important.

7.3 Working on your own skills

Let’s focus a bit on you, shall we? Getting the manager to love you is crucial, as is fitting in with your team. But you need to care for your own self-improvement from time to time. After all, learning doesn’t just happen (although sometimes I wish it did, trust me).

Imagine, if you will, that you’ve been working at this new job for about a month and a half, and you’re starting to get it. You’ve gone through the onboarding process, you’ve learned the custom framework they’re using, and now you’re starting to close tasks on your own. You’re finally doing it—you’re a somewhat autonomous developer. Yay!

But there’s still something missing. You can’t really put your finger on it, but you have this feeling of not being good enough, not yet. You can feel the eyes of your manager piercing you, looking for a sign that you’re special, and then looking away disappointed. Your teammates talk about new technologies and new frameworks they can’t wait to try, but they never include you in those conversations, as if they know something you don’t. Are you going to be fired? Are they going to finally realize you passed the interview by mistake and you have no idea what you’re doing more often than not? What is happening!?

I’m willing to bet that 99% of the time, nothing is wrong. That’s just your impostor syndrome kicking in. Congrats, you passed the final test, you’re a developer now! The impostor syndrome is a psychological pattern in which the person doubts their skills, knowledge, and accomplishments. They constantly feel like they’re about to be discovered as a fraud in front of everyone.

Does that sound familiar? It’s okay if it does—according to a study from Blind, almost 58% of all developers working for FAANG (Facebook, Amazon, Apple, Netflix, and Google) feel that way.² And don’t feel special just yet—according to research by Jaruwan Sakulku and James Alexander, almost 70% of people from different personal and professional backgrounds feel it.³

Why am I talking about this, and what can you do to solve it? The first thing to understand is that I’m not a psychologist, and my advice only comes from personal experience, having felt this way often in the past and still feeling it today from time to time. This is a very real thing that happens in our industry, and it is fostered by the way our industry works. We sometimes worship developers who create tools and libraries that millions of other developers use. We hope that one day we’ll be as good as they are, but we forget that we already are. We see a lot of online “celebrities” within our industry, with tens or even hundreds of thousands of followers pushing content every day, and we feel tiny compared to them. But we’re not, and we need to remember that.

Overcoming, or at least learning to cope with, impostor syndrome is not easy, but it centers around understanding that you have what it takes to make it. Boost your self confidence to a point where you feel comfortable enough with your peers. How can you do that? One path I recommend is improving your own skills. Working on them will show others and (more importantly) yourself that you’re doing something to improve, to better yourself.

7.3.1 Continuous learning

Step one is to keep learning. We all know this by now—your software development career stops progressing the moment you stop learning. So let’s not stop, shall we?

You’ll find learning opportunities popping up all the time, so try not to ignore them all. Pick one every now and then, and follow through. Which one should you pick? That’s really up to you. But since we’re discussing team-related topics here, I recommend considering your current context when making that decision. Are you struggling with the current framework of your project? Or perhaps the language itself feels a bit alien to you? Improving those skills will not only benefit you, but your team as well. That’s what I call a win-win.

Depending on the company you work for, one of several things can happen:

• They might provide the learning experience themselves. The company may provide internal training or perhaps grant their employees direct access to learning portals such as Udemy or Pluralsight. This is good, because on the one hand, they are showing that they care about the education level of their employees, and they want you to keep growing. On the other hand, it’s also great because by signing up for these training sessions, you’re directly showing them that you care about the same thing. They’ll be keeping an eye on what you’re doing and how it goes.

• They might provide a training budget you can take advantage of. Some companies have a training budget that can be used by employees. You may have to go out and find the course you want to take and figure out how much it’s going to cost, but your company will either pay the full price or help out with a percentage.

• They may not have any way to help you. Not every company is capable of financially helping you or even interested in doing so. This makes things a bit harder, but it’s still not impossible, considering how many learning resources are online these days.

Whatever your employer’s policy is toward your continuous training, it’s always going to be up to you. Don’t get discouraged if you’re working for a company that just says “Sorry, but we have no way to help you there.” You can do it without them—not a problem.

So what can you do? Where can you improve your skills, and why should you pay money instead of getting it for free? All great questions! The first thing you need to do is pick the topic you want to improve on. As I already mentioned, it’s completely up to you, but if you’re expecting your teammates and employer to appreciate the effort you’re making, it should be something related to their needs. Mind you, I think there is a huge benefit to learning about technologies that are very far from what you do daily, like doing a Unity course (Unity being one of the biggest game-development platforms around) on creating 2D platformers, if you work with microcontrollers daily. That’s probably not going to be seen as directly beneficial by your team, but it will broaden your horizons and show you something that you would have never learned otherwise. That’s also a way to indirectly improve your skills, so don’t limit yourself.

Once you’ve decided what you want to improve on, the next step is to pick a learning platform. There are many out there that are very good, such as these:

• Udemy (www.udemy.com)—Udemy has varied courses with multiple levels of difficulty. They also often have a $10 course promotion that allows you to pick up expensive training for a fraction of the cost.

• Pluralsight (www.pluralsight.com)—While you can take single courses, like with Udemy and others, Pluralsight offers preset learning paths that you can follow to make the most out of your effort. This is the perfect way to go from zero to expert without having to decide what to learn next.

• Educative (www.educative.io)—If learning through video is not your thing, Educative offers written courses on many different programming topics. They have interactive sections in which you can practice what you learn.

• Coursera (www.coursera.org)—If you’re looking for more academic-oriented courses, either because of the topics you want to learn about or because you learn better that way, Coursera is for you. They have partnered with over 200 universities and offer, in some cases, full degrees through their online platform.

This list can be as long as you want, because there are many more learning platforms. Don’t get caught up with the number of choices. If you’re starting out, pick one of the most common providers and go with it. If you don’t like the experience, you can switch and try a new one. However, these are the most common platforms with the highest-rated options.

If, on the other hand, you’re looking to train yourself without spending any money, there are alternatives. If you like learning through videos, searching for the topics you’re interested in on YouTube is your best bet. Otherwise, you’ll be better off searching Google for tutorials and articles related to your interests. A common place to find these tutorials is Medium.com, which concentrates a lot of programming knowledge through multiple publications about our industry (they’re like mini blogs inside Medium). If you pay for the Medium membership of $5 a month (I know we we’re talking about not paying a dime, but hear me out), you get access to the entire catalog of Pragmatic Programming books (https://medium.com/@pragprog). That’s a lot of books and knowledge for just $5 a month.

One could argue that given the amount of free access that you can get by Googling for tutorials, it makes no sense to pay for online courses. But the truth is, you can’t really certify that you’ve learned a topic well enough on your own, whereas the preceding learning platforms will give you some kind of completion certificate that you can share with your employers and teammates if so required. Beyond that, you may also need the guidance a learning platform offers, or the potential interaction with other students. Whatever the case, learning through online, paid platforms is an option that you should not dismiss simply because there are free alternatives.

7.3.2 Measuring your learning progress

Once you start learning, the next thing you’ll naturally want to know is how you are progressing on your path to becoming proficient in the topic you’ve picked. The classic mistake we make in this situation is to compare our progress with that of others going through a similar process, and especially with those who actively share it online. That is the worst thing you can do.

Whether you’re comparing yourself with a colleague or with someone you follow on Twitter, what you’ll see is what they let you see, which is usually the results and not the process. You can see that they’ve mastered a new skill or perhaps understood a new concept, and you’ll immediately compare it with your own progress and get depressed if you’re not there yet. The problem with that is that you’re not making a fair comparison. When you look at yourself, you see all the struggles you’re going through, all the problems you’ve found along the way, and all the times you thought about giving up. But when you look at the other person, you only see the results and assume they had no issues. In reality, they could have struggled more than you. If you’re looking for a perfect recipe to trigger that impostor syndrome I talked about, this is it.

How can you know if you’re actually making progress? Don’t look at anyone else but you. Compare your current state with your own state from the past. That’s the only true metric you should care about.

If you’re following a preset path like one you’d get from Pluralsight or Coursera, your progress will be determined by how far along you are. However, if you’re learning from random tutorials and videos, set some goals before you start. Decide where you want to get to, and then start planning backward toward your current state. For example, if you’re looking to build a 2D platformer, but you’ve always worked in web development, what would be your learning path? Where would you start learning? Your end goal is to create a 2D platformer, so set that at the end of your timeline and do some research. What goes into creating a game like that? Your character needs to move around and interact with the world and the enemies, so there is a physical component. Make a note: “2D physics for game development.” But before getting there, you need to have something to move around, so write down “Add 2D character to game.” How do you control your character? Write down “2D character control.” Your character also has to move around somewhere, so it’s time for “2D level design and implementation.” That would require you to know how to structure your game code and load a level, so perhaps write down “Game loop and internal architecture.”

Alright, let’s trace our path:

1. Game loop and internal architecture

2. 2D level design and implementation

3. 2D character control

4. Add 2D character to game

5. 2D physics for game development

Perhaps now you have the basics for a game—at least the minimum viable product (MVP) version of it. You have the basic idea of what you want to do—the main game mechanics. The rest is just figuring out what you’re missing and doing the same exercise. For example, you’re probably missing music and sound effects. Try to reverse your path into that one.

Finally, if you need to, set yourself a time limit. That will be another way you can motivate yourself. Knowing that you need to complete this curriculum in under two months, for example, will make sure you don’t slack off or procrastinate too much. You can track your progress inside your own timeline and measure how much you’ve learned based on your own experiments and insights.

Just make sure that when you create this learning curriculum and set a timeline for it, you don’t shoot yourself in the foot. You know more than anyone else how much time you have to spend on this and how badly you need it. Use that knowledge to set a reasonable timetable.

7.3.3 Learning from code reviews

Finally, another way of learning that does not involve money being spent or extra time away from work is to learn from your colleagues. Code reviews are a perfect way to capture that knowledge, especially if they’re done right.

Code reviews are sessions in which colleagues review your code before it’s marked as “ready for production,” to make sure you haven’t introduced bad practices or unwanted bugs. Sadly, not everyone understands that. Learning to take criticism is a skill we have to develop. It’s a great source of knowledge, after all—we just need to learn how to tap it.

The main thing to understand about code reviews is that they’re not personal. If you don’t understand this, you won’t get any of the benefits. During the review session, you’ll normally be asked to explain the code you’ve worked on. You’ll explain the problem you were trying to solve, the logic behind your solution, and any particular technical choices you made. Normally this takes place as a conversation between you and your reviewers. They’ll listen to you for a while, and then they’ll start asking questions, mainly the dreaded “Why?” but don’t worry. If you wrote that code, you’ll know why you did what you did, so you’ll be able to answer those questions.

You can receive feedback like the following:

• Typos or grammar errors in your comments—Yes, some teams review even the comments you write, and if you think about it, it makes sense. The comments are just as important as the code you wrote, if you’re expecting anyone else to understand your code and maintain it in the future. Writing comments with proper grammar is important.

• Logical mistakes in your solution—This is the classic problem: when you start explaining how you solved the problem, they might point out that you forgot some edge cases, or you went about solving the problem in the wrong way. This doesn’t necessarily involve your code, but the logic around it. It’s important that if you get this type of feedback, you also ask as many questions as you can until you fully understand where the error lies and how you can solve it. Either that, or schedule a follow-up meeting to discuss the topic if your reviewers don’t have the time to do it at the time.

• Incorrect or missing coding standards—This is another easy one to spot. If your reviewers have been coding in your team longer than you, they’ll have these rules more internalized than you, and they’ll be better able to identify when you’ve missed them. These are easy to fix—they usually involve naming standards, removing magic numbers into constants somewhere else, and the like. A good idea here is to take notes of all these mini issues and tackle them together as part of the same fix.

• Bugs—This is probably the worst thing that can be found in your code: problems added by the way you coded the solution. This can happen to anyone, and it’s not necessarily a bad thing, but it’s something you need to own and fix once the review is over. If a bug is found during the review of your code, make sure you fully understand what the bug implies and what you have to do to remove it. Just like with logical mistakes, if discussing the solution will take too long, consider setting up a follow-up meeting to discuss it further.

A successful code review is one you come out of having learned something new about your code, the solution, or the way your team works. To do that, make sure you ask about every little detail related to the feedback you receive, and don’t be afraid to say “I don’t understand” if the explanations aren’t clear enough. Not every developer knows how to explain complex topics well, and sometimes something that is obvious to your reviewer might not be obvious to you. That is perfectly fine.

Summary

• Getting your manager’s attention and interest is crucial for your professional progress. You can do so by providing updates about your status, often using the preestablished task-tracking system, understanding how to behave in meetings, properly planning your work, and avoiding reinventing the wheel when applicable.

• Learn to get along with the testing team. They’re not there to highlight your mistakes, but rather to ensure that you all build a stable product.

• Don’t let your ego get the best of you. All developers have that problem at the start of their career, but only great developers learn how to control it and keep it from hindering their progress and the way they relate to their teams. Consider the way you interact with your teammates, and adjust it if you recognize some of the behaviors I mentioned in this chapter.

• Understand that working remotely does not just mean working from home. It also means being there on time, showing up when you’re needed, taking into account your teammates’ time zones and, most importantly, taking care of your work/life balance. Remote work provides a lot of benefits for developers by giving them flexibility in their working schedule and saving potentially hours of commutes. However, you need to commit to following the standards set by the company around this practice.

• Socializing with your team is just as important as doing good work and writing quality code. Whether you’re physically going to the office or interacting with everyone remotely, you, as the new team member joining the team, need to make an effort to make sure others get to know you.

• Remember that impostor syndrome is real and quite common in our industry. There are multiple things you can do to combat it, one of them being working on improving your own skills.

• Make sure you keep learning new things and compare your progress with yourself. Everyone learns at different rates and through different processes, so comparing your progress with that of others is only going to give you an unrealistic view of your progress.

---