I do rather like to write. Before I was a developer, I was a teacher. An English teacher to be precise. I spent 6 years of my twenties teaching or attempting to teach, young adults to write a decent essay about Dickens, or a speech about Shakespeare, or a persuasive piece on the merits of scrapping school uniform. I think what I’m trying to tell you is that I should really write more. It’s something I know how to do. I know I have a blog inside me waiting to get out but what stops me is the worry that I’ll say something badly, or inaccurate, or just plain daft.

It’s this very concern that helped me to choose a subject for this piece. They say that good writers write what they know and what I do know is this: I have made some mistakes in my first couple of years as a developer. I will probably make them again too. That said, I am going to tell you a few of them and, who knows, maybe you can learn from them too. At worst, you should be able to have a giggle at my expense. Merry Christmas, you’re welcome.

Mistake #1 - Multi-tasking

As a parent, I do a lot of multi-tasking. I have mastered the art of ‘listening’ to one of them do their reading, whilst cooking dinner and reading out spellings to the other. I’ve the burn scars to prove it. As proud as I am of this achievement, as a developer, I have had to un-learn this skill. Why?

Deep work is a state that is very necessary to achieve anything remotely cognitive. You know what? Even the easy stuff deserves your full attention. I am someone who harbours a morbid fear of forgetting to return a slack message so am known to flick back and forth as soon as the little notification pops up. This makes me, and I promise you it’s not just me, prone to making silly mistakes.

This time last year I spent an hour trying to work out my controller wasn’t getting hit. I had a range of ideas as to why this might be - had I creating some custom routing that wasn’t firing? I wouldn’t have known where to begin with that. Was Visual Studio broken? Yes, that. Debug was being weird? Of course! I think we all know how this ends. While I was doing the ‘easy’ part I was also half watching a Pluralsight video. Just finishing off the last 5 minutes.

I named the controller SomethingSomethingContorller.

Nowadays, I’m not nearly as ambitious in my multi-tasking but from time to time I’ll see a task pop up and think, “Oh this little thing? This will only take me 5 minutes. I might as well just knock that out now.” It’s rarely worth the risk. The time it takes to get back into the original task and the little errors I’ll make along the way means that 5 minutes is usually more like 20. And in some cases, much, much more.

My ‘contorller’ error still makes me cringe. This was one issue I didn’t even solve myself. I asked another developer for help and he spotted it, raised an eyebrow and told me firmly always to check that the controller is named correctly. I nodded, suitably chastised, which segways nicely into Mistake #2.

 

Mistake #2 - Asking for help too soon

How do you know when you’re asking for help too soon? When you get the help you also get that crushing feeling that you could have solved it yourself. I’ve even done that thing where someone starts telling me and I start shouting “No no no! Stop! Don’t tell me any more!”

This one can be incredibly difficult to guage but in the last couple of months something interesting happened to me. My lead developer went on holiday. Our unspoken arrangement is thus: I limit how often I ask him for help and he helps me whenever I ask. I do this partly to make sure I am thinking for myself, partly to allow him to think for himself too. Upon learning I would be alone for a fortnight I was a bit shaken. I have other people I can turn to but he knows exactly what I’m doing, exactly where I’m at and, well, it’s his job to help me. Anyways, he left, and I was alarmed to discover that I survived. I did the fortnight without that help. I probably wasn’t as fast as I could have been but I didn’t need to call in the big guns.

I didn’t boss everything either. I put together a list of ‘could waits’ and we talked about those things when he returned but the satisfaction of getting through that couple of weeks was immeasurable. It made me question how often I needed the help I asked for. When I realised I was hitting my head against the same brick wall of a problem, I stopped, I took a break or I moved on to a different problem. Sometimes, I wrote the problem down, ready to ask him what to do upon his return. Other times, I went and made a cup of tea and returned to find I’d come up with a different angle and sit down and solve it there and then. Having the help effectively removed caused me to be more creative.

My son was struggling with some homework on the Romans last week and, being such a good parent, I asked if he wanted some help. He said that he couldn’t accept it because first he has to try the ‘3 before me’ rule. Intrigued, I asked him to explain it to me. It goes as follows: Before you ask an adult for help you should try these three things - 1. Try re-reading the question. 2. Try looking around the room at a poster 3. Speak to your classmates. We don’t generally have posters on the Romans around our web agencies but I am an advocate of making my notes a first port of call and graduating on to Google as the next resource.

Not all of us have that luxury, of course. Overbearing clients, tight deadlines, the usual things, but I am fortunate enough, as a junior, to usually be allowed the time to ‘get there’ on my own. If you can too I urge you to try it. Unless, of course, you can’t, which leads me to…

 

Mistake #3 - Not asking for help soon enough

Sometimes, it’s really good to admit that you’re flogging a dead horse. Sorry, I realise that the last few hundred words might suggest it’s always better to battle it out alone but, guys, we still have to deliver. There’s a lot you can learn from your team, peers or people from the internet. Don’t be stubborn - if it’s going nowhere, you just gotta.

 

Mistake #4 - Trying to tackle all the things at once

On one of those occasions I have asked for help, in response, I’m often offered a bit of a guidance and set back onto the task. Sometimes (usually!) the guidance will be brief but enough to get me started. Sometimes (usually!) I hear what is said and swiftly break into panic mode. And sometimes (usually!) I start beating myself up about how little I know.

That’s when my sensible side kicks in. It generally encourages me to do three things. Pick up a pen, one of those things from the olden days. Grab a notepad, yep, a paper one, also from the olden days. Write down what I’ve just been told. From there, I start breaking it down into a list of tasks and more often than not, task 1 will be something I do know how to do. If I don’t know how to do it, I’ll generally know how to begin it. At this point I’ll make myself a promise. If I can’t get to the end of task 2, I need more help. Just a little more clarification. I have never not made it to the end of task 2.

The way it goes is that along the way, somewhere between task 1 and 3, you start learning new things and drawing on things you knew and some you’d forgotten you knew. By the time you’re in the last half of that list, wherever that may be, you’ve probably already surprised yourself and that in itself will help you solve bigger problems in the future.

The biggest mistake you can make is taking a task at face value and failing to break it down into its constituent parts. If you’ll forgive a clumsy metaphor, imagine each problem as a brick wall that needs relocating, you need to approach it the way any sensible bricklayer would, brick by brick.

 

 

Mistake # 5 - Assuming that I can’t solve something

Another thing that causes the veil of panic to descend for me is being asked to do something I have never heard of. As a junior this happens pretty often so I thought I should probably make this my final section.

How siloed is your workplace? I’ve worked in teams where a problem arrives on my desk and as I get to part where I get to diagnose what’s causing it, I realise that in fact, it’s a front end issue and that means it’s not mine to solve. And anyways, I couldn’t solve it even if I wanted to! I’m a back end developer! This reminds me of a highly underrated joke I heard as a kid. It goes like this:

“How many software engineers does it take to change a lightbulb?

 

None! It’s a hardware problem.”

 

The joke is funny - it is, right? - largely due to the absurdity of people who are apparently smart enough to write a few lines of code but refusing to carry out a task as simple as changing a lightbulb because, well, it isn’t their area of expertise. And this is the danger of siloed thinking.

I like to see my job as a solver of problems, large and small. A few weeks back when I was asked to investigate performance problems in a site I thought to myself, ‘This is not my area at all. I know who should be doing this and I don’t know why they’ve asked me.’ I tried to give the task back saying I didn’t know how to begin and, baffled at the suggestion I should look into it at all, began to realise I didn’t know where to even begin. It didn’t take me long to realise that of course it is my job and even if I didn’t know where to start I should find out.

And so I did! And I didn’t succeed right away. My investigations into the source of the problem all proved fruitless for the first couple hours. I realised I needed some help and asked (see Mistake #3) and was pointed in the direction of donut caching. I spent that afternoon learning how to implement donut caching. Again, I didn’t get it right first time and when it transpired that none of the forms were submitting, I realised why the name donut had been chosen (the holes, duh!), rolled up my sleeves and went about creating caching profiles with different durations and decorating my controllers with them.

Had my colleagues taken that job back as requested, I wouldn’t have learned how to implement this myself. Had they not had the patience for me to get it wrong a couple of times, I still would have that mistake to make in my future.

I can’t say I don’t still freak out and wonder if a job can be passed on to someone, anyone, who knows better. I do do that. But at the same time, I’ve become a little more curious about each task I’m assigned and a little more excited about something that’s categorically ‘not my thing’ becoming ‘my thing.’

 

Just the five

I could go on.

When I started writing this article it was called ‘10 mistakes I have made while learning to be a developer’. After I spent a thousand words on the first 3 mistakes, I realised it might be prudent to rename the article and focus on just half of that number. Remarkably, writing down all the ways you suck is rather enjoyable.

More importantly, it’s an exercise in reflection. As a developer, thinking about the ways that we work is not just useful but it’s essential. It’s the difference between doing and learning, between building and creating, and finally, it’s the difference between being okay at what we do and, maybe one day, getting to be great.