Software engineering is a very broad profession with many different types of work you can do, each with their own opportunities and challenges, but have you ever wondered what those opportunities are? Perhaps you’ve feel your work isn’t challenging you enough, or your not motivated but what you do.

Photo by ThisisEngineering RAEng on Unsplash

In this article, I want to take you though some of the different places software engineering can take you, and what the opportunities, challenges and rewards are for each of them. Hopefully by the end you will be more equipped to understand the challenges and opportunities available to you and how you can shape your career choices around what excites you.

Front End & Back End?

You’re probably familiar with the split into “frontend” and “backend” engineering, you’ve possibly seen somebody exclusivity describe themselves as a frontend / backend engineer.

Separations like this are a good start, and we tend to think we have a pretty good handle on what they mean, but I don’t think they tell the whole storey. This separation makes the assumption that each of these categories is a fundamentally different role. However, the core challenge and activities in all of these roles is the same; you’re using your creative human brain to find solutions to problems and convert those solutions into code.

Or as a former manager of mine put it…

The biggest difference between front and back end development sits in two areas: The tools used to do your job and the problems you will be solving. Let’s dig into each of those a little deeper to see how they can effect the work you do.

Tools

No matter what you do, you probably use some kind tools, and those tools will be highly specialised to the task you are doing. For a mechanic these tools may looks like wrenches, screwdrivers or diagnostic devices. But for a software engineer these are more like the programming language, operating system, development frameworks and even development methodologies.

But here’s the thing: You are not your tools.

These tools exist to help you get your job done and may be different depending on what that job is. You shouldn’t allow yourself to become limited or defined by the tools you use. You chose them, you learned how to use them, but they are but an artefact of the problem you are solving not the definition of what you do.

The Problems Being Solved

The other difference is the actual problems you are trying to solve – the challenges you are facing on a daily basis. I’ve heard a lot of engineers over the years talk about how they don’t feel like their project is providing them with “real challenges”.

Photo by heylagostechie on Unsplash

For developers who work on the front end, this can often sound something like “all I do is call and API and render it on the screen; I don’t do any ‘real engineering’”. Whereas on the other side it can sound like “All I do is manipulate data and pass it to the UI; I’m too far from the real code that the user sees”.

Often when feeling this way, there is challenge available to them – but it’s not challenge that excites them, it’s not work that motivates them to get out of bed in the morning and go to work.

If this sounds sounds like you, perhaps you too are not solving challenges that motivate you. Understanding what challenges are available in different roles and knowing which ones inspire you most will empower you to make the right next move in your career (weather that be a new job, or a discussion with your manager to ask for different activities).

The Challenge Spectrum

So, it seems that a traditional frontend vs backend definition is not enough to articulate the different choices you can make to position yourself in a place to solve exciting problems and do your best work. Instead, I want to introduce you to the Challenge Spectrum.

The Challenge Spectrum spans from data & platform challenges to human & interaction challenges, taking in all possible roles you can occupy along the way, all of them as just important as the others. At several points along the spectrum, Ive annotated some example challenges you may face at that location.

By thinking deeply about opportunities that excite, drain or bore you, you should be able to find a place (or number of places) where you are most challenged and inspired to do your best work. Its important to remember that no point on the spectrum is better or worse than the others. Hard work across the spectrum is required to create successful products, and finding your place on it will allow you to make your best contribution.

• Backend: Data & Platform

  In these roles, you are primarily solving problems involving specific platforms or data structures. You’ll be pulling from your deep platform or theoretical knowledge.

• • Memory optimisation of 3D textures to avoid CPU cache misses
  • Writing low level CPU specific code
  • Heavy data manipulation
• • Considering the architecture of the whole system and how the different pieces communicate into one product
  • Reverse engineering malware
  • Game engine performance optimisation
• • Web service performance optimisation
  • Creating a flexible architecture to build the UI on
  • Integrating multiple components together into a single product to solve customer issues
• • Understanding and reacting to a range of machine unknowns (screen size, font size)
  • Thinking deeply about accessibility tools
  • Working with user experience designers inform the design direction and possible highlight any possible issues
• Frontend: Human & Interaction

  In these roles, you are primarily working on end user facing problems. You’ll be relying on both your empathy as well as data-driven conclusions of how users use your product to act as a customer advocate.

Common Challenges

Along the entire challenge spectrum, there are a set of shared challenges that are common to all software engineers. The very best engineers are expert at solving these challenges as well as those specific to their role:

• Communication
  Teams that work together towards a shared goals, rather than individual advancement, are more successful than those where people work individually. If you can communicate your ideas clearly to others, as well as listen closely to their ideas, you will not only build up the skills of the people around you, but also learn more yourself.
  
• Coaching
  Successful engineers not only build themselves up but lift up those around them. Caching your peers through tough problems is a very powerful skill that ultimately will make you the go-to person on your team and will drive up your visibility outside of it.

• Inclusion
  We know that teams made of up of diverse members from different cultures, religions, backgrounds or races are more successful than less diverse teams. But this can still be a challenge to achieve, it’s the responsibility of every member of a team to understand your own unconscious bias and to make sure you are actively working to include everyone on your team, be that making sure everyone gets a voice in meetings or ensuring that you’re hiring processes are fair.

• Critical Thinking & Review
  You’ve probably been asked at some point to do code reviews or pull requests for changes other members are making to the code. This is an important step in maintaining high quality code, as it can catch issues early in the development process. It’s also a great opportunity for you to get exposure to the changes that are happening in other areas of the code, and to observe some of the different ways that your team think.  
  
  This isn’t the only opportunity you’ll have to review, though, you may find yourself reviewing API docs, technical specs or visual designs. If you can provide detailed reviews, and articulate clear constructive feedback, you’ll be able to make very real improvements to the product that will empower your whole team.

Conclusions

To misquote JFK, we choose to develop software, not because it is easy, but because it is hard.

Real bloody hard.

We choose to rise to the challenges to stretch ourselves, and to learn from them. The trick, though, is to find those challenges that speak to our personalities, speak to our motivations. When these are matched, we don’t mind rising to those challenges, and it can be incredibly rewarding to look back at what we achieved.

When they are not matched, though, it’s easy for us to feel burned out, or underutilised and it can make it tough to want rise to those challenges. In those moments, we can reflect on our motivations and ask, “is there a way to align the challenges I’m facing, with the ones I want to solve?”.

I believe that there are deep and complex challenges available at every level of software engineering – from purely technical, to understanding humans and their personalities. But not all of those excite every person, you are a unique individual and there’s no shame in liking different things to other people.

If you find your happy place is, you can unlock your engineering superpower, and be a more fulfilled engineer, this will in turn allow you to make better products and empower those around you to do so too. In short, everybody wins.

So where is your happy place?

Feedback

I hope this was useful to you. Let me know what you think in the comments or on Twitter.