Being a good developer is not all about technical

Photograph by Manik Rathee

I started in development quite recently, 2010. Since then I’ve been very opened to learn any new programming language, skill, or trick that I had no experience with. By that time I thought that in order to be a good developer all I had to do was to focus on these technical areas that I wanted to be good at and make sure I mastered themlike the one who wrote the Frameworks that I was going to work with. Does it define you as a good developer? Not at all. You’ll be a good developer technically speaking, but working in tech is not only about code but about doing things such as working with people, with designers, with users,… Being good technically would keep you ahead from what’s going on around you, and these variables are very important and influence the way you work and the quality of your work. I’ve learnt some of them during these 6 years developing. Some others are probably missing and I’m looking forward to learn get better at them.


The first one of these variables for me is being human, we work with computers but also with people. You might know how your computer works, all the scripts and shortcuts that you have defined, or the tools that you use every day, but remember that you work with people and humans are the most complex machine ever invented. It’s so complex that sometimes we don’t understand ourselves. Every person in your team will have its own personality, and you have to learn about them in order to know how to work with each one. Having people with different personalities makes your team rich and more diverse and the project benefits from it. Try to understand the people in your team, their concerns, their goals in life, what’s their current situation, what excites them and what’s incompatible with them. Try to be flexible to “match” these people and work with them nicely. In that regards I like talking about personal things with my colleagues, what they did the day before, how is the week going, … I ask them about their children, or plan some beers afterwork. Be emphatic. Be human when writing code. Write code that everyone can understand, write code readable for humans and interpretable for computers.

Love what you do, pursue your passions. If you don’t, stop doing it. Our code is the way we express a problem’s solution, and with it, our feelings are printed. If you don’t love what you do, your code won’t be a lovely code. Sometimes you’ll have to work in areas that you don’t like that much, but at the end you’ll have to code, and that’s something as a developer you should love. Don’t leave a bad day to ruin the quality of your work. If you don’t feel good to write a few lines of code don’t do it. We, all, have bad days but it’s very important you control your feelings and don’t manifest them. It’s hard when you have a nice day of work with one of your colleagues and the day after he/she’s upset because of something and there’s no one who can work with him/her.

  • Love your code, and write it with love. Don’t add shit to shit, but cleanup and write code that other people would love using as well.
  • Love coding and making things real. Taking specs, taking designs and shipping features for users. You’re an user as well!
  • Love your team, and do your best to understand them.
  • Love the product (and use it). You’ll even be more passionated when writing code for it.

Be curious and don’t lay over your comfort zone. If you love what you do, you’ll likely be curious about what’s coming up next. Don’t try to use the same patterns and tools over an over because they worked for a particular problem but there might be better approaches now. Avoid copy and pasting code that will make you feel less curious about what the code is actually doing. Feel curious about the new languages, patterns and platforms that are constantly evolving and improving the way we write code nowadays. Keep a focus when you do it, otherwise it can be a bit overwhelming sometimes. Relax in what you learnt some years ago is a bad signal and not having time a bad excuse. If you have 1 hour daily for Facebook I’m sure you have a couple of hours every week to read tech articles, blog posts, work on an open source lib, … If you don’t feel that curiosity it might mean that the area you’re working on is not interesting at all for you. Consider moving away from it and find your path.

  • Try to understand the code that you write, even if you based it in an existing pattern. The pattern might have been valid for a long time or for some use cases but not for yours.
  • Try to understand your colleagues improvements, and give them feedback, in particular for that code that you’re going to build components on top of it.
  • Stay connected with the community, learn about the new tools and languages. You can take your time, there’s no need to rush, but keep connected.
  • If there’s any area you are particularly interested in learning, establish a focus there and find the path to get better in that area. It’s very important the company supports you here since it’s part of your personal growth.

Leave the ego at home. Don’t try to show off your stuff in your team & company and be humble. Ego is synonymous of discomfort. Celebrate the success with your team and show gratitude to every colleague that has been there helping you. Don’t try to rise up yourself over your colleagues and look for horizontal structure where everyone has voice, where the decisions are taken as an agreement of every person’s opinion. It shouldn’t be a matter of the time the person is at the company, the age, the experience, the gender,… Encourage people to be more participative, and flatten team structures when they are becoming pyramids.

  • Don’t try to be everywhere to show off that you’re a “responsible” person.
  • Share the success as a part of a team effort (because in very weird scenarios you did it alone).
  • Allow and encourage people to be part of showing successes. Even if they are shy.

It’s also important that you learn to be thankful. People will help you along the day, to fix that problem that came up in the morning, to understand a component that you have to refactor, or to learn something that you have no idea about. Make sure that you end with a big, THANKS. Because these people are investing their time on you and that means they appreciate their colleagues. Be helpful with these people that need help from you. You can be very tired, very focused on your tasks, but learn how to move into these people concerns and help them to move on. It can be a new colleague with some doubts regarding the project, a component that you implemented in the past and someones is trying to improve it… Don’t say no. You might need help from that person in the future.

  • Thanks the colleague that helped you with that issue that took you hours to fix.
  • Thanks the colleague that helped you with sharing the concerns with the rest of the team.
  • Thanks the colleague that spent some time listening and understanding you.
  • Help newcomers to get on boarded into the project.
  • Help someone who is trying to fix a bug and has no clue about how to fix it.
  • Help someone who is doing his/her first big feature and there’s something he/she should know about.
  • Help in other departments when they need your help.
  • Think about the help people might need in the future and help them in the present.

When you work as a developer you write software logic. That software is going to be used by users, other companies or even your own company. You might write a perfect code which work as expected or you might forget some odd edge case that is going to cause unexpected software behaviour. When that happens you have to be very responsible. The first step is assuming that the error is part of what you wrote and take action, analyse the problem source, fix it and propose a solution to avoid this happening in the future. Don’t throw the ball in your colleagues court, don’t find another responsible person. It’s very important that you are calm when these things happen, product managers or your colleagues might come to you a bit upset, or with a cold voice tone, don’t take it personal, relax and do your best as an engineer, solve problems.

  • Feel responsible for these pieces of code you write. When a bug arises, rise your hand as well and help with the fix.
  • Be responsible with your work, and work as a professional. Be there whenever the company or the project needs help from you.
  • Be responsible even if there’s no on-call rule define (and even if that means working during the weekend).

Embrace openness. Share your thoughts, your concerns, doubts… Share how you feel and share if you are not happy at all with what you are doing inside the company. If you are close and keep the things for yourself you are just creating a big ball of discomfort and sooner or later it’ll end up exploding. Don’t be afraid about doing it, but be completely honest. To your manager, your colleagues, your CEO, … Be open and don’t forget about being respectful. It’s very important that when you argue with another person you respect him/her and don’t bring personal feelings against him/her.


And before concluding, one that I think is very important and includes the previously mentioned, be a professional overall. Keep it in mind and if there’s any area that you feel needs some improvements work on it. I’m the first one that is not good at all the points I’ve mentioned. It takes time and experience to understand the important of every of these points. Whenever I feel I’m behaving not professionally in any of these areas I stop, rethink it and try to modify my behaviour and the way I was pretending to react. I think as a developer we should do our best to learn from experienced people and put some focus on these areas. Being a developer is not only about you working with computers, is about you, working for people, with people, using your computer. I read a lot about these areas, either via blogs, books, Youtube videos and hanging out with experienced developers that are opened to share their experience.

I’m sure I forgot some points that are also important. If you notice there’s some missing please write a comment or send me an email pepibumur@gmail.com. I’m open to include them as a part of how to be a better developer.

Thanks for reading and María for helping with the grammar & typos.