Here’s an opinionated set of thoughts on what a software engineer should do. This is not an exhaustive list—think of these as guidelines I sometimes follow in my head.

I’ve been involved in software engineering for over a decade now. I’m mainly an Android developer, but I spend more time thinking about builds and software in general.

I’ve been incredibly lucky to work in both small and large companies. I’ve worked with bad developers, good developers, and incredible developers.

This isn’t a topic I’ve really put pen to paper to think about (despite my advice below). I would love to see other developers thoughts and opinions on this!

Code Is Not Everything

At Twitter, I worked on a team that built features. We didn’t design architectures—that was the platform team’s job. We used the tools built by the platform team to create new features for users. In a sense, we were coding on rails—the core stuff was already solved, leaving us to focus on user-centric problems. It went something like this:

Making a new screen was a breeze; it was a solved problem on Twitter for Android. And frankly, this made coding pretty easy. But more importantly, it freed my mind to realise that there’s a lot more you should be doing with your time.

You Should Be Writing

I don’t mean writing a blog or adding code comments. I mean writing down opinions and positions on things. At Twitter, we wrote technical design documents, which were peer-reviewed and questioned.

Only once you’ve written down your thoughts, argued with yourself, and really thought through a concept, can you then take it to the world.

Part of software engineering is winning people over. You can only do this if you have a solid grasp of a concept.

You Should Be Talking to People

Learn what others do.

Twitter was a fountain of knowledge. I met so many incredible people working on a vast range of projects. I learned from design, UX, product, and engineers from Android, iOS, frontend, Scala, Python, and build tools. But never assume you know how to do their job better than they do.

At Twitter, we were encouraged to spend a lot of time talking and learning. This is better for your team in the long run. A good software engineer should instill this mindset in other engineers—and even in the entire team.

I can’t even quantify how much I learned and how many conversations I mentally refer back to. In hindsight, I wish I had made more of these opportunities—especially since I was often coding on rails.

Learn a Superpower

Or learn a tool.

I invested a lot of time into Twitter’s observability tool, Interana. Mastering this tool was a superpower—it allowed me to identify issues quickly and find solutions. It’s something I still find helpful today in my work at Marks & Spencer.

While learning a tool can be a superpower, learning others’ superpowers is another one (are you following?). My favorite moments in my career have been when someone’s mastery of a tool makes my jaw drop. Those moments teach me who to approach when I need help.

Opinionated But Pragmatic

Software engineers tend to have strong opinions—and a habit of disagreeing about everything. I’ll never understand why, but they do. I call these “software engineering fights.”

In my opinion, it’s incredibly unproductive for the business to be constantly combative. A good engineer is pragmatic.

Pick Your Hills

Choose topics to become an expert in (write about them and argue with yourself). Then, hold your opinions on those topics with conviction. When necessary, these are the areas where you plant your flag on a hill and defend them.

For other topics where you’re not an expert, share your opinions and defer to those who are experts. Take on their viewpoints and really mull them over. You may still disagree, or you may learn something new.

To tie this back to earlier: I will always fight for something I believe will put part of a codebase on rails.

First Principles

Learn how to break down your area of expertise to first principles. I don’t think you’re truly an expert until you can explain a complex topic from the ground up.

First principles are key to getting people who disagree with you onto the same page.

Give Up on Some People

Hard conversations are a good thing, especially when you’re dealing with another pragmatist. But when you’re not, you have to learn to give up on some people.

Here’s who I’ve given up on (and continue to do so):

  • Developers who enter a legacy codebase and immediately insist everything needs to be rewritten.
  • Developers who make you question your own expertise. Have you ever known a topic inside out, only to be told you’re wrong? You read the documentation and realise you were right all along. At that point, give up on that developer.

Now this sounds drastic. But I think of it like this, I want to give my best to my employers and I don’t think I do my best when I am hung up on a silly software engineering fight.

I do think you should invest time trying to understand why you are having a disagreement and grow from it.

Don’t Give Up on Juniors

Learn how to mentor. While I dislike labeling developers as “junior,” I think it’s relevant here.

There’s a difference between a junior with a strong (but wrong) opinion and a developer with 20 years of experience holding a strong (but wrong) opinion. Go back to your first principles and guide them through.

Be Good at Coding

Didn’t I just say code isn’t everything? I did—but everything else in this post is only possible when you’re really good at what you do.

I’m pretty good at Android development. I have my areas of expertise: Dagger, Coroutines, Gradle, and more. But the reality is, it can get pretty boring after a while. That’s actually great—it means the coding part of the job can go on rails. This allows your brain to branch out and explore the wider domain of software engineering.