You have two jobs

This post was originally published here

Welcome to FictionalSoft! I hope your first week is going well? Great.

As you start to find your feet, I want to make sure we’re have a shared understanding of what success looks like here. Apologies in advance if I’m telling you something you already know, but I think it’s important to be explicit about this early.

You were hired to write code. Many developers make the mistake and think that their job stops there. That’s not true. In fact, you have two jobs:

  1. Write good code.
  2. Be easy to work with.

The first part tends to be the easy part. Coding can be challenging at times, but you’ve made it this far in your career so clearly you know this bit. The bit that many engineers struggle with is the second part, but it’s that second bit that tends to be most critical to success. Solving technical problems, or earning new tech – that’s is easy with support. People who are great to work with get that support. But people who are difficult to work with struggle. At best their careers stagnate; at worst they get fired.

Being easy to work with doesn’t mean being a sycophant or a pushover. It doesn’t mean not having and expressing strong opinions. In fact, some of the people I find easiest to work with are people who consistently disagree with me! “Easy to work with” means that you act professionally at all times. You disagree respectfully. You seek to understand before looking to be understood. You communicate clearly. You value your commitments.

Mostly, it means that you understand the value of relationships, and build them as carefully and intentionally as you build frameworks and libraries. Strong relationships with your colleagues will make you – and them – more effective. It’ll give you both common ground to build on when you don’t agree on something, and ensure that you can resolve conflict professionally.

One of the most effective engineers I worked with spent her first month here very intentionally taking every single one of her new co-workers out to coffee, listening carefully to what they did, what they struggled with, and what they hoped she’d do in her new role. That was a great investment for her and us: it meant that she could join any team and instantly be productive, because she had a relationship to build on. She quickly became a key “fixer”, someone we relied on help solve our hardest problems. Part of this was her technical skill, of course, but her relationship power played an even greater role in her success.

You don’t have to copy this specific tactic. Just like there are many ways to write good code, there are many ways to be an excellent co-worker. I expect you to be effective at both of your jobs, in whatever way that works best for you.

Most of the hardest problems we face have both technical and human components, and the best engineers know how to solve both.

I think you’ll do great – we wouldn’t have hired you otherwise! I’m here to support you, and help you be successful at both your jobs.

Any questions?

Related Posts

psutil 5.4.0 with AIX support is out After a long time psutil finally adds support for a brand new exotic platform: AIX! Honestly I am not sure how many AIX Python users are out there (I ...
Gynvael’s Mission 11 (en): Python bytecode reverse-engineering Gynvael Coldwind is a security researcher at Google, who hosts weekly livestreams about security and programming in Polish and English). As part of th...
Leaving HPE For the past two years I have been employed by Hewlett Packard Enterprise to work on the various tools, libraries, and frameworks that make up the ope...
Unix locales vs Unicode (‘ascii’ codec can’t encode character…) You might get unusual errors about Unicode and inability to convert to ASCII. Programs might just crash at random. Those are often simple to fix &mdas...