I received a question on LinkedIn recently that has caused some reflection for me. The question (paraphrased below) was:

I aspire to be a software engineer and I was wondering if you could help/advise me on some courses/resources/work experience ideas/etc.

It was a great question, and started a period of reflection for me - not only directly on the question, but in my own career. What had I learned in the past 25+ years of my career that I didn't know back when I started that may have been useful to know? I thought I'd distil some of my thoughts into a blog post to try to generate discussion to contribute to the original question.

The below thoughts are not all 'day 1' - they would be overwhelming, but in thinking about your own growth, these are the areas you should be considering.

Formal vs. Informal Education

I thought it worth starting with this given the nature of the question and the question about courses/resources. A formal education (in the UK that is A-levels/college -> University) can help, and I don't dismiss it, but one of the things I've learned over my career is some of the most amazing engineers I've worked with did not go down this pathway, and have instead 'learned on the job'. I took the formal pathway, but if you aren't able to progress in academia for any reason, do not let that rule out having an effective career in software engineering.

I've recommended in the past harvard's CS50 Introduction to Computer Science course. It's a free 12 week course with between 6 and 18 hours of work each week, and I've helped a few people through it in the past successfully. It's a great foundation and can help if you're looking at early opportunities in apprenticeships etc. and do not have a formal academic background.

Focus on the tech, obviously

It seems self-evident to say it, but I thought I'd prefix the rest of this post with it. I assume that anyone reading this post is already doing clear and focussing their technical growth. I don't necessarily think it's the most important aspect to your growth, but it's foundational to a career in software engineering so thought it worth getting it out of the way.

Effective delivery of software solutions is why you exist in a role, so this is your '101'. I'd urge you not to just focus on a single area though. The software engineering career landscape is vast - platform, software, front end, back end, full stack - the terms go on and on. Do not stay still during your career - you should always look at 'the next thing'. Polyglot programmers have broader toolbelts to solve problems and are, over the long term, more effective problem solvers. This is not to say that you should not go 'deep' on a particular language/tech stack etc. but ensure that your skill set is broad around technical delivery.

Ensure you understand cloud too - be that GCP, AWS, or Azure - they are somewhat ubiquitous now, and on-premise work is becoming less prevalent. Understanding the paradigms of the cloud will massively help with your software architecture - again, just having more solutions to any particular problem. Also spend some time in your career (further in) in understanding cloud automation - creating repeatable infrastructure is hugely powerful. There are many tools out there to do this, some of the most popular are listed on the Cloud Native Computing Foundation (CNCF) interactive landscape

The 'Human Skills' - turning the good into great

This is the advice I wish I had gotten most in my early career. We readily solve for the technical problems, but 25+ years into my career, this is one of those I wish I'd focussed on sooner. Software engineering in all its forms is a 'team sport'. Rarely are we just working alone - we have users/customers, we have team mates, we have dependent teams. Effective software delivery is a human process as much as it is a technical one (perhaps more so!).

There are some key skills that I have really will make a huge difference to your career:

  • Empathy and Compassion - you have a different perspective to me, you have different experiences, and you have an different way of handling things. The key in empathy and compassion is me coming into your space and trying to understand and feel what you are feeling. Brené Brown has a great talk on this which has been replayed in an animation to great effect. Empathy is not sympathy, and is key in our careers to getting beyond 'why did that team take so long to do X' or 'why does team Y's work always have errors in it?' into a deeper understanding and connection.
  • Emotional Intelligence - have you ever been in a situation where someone has said or done something and your immediate reaction is to flip out and respond angrily? Welcome to an amygdala hijack. My early career certainly saw more of these than I would have liked. Emotional intelligence is the key to unlocking your own awareness of yourself so that you can take a conscious choice about how you react to situations. You could do a lot worse than starting with Daniel Goleman's book on the subject.
  • Communication and Feedback - a significant danger in our careers are the things left unsaid. Communication is hard! Giving feedback is hard! There isn't anyone who doesn't wish they weren't better at communication though, nor better at giving feedback. There are some great books on the subject, and along with the topics above really do make a huge difference when we communicate. Kim Scott's book in particular showed me that I had spent the early parts of my leadership career being 'ruinously empathetic' - trying to be nice, be liked, but not challenging teams. This never gets the best outcomes!

All of these areas are really hard to put into practice. Unlike writing lines of code, these involve humans, and being human is complex at the best of times. Mastering the above over your career will (and this is just an opinion after living this career choice for many years) make a huge difference to your own enjoyment of your career, and your earning potential.

Ask the question, raise the concern, bring the idea

Following on from some of those key human skills, it would be remiss of me not to bring out the important call - you have to DO something with them as you practice and grow them. Psychological safety has become a huge topic in the past 5-7 years, and an environment that is safe is crucial to high performance.

For you, this means bringing your whole self to work and the problem at hand. Do you have a (stupid) question? Do you have a concern? Do you have an idea, even though it may not be a great one? RAISE IT!

Your voice matters. Naturally, doing so with those human skills listed above, but bringing your voice to the workplace is paramount! There isn't a good workplace anywhere that will not want to hear it. If they don't want to hear it, it may be that they're not as good a workplace as they perhaps aspire to be.

Having a product/customer mindset builds better solutions

In my early career, I cared massively more about the lines of code than the users who would eventually have to suffer the solution I'd written for them. Being close to the customer is still a significant competitive advantage for anyone in the engineering space, and the people I've seen being most successful over the past 5 or so years have been customer-centric rather than solution-centric. Solving customer problems, avoiding over-architecting, keeping things simple, and focussing on the opportunities and needs of the customer. There's a great article by Gergely Orosz on product minded software engineering that I'd recommend a read.

Be 'Gap shaped'

In engineering, we talk about 'T shaped people'. The best engineers I've worked with take this a little further and alter their vertical on the 'T' based upon existing problems. Do we have an infrastructure challenge and need to focus in on that? Not your skillset? Jump in and learn and contribute. Do we have a problem with customer interviews and understanding the problems in the product? Jump in. Finding the gaps and filling those gaps is a great way of maximising your learning, experience and value.

The vertical' in the T jumps around in these people, and they quickly become strong in 'many' rather than just a single area, and it's incredibly powerful in an overall package.

Love what you do, change it if you don't

Software engineering is a buyers market - there are many roles out there, and generally speaking employers need you more than you need an employer. If you find you have a bad boss that isn't responding to feedback, or you are being stretched to burnout regularly by an employer, another employer will be only too happy to provide a better experience. Do not suffer a bad employer, and do not fear leaving quickly when the situation isn't conducive.

This is incredibly true if an employer is not willing to invest in you. That famous phrase/quote (may well be apocyrphal):

What If We Train Them & They Leave? What If We Don't & They Stay?

This is fundamentally true in any modern employer. Do not put up with an employer that is not prepared to invest in your growth, be that time, coaching/mentoring, all the way through to formalised budget/tooling for learning.

Invest in you - the 37.5hrs week

This one is likely to be controversial. In my early career I used to spend a LOT of time outside of work trying to become better. It is something I have continued to this day. I made the mistake of 'doing more work' early in my career rather than focussing on growth, and I do not advocate for that. That said, the best engineers I see in their careers today devote some time outside of their weekly contracted hours to personal growth. This isn't a slight on those who can't (people with families, or with other challenges outside of work) - it's worth stating that if your employer works you so hard that you HAVE to take growth time outside of hours, it is perhaps worth considering a new employer. A good employer will strive to ensure that you are at no higher than 80% allocation and you have some space to think, reflect, and learn during your working week.

For me, this has covered a number of guises, and can take as little as 2-3 hours some weeks:

  • Listening to a management/code podcast on the commute to work - rather than listening to music or playing a game of some type on my commute, I would take that downtime to focus in on growth and learning.
  • Book Reading/Audiobooks - a lot of the topics above have books linked directly. I love reading, so it works really well for me, and although I don't always get a lot of books read per year, it's a great source of learning.
  • Side projects - this blog, building websites for friends, playing with new technologies, creating code for business ideas etc. whatever guise it takes, this can be a great way to play freely with new tech.

I achieve the time for this by minimising or avoiding time wasting activities - netflix, social media browsing, etc.

So, to be clear:

  • I am NOT advocating for 'doing more work in more hours' for your employer
  • I am NOT advocating to work for an employer where learning out of hours is actually required because they work you so hard

But:

  • I AM advocating for spending some time outside of your working hours focussed on what growth looks like for you.
  • I AM advocating for understanding what burnout looks like in you, and taking breaks when you need it

Big problems are just a lot of little problems put together

It can seem overwhelming when you are early in your career in software engineering - how do you solve those 'big problems'? How do you build that huge feature, or that new service? They key in any problem in life, and in software engineering, is if it feels huge, break it down. What are the component parts? What do you have to do first? Is there anything foundational that needs to be done? Ask someone more experienced to show you how they'd break problems down. Work away from the main solution in a 'sandbox', and just play with it - but bitesized chunks are so much easier to work with than epic deliveries.

Continue learning from others

It feels prudent to close out by saying that our field is vast. Follow technical people you aspire to mirror on twitter, linkedin, etc. - read their blogs, listen to their conference talks. Also, reach out to them for a chat! Most engineers further into their career are only too happy to talk.

Just make a start, it doesn't cost anything

A great piece of advice from an old team mate that I thought worth including - 'just have a go!'. You can get free development tools now, github accounts are free for source control, and all the cloud providers provide free tiers and you can play safely. You are essentially in a fully free environment that is likely to mirror a lot of what an employer would have in place to deliver commercial products. Having a presence of trying things is also a great indicator to future employers. Just make a start!

What advice would you give your younger self?

I'd love to see what advice outside of the above you'd give to your younger self - perhaps take this post and share it with some of your own thoughts added?