5 Tips to Be The Best Version of Yourself as a Developer

We strive to be the best we can be. To be acknowledged by our peers. To receive praise in our company newsletter, favorite mailing list, or blog. You might think you’re doing everything right, but what if you’re wrong? Let’s take a look at how you can be the best version of yourself as a developer and maybe even as a person. Letting go of your ego could be the key.

Below are five steps that will help you make a start.

1. Become a student
2. Don’t be passionate
3. Don’t be proud
4. Stay a student
5. Be responsible

These steps have been inspired by feedback from developers, as well as from books such as Ego is the Enemy by Ryan Holiday, Extreme Programming Explained: Embrace Change by Kent Beck and Cynthia Andres, and Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt.

1. Become a student

It doesn’t matter whether you’ve been a developer for the past thirty years or if you’ve just started, we all need to start (again) from scratch, as though we don’t know anything. To learn and to progress, you need to become a student.

The most common and effective way to move forwards is to learn from others. We read books and articles. We listen to podcasts and watch tutorials. Then we write some code and fail. We debug, then fail again and again—until we work out how to do it. Then we can move on to the next thing on the list, and then the next. After a while, we can look back and see that we’ve learnt a lot. But how quickly we reach this point is solely up to us.

It’s not just about how “clever” you are, it’s about how humble you are, too. It’s about how you want to learn from your failures and if you’re prepared to exchange your ego for feedback from people who have something to teach. It may hurt, but it’s the fastest way to improve.

2. Don’t be passionate

On the one hand there is passion, but on the other hand there is caring. Passion is the unbridled enthusiasm we have for trying new things—for telling others that our way is the right way and that we are the ones who are right, not them. Passion is that energy we use to dive into a problem without thinking first.

You might hear people arguing about which is the best text editor and why their favorite one is the best (only) tool to use. There is an excellent example of this in Extreme Programming Explained (further information about extreme programming can be found in these rules).

_“People get passionate about coding style. While there are undoubtedly better styles and worse styles, the most important style issue is that the team chooses to work towards a common style”_—Kent Beck and Cynthia Andres

You see, it doesn’t matter if you think your way is the better way: the best way is the one that everyone agrees on. Sure, when it comes to choosing a text editor, someone might prefer using Vim, while someone else might prefer Sublime, but if you are going to pair program, you need to ignore your ego, swallow your pride, and use a text editor that you are both happy to use.

Another thing to bear in mind when you are too passionate is something called “sunk costs”.

_“If you cannot imagine circumstances that would cause you to change your mind about something, then you may well be the victim of the power of sunk costs”_—Alan Jacobs, author of How to Think: A Guide to the Perplexed

Let’s say you spend a week on a task from your Sprint. You think it through and come up with a brilliant solution. It’s elegant and you are proud of it. You’ve run all the tests and everything looks great. You’re ready to merge into master and deploy to production. Then the product owner changes their mind, or circumstances change and your solution is no longer needed. There are two ways you can deal with this: you can let your ego take over and you can complain to your product manager about it and even call them a @!#$$!@, or you can feel sorry that the customer spent money on something they no longer need. Adopting the latter approach allows you to stay calm about it and view it as having been an excellent exercise for you. In the process, you learnt that you can come up with good solutions and you did a good job.

The second reaction is called caring—you care about the product you are working on. You care about improving your skills and helping the customer. You care while retaining an open mind and a desire to learn.

3. Don’t be proud

_“A proud man is always looking down on things and people; and, of course, as long as you are looking down, you cannot see something that is above you”_—C.S. Lewis

You are proud of yourself because you were able to fix the bug in record time. You are proud because you have better code-fu than your colleagues. But are they things you should actually be proud of? That you can show someone you are better than them? How is that going to help you? Do you think you will make more friends because of it?

_“Pride leads to arrogance and then away from humility and connection with your fellow man”_—old Christian saying

Pride turns to arrogance, which will only hurt you. Some developers don’t write tests because they are arrogant enough to think they have written bug-free code.

Some developers are also too proud to take note of their customers’ needs, despite having been given a clear list of features and an outline of how the product should work. They decide it doesn’t make sense and do things their way instead. Does this mean that the customer is always right? No. However, you shouldn’t ever be so arrogant that you don’t see a need to ask for feedback or guidance on something that doesn’t make sense.

So how do you avoid falling into the trap of being proud? Is there a checklist you can use? We found a useful one put together by Holiday.

“The question to ask, when you feel pride, then, is this—What am I missing right now that a more humble person might see? What am I avoiding, or running from, with my bluster, franticness, and embellishments?”_—Ryan Holiday, author of _Ego is the Enemy

And to that, we would add ask for feedback. You might be right, but it never hurts to hear other people’s opinions.

4. Stay a student

Once you reach a stage where you feel comfortable with the knowledge you’ve acquired and other people might come to you for help with problems, it might feel like you’ve become an expert. You might think: “_Sure there might be a few more things I could learn but, hey, I’m good._”

Sorry to tell you this, but if this is the case, it sounds like you have got stuck on an alternative learning path known as Expert Beginner, as outlined in the Dunning-Kruger Effect, a theory that has five stages:

• Novice
• Advanced Beginner
• Competent
• Proficient
• Expert

_“Advanced Beginners can break one of two ways—they can move to Competent and start to grasp the big picture and their place in it, or they can ‘graduate’ to Expert Beginner by assuming that they’ve graduated to Expert”_—Erik Dietrich, programmer and author of How Developers Stop Learning: Rise of the Expert Beginner

The way to avoid this is to stay a student. The best of the best in every field are continually learning. Is your ego so big that you think there is nothing else for you to learn? Or do you agree that there is so much to learn that you will never know it all?

Only by accepting the idea that you will never learn everything and that other people may know something you don’t, even if they are more junior than you, will you be able to step in the right direction.

“It is not enough only to be a student at the beginning. It is a position that one has to assume for life. Learn from everyone and everything. From the people you beat, and the people who beat you, from the people you dislike, even from your supposed enemies. At every step and every juncture in life, there is the opportunity to learn—and even if the lesson is purely remedial, we must not let ego block us from hearing it again.

_“Too often, convinced of our own intelligence, we stay in a comfort zone that ensures that we never feel stupid (and are never challenged to learn or reconsider what we know.) It obscures from view various weaknesses in our understanding, until eventually it’s too late to change course. This is where the silent toll is taken”_—Ryan Holiday

5. Be responsible

_“You don’t have to respond to what everyone else is responding to in order to signal your virtue and right-mindedness”_—Alan Jacobs

You might hear someone talking about responsibility as response-ability. What does that mean exactly? It says that you have the ability to react or respond to different situations respectably—that is, without your ego.

So when someone says or does something you think is to provoke you, don’t respond immediately. Don’t let your ego take over. Give it five minutes if you can. You might have misunderstood what was said. Or the context might be different from what you originally thought. Never just assume things.

Did you find a bug in the code that’s not yours? If it’s in the production code, then it’s your responsibility to fix it. But keep in mind that no one can give you the responsibility, you have to accept it. And just as you accept the responsibility to write better code with automated tests, so these tests will be there for future programmers who will need them to make sure their work is not breaking anything.

You should accept responsibility to be a better you, to learn from others, to receive feedback with an open mind, and to help others if they need it. That is your responsibility. Try to let go of your ego and accept that you will make mistakes along the way. The rules we’ve outlined in this piece will help you in situations where your ego might get the better of you.

Now think about these rules—don’t just blindly accept them. Are they achievable for you? Think about them, sleep on them, and in the best-case scenario, act on them.

What you can start doing immediately after reading this article

• Write down the below guidelines and put them somewhere you can see them:

  • “I’m not afraid to say I don’t know”
  • “I’m not afraid to ask a question”
  • “I respect my coworkers’ opinions without judgment”

• Ask yourself this: “Do I know everything about what is important to my work or am I just avoiding learning?”

• Start saying thank you to people who help you, even with the smallest things.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by Brice Marchal