How to supercharge your first 6 months as a software developer
Intro
The TLDR; after helping multiple graduates get up and running, I kept seeing the same patterns repeated. Gifted individuals being let down a bit by the onboarding process. With a bit of help, they could get the best out of themselves and contribute to the team far earlier. So, I went a wrote a book about just that. It’s on pre-order, with a 20% discount for Medium readers (using the link given above).
There’s also a free sample available where you can get 3 chapters and see the full table of contents.
The longer version goes a bit like this:
I saw the same bad patterns:
Over the last 18 months I have coached graduates at work in their first roles, getting them up to speed with Java development and some DevOps and engineering practices. All the people I helped were definitely capable, and and after my 4th ‘student’, some definite patterns started to present themselves. So I started thinking a bit deeper about it.
I kept seeing the same chaotic patterns of onboarding repeated. I got common questions from the graduates, the same themes based on a lack of prior experience. I went even further, looking back at when I first entered the industry. I could remember similar patterns. So not much had changed in all that time.
It’s hard to know how ask for help in an effective way.
Getting context on new projects is difficult without experience.
Imposter syndrome is a real problem.
Knowing how to best use your time for up-skilling is tough.
Knowing your build tools and the debugger is as important as the programming languages initially .
There are some overlooked aspects of software development that should really be explained.
Turning the problem on its head
I didn’t get frustrated at answering the same questions again and again, since they were coming from different people each time. It wasn't as if one individual person wasn’t learning. I could do something about this.
I’ve talked on my blog about mental models such as inversion — namely envisaging the opposite of the current situation. I went with it.
“I know what’s wrong, so is there a formula to succeed in my first job?”
I started to distill the essence of what was missing in the onboarding process. General points on hard skills, and tools etc. Hard-earned lessons on teamwork that could instead be explained. The obvious isn’t obvious before you learn about it.
A book of actionable steps
Since each company is different, any book can only offer guidance, however that’s not to say you can’t set someone up with transferable skills. Throughout the book, I have included actions and steps to go along with any observations. The reader will be able to see the essence of what they need, and then apply it to their workplace.
I cover the following in my book:
- 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.
Some sample lessons
The overall theme of the book is quite simple:
Success in your first software job starts with understanding how to ask questions, how to work on a team and investing your time wisely.
So, how to make that a bit more concrete? I’ve included some sample observations — and how to action those below.
Lesson 1: 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 they 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.
Lesson 2: 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 my first role, I was only thinking(and only really knew) 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.
Lesson 3: 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? Is this relevant?
And then once I get into something, I can virtually guarantee that I’ll get interrupted by a meeting and the like.
What I’d do differently
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.
All this and much more .. in the book!
The lessons above are just a sample of the pain points that can be fixed with a little thought. If you’d like to fix a few more problems, perhaps you or a new starter might be interested in a copy of my new e-book?
Finally please feel free to share this article with those you think it may help. Thanks!
