4 things I wish I’d known before starting as a Software Engineer

It’s been almost 6 months since I started my new career in the technology industry and I’ve learnt a lot in that time. The period has been split roughly 50/50 between formal training and work, each providing new insights to what my future career has to offer.

While my personal study before applying for the role has stood me in good stead, there are a few things that if I’d have had my time over I definitely would have paid more attention to:

Unit Testing

Practice writing unit tests. I cannot stress this enough!

My journey learning React through FreeCodeCamp has been a great help to my day-to-day role and I’ve found myself able to be productive and solve some tricky problems. In the last 6 months I’ve found I can code a working component quite quickly, however writing the unit test takes me a whole lot longer.

We write our unit tests using Jest, Enzyme and Chai, which all work perfectly with React. I’ve had a steep learning curve setting up mocks/stubs/fakes and knowing some of the intricacies around Shallow rendering and Mounting components. Spies are also one that has thrown me. You can assert that a function has been called when performing a certain action, rather than asserting on the value that it produces. In this case a spy is set to a function and register’s when it’s been invoked. It’s all a bit confusing to begin with, but I feel that with practice it will hopefully become more ingrained.

FreeCodeCamp now offers a Quality Assurance module that focusses on unit testing. Having my time over I would focus on this first and foremost. Unit testing is such an integral part of my team’s work and if I’d had any bit of experience with it then I could have been even more productive coming into the team.

Well-Named Functions/Variables

What I’d tell my past self if I saw him today is “This really matters!!!”. It’s probably the aspect I struggle with the most. Writing a good function or variable name takes time and a lot of effort, certainly in my case! I’m still working hard on this. it’s definitely not a skill that comes naturally to me.

While it sounds really simple, I constantly have to remind myself:

“What does the function do? What is its purpose? What does it return?

When I come to refactor, this is one of the areas I focus on the most. While the function may make sense in your mind, can a non-technical person come in, read your code and intuitively understand what it should be doing? Sometimes you can become too blinded to your code and think it’s obvious, but when you actually read it aloud it really isn’t.

One of the earliest chapters In Robert C. Martin’s “Clean Code” is titled “Meaningful Names”. The prominence of this chapter shows how integral well written names are to an application. It helps the reviewing colleague and any current/future member of the team to read the code and understand it’s purpose. Ambiguous names create confusion, so stop it!

Isolating functions to a single use

Similar to naming functions to do what they sound like they should do, I also need to declutter functions so that they’re not performing more tasks than they should. I often found myself declaring a wide ranging function that performs a variety of tasks. This would get highlighted in code reviews and I would be encouraged to split it out into smaller chunks, isolating each piece of logic handling.

I’m told this is more in line with good functional programming that I’m trying to achieve with my React code. Each piece of logic has its own function and if that is needed to be used elsewhere, it can be abstracted away and reused by multiple components.

This is a nice quick-win for me. I find it much easier to break my chunky function into smaller bites. It’s just more naming issues that’s the troublesome part!

Object-Oriented Programming

This would have been the opposite had I known only object-oriented programming methods but my whole experience was centred around Javascript, used in a functional way. This has led me to be very blinkered to other writing styles and made it harder to learn those in the process.

My team uses React for front-end work and Kotlin for back-end. Kotlin is an object-oriented language and while some aspects of it are intuitive and seem a logical way to write code, it’s been difficult for me to pick up. This is particularly evident when reading other’s code. I often find myself looking up a class thinking it’s from a Kotlin standard library only to find it’s a custom class and I have no idea what it does!

This will be a learning curve for me, but one that I see massive benefits in me conquering. I’ve only started learning Kotlin in the last few weeks so it’s all very new to me.  However, I believe knowing both functional and object-oriented programming styles will make me into a more rounded and knowledgable engineer.

Conclusion

I’ve left this list at 4 – the ones that I felt I would have benefitted from the most before starting. Not necessarily knowing them fully and having a lot of experience in them, but at least having more exposure to those topics. I believe these would have given me the ‘biggest bang for my buck’.

I was lucky enough that my team uses React which I’d made a few projects through FreeCodeCamp (one of which you can see here). This has led me to be quite productive in my early months which in part gives me more exposure to harder topics. The areas above would have propelled me even further. These will be in the foremost of my mind going forwards and hopefully I will reap the benefits of this work soon.

I’d love to hear from your own experiences! Is there anything you’d wish to tell your past self at the beginning of their career?