A day in the life of a Software Developer

Hi! My name is Bryan De Smaele, and I am one of the founders and managing partners at Cymo. Besides management work, I also work as a Software Developer. This means that I translate (mostly internal) requirements into a working piece of software. We use several technologies along the way and focus on back-end applications. Read on to find out more about what it’s like to work as a Software Developer at Cymo!

Let me start off by describing how we do things differently at Cymo when it comes to software development. It’s not the dime-a-dozen developer job where you mindlessly have to write code or do some glorified plumbing. Our developers need to think further and consider integrations and data structures as well. I often compare our job to that of an artist. As a coder, you get a blank canvas, and it’s up to you to create something that is beautiful while considering requirements and functionality.

If we trust our coding artists to deliver, we need to give them the right tools to create. That’s why we don’t focus on one specific programming language. In the past few weeks, I’ve used Rust, Java, Python, and Golang on various projects. I always tell developers that a language is just a tool, one of many brushes you can use. Constraining a coder’s freedom just doesn’t make sense to me. It’s also why we focus on Event-Driven Architecture: we want people to think of supporting events and how they can be improved as soon as they walk in somewhere.

With that out of the way, let’s talk about what my average week looks like. We start every week by looking at our Sprint board on the monday.com app. This lists the priorities that week, divided in user stories. Since we are a relatively small company and a start-up, we deliberately try to keep those stories vague where possible to spur creativity. Of course, some stories are implementation-specific, which means they have technical requirements. In both cases, we set a general definition of done and emphasise the collaborative aspect. We don’t limit freedom, but support our coders through our team.

Once we’ve divided the stories, we start writing our code in IDEs like IntelliJ. We also write our own tests or scripts, so we can immediately check its performance. We sometimes review each other’s code afterward, but I prefer coding in pairs so reviewing happens naturally throughout the writing process. During onboarding, we take care to always code in pairs so we can ensure quality and get our new colleague up to speed quicker.

Once we’ve written and tested the code, it’s time to do some DevOps work. We set up pipelines, add required parameters, and deploy in cloud environments like Google Cloud. This also includes tasks like templating, roll-outs, devising a migration plan, and database administration if necessary. Since we’re a small team, we get to be responsible for the entire cycle from analysis to debugging, which I’m thrilled with.

Being part of a small team also means that changes can happen quickly and without any hassle. When modifying our internal product offering, most changes only need the approval of one managing partner, since we all have a specialisation. Keeping everything nimble ensures that we can adapt new tools and technologies quickly and don’t stifle innovation.

Our working environment is also subject to rapid change, especially when we have multiple projects going at once. We try to limit the number of simultaneous customers and the resulting context switching because our coders do their best work when they are “in the zone”. We also avoid constraints imposed by clients as much as possible. After all, you shouldn’t invite a great artist and then only give them a single coloured pencil to work with.

We do everything in our power to spur our artists’ creativity. Everyone receives a laptop with their desired specifications, as well as all the tool subscriptions and licences they need to write their best code. They can go to conferences that sound interesting, and we recommend our developers to get any certificates they deem relevant. Certificates are not mandatory in most cases, but we like to see our employees invest in themselves. If you’re not certain how to proceed, we’d be happy to inspire you. Not just for Cymo’s sake, but for their own: career coaching matters!

We assign a mentor to new employees during their onboarding. This is someone with a lot of experience who has become a Subject Matter Expert (SME) in their field. During the first few weeks, they work in pairs so questions can be posed at will and people get to learn on the job right away. Of course, employees can always reach out to any colleague they want. A Slack message or Google Meet call quickly solves most problems. If you ask me, our extensive knowledge sharing is one of the best parts of working at Cymo!

In short, I think that Cymo is a great place to work as a Software Developer. You end up in a dynamic team with lots of experience, where we share a passion for innovative technology. You get the freedom to solve your problems your way, and there are no boundaries to communicate with management. Finally: you can really expand your expertise thanks to our knowledge sharing, mentoring system, and generous tooling budget!

Did Bryan’s enthusiasm work contagiously? Do you also want to work at an employer that trusts you to do things your way? We’re constantly looking for new coding artists at Cymo, so apply here and we’ll be in touch soon!