It’s been 2 years since I started to learn to code and just over a year since I became a developer, so it seems like a good time to reflect on what I’ve learned…

1. You don’t need to know everything

When I was first learning to code I felt like real developers knew everything and I knew nothing. But it’s just not true. There are always new concepts, languages, frameworks, technology and terminology. It’s good to keep up to date and be aware of new things but you can’t know everything.

I still feel like a kid in a sweet shop as there are so many exciting things I want to learn about but I am trying to focus a bit more. I’m going to try an 80/20 approach. 80% of my learning time on topics that deepen my knowledge and understanding (e.g. Advanced Swift, Design Patterns, Functional Programming, Objective C) and 20% on new shiny things that tempt me (e.g. Arduino, Python, Alexa skills) I’m also trying to keep an active list of topics I’m interested in so I can explore them later rather than distracting me too much in the moment.

2. Software development is much more than coding

Learning to code is obviously a massive part of becoming a software developer but it’s not the only skill you need. I spend much less time sat at a laptop on my own writing code than I thought I would. I spend quite a lot of time with other developers either pair programming or discussing an approach before starting some work. I also use skills such as using Git, Terminal, Postman, Charles, automated and manual testing, CI and much more.

Communication skills, collaboration and teamwork are also really important as a developer in an agile team.

3. Practice makes permanent

No matter how much you think you understand something, the only way you know for sure is by putting it in practice. This doesn’t mean that every time you learn something new, you have to build a fully functioning web app or an app that’s ready to submit to the App Store though. Once I realized that I could practice specific skills by building prototypes or by practicing in a small app then my learning became more focused.

4. Imposter Syndrome is normal

As someone who doesn’t have a computer science degree, and also a career changer I am prone to Imposter Syndrome. The problem is that it makes me retreat and blame myself for not being able to understand something. That’s not very productive!

I am trying to fill in gaps in my computer science knowledge by reading The Imposter’s Handbook and ensuring I always ask questions no matter how stupid they seem! Also, building a supportive network to discuss it with helps. I’ve realised that loads of other developers feel the same, no matter what their background or journey into tech.

5. Slow is smooth and smooth is fast

I can sometimes feel pressure to complete a piece of work more quickly, either because the business is keen to implement something, we are nearing the end of a sprint, or I’m just put pressure on myself to complete a task.

I am learning that however tempting it is to do something quickly, it’s often best in the long road to take my time (within reason!) I am more likely to write cleaner, more flexible code and write good tests if I take a step back and don’t rush unnecessarily.

Also, there are times when I’m struggling with solving something and I need to make myself get up and take a break. A 10 minute coffee break, a walk or just doing something else for a bit will mean I look at the problem afresh and solve it more quickly than if I put my head down and battle with it for hours on end. I am getting better at knowing when to keep battling, when to take a break and when to ask for help.

6. Understanding an entire codebase takes all developers time

When I first started as a developer, it was a bit overwhelming to be faced with a large existing codebase. All the other developers seem to know it inside out and I didn’t know where to start. I now realise that it takes all developers, even senior ones, time to understand existing code.

Taking time to understand the basic architecture and selecting an area of the code to get to know in more detail helps. But it’s only by using it, changing it and working with it that you can really understand it. It can take weeks or months to feel comfortable with a new codebase.

7. Context switching impacts speed and quality of development

In my previous role I was used to juggling multiple projects at once, going to lots of meetings and generally multi-tasking all the time. As a developer, this kind of context switching is unmanageable.

Joel Spolsky explains this really well,

“…programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code…”

Working in a team means there will always be distractions but as a developer it is good to be aware of it. Don’t pick up two pieces of work at once for example or try not to be constantly interrupted by email or Slack. There’s a good reason why developers often wear headphones, it’s probably more to do with eliminating distractions than being unsociable!

 

Thank you for reading! :)