From testing to development

Whenever I learn something new, I write it down.

No matter how trivial, it goes straight into my Evernote. Quite frankly — I’d be lost without that little green elephant.

So when I look back at my notes over the last 6 months, I’ve a big smile on my face. Without meaning to be egotistical, I’m amazed and proud at how much I’ve learnt in this time, as I’ve transitioned into my role as a Junior API Engineer at busuu.

I joined busuu 13 months ago, initially in a test automation role. I was lucky enough to then be allowed to switch careers after 8 months — to go from testing software to developing it as part of our API team. Perhaps a standard journey for some of those in the test automation world, but a tricky one nonetheless.

It had got to the point where testing just wasn’t enough for me anymore. I wanted to build stuff, and I needed another buzz — watching my football team finish in their highest league position for 30-odd years just wasn’t enough…

Now let’s be clear. I’m only 6 months into this new role. There is much, much more for me to learn, I am still nowhere near the level of my more senior colleagues. But so far, I think it’s gone pretty well. There’s always a risk when you make a career change, you never know how it’s going to work out (you might be sh#t at it, you might not actually like it etc). So it’s at least reassuring to know that I like it — I won’t comment on the “being sh#t at it” — my colleagues will let me know as soon as this blog is published no doubt (please be kind lads).

I’m now writing this post in an attempt to summarise some key things I’ve learnt in this time, in the hope that it can inspire and help others who are making a transition into a technology role, whether that is from a technical or non-technical background.

Actually, just one more thing before I do, I think it’s important.

Now, I don’t for a second think that this paragraph will inspire anyone to “follow their dreams”, but I think it’s important to know that I don’t come from a traditional computer science background. I studied English at university — not because I was passionate about it (I definitely wasn’t), but because I didn’t really know what I wanted to do (who does when they’re 18?!). I was good at it at school, and ultimately thought that it would leave the path open for me in the future (which has proved to be correct)…

The point here — you don’t need to come from a computing background to become a developer. Or you don’t have had to have loved it since you were little. It wasn’t until I was 26 that I actually knew what I liked doing at work, and so from that point forth, every action I’ve taken has been to get me to this current step. And there will be further steps to take in the future no doubt. I just push myself to where I want to get to. I hope that this will inspire others to do the same.

Anyway, here’s some of the top things I’ve learnt in the last few months:

1) Backend development is so much more than just the programming language itself….

If being a backend developer was just about learning e.g. PHP, it would be much easier. But it’s not. Knowing system / DevOps configurations is a huge part of the role. Knowing where to find logs when things go wrong, how to interpret those logs, and how to troubleshoot issues, is also integral. I actually find myself gawping when something goes down (we get alerts) and the more senior backend developers around me know exactly where the bodies are found. It’s crazy. Knowing where to look in the system, how it works etc, is something I find fascinating. Throw in some discussions on how best to configure the database, how and when to do caching etc etc — backend development is much much more than simply writing the actual code itself.

2) Unit and functional testing is really difficult but vital

Being “vital” — ok, it’s not rocket science.

But writing unit and functional tests being “really difficult” to write. Wow, this was actually quite a shock to me. The ironic thing about the last 6 months is that I always get stuck when it comes to writing these. Coming from a test automation role, you can imagine that this is f$%king annoying. In my defence, writing UI tests (what I used to do) and writing unit and functional tests (what I now do) are totally different. And these last 6 months have taught me that getting unit and functional testing right is really hard.

Controversial — I understand why some developers don’t write them (not saying it’s acceptable, but I can understand it). I find that at present (early days in my development career), these are the things that take the most time. But at the same time, the tests are absolute life-savers during development. And I totally get how bugs can easily slip through the net without them.

Throw TDD into the mix…wowser. This way of working is seriously hard and companies should probably hire anyone who can do this well…

3) Always, always, always make the most of the people you work with and their experience…

Not just a technical one this. But it’s definitely been a huge part of the last 6 months. My colleagues have been incredibly supportive and they’ve helped me to understand a lot. It goes without saying that you should always put in the effort if you want to get good at something, but it always helps when you’ve got others who can talk you through any questions you have. Like me, if you’re making a transition like this, you need to make the most of these people because they will help to improve you understanding, knowledge and then ultimately your career. Don’t be afraid to ask the stupid questions.

4) Get your data types right and keep them consistent…

Honestly, this sounds so obvious but it’s given me headaches in the last few months. Having something as an object and then converting it to an array, before passing it as another object…etc etc. What a f@*king hassle. When passing things around, if it makes sense, try to have the input be the same as what the function then outputs. I.e. if you take an array as a function parameter, dish it back out as an array, not as an object e.g. a fu%king /stdClass. It’s a pain to debug and will lead to bugs. Keep it simple.

5) Keep positive

There have definitely been times in the last few months where I question whether I can actually do this and not be s*it at it. Writing test code (previous role) to writing production code (now) is massively different. I’ve found myself having to think in a completely different way, it’s a totally different mentality. And I actually think that this mentality has been the trickiest part of the transition — I would say I’m getting better at it everyday, which is natural given the more experience I have. But it’s been quite an interesting challenge. In any role, there will be good times, there will be bad times. It’s really important to be resilient.

6) Understanding of the pros and cons of strict and loosely typed languages

I love the flexibility of a loosely typed language but my goodness do I sometimes miss the compiler…

At busuu, our APIs are written in PHP 7, whereas the test code I was writing in was mainly Java. It’s quite a nice transition to make, given that the syntax of the two is quite similar and they’re also OOP languages — I’ve not had to teach myself the basic concepts again (e.g. inheritance, encapsulation etc).

But a key difference — PHP is a loosely typed language and Java is not. When someone said strict vs loosely typed before, I kind of acknowledged what this was but never really had any practical experience. So it’s been great to now fully understand this, and to gain understanding of the pros and cons of both.

I find PHP brilliant to just get things done quickly. Honestly, really quickly. And I absolutely love that I don’t always have to type hint, it’s optional in my functions. But I must say that I do sometimes miss my old friend the Java compiler. That layer of security that tells me I’ve fundamentally f£#ked something up before you try to test it…it doesn’t exist in PHP. And sometimes I wish it does.

And that’s it for now. I could perhaps continue to write more stuff about the resources I’ve used to learn stuff since I’ve transitioned into my new role (other than actually doing it in my normal working hours), but I’ve rambled on for long enough and perhaps I’ll do that in another post.

Until next time…