Cordial Coder

soft skills for software developers

A Quick Guide to Ego-Free Coding

As a developer, it's so easy to get emotionally attached to your code. Partly because at it's core, writing code is a solo activity. It's also enormously difficult - fighting with a compiler, stringing together fragmented tooling, and trying to solve difficult problems all day will cause you to feel quite relieved when you finally do accomplish something.

But then, after all your hard work, a teammate could look over your shoulder and point out everything that you could've done better. Or you could get hammered in a code review. Or you might break the build right off the bat.

What!?!? After all this intensive effort, and a looming deadline, you have to go back and make changes to the code you worked so hard on because by some metric, it's just not good enough.

via GIPHY

Welcome to being a developer! We can all relate to this feeling through similar moments that have probably happened many, many times in our careers. Despite having technical jobs, how do we solve this frequent, non-technical problem?

This is where having a healthy dose of perspective comes in handy.

Ego-Free Coding in a Nutshell

Writing code on a team is unique in that it requires you to both demonstrate technical ability in a difficult, independent activity while also coping with your work being questioned at all levels by coworkers. Sure, you can remain unattached and haphazardly sling code around, but often it won't work or it (eventually) won't scale in some sense.

And if you've been in the game long enough, you've probably developed a sense of pride in how you work as a developer - your code style, your special preferences for tooling, how you solve problems, etc. This pride can definitely have the potential of getting a little unhealthy.
"Developer Holy Wars", such as Vim vs. Emacs or tabs vs. spaces, are great examples of investing a little too much pride and emotion into developer tools.

To manage the constant challenge of both improving your technical skills and handling external evaluation of your code, it's important to keep your ego in check. Practicing ego-free coding facilitates this, but it requires you to have the soft skills necessary to perceive your work in different contexts in a healthy way.

By all means, have pride in your code and fall in love with your own personal style as a developer. You're doing something that's incredibly difficult, after all! But when it comes time for your code to be analyzed by your peers, be able to take a step back and look at it more objectively.

In other words, don't fret about becoming attached to your work, but understand that code can always be changed or improved in different contexts. This doesn't lower your worth as a developer - it just offers opportunities to continuously learn new things!

Where Ego-Free Coding Benefits You

Individually, being able to look at your code in the most objective way possible will help you to find areas of improvement. It's easy to copy a few things over from Stack Overflow and call it a day, or reuse a component somewhere else in the codebase (which should absolutely be done, by the way). It takes much more discipline to take a hard look at your code and identify areas of improvement.

And to echo the message of this blog, there's so much more to being a developer than writing code. Your work will constantly be evaluated in a technical sense by your teammates in code reviews, team meetings, pair programming, etc. Automated testing is another area where your code will undergo scrutiny.

Depending on where you work in the stack, your work may also be reviewed and possibly challenged by other technical folks too. For example, a back-end developer might work hand-in-hand with build engineers on occassion. Or a front-end developer may pair with designers on prototypes. A healthy ego can help smooth these technical conversations and keep focus on the task at hand.

And then there are the non-technical evaluations. Think product demos. Your Product Owner, manager, stakeholders, and other interested colleagues could all be looking at your work in a critical way. In these scenarios, it's really easy to get trapped in the "It's not a bug, it's a feature!" mindset.

via GIPHY

Eventually, your work will trickle down to the most important part of the equation - the end user. There, user feedback and analytics data could prove that certain parts of your hard work weren't all that successful. Or at least that there's room for improvement.

At every step of the way, your code will be analyzed and critiqued. As someone who's been there before, I know how easy it can be to get defensive when your code, or the output of it, is questioned. But being able to step back and take a look at the bigger picture will help you to gain a healthier perspective. In short, the perspective gained from ego-free coding will improve every area of your working life as a developer!

Three Outlooks That Padawan Ego-Free Coders Should Have

Let's get started. There are three frames of mind that every developer should have on their path to fostering an ego-free coding work style. Keep in mind these outlooks aren't like code - you can't create them overnight. But by working on integrating these three ideas over time, you'll become a more focused, effective developer by leaps and bounds.

Start with #1.

1) Cultivate and accept the idea that there's no end to programming knowledge.

There's always something new to learn as a developer, and the sheer volume of information can often be overwhelming. Behind every language, framework, library, build tool, and computer science concept, there's a virtual treasure trove of information to explore.

You'll always be learning, and there will always be something that you don't know. Because of this, understand that there will always be holes in your knowledge and "flaws" (or the perception of them) in your work. You're not perfect. With ever-changing technologies and innovation, there will always be something new to learn.

Does this excite you, scare you, or maybe a little bit of both? Either way, have faith and move to #2.

2) Cultivate and accept the idea that you won't always write "perfect" code.

You won't always have days that are optimal for writing your best code. Life is tough, and other distractions that come your way will prevent you from giving your 100% at work. Maybe you'll get sick, or family troubles will come up, or March Madness begins and you can't help but pull up a game on your second monitor.

This is ok! The sooner you accept that fact that you'll never be able to write the "perfect solution" in every situation, the easier it'll be to focus on continually learning and practicing. And forgiving yourself when your code doesn't pass the linter because you were busy watching replays of that slam dunk while writing it :)

Relax and stop taking yourself so seriously.

After you've breathed a sigh of relief, take your final step to #3.

3) Cultivate and accept the idea that there will always be better programmers than you.

Let's briefly shift way beyond coding for a relevant anecdote. Starting in high school, I trained Brazilian Jiu-Jitsu for ~8 years. For those not familiar, it's a grappling art (which has also evolved into a combat sport) in which the goal is to defeat an opponent through chokeholds or joint locks.

I was fortunate in that I got to train with a wide variety of grapplers from all walks of life - men, women, rich, poor, old, young, small but springy, and even bodybuilder-sized mass monster dudes. Competing with such a wide variety of people taught me one very important psychological lesson at a young age - no matter how much you learn, there is always someone out there who's more skilled than you. Someone will always have your number.

via GIPHY

Now I don't think you need to get yourself into a joint lock to learn this lesson! I think this concept translates over to any pursuit, including development, and I could see how it could be really uncomfortable to someone who's never really considered it. But by accepting it, you'll be relieved of the notion that you always need to be better than everyone else at everything you do. You'll be able to look up to developers with more experience and feel inspired rather than insecure.

Long-Term Benefits Of Ego-Free Coding

Adopting an ego-free work style as a developer will enable you to improve both your technical skills and soft skills. This will translate into higher quality work and better working relationships with your teammates.

From a technical sense, you'll be able to analyze your code in a more objective way and find areas to improve. By identifying patterns in your work, you'll be able to identify gaps in your knowledge which will inform what technical topics to learn next. You'll also build up your tolerance for criticism on code reviews, even when it's communicated poorly. In these cases, you may feel frustrated but definitely not threatened, because you'll understand that there's an infinite amount of things to learn and your code can always be improved.

Beyond broadening your technical skills, being comfortable with constructive feedback and not getting defensive will cause your peers to respect you more. You'll be able to foster stronger working relationships with them because they'll feel like they can share information with you without the fear of negative consequences.

When tense situations arise, having a healthy attachment to your code will allow you to maintain a relaxed demeanor. That way, you can steer the conversation toward the truly important topics and demonstrate that you're a natural leader. This will translate into higher quality output from your development team and a better product for your end users when it comes time for evaluations like product demos and examining user feedback.

Without your ego in the picture, you can relax and focus on solving real problems alongside your team.

Since you'll be more focused on delivering value to users than "proving yourself" in a technical sense, you'll have a critical shift in mindset. You may find yourself asking stakeholders more questions and being more concerned with catering to user top tasks rather than building out arbitrary new features.

If you're on a development team, ego-free coding will help you to stop contextualizing every situation with the word "I" and instead use "we". You'll optimize your code for value added - designing it for team use and only solving for relevant use cases. After all, your users don't care about who the smartest technical whiz on your team is.

How Ego-Free Coding Practices Can Benefit Your Entire Team

If your entire team can align with the principles of ego-free coding, you'll be able to accomplish so much more. Instead of wasting precious time and energy on personal status management in code reviews and team meetings, everyone can stay laser focused on satisfying the needs of your users. A paradigm shift will take place in which everyone will view their code as simply a tool that solves user problems.

Developers won't think of writing code as a way to showcase technical talent, but instead as a way to solve for real life use cases. To ensure that the codebase and product remains stable and improves over time, high quality code will be encouraged and ideally code will be written so that it can be maintained by all other developers.

This mindset will also steer the team's energy towards collaboration. By thinking from more of a team-oriented perspective, developers will be less likely to worry about their individual status and more likely to focus on how the team can provide the most value. They'll become more open to asking questions and working together instead of tucking themselves away into a corner in an attempt to solve a problem all by themselves.

via GIPHY

Other Ego-Free Coding Topics to Think About

There are so many more topics to explore when it comes to ego-free coding. One important area to think about is fostering a team environment that values and supports ego-free coding. Another such area is how to healthily recognize, evaluate, and appreciate your own value as a developer on a team. I'll be exploring this topic in my next post.