Mapping Out Your Dev Skills

Developers spend a lot of time learning and practicing new technologies, but there are also many non-technical skills that can complement your career and help you grow. They are often recognised as important, but overlooked when it comes to practise and cultivate them. Here are some of the most critical non-technical skills and how I developed them, which may help you route out a plan for yourself.

This epic checklist is a great way to keep track!

In my career, there have been some specific realisations and skills that helped me move beyond the growth plateaus which I was stuck in. If you feel you are not growing as a developer, then maybe it's time to try out a new routine and focus on new skills. I went through three major mindset changes. Each of them correlated with my experience as a developer:

1. As a junior dev, I grew by focusing on learning a broad spectrum of skills and listening to others. It was all about getting the gist of the industry and figuring out where to go.
2. As an intermediate dev, I became an expert in the technologies that I used while working to produce a large amount of high-quality software.
3. As a senior dev, I now focus on seeing the entire process and linking everything together - from the technologies and processes to the human elements like teamwork.

Moving between these phases required all of the skills that I had learned in the previous one. If you are not yet comfortable in your current position, I would recommend focusing on the skills that you need for that level. This will help you build a strong foundation. If you are looking to be promoted to the next title at work, focus on the skills needed for that level and behave as if you already have that title. For example, if you want to become a senior, take on senior responsibilities and get more involved in planning, code reviews or teaching.

If you make yourself valuable and prove your worth, then promoting you is an easy decision for your company to make. Everytime I moved forward in my career it was because I put myself out there.

Junior skills

When you are a junior, it is a great time to explore and find your space in the tech world without too much pressure. You don't have to be an expert yet - because nobody expects that from you. It becomes more difficult for intermediate and senior developers to do things like swapping to a brand new tech stack, because companies expect a certain output from them.

Before I started working, I thought I knew a lot. After some practical work experience, however, I quickly realised that there were many gaps in my knowledge. Spending more time learning a single subject was not going to broaden my overall understanding. So I needed a strategy that would help me learn, and keep learning despite the fact that I didn't yet know what area of development I wanted to work in. There were two major skills that I picked up as junior and refined over time:

• Continuous learning, and
• Investigation.

Dev skill 1: Continuous learning

Technology is constantly growing and, as a developer, you need to stay abreast with the latest and greatest. Having a simple routine and multiple sources of information can help you stay up to date and will leave other developers wondering how you know so much all of the time. Here is how I do this:

Step 1: Find multiple sources of learning material and general tech news

Different sources tackle information differently, which will give you a broad view since there is always something new to learn. Some great sources include podcasts, YouTube, paid courses, blogs, books, dev meetups, and, of course, OfferZen posts.

Step 2: Schedule time for learning

Have a set time everyday to actually go through the material. Having a routine and plan for learning, you will find yourself actually doing it. -You will have less excuses not to because you can plan around your learning time. For example, I spend 1 hour everyday learning and writing summary notes, otherwise I listen to podcasts or audiobooks while I travel.

Step 3: Practise what you've learned

As you learn something new, try to implement it by writing small applications or by practising online code challenges. This helps solidify your knowledge and allows you to truly understand it, since you will have to make it work and fix any problems that you come across. Everyday, I spend some time writing small applications where I try different variations to see what works and what doesn't. This is useful because I can keep this code and all its variations for future reference.

Step 4: Watch senior devs dev

If you get the chance to just sit quietly next to a senior developer while they work - DO IT! Even if you are senior, watching others is a great way to learn because you get to see how they solve problems and you may pick up some interesting tricks. Sometimes you can even find devs live streaming on Twitch as they work. Otherwise, unedited YouTube videos can also be a good substitute. I try to watch other devs or go to a meetup to chat about the tech space at least once a week.

Dev skill 2: Investigation

As a developer, you will run into new problems nearly every day. It seems obvious that being a good problem-solver is important, and it is, but before you go solving problems or asking others, use Google.

I find that many devs often try to reinvent the wheel, spending unnecessary time trying to solve problems that have already been solved in the dev community. Rather spend time looking at how other people have solved the problem, and don't just copy the solution! Make sure that you understand it so that the lesson you've learned can translate to other, slightly different problems. For example, if you read about "online code challenges" above and didn't know what it was about, you could have just copied the exact phrase and pasted it into Google to find out more.

If you are an experienced developer with this skill, you may take for granted that many juniors have yet to learn it. I have had many devs ask me about a problem they are having, and sometimes they even send me an email with the exact error attached. In this situation, I have learned that the best thing for me to do is to ask them if they have Googled it. 90% of the time they find the solution very quickly by themselves.

Intermediate skills

Once I found my direction as a software developer, it was only natural to dig deeper and specialise. I chose back-end development and spent all of my time learning everything about C#, its frameworks and libraries. As an intermediate developer, it's important to pick a specialisation tech, get really good at it, and then learn all of the advanced concepts associated with it. If you keep switching languages or technologies, then your knowledge might broaden but it will also remain shallow. This is important to keep in mind because you don't want to be a "jack of all trades, but master of none".

As I drilled deeper into technologies and spent more time doing productive work, I found the problems that arose were no longer simple enough for a quick Google search. I now required two more major skills, namely:

• Problem solving and
• Communication.

Dev skill 3: Problem solving

Standards, best practices and Google will only get you so far. At some point you will run into problems that you will have to solve on your own. Being good at solving problems is not purely about IQ, I find that the biggest factor is being persistent - something that everyone can do.

When tackling issues, I stick to a very simple process:

1. Whiteboard the problem and get a good understanding of it, so that there is a clear goal for what needs to be solved.
2. Simplify the problem or break it up into smaller concepts.
3. Brainstorm many different possible solutions and ideas. This is not the time to analyse the ideas, but to simply write them all down. Even a bad idea may spark a different idea in someone else.
4. Compare the solutions by drawing up a list of pros and cons. This is when you should analyse and criticise every idea to find the best solution on your list.
5. Explain the problem and the possible solutions to someone else - even to the pot plant if nobody is around. This step helps because explaining the details of a concept requires breaking down the idea and structure into a simple form, which improves your understanding of it.
6. Keep revisiting the problem, take breaks and look at the problem with new eyes. We often don't correctly judge our own ideas because they make sense at the time. Once you have forgotten your justifications for an idea and it's no longer personal, you can judge it as if it is not your own.
7. MOST IMPORTANTLY: Don't give up! Keep trying and simply spend more time on it.

"It's not that I'm so smart, it's just that I stay with the problems longer." - Albert Einstein

Dev skill 4 - Communication

I believe that communication is the most important skill that you can cultivate as a developer. This is because you need to be able to communicate with your team members, other teams, clients, and even yourself. So, it is important to broaden your understanding of what good communication might look like.

Often we think of communication as the transfer of information from one person to another via spoken or written words. But I'd even include the transfer of information from your present self to your future self. For example, taking notes that you can't understand the next day is likely due to poor communication. The same applies to modern code because it needs to be written for humans to read, and to be translated into bits of information that computers can understand. This means that your code is a form of communication. As your code base grows larger it becomes more important for it to be readable.

With that in mind, here are some tips to focus on:

1. Clarify the obvious: Avoid any misunderstandings by double-checking that everyone is on the same page, because what is obvious to you may not be obvious to others. To clarify what you have communicated, state the obvious and ask many questions.
2. Clarify jargon: Don't assume that everyone uses or understands the same jargon. Simplify your language when talking to new team members, or people outside of your direct team. Furthermore, if they use jargon, ask them to define it - even if you think you know what they are talking about. Often, you will find that people have slightly different understandings and interpretations, which could lead to a massive miscommunication.

"Indeed, the ratio of time spent reading vs. writing is well over 10:1." - Robert C. Martin

3. Code in a communicative way: The quote above really points out how much time we spend reading code, and why writing code that is easy to understand is so important. Writing logical and straightforward names for your projects, classes, functions and variables is a crucial part of communicating well. Spend some time and effort considering them.

Senior skills

A quality senior developer has earned all of their badges for being able to write good code. This does not necessarily mean that they write more code faster, or even better, than the next developer. They are simply able to add more value to the bigger picture and to make everyone on the team more efficient.

In other words, the real job of a senior developer is to double the output of all the other developers on the team. I have learnt that to do this effectively, one needs to learn three overarching skills:

• Leadership
• Teaching
• Reading the bigger picture

Dev skill 5: Leadership

By motivating team members and providing a clear path for them to follow, senior devs are able to help them do their best and reach new heights. Learning how to be a good leader is a topic which could take up another entire blog post, but I'll give you the shortcut here. A simple way to understand leadership is to differentiate it from dictatorship:

Dictators:

• Push their ideals onto others.
• Always do what is best for themselves.
• Take credit and assign blame.

Leaders:

• Set a good example which others choose to follow.
• Make decisions that are best for everyone while always including them in the process by listening to and understanding them.
• Assign credit and take blame.
• Protect those around them.

Good leaders realise that their own success is derived from the success of their team, and therefore uplift and help every team member reach success. After all, either everyone wins or nobody does.

Dev skill 6: Teaching

Naturally, once a developer has reached a certain level of seniority, everyone looks to them for advice. Learning to become a good teacher is a great thing, because the more a senior developer can upskill their team, the higher their output will be. Teaching is something that anyone can be good at because the fundamentals are simple:

1. Teaching requires patience with yourself and others: The most important trait to being a good teacher is patience… practise it! A good teacher realises that a subject is easy for those who know it but is difficult for those who do not, and this helps them to be patient with their students.

"If the learner has not learned, then the teacher has not taught." - Unknown

2. Diversify your explanations: If your student did not understand your explanation the second time, they probably won't understand it the tenth time. This is when you should try explaining it differently, from a different perspective or with a different example. This is a rinse and repeat process, and a good reason for why you need to have patience.
3. Make complex ideas simple: Good teachers truly understand what they teach and are able to break complex concepts down into very simple forms. When explaining:

• Avoid jargon
• Use simple, practical examples, and
• Use analogies.

"If you can't explain it simply, you don't understand it well enough." - Albert Einstein

Dev skill 7: Seeing the big picture

Senior developers need to make sure that the team is going down the right path, and in order to do that they need to understand the "bigger picture". The big picture includes:

• How the system fits together,
• How the team works, and
• Understanding how decisions made affect the system.

By seeing this, you can steer the team around obstacles and towards success. For example, if the first iteration of the system is easy to maintain, resilient, has no technical debt, and performs well, then there is immediately a greater potential output for future work on the system.

While it is usually not possible to get everything perfect on the first try, even 50% is better than nothing and a constant drive to full efficiency is what will create a great system. This is preferred over a scenario where the senior dev has no understanding of the big picture, which may lead to constant "fire fighting" when it comes to difficulties in maintenance, deployability, stability, and technical debt.

A lot of the knowledge on how and where to steer your team comes from experience, but here are some areas which can help you grasp this faster:

• Design and architecture: Learn how to structure your projects, build reliable systems and write maintainable code. For example, you can check out the 12 Factor App to get a good overall understanding of the types of things you need to consider for your applications.
• Learn supplementary techs: Broaden out again and learn techs that touch on your main tech. For example, I am a back-end dev, so I learned a bit of front-end, DevOps, and database management. The goal here is not to do that work since specialised talent will have a much deeper understanding and skill. The goal is actually to allow you to see the strengths and weaknesses of surrounding techs when you are planning and building your solution.
• Project management: Learn about management styles and how companies run tech teams. As a senior, you need to guide and mold your team's work culture and, by having a good understanding of management, you can maximise its benefits. For example, understand the Agile manifesto which will give you a strong base understanding of the most common management styles used today.

Keep working on it!

Growth Phase:

If you are feeling hardworking, eager to learn, motivated or inspired, then you are in a growth phase. Take advantage of it and aim to reach that next level. Stay in your growth phase as long as you can, because you will naturally drop into your rest phase as you feel tired. I often see people grow for one or two days and then think that it's time for a break, when in reality a growth phase can last for months.

Rest phase:

Building your skills can take a large amount of effort and time, which you need to be willing to give in order to level-up. However, it is important to mention that rapidly growing for too long is not sustainable, and you will need rest periods. If you do not know how to grow more, then you are plateauing, not resting. In my rest phase, I do whatever relaxes me to help prepare for the next growth phase.

Plateau:

If you are eager to grow but find that you are stuck in a plateau, then you have to try and force yourself out of it with a new routine and a new goal. Go through each of these dev skills and assess where you may need some work, you can use this checklist to remind yourself of what to do.

Masters always go back to the basics!

Your skill and growth phases are directly proportional to your love and obsession for development. Find that passion and nurture it, because if you don't enjoy what you do, you will always be a step behind.

Resources

Here are two great blogs I follow which cover general topics on architecture, technologies and coding practices.

• Robert C. Martin's The Clean Code Blog

• Martin Fowler's blog

I put my personal notes on my Devobsession Blog, where also I cover technology details to broad designs.

Brandon Pearman is a Software Engineer currently working in Cape Town. He has a broad understanding of different technologies but his focus is on software design, architecture, distributed systems and code quality. He posts content on his personal site which you can check out here.