4 Pitfalls to Watch Out For as a Developer

In today's world of software development, there are many traps and pitfalls we can fall into that can have significant impacts on our lives and careers. In this post, I'd like to share four of the common ones I've seen and personally experienced, as well as offer some suggestions in how to climb out of them if you've fallen into one or more.

Let me start this all by saying that if you find yourself in one of these pitfalls, there's no judgement here, and it's okay! I'll be the first to admit that I've fallen into my fair share of them over the years! Just know there's always a way out. Just because you've fallen into one of the pitfalls mentioned, or some other one, doesn't mean you can't climb out, dust yourself off, and charge forward to change the world! With that said, let's dive in!

1. Taking Too Little or Too Much Time

These 2 pitfalls can be a bit subjective, but they're ones I think are important, especially in the work place. Everyone's different in how they learn, how they approach problems, and how they implement solutions. So the amount of time it takes can vary from person to person...which is why this is a bit subjective. But in this case, I'm referring to the extremes in either direction. When someone immediately calls for help as soon as they encounter an issue (without trying to solve it themselves first), or someone that spends many hours on a problem without reaching out for help. Let's discuss each of these individually.

Taking Too Little Time

Consistently not taking enough time to try and solve an issue before reaching out for help is generally not a good sign, and is something that should be avoided 99% of the time. Trying things yourself is really the best way to learn, particularly in this industry. So what you're doing is hindering your own growth! Not to mention you're taking time away from other members of your team who also have things they're trying to solve.

Taking Too Much Time

On the other side, there are those that take far too long to solve problems. In these cases, they might spend 5 or 6 hours trying to troubleshoot a problem without asking for help. This could be due to being stubborn, fear of looking ignorant, or some other reason I'm not thinking of...but regardless, it's a pitfall that should be avoided. When developers fall into this pitfall, I generally see 1 of 2 things happen. Either deadlines are missed, or last minute emergencies come up, and the rest of the team has to scramble to help. In both cases, everyone generally has a unpleasant time.

Make It Just Right with the 30 Minute Rule

Regardless of which pit you find yourself in, I generally have the same advise. I call it the "30 Minute Rule". Try to solve the problem for 30 minutes. If you haven't solved it in that time, reach out for help. Why do I suggest this rule?

In general, 30 minutes is enough time to have tried a few potential solutions, maybe read a few posts or pages of the docs, and you get several of the "obvious" solutions out of the way. So this alleviates the first pit, because now you're giving it a try and making an actual effort. Now when you ask for help, and your team member asks "what have you tried so far", you actually have an answer for them.

It also solves the second pitfall, because it puts a cap on how long you should try before reaching out. If you haven't solved the problem in 30 minutes, it's a good idea to get a second pair of eyes on it, which generally leads to 1 of 2 things happening. 1, your team member already knows how to solve it, and they can teach you, saving time. Or they don't know the answer, and now both of you can try to solve it, resulting in shared knowledge across the team! To this day I still use the 30 minute rule myself, and it's saved me tons of time and heartache, not to mention has built better relationships with my teammates!

2. Taking Feedback About Your Code Personally

Let's start by saying that none of us write perfect code. Even the greatest developers in the world can introduce bugs, overlook certain use cases, or forget to consider how one thing might impact another. It's for this very reason why pull requests (or merge requests if your a GitLab user) exist at all! Getting more eyes on code drastically reduces the chance of bugs being released to production. But this process relies on providing and receiving feedback on our code. The pitfall I've seen many developers fall into (including myself at times) is when they take that feedback as a personal judgement or attack.

When code feedback is taken personally, it can have far reaching consequences...for you personally, for the team, and for the company you work for.

When someone is focussed on what they assume the intent behind the feedback is, I've noticed that the feedback itself seems to get lost. This causes the developer to not learn from the issue, resulting in the same issue being repeated, and stifling their personal growth over the long term.

It also causes tension on the team, which inevitably leads to resentment. You start to see signs of people avoiding conversations (even outside the pull request process) with the person that takes the feedback personally. This causes a whole slew of issues. The person who takes things personally doesn't get feedback, so they believe they're doing a good job, so they aren't learning and growing. More bugs and inefficient code are being allowed through as result of avoiding difficult conversations, which leads to team and company impact.

Phew, that's a lot of impact! Fortunately, there are some things we can do to help with this...

Assume Positive Intent

If you find yourself taking some feedback about your code personally, try to practice assuming positive intent. This means actively stopping your train of thought, stepping back and telling yourself that this person probably didn't mean this the way you're taking it...that they actually meant it in a positive way. To help with this, ask yourself, "Why would a reasonable, rational, and decent person provide this feedback?". Answering this question allows you to explore other possible reasons why the feedback was given. These stories can often soften your view of the situation, and allow you to find the positive intent that you may have missed with your initial reaction.

This can be really challenging at first. But if you practice it enough, eventually it will become habit and you'll start to assuming positive intent naturally.

Consider the Loss of Non-Verbal Information

As the person providing the feedback, keep in mind that a lot of non-verbal information is lost when dealing with asynchronous communication...the same way sarcasm doesn't come across when a court transcript is being read. With that in mind, as you write your feedback, try to phrase it so that positive intent is more easily identifiable and understood.

Add More to the Conversation

Lastly, if someone is still taking feedback personally, or if the reviewer does actually seem to have negative intent, it's probably a good idea to get on a call or meet up in person. This adds more tone and context to the conversation and will hopefully resolve the issue without needing to escalate it to management, or whoever.

3. Pretending To Understand

Have you ever had a hard time with something, reached out for help, still didn't quite understand after the other person explained it, but smiled and nodded because you were afraid of looking incompetent? This is what I'm referring to here.

It can be hard to admit when we don't understand something. We put this weight on our shoulders and tell ourselves that others think we're incompetent or stupid, simply because we don't have a firm grasp on a topic. That feeling is exaggerated when we do finally ask for help, and we still can't seem to grasp the concept after the other person has explained it to us. Rather than face the self-imposed embarrassment, we dive headfirst into the pitfall of pretending like we understand what they said, and then go back to struggling on our own. When we do this, we're actually doing multiple disservices to ourselves and the other person.

The obvious disservice is that we're allowing our fear of looking incompetent to keep us from actually learning the thing, so we continue to be ignorant, and nothing gets better or changes.

Second, we're wasting the other person's time. They've taken time away from whatever they're doing in order to help you. And if you only pretend to understand, then the time they spent with you offered no benefit, and so it really was just a waste of time.

So what can we do? It's not like we can snap our fingers and magically understand that thing, right? Fortunately, there are few things that can help.

Everyone Has Blind Spots

In my opinion, one of the best things we can do for ourselves is embrace the fact that literally everyone has blind spots or gaps in their knowledge. Even the most senior of developers don't know everything and they have to ask for help from time to time too. When you really wrap your head around this, it helps to take that weight off your shoulders.

This is why I started my I Made a Boo Boo series. I want to help share that everyone makes mistakes. That even someone with more years experience than you may not know something that you already do. And that's okay.

Repeat Your Understanding

After the person has explained the thing to you, repeat back to them what you understood they told you, in your own words. Even if you only understood part of it. I've noticed that doing this starts to help alleviate some of that uncomfortableness we've placed on ourself by showing (to the other person as well as ourselves) that you do understand some of it, just not all of it.

This also helps the other person know that you're not quite there yet and they might need to explain the concept in a different way. It helps them understand exactly where you're still hung up. Together the two (or more) of you can narrow down the scope, and focus on where the confusion lies. Then they may be able to explain in a different way that helps you reach that "aha" moment.

4. Not Continuing to Learn

This may be the biggest pitfall of them all. The tech world is in a constant state of change. In fact "change" is about the only constant we can expect as software developers. Because of this, we must always be learning as new technologies, techniques, tools, security vulnerabilities, user demands, and so much more are identified.

Now, before we look down this deep, dark pit, I'd like to clarify what I mean here. I am not referring to learning everything and being completely up to date on all things in the industry. No one can learn it all. This industry is too big for any one person to ever learn everything. So I'm not referring to those developers that work to learn new stuff, but fall behind in certain areas, or who focus on a certain specialty and don't learn about another. This will always happen to every single one of us. No, this pitfall pertains to those developers out there who, for one reason or another, stop learning new stuff entirely.

One of the most common places I see this is when someone gets comfortable in their role and complacency sets in. Which completely makes sense. I mean, how much harder is it for any of us to get up and do something if we're snuggled up in bed, or on a comfy couch with a warm cup of coffee or tea?! But while it makes sense why this happens, it can lead to stagnation in your career, growth, and even leak out into other areas of your life.

So what can we do to avoid this pitfall? Unfortunately, there's no one right answer. It's going to be different for everyone. But I'd like to offer some tips that I've seen work for myself and others.

Build a Habit

Much like exercising, learning isn't something we can do just once in a while and expect significant results. So my first tip is to make learning a habit in your life. Dedicate some time each day to spend learning. If you only have 20 minutes a day for this, that's still enough to learn something. If you have more time, great! But setting aside time (and sticking to it) sets a marker in your mind that says this is important.

It may be challenging at first. You may find you don't have the motivation, or you get distracted after just a few minutes, or you can't decide what learn about. But in my experience, the more you hold yourself accountable and follow through on this time, the easier it becomes. For me, I even got to a point where I now look forward to this time in my day!

A word of caution for this though. Don't spend ALL your time learning. Just like muscles, you need to give your brain a break. So even if you have 8 hours a day that you could completely dedicate to learning, I encourage you to take some of that time for learning, but fit some other stuff into those 8 hours as well.

It's Okay to Skip a Day, But Never 2

I get it, it's a fact of life, some days you just don't want to spend time learning, or you don't have time because life gets in the way. So tip number 2, give yourself a break. It's okay to take a day off here or there. It's actually encouraged! But I recommend that you never take 2 (or more) days off back to back. Why? Because of how easy it is to stop.

It's easy to pick right back up where you left off after a 1 day break. But as more time passes, it becomes harder to get back to it, and easier for procrastination to set it. It's not like after 2 days, all is lost...but procrastination always starts somewhere, and it's better to just not let it start.

Pick What Interests You

"There are so many options out there, how do you pick what to learn?"

I've heard this question, or variations of it, more times than I care to count. And it's a great question! It reflects the reality of the tech industry. From different fields, technologies, languages, frameworks, libraries, methodologies, the list just goes on and on and on...how the heck do we pick what to focus on?! Once again, there's no one right answer. So here's my advice...first learn what you have to...then learn what interests you.

If work needs you to learn how to use some new tool, or how to integrate with some other service, you don't really have a choice. You have to learn that thing. Similarly, if your industry is experiencing a major shift in some direction, you may need to learn about that thing in order to remain up to date in your field. These are things you have to learn, so they'll come first. But after that, pick a subject that seems interesting to you, even if it's not the recommended thing.

Now, this may seem a little out of place. After-all there are so many recommended things to learn, why spend your time on something different? Because it will keep you engaged, and you will always bring something back that's valuable. Also, I can't tell you how many times I've dove into an interest rabbit hole only to discover that those recommended things start popping up, and now I'm more motivated to learn them because they directly apply back to something I'm interested in.

So pick something that seems interesting to you, and just dive in!

Learn Just Enough

My last tip for you comes from my own life lesson. You don't have to learn every little detail about the technology you're learning about.

In my earlier years in software development, when I was learning something, I felt like I had to become a master at it. I needed to know all the ins-and-outs, all the nuances, everything before building something of substance with it. But as time went on, I came to realize that I could do even more by learning just what I needed to in order to accomplish the task at hand. The more I built, the more tasks I needed to accomplish, the more I learned along the way.

So my recommendation to you is try not to worry about knowing a technology perfectly. Instead, learn what you need (or want) to know, and move on. I bet you'll find that you accomplish significantly more!

Conclusion

The world of software of development is littered with bumps, traps, pitfalls and landmines. Many are technical, but many others are brought on by our own personal habits and idiosyncrasies. In this post, we talked about 4 of the big ones I've seen (and experienced), and some suggested approaches in how to avoid them.

So, if you find yourself not taking enough time, or taking too much time to solve problems, considering adopting the 30 Minutes Rule.

If you notice yourself taking code feedback personally, maybe taking a step back and trying to assume positive intent could help.

Rather than nodding, smiling, and pretending you understand something, when in actuality you still don't quite get it, even after someone has explained it...try to give yourself a break and embrace the fact that everyone has gaps in their knowledge and struggles to understand things from time to time. To help, maybe try summarizing what you do understand, and use that as a starting place.

Finally, if you're looking back on the last few months and realize you've maybe not been learning as much as you feel you should, that's okay. It's never too late to start building that habit of learning within yourself by dedicating time to it each day, picking things you're interested in learning, and not forcing yourself to master every little thing.

I hope this post has helped you in some way. Maybe it's given you insight into what to look out for in your career as you driving forward in changing the world. Maybe you're realizing that you've found yourself in a pit, and hopefully some of these suggestions will help you climb out and drive forward.

I would love to hear about your experiences when you've found yourself in a pit, and how you got yourself out! Please share!

Thank you for allowing me to share my thoughts with you. Until next time, Happy Hacking!