How to succeed in your first software development job

TLDR; tips below on some of the unexpected parts of software development, and I have a book out. Free sample of that here.

As I have improved in my career, I’ve been trying to think more critically about ways to improve. Over the last 18 months I have coached graduates at our work in their first roles, and after my 4th ‘student’, I did start thinking a bit longer about it. “Is there a formula to succeed in my first job?”

With the graduates, I saw the same chaotic patterns of onboarding repeated. Not only that, I also felt that many of these issues were still happening when I first entered the industry. So not much has changed in all that time.

What’s needed for success?

I’ve talked before about mental models such as inversion – and I went with it. Given all these problems I reflected on, what would it take to succeed? I got started on some common problems a newbie would face and how I’d tackle them with the benefit of hindsight.

TLDR; Success in your first software job starts with understanding how to ask questions, how to work on a team and investing your time wisely.

I wouldn’t worry about my ‘hard skills’

I realise that sounds a bit crazy – why wouldn’t I worry about my development skills when my job is .. ‘software development’? What I mean by this is that these will progress naturally anyhow. As long as I’m not complacent, and invest in my learning, these will take care of themselves.

When I started

I was really focussed on getting good at Java, failing to understand I was working within the constraints of a large bureaucratic insurance company. This wasn’t a Silicon Valley tech giant. Honing my OO skills was definitely important, don’t get me wrong. But that would only get me so far when I couldn’t translate what I was doing to our project manager, or estimate how long something would take.

What I’d do differently

I would try and understand a little more about the roles and perspectives of of others on my team. My project manager might have come from a development point of view, or they might not. But in their current role, they’re more interested in the business value of what I’m doing right now, and how soon they can get a good (not rushed) product. The business analyst is someone that I can put questions to, not expect to spoon feed me a specification. The testers might know more about architecture than I think.

I’d learn ‘how’ to ask questions

You would be surprised at how many things you can catch early by asking the right questions. You would be further surprised by how much more you can get by asking those questions in a group forum. Bouncing ideas off each other, getting the business and developers taking together – it really is a case of the “whole being greater than the sum of its parts”.

When I started

In the first instance which of questions to ask, I was only thinking about my technical sphere. Let’s say the business analyst gives me a spec, I’m reading it and thinking of exceptional cases e.g. “what happens when the a field is 75 characters and the data passed in 50 characters?”, what happens if I get a negative number for something?” and so so on. Whilst these are important, they are low-level implementation details. A far more important question would have been along the lines of ‘how does our systems get its data, what does that source system look like? Can it even get into that state?

What I’d do differently

I’d leverage the expertise of other team members, and look at the ‘question behind the question’. I couldn’t gain their experience overnight of course, but I could see why their questions differed from mine, and if there was something I could learn in future.

As an example, at one company I worked at, we worked in the micro-service responsible for presenting and serving invoices. However, no-one on my team knew (or wanted to know) how to use some archaic UI to create invoices. We just got invoice data from another team and tested with that.

When I got a tester to help me to learn this quirky UI, I could create my own invoices with various permutations of data. I suddenly had a much greater understanding of what could happen to the data before it got to us. The reason why the tester was asking different questions to the rest of us became apparent – they had used the system in a ‘real-world’ environment.

I’d learn ‘when’ to ask questions

When I first started, I was super keen to learn ‘real’ Enterprise Java, rather than just university project stuff. Then I realised I needed to learn about architecture too. And of course the life cycles of software development at my company. And then there was the business itself. Soon I had a whole heap of questions, a brain up of loosely related areas that confused the hell out of me.

When I started

In my first job, I had a bad time of it because my tech lead/mentor was highly volatile and unapproachable. However in fairness, I had failed to understand that she was being pulled in all directions by the business. In hindsight it was obvious that she felt threatened by not having the answers, but I also could have chosen my moments better and also not bombarded her with questions.

What I’d do differently

As it happens, a colleague at that job gave me a tip that has been useful over my entire career:

If you’ve got heaps of queries, maybe don’t ask the same person everything. Spread the questions around the team members where you can.

This worked really well for me in that job. Whilst the tech lead had a lot of the project knowledge, most of my questions were better directed at other developers and the business analysts in any case. I was able to get the help I needed without being too onerous on any one person. 

I’d take advantage of on-boarding ‘downtime’

The larger the company the more acute I’ve seen this to be. You’re waiting around for credentials. Your tech lead had the answer to stuff, but they’re in yet another meeting. You know you should learn some new skill, but there’s some mandatory training course on Health and Safety, or Money Laundering, or Acceptable Email Usage policy.

When I started

I’d have made some best effort to learn like anyone would, but would have felt a bit helpless waiting around. After all, I have so little context on anything that I could do a few tutorials at best. How should I actually spend my time? And then once I get into something, you can virtually guarantee that I’ll get interrupted by a meeting and the like.

What I’d do differently

I’d ‘seperate the what from the when’. In other words, I’d break everything I had into blocks and categories. Then I’d timebox it. Rather than get frustrated by the stop-start nature of onboarding and meetings, I’d go with it.

I’d start by spending a bit of time aggregating or gathering all the questions I had into actionable steps. But I wouldn’t dive in and do them until I had a solid list of say 20 items.

The table below is a snippet of something I could have used in the beginning of my career. As an aside, in my latter years in development, I have fully embraced a productivity system like GTD.

I’d actually go a step further and break the tasks down into 30-mins blocks these days. This is to take advantage of smaller pockets of spare time (the perils of being senior!). I also record the actual vs estimated time to give me a warning on being overly optimistic in future.

The key thing is that, as soon as the day presents me with some spare time, I’ve got a list that’s ready to go. And if for whatever reason it’s appropriate for me to focus on the business over development today, then I just pick tasks from the appropriate category – it’s already organised for me.

I’d be proactive with my learning time

When you’re confronted with the sheer amount of work you have to do, it’s not surprising you might get overwhelmed. And you will certainly not have problems filling the days with work. The problem is the whole ‘sharpening the saw’ problem.

Put simply: developers need to keep their core skills current for career self-preservation. The business want their stuff now, and in fairness they have their own priorities. Net result – we have to look after ourselves because no-one else will.

I don’t mean that to sound negative, you may well have a great employer. But the sad reality of the IT world is many employers want everything now. If you ask for self-improvement time, you may not get it, despite that being best for everyone in the long run.

When I started

I’d have asked for self-improvement time, often been promised it, then not got it once the deadline pressure is on. Despite that being best for everyone in the long run, it’s a case of “we’ll catch up later”.

What I’d do differently

I’d tread carefully initially because early on changes are my peers know what’s best with my self-development. After a couple of months of learning the ropes though, I’d be wanting to carve out my own improvement time. Something not directly project related, but still of value to me and employers alike. If I get better at bash for example, I speed up, which benefits both of us.

I take a 45 minute bock each day to improve some core skill or do some reading outside if the project I’m on. 45 mins is enough time to get into something useful, but not long enough to be of detriment to your project. BTW if you think 45 mins is too much to spare, an article from Evernote suggests we waste 2 hours a day just looking for information. You can spare 45 mins with a little optimisation of your processes.

All this and more .. in my new book!

If the points in article have been of interest to you, you might be interested in a copy of my new e-book. Alternatively, maybe you know a new starter that you know that would like a copy?

“How to Supercharge Your First 6 Months as a Software Developer” contains pointers on subjects that don’t seem to get taught in the workplace, yet commonly occur. These include:

• Being able ask for help effectively.
• Learn how to help yourself and your tech leads.
• Get to make yourself more valuable as a team member.
• Learn how to get context on new projects.
• Understand the basics of testing automation, estimating and deployments.
• Understand the role of your build tools and the debugger.
• Understand some of the overlooked aspects of software development.
• Avoid some of the pitfalls that inexperience can bring.
• Save time up-skilling by having a curated starting point.

I’m hoping you will find it valuable and can help spread the word. Thanks for reading. You can get a free copy of my sample chapters should you wish. Thanks!