Careers

A career plan: we should all have one, right? But it can be hard to know where to start, or what you should do with it once you’ve made it. This can be especially challenging when you’re just starting off in your career – you manager asks what you want from your job, and don’t really know what you want beyond ‘just progression’.

A child stand in the countryside, holding up a map. — Photo By Annie Spratt

Today, I want to tell you a little about how I manage long term career planning for myself, and how I use that to make regular evaluations of those plans and my progress towards them.

A Plan Is a Guide to The Next Step, Not a Rigid Set of Rules

It’s easy to think of a career plan as something rigid and unchanging; a plan that you must stew over and perfect every detail, and then stick to forever. This can make a career plan a very intimidating document. How do you think it all through? How do you know if you’re on track or not? What if you’ve made the wrong plan and won’t be happy!?

Instead, think of a career plan as a framework to help you process your feelings and observations in order to plan out next steps. You can then regularly use this framework to evaluate your current path and chosen destination.

Imagine, you’ve been dropped in the wilderness without knowing where you are or how to get back. Perhaps you climb to the top of a large tree nearby and look out around you. As you look to the north, you can see smoke rising in the distance, maybe it’s a camp? You decide to head towards it and find out.

A person standing in the clearing of a forrest. — Photo by Robert Bye

After walking for a couple of hours, your progress is halted by a wide, rushing river, and there’s no way you can cross it. There’s no way to continue to the north now. It’s time to revaluate your plan, heading north was a great idea in absence of more information, but now you know about the river, is heading that way, still the best path? Perhaps you can see something else from here? Perhaps north is still the best direction, but you need head a different way for a little to find a place to safely cross and head back.

That’s the thing with plans: You need them, they give you direction of purpose, but the most successful people are always considering their plans – changing and tweaking them to ensure they’re making the best choices for the current data they have. Changing a plan is not a failure, it doesn’t mean your plan wasn’t good enough. Changing plan means you are in control and evaluating input data.

Where Do You Start?

Just like with the above example, you start not with the next step right in front of you, but with the destination, and figure out next steps from there.

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.

A picture of a woman working writing code.

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…

A post-it note reading "Design spec = Use C# to build epic s**t (secure, scalable, blah, blah...profit!)"

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”.

A image of a man and a woman working together on a computer

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.

Andy Bradford

How To Make a Long Term Career Plan That Actually Helps