5 important but overlooked skills you should have as a top developer!
Tags: career, beginners, motivation, programming
Published: 2019-07-27 18:12:35

---
title: 5 important but overlooked skills you should have as a top developer!
published: true
description: Skills that you should know but nobody teaches you!
tags: career, beginners, motivation, programming 
cover_image: https://thepracticaldev.s3.amazonaws.com/i/q7dqunkalc9b93jylyxz.png
---
### Introduction

**You have seen these articles a thousand times:**

- "10 things you should build to become a top developer."
- "Top Frameworks to learn in 2019."
- "Do this to become a rockstar developer."
- "Read these ten technical books, and you will be a successful developer."

What they talk about is that you should learn `reactjs` or `node`. Build the 1.000.000.000 ToDo App. Read `Python Crash Course` and boom you're a top developer.

This is all (theoretical) technical knowledge. You need to learn the technical knowledge but do you think that a hairdresser that can hold some scissors in the technically correct way is good? There are more skills to consider in every profession!

Let's talk about at least, in my opinion, overlooked skills.

#### Abstraction

As a developer, you have to implement a feature that will be used by someone. This someone can be you, a client, your colleagues, people on the internet that you will never know.

Knowing this, it is your job to think for all of them and get the feature down to its essence.

Your management wants to see how often people click something on the website. You need to understand that they are **concrete thinkers**.

Your management thinks in list, numbers, and spreadsheets. Right now, they don't care and understand the bigger picture of your complex software. They don't have to. That is your job!

Coming back to the `how often has a user clicked on the website` task. I imagine my self in both roles. In the role of the user and of the person who then will see this data and will try to figure out what the user intended. 

For the end-user, nothing should change. Maybe a disclaimer that he/she has to click once. That's it. These features should be not visible for the end-user. Okay, that was easy. Always think about your end-user first! Always! 

Now, let's think about the person that has to make sense of the data. So what will he see? Just a number. Like `42`? But what does that number mean? Maybe a better way would be to measure not how often he clicks but what he clicks? You go back to your Product Team or the stakeholders and tell them that it would be maybe better to have a statistic about how often we click and what action was followed by that click. Probably you will hear something like `Oh you can do that? Yeah, let's do that`. I could go even more abstract on this topic, but I hope you get the point.


#### Asking the right questions

I see this all the time from Junior to Senior Developer. You get a task, and you do it. I call these people `Code Monkeys 🐵`. 

Part of being a developer is to ask questions and get down to the essence of what we want to achieve (this comes back to the abstraction point).
**One sentence can be interpreted in 1000 ways.**
You should understand why you are implementing this feature. So you can better see problems and future hazards.

Questioning **why** in companies is sawn often as a **trust problem**.
You will hear sentences like:
- We should trust the product team.
- Let's trust them they know what is best for the company
- Don't you trust me?
- Let's first try it and then ask questions

Asking a question and trying to understand why has absolutely nothing to do with trust. As a developer, you know the inner workings of the system. You can see the technical problems and point out what can work and what can not work. If you ever hear these sentences here is a reply that works always:
- "I trust you, and I know that this is important. <Repeat your question>"

#### Communicating with non-technical people

How often this has happened in companies chat systems like slack:
You open up a channel for the entire company, and you see some link to a super technical blog post about why `forEach` is faster than `map` in javascript.

Or you say "No, we can't do that" and you start to explain that reactjs does not have this feature and we need to load a npm package. 

If your product manager is not an ex-developer, then he/she will not understand a word you are talking about. 

Instead, you should try to find a good Analogy from a domain that everybody understands. Like I did in the beginning with the hairdresser. A non-technical person can understand that and conclude that you have a point. 

#### Patience

You see these tutorials on youtube where people create something in the video in 15 minutes, and then you try it, and it takes you way way way longer!

You get frustrated because you can not implement that todo list. It is also the first time you touched code. The Youtuber has at least ten years of experience and also prepared that video and implemented that todo list before at least once and now is just going down a script.

You know where the cliche comes from that developers are creatures of the night? Because we like it? Because we are anti-social? That's true maybe for a small group of developers. The biggest reason is that coding takes time! A long-time if you try out new things!

#### Strong opinion

I'm a strongly opinionated guy when it comes to web development, and I tell people my opinion even if I know that they will not like. I don't do that to annoy people or to bring them down. Like how can be my opinion so emotionally intense that after hearing it, you doubt your whole existence? Sorry but there are more significant problems behind that, and you should figure out how to deal with them because it will lead to only one thing: Stagnation. You will be the same at age 18, age 25 and age 50. I know this is easier written than done but you need to know: "How you are right now only brought you so far".

The worst thing that can happen in a development team is when everybody has opinions, but nobody is telling them! If this happens, you are doomed. It is the beginning of the end. If you are not a `code monkey` you will feel less motivated and more frustrated every day, and it will not only be you. Someday suddenly, people who worked for several years at that company will leave because they can not take it anymore.

Also, I'm not saying that you should say that you don't like this. You should tell why and give some examples. Don't be an as*h**e but also don't get frustrated a little bit more every day. It helps nobody. So either say your opinion, don't have an opinion and be a code monkey or leave the company to find a better job or go freelancing. I don't know, but don't stagnate!

**Thanks for reading!**


**Say Hallo!** [Instagram](https://www.instagram.com/lampewebdev/) | [Twitter](https://twitter.com/lampewebdev) | [LinkedIn](https://www.linkedin.com/in/michael-lazarski-25725a87) | [Medium](https://medium.com/@lampewebdevelopment) | [Twitch](https://dev.to/twitch_live_streams/lampewebdev) | [YouTube](https://www.youtube.com/channel/UCYCe4Cnracnq91J0CgoyKAQ)