Some on three years of professional software engineering.

Advice I’ve been given that's worth repeating

Focus on the fundamentals. Software is layers of abstractions. I don’t think you need to start with bits and bytes, but you do need to choose a layer and dive deep into the foundational elements. Yeah, you can google stuff or ask an AI chat bot, but all the great software engineers I’ve seen have a level of automaticity that comes from repetition and deep and understanding. The layer I chose was web development — via https://launchschool.com/. When I eventually started my professional career I came into the job knowing that I needed to learn an incredible amount, but filled with confidence that I had the foundation to do that. I’ve seen juniors arrive without the fundamentals and perpetually struggle.
Focus on problem solving, with other people. It's a magical feeling when you first learn to code, being able to get the computer to work in harmony with your thoughts. It is one of the privileges of this job that the feedback loop is tight which gives addicting direction and motivation. After a while, you should realise that the code is nearly always the easy bit. The main challenges in the job are understanding and breaking apart problems, thinking through technical and business trade-offs, and how you collaborate with other people on the journey of solving [business] problems with software.
Your first job matters. If you can, find a job at a software-engineering company, not a company that has software engineers. The distinction is going to make all the difference in terms of how you will learn, how you will be treated and what problems you get to work on.

Advice and reassurances I’ve given that I hope are useful.

Its going to take a while to be the worst. It takes decades of consistency to catch up and be great.

Roughly 9 months into working at Ferocia I remember talking in my 1:1 with my manager about the project that I was working on — a moderately sized refactor some of the login, signup and account recovery processes. I remember feeling great because I’d largely been able to work entirely autonomously for most of that week. Nine months in and I’d gotten up to speed on our tech stack and codebase. I’d wrapped my head around some parts of the domain. I’d been able to deliver on some smaller projects without any hand holding. I no-longer felt like or was treated like a junior. I felt like I was now officially the worst engineer in the company.

I’ve given some version of that story to multiple juniors who started with us since then. Mostly as a way to re-assure them that it is a long journey and their progress is good, but also to try emphasis that becoming great at anything takes years or decades of deliberate effort.

I think you can be a solid developer with a good career without additional ongoing study, side projects or contributing to open source. The percentage of engineers who continue to do those things once they’ve got a job is teeny tiny. However, if you’ve left it late and want to be great… you kinda do have to go above and beyond. Somebody who did a CS degree right out of high school might have had a decade of professional experience before I even started writing puts hello world in ruby. You can’t catch up to the skill level of people with a decade of experience if you don’t go above and beyond what they are doing.

Imposter syndrome in this industry is so common thats it feels like a trope. In addition to the type of people who are attracted to software engineering, it is probably so rampant because our technical workflows are so geared towards review and feedback that our inadequacies are often on display. That doubt can be a barrier to your success. I think its a pre-condition to catching up in your career that you actually have the ambition and belief that you can be amazing if you have a long term dedication to your craft. Not just the belief that you can be good, but you can be one of the best (however you define it) engineers in your country or the world. Maintaining the belief, ambition and motivation is hard, but they are all pre-conditions for success.

At some point you need to pause and think of new goals

One thing that helps with motivation is clear, ambitions goals. This is a very rough sketch of my goals as I embarked on this software engineering journey.

Before getting job.

Finish all the launch school curriculum and be the first Australian in their capstone program.
Get a job at one of Australia’s best software engineering companies that could kick start my career.

After getting job → 9 months into the job

Try get up to speed as quickly as possible.
Not get caught out as a fraud.

9 months into the job → ~18 months in the job

Keep gaining more technical skills in new areas.
Gain more project responsibilities and eventually lead larger projects by myself.

~18 months - Now

Who bloody knows???

Today, I’m a competent member of a great a team. I have a lot of domain knowledge, some of which I think is unique across all of the engineering team. I’ve delivered a lot of important projects. I still feel so far behind the technical competency of so many engineers we have at the company. I don’t feel I’ve stagnated, but there is a lot of work that comes my way that I can deliver the technical component without much thought. Yet, for a long time my motivation to seek out challenges, get out of my comfort zone, or be extraordinary outside of work was low. I would get bursts of motivation to study or work on side projects, but nothing sustainable Now there are are extenuating circumstances, like living in the most locked-down city in the world and having a toddler to interrupt your sleep every day, but I think thats only an excuse that covers up the real issue.

It is only recently that I realised it is because after after getting the “great job” and having the initial goal of not getting caught out I never re-calibrated my goals. I never formulated a longer term, ambitious plan for what I wanted my career to look like. My managers would even ask me and I remember thinking the goal would just appear fully formed, one day as I became more interested in a particular aspect of being a software engineer. It never did. I never took the time to do the work and think about it myself. Here is a larger post from Oz Nova which helped me refocus on the need not just for good habits, but new motivations.

Think about what else you bring, but be careful about flexing it.

The fasted way not to get stuck as a software engineer is to waste hours or days on the same thing before. You gain wisdom from the exposure to lots and lots of problems that come from building software that used by real people. However, businesses, even the software-engineering part of the business, is not just about technical problems. You’ve got work design, prioritisation, organisation structures, people management, politicking, resource allocation and all the other stuff that is a by-product of enough people working together. As somebody changing careers you are going to have lots of valuable experience for somebody with your technical ability. That experience will make you a better employee and a better engineer, but if you aren’t careful it might get in the way of you getting improving your technical competencies.

I work for a bank, Up, that sits entirely within a much bigger bank, Bendigo Adelaide Bank. We dependent on the larger bank for lots of technical infrastructure — especially core banking APIs. About 15 months after I started the team that looked after our APIs was being disbanded as part of an organisational restructure. I was seconded into that team as an insurance policy so that we had some knowledge of how those APIs were developed and deployed if the re-structure left important resources without an immediate home. My role was to try get some small wins shipped and to document as much as possible about how things currently worked.

Why me? I was still very junior in my technical ability so it wasn’t because of my ability to deliver new API functionality. Primarily it was because of my previous experience as a consultant — the ability to build relationships and understand the workings of a large organisation.

Was it valuable for the company? Yeah, I think so. We pulled back the curtain on how the larger organisation worked more than we had ever before. Some of that work is still paying small dividends many months later.

Was it good for me? Maybe, probably not for how long I had to do it for. Organisational constraints meant that I wasn’t able to deliver, or even work on, API features we needed. As a team we felt committed to the journey and I’d committed to trying to make it work. The weeks turned to months I felt myself doing more and more business analyst, project management, stakeholder relationship — the type of work I had a decade of experience in (and left for a reason). It will always be a delicate balance between what is good for your career, your personal technical development and the company’s goals. Early on in your career, eager to please, you might find it difficult, but if you are presented a new opportunity you should always consider it through multiple lenses of how it’ll help you grow towards your own goals.

End

Was this helpful? Let me know. It was enjoyable to think about and write.