8 Ways to Become a World Class Engineer

8 Tangible Tips from the Head of Systems Engineering at Vorboss

Meet Aaron Rice, the Head of Systems Engineering at Vorboss, in this one-of-a-kind insight into Software Engineering at Vorboss (and his tips from his career so far). He's a self-taught Software Engineer, with a wealth of experience from hands-on engineering to leadership from start-ups to some of the biggest companies in the world.

If you're wondering who Vorboss is – where have you been?! Vorboss are currently building London’s next-generation, enterprise-focused fibre network and looking for more amazing engineers (namely you!) to join them. Without further ado, let's find out Aaron's top tips and how this could help you progress.

1. Find your community.

When I've seen communities that are most passionate about furthering the technical niche they're in, it’s usually come from them being frustrated at a generally accepted approach to solving a problem. I’ve usually stumbled into those communities by feeling the same and enjoyed joining them in working towards the next iteration. When you're all working towards something together, there's a particular energy that drives each of you individually and as a collective.

Tip: Go to meet-ups and tech events and join online groups. For example, I enjoy going to anything put on by CNCF companies.

2. Learn how to work with both internal and external stakeholders, not just one or the other

Earlier in my career, I thought it would be harder to manage external stakeholders over internal stakeholders but that wasn't quite true. With external stakeholders, you’re trying to get them to part with something, whether their time or their hard-earned money to solve their problem and further what you're offering. It's clear and obvious, whereas internal stakeholders have their own set of wants and needs that might not be so obvious.

There may be politics internally, they might be trying to make their own play to do something that steps on your toes. They might even have also seen you at your worst (we've all had that 3am outage) so there can be less trust with internal stakeholders. If you know that you have to gain their trust as you would with external stakeholders, you can take them on a journey and help them to buy into your solution or proposal.

Tip: Use slides.

3. Be a hungry engineer, don't forget your roots

At Vorboss I have the autonomy to build the engineering team that I've always wanted to work in. We’re now at about 16 months in and are starting to see the rewards from the hundreds of interviews we've conducted. We've hired some truly fantastic people, some with lots of experience and eager to teach and some with less experience but eager to build and learn. My theory was that hungry engineers who want to go build things would bring much-needed energy and passion to a brand new engineering team because being in that situation myself created some of my fondest memories of being an engineer.

When we were all hungry engineers trying to build fires and try new things, you really saw magic. It’s hard doing that with more experienced developers sometimes, so I wanted to get a balance. I thought by starting with this, we’d get our culture right and that's starting to pay off. I can’t think of any setbacks, it’s a good place to be.

Tip: You should be part of a team that has a balance of experience and don't mistake your value to a team if you're early in your career. Sometimes you bring an unmistakable passion to the team.

4. Getting your application to production is your responsibility

DevOps is often called a role. Most of us have given up trying to fight this but we can still apply the methodology's teachings of cross-functional teams where everyone has the ability to take their application from requirements to production in an iterative, repeatable and transparent manner. The role of a DevOps Engineer / Platform Engineer is to build the environment that allows this.

Tip: Learn about CI/CD and get comfortable with the concept that it's your responsibility to deploy your application and you're the one who will be woken up at 3am if it breaks (good test coverage will save you).

5. Diversify your tech stack (within reason)

In the spirit of you being responsible for getting your application to production, you can make life easier for yourself by following the 12-factor application model.

In addition to following this model, I like to set some guardrails for my team at Vorboss to guide their decisions on language and framework choices:

1. At least one other person on the team should be familiar with the language or framework to keep the energy of the community alive (and also so you can go on holiday)
2. The language or framework should be using a standard software licence that allows commercial use. Nobody wants to be given a surprise invoice or be told that someone else owns your product because you didn't look at the license of one of your dependencies.
3. The language or framework should be under active development with an active community.

Tip: Learn about 12-factor applications and set your own guardrails for language and framework choice when building products.

6. Stay Curious

The best engineers I've had the pleasure of working with have been hackers at heart. They may have been an expert in one language but they were comfortable hacking away at others, working on little side projects or constantly reading about new technologies. Sometimes we don't have to be this actively engaged but in my experience, the best engineers at least have a latent interest in how the world works.

It's great if you're someone who cares about the product on the inside. Think of the Steve Wozniak approach. I really subscribe to that idea; the best engineers build code that looks beautiful on the inside and out.

Tip: Read hackernews and you know...hackajob. Also, check out eater.net if you're interested in how a computer really works.

7. Question the status quo

It's good to question the status quo but be prepared for the answer to be to adopt it. Sometimes we do need an iteration of an existing solution, or there's an entirely different way to carry something out. Likewise, sometimes it's actually important to not be different.  

I want to reduce the cognitive load of my engineering team and allow them to carry over their expertise from other companies. This means not having to learn a whole new set of internal tools which reduces the barrier to onboarding and being a productive engineer on a new team.

Tip: As per tip 1, be involved in communities so you can understand what the common tools are to solve your problems. Learn these and understand that there is a mental cost to replacing them with internal tools.

8. Join Vorboss

We’re working on problems that not many Software Engineers get to work on. Problems that include deploying of physical assets that will be under the ground for 20 years, powering the businesses, hospitals and banks that support our nation and doing this in a modern and efficient way.

We’re looking for engineers who are driven, capable and curious. Apply, and we'll provide an environment that you want to be a part of and that you can help shape. You can check our hackajob page out here.

Tip: Join us.

Like what you've read or want more like this? Let us know! Email us here or DM us: Twitter, LinkedIn, Facebook, we'd love to hear from you.