What developers take for granted : a reflection on what new starters need to know
Recently at work, a combination of project scheduling, experience and expertise meant I found myself leading a mini-project, rather than just being a team member. What started out as a spike needed to be made production ready.
We needed to write tools that could integrate a code scanning tool into our bamboo, Jenkins and Amazon CodeBuild pipelines. Our motley crew comprised the stereotypical 2 and a half men - myself, a recently appointed graduate and an analyst from the security team who was too overwhelmed with other work to commit to the project full time.
Whilst the young man in question was pretty able and very receptive to learning new concepts, it did get me thinking about what I would have liked to have known were I in his shoes.
Despite our jobs being technical in nature, I am of the opinion that if you’re capable enough to get through university (or indeed other training courses) you can, over time, pick up enough technical knowledge to get the job done well. But there are things you can do straight away to have an impact/improve your success rate.
CTOS are looking for soft skills more than technical
Far more senior people than myself believe this to be true as well. Pillar Leaders, who focus on soft skills for software developers, recently consulted with Australia Post. During a lunch break, I had a very interesting chat with Andrew Murphy, one of their lead trainers. It turns out he did some research with 37 CTOs in Melbourne, asking what they feel new hires are lacking in, and shared the results with me.
What would ‘younger me’ loved to have known?
TLDR;
- Communication, communication, communication!
- Learning how the business works and your customers will improve you overall
- Invest in yourself
- Self awareness is vital to both grow and progress yourself
More detailed look at our findings
Communication, communication, communication
From the above graphic:
Out of 37 CTOs, 34 of them rate communication as very important
Seems like that’s a pretty big deal then. But I’m not sure the communication this refers to can be taught that well at university. At uni, we have teamwork projects but we’re all the same level.
Maybe the problem the CTO refers is more around communicating with those who have more experience (senior devs) and also those in different disciplines. Project managers and business analysts may well have started in technical backgrounds, but they’ll still want info at a more summarised level.
If I had just started out, what would I like to have known?
In terms of teamwork, your senior devs need their focus and flow (just like you do), but it’s also their responsibility to help you grow. Working on this project, we established early on for both us that consciously separating Q & A and coding struck the sweet spot between mentoring and productivity.
Whether I’m communicating ‘up or down ’in terms of seniority, batching my questions would be the way I’d go. It would be showing that I’d (lightly) researched some options beforehand, It demonstrates both respect for others time and that you are capable of evaluating options.
I’ve yet to see a workplace where this isn’t preferred over random interruptions or wanting to be spoon-fed the answers. I’m pleased to say our graduate did both these things without prompting.
Likewise with your progress — senior devs like to know your progress (good or bad) ahead of time — if you’re struggling, flag it once you’ve done your best efforts, or maybe even halfway through. Likewise if you’re going to run out of work soon, let them plan something for you.
This is even more important for project managers and those less technical than you, people can grasp time remaining even if they aren’t exactly sure of the details of what you are doing — this can then lead to the discussion that asks the right questions.. Which brings me on to..
Learning how the business works will improve you overall
Lack of understanding of the business came in as the single biggest reason for failing an interview (27%)
From Andrews’ research, the above response got my attention:as it was the single biggest reason at 27%. Seems a bit harsh to be expected to know about the business before you start though…
So, whilst there is an obvious lesson here on interview homework, what if you actually land the job? What should you strive to do?
It did get me thinking about a lesson I was taught during an appraisal years ago when I naively said that because I wasn’t in the front line to the client, my work wasn’t customer facing.
In other words, I was just interested in coding. I was subtly prompted as to who I thought my customers were.. Perhaps I should consider the project manager as that customer?
Fast-forwarding to our own project we had an ‘aha!’ moment when we came to talking about a certain use-case. In its current state, the code wasn’t designed to work in the way that developers use bitbucket — we’d failed to consider how our customers and the business actually worked! Note that all of this was a technical consideration but the idea of thinking about your customers still holds true.
If I had just started out, what would I like to have known?
Spend some time learning about the business for sure. Your technical skills should mostly be bending around the business, not the other way around. Early on, of course, you won’t have full business knowledge, but at least ask yourself for the small component you’re working on ‘who will use this’ and ‘how will this be used?’
These questions can be applied in wider and wider scopes as your knowledge of the domain increases, not just other devs, but project managers and yes, the actual ‘end’ customer we traditionally think of.
Two questions I try for each use case are ‘what processes build the inputs to the system we’re developing?’ and ‘what happens with the output?’ — these are enough to start me thinking in terms of how the business will be operating.
As you gain experience, come to think of the business analyst (if your team has one) as a person to actively quiz, rather than spoon feed you the requirements. Start small, but leverage their knowledge and you can both deliver a far superior product.
Joey Mangaser, a business analyst working at Australia Post, agrees.
“The most effective teams I have worked on have come from when we have active discussions with developers. I don’t have all the technical knowledge, but I might have considered something they haven’t. Also, when developers ask me about why we want to do something we might find an easier way, or uncover hidden requirements there and then, rather than halfway through implementation. We don’t get that benefit when people just work in silos”
Invest in yourself
Andrews’ research shows 33 of the 37 CTOs gave self-improvement a ranking of ‘very important’
However I know from first-hand experience (especially at former workplaces that micro-manage) that unless you make the time, you won’t be allowed it necessarily. It’s a hard balance to strike, but if you’re not careful the day will just get away from you.
We experienced this exact problem during the project, our grad needed time to learn how to use the Visual Studio plugin for Python testing but it wasn’t working. There was no-one around to help investigate (we all used PyCharm and IntelliJ) so we had to keep running scripts to do the heavy lifting, which didn’t give the same ease of debugging.
If I had just started out, what would I like to have known?
Pay yourself first, i.e. at the start of a sprint or at the start of the day. Find the high impact, or return on investment to improve yourself and resist pressure to just get short term stuff done first. You can timebox that learning, but a little bit of investment every day beats hours and hours sporadically.
Make a list of skills you lack as you go through a sprint, but don’t dive into all of them. Dedicate some proper time to them later. Just like compound interest, you’ll reap the rewards.
As a trivial example, learning “vi” has greatly sped up my development time because I can build a docker image using IntelliJ, use the in-built terminal to spin up a container and quickly tweak config on a running instance. Once I’m happy I can save and paste back into source control within the IDE. Vi has assisted me doing all of that without leaving IntelliJ.
As a more substantial example, learning a productivity methodology like GTD (Getting Things Done) was a game-changer. Something that lets you offload things from your brain like this will be well, well worth the investment.
Self awareness is vital to both grow and progress
Pillar’s research shows that CTOs rate self-awareness extremely highly (31 out of 37) and yet feel it’s not supported by universities (19 think it’s done badly, 18 are neutral, no-one thinks it’s done well).
But how do you even ‘do’ self-awareness? The dictionary definition that comes up from a rudimentary search is “conscious knowledge of one’s own character and feelings”
I suppose carrying this over to the workplace, knowing what makes us tick (and importantly our triggers to bad performance) could be a pretty useful tool. Related to the recent project, I was pleased at how receptive to ideas our graduate was, and honest they were with what they didn’t know.
For my own part, I was able to detect/pre-empt when they were struggling with an explanation and could change to a different tactic to get a point across. But it did get me thinking about how I could have leveraged all of that as younger me…
If I had just started out, what would I like to have known?
It’s hard because you didn’t know what you don’t know. This is true of both the office environment and the technical expertise required. It’s further exacerbated by two forces that potentially conflict — your need to tread your own path and people trying to help you to get up to speed with work life.
Knowing your strengths and weaknesses
The ability to be completely honest with yourself about your strengths and shortcomings is something that’s talked about often. Usually though, that’s in the context of appraisal/personal development plans or even an interview — neither or which are the most organic of environments.
I realise now that you need to be reviewing strengths and weaknesses far more often than that. I’d love to have said that this was down to my own introspection and ambition, but quite the opposite. It was a very uncomfortable conversation with an aggressive employer who was extremely unhappy with my progress. Whilst the specific criticism levelled at me was unfair, the fact I’d allowed myself to get into the situation was not.
I turned this situation around in a number of ways, but I started out by mind-mapping all the areas of weakness, both perceived by others and myself. Things like security/networking knowledge, how I was perceived in meetings, what questions I wasn’t asking but should have been — all ended up in this mind-map.
Now a mind-map full of just weaknesses might seem de-motivating, or even contrived or cringeworthy, but it helped me to identify a plan of things and work out which things to attack and in which order.
From a ‘strength’ point of view, I found a few useful reads, one of which was a book called the ‘Mind Gym’ — which let me see how to get the most out of my (sometimes too) agreeable personality type.
Were I starting now of course, I’d probably spend the first few iterations doing a mindmap/list of concepts I didn’t understand, but review it every quarter. Many concepts you don’t understand will become clearer over time and it’s the ones that ‘survive’ that need help.
I’d also be seeking feedback (both technical and interpersonal) from my peers occasionally rather than waiting to be told. The mind-map would be my input and the feedback theirs, and I’d have to filter based on what I thought would be right for me.
Know you can’t do it all — you’re on a team for a reason
The biggest temptation is to try and learn every technical concept in the job, or fix every weakness. It should be obvious but it wasn’t to me at the time — it has diminishing returns. You’re on a team for a reason, and you should be able to leverage each other’s skills if you’re a healthy team. Early on in my career I either fixed problems that had mostly been fixed by other teams at work, or spent too long on something without asking for help out of pride.
Were I starting now, I’d timebox my work before asking for help, e.g if I can’t make progress in an hour, ask a more senior dev. It’s a hack to get around the fact my pride will kick in and stop me asking if I don’t give myself a boundary, which of course comes back to knowing yourself.
Likewise, when given work, I’d be asking questions around which team this work has originated from, or if any other teams had solved problems for the originating team and specific domain experts I can ask for help from if I get stuck. I’d shelve the fear of being ‘slowed down’ and ‘not starting’ just in case a collaboration bought about a win-win. It doesn’t take long to have the discussion, yet we often feel impatient to start and not ‘over-plan’.
Perhaps you can think of some hacks to work around your shortcomings — until you fix them of course?
Conclusion
This is a far longer article than I originally intended to write. And there are far more points than just these on Andrew’s research that CTOs have picked up on. I tried to pick the biggest ‘bang for buck’ points and offer some insight where I could. To summarise as best I can.
- Communication is key for senior devs to help you and you to help yourself
- Learning how the business works will reduce your re-work, and improve your value to the business
- Invest in your own development, do a little every day, and ‘pay yourself first’
- Learn your shortcomings and ‘hack around them’, introspect to understand your strengths and don’t be shy to ask for peer feedback.
