Capdesk is a startup, which affects almost every aspect of the employee experience. If you ask me, the development process is less rigid and more fun in a startup. It’s also very rewarding to work somewhere you can earn trust and gain influence relatively quickly. This isn’t just the case for developers – all Capdeskers enjoy these perks of our work culture.
Capdesk has changed a lot since I first joined, but what’s happened in that time has taken the company from strength to strength, and I’m proud to have been part of the journey. To mark the occasion of five years at Capdesk, I’m sharing five important lessons I’ve learned:
“Time that isn't spent coding is time wasted”
Sound familiar? This was an ethos I carried with me from my time at the University of Copenhagen. While studying computer science I often came across head-scratchers, and my first response was to jump right in and code until I was stuck. But I wasn’t solving major problems or even trying to find long-term solutions.
Capdesk taught me that analysing the problem is just as important as implementing the fix. This approach has saved me countless hours of refactoring code that I could have become lost halfway through coding. It gives me the chance to uncover potential problems before I’ve jumped in headfirst.
Of course, the scope of the analysis depends on the task at hand; a simple bugfix doesn't require the same thought as a new feature.
Before the pandemic, we would scribble diagrams and analyses on paper or have in-office whiteboard sessions; being remote has pushed us to find new ways of doing it. Today, all our technical analysis goes into Notion and we leverage tools like Whimsical and Draw.io for flowcharts, diagrams and mockups.
I studied computer science for my bachelor and master’s degrees, both of which focused on theoretical aspects of the subject. While I have no regrets whatsoever about my education, it did not prepare me for what I was about to encounter at work.
When I started at Capdesk I was tasked with choosing and setting up the application stack, server architecture and SSL certificates, which my studies had somewhat exposed me to. But before long, my remit included project management, QA analysis, web design, content writing and more. It wasn’t what I’d been explicitly hired to do, but as an early-stage startup we were scrappy. Outlying tasks had to be done somehow, and I pulled my weight.
The biggest surprise to me, however, was the amount of legal work involved in Capdesk. I knew from the beginning that the domain would be heavily regulated, but I did not expect that I’d be reading and reviewing legal texts. Without the appropriate training, I felt out of depth and was glad to hand this work over to external lawyers as soon as possible, but it gave me a solid foundation in the area.
Today Capdesk focuses on hiring subject-matter experts with specific skill sets, but I wouldn’t trade in my early years as a generalist. What’s more, the company is still small enough to design bespoke progression paths for individuals, so there’s a great balance between structure and freedom.
Iteration is key! I can’t say this enough. In fact, it’s one of our company values. Our first Capdesk build was a true MVP (minimum viable product). This barebone solution wasn't built to scale, but rather to gain early market feedback we could learn from. Taking the MVP route made iteration easy and allowed us to change and release features rapidly. Another benefit? We didn’t feel attached to certain features or pieces of code, which made us quick to scrap things that weren’t working.
Initially, we didn't focus on scale or longevity. Because there was no certainty we would be around for the long-term, our focus was finding product-market fit, not building a product stable enough for millions of users. Over time we accrued product debt, in particular regarding performance and our stack: we're still running AngularJS and that ship sailed a long time ago.
I don’t regret any of this, because it brought us to where we are today. We’ve made a start on fixing our product debt, and while we’re still accruing a small amount it’s nothing like before. Fear not, we’ll also be migrating from AngularJS very soon.
Is the tech stack we chose five years ago still relevant today and do people want to work with it? We've had to ask ourselves that question a couple of times at Capdesk.
During my studies, I loved learning about new languages and frameworks and tried to stay up to date. While I’ve kept that up to an extent, I’ve also realised that as long as the tools allow us to do what we need, it often doesn't matter what that specific tool is. That said, Capdesk has been guilty of neglecting its tools and frameworks in the past. With so much focus on features and clients, our stack was left largely ignored.
Today we've found a better balance, thanks to new student developers and full-time engineers who’ve helped us see where changes are needed. But there's a new framework coming out every day, and to switch systems every other week simply isn't feasible. It's all about getting our priorities right, because even though customers don't typically feel the time spent upgrading, the team definitely does.
What I really like about software engineering is the potential. In theory, we can build anything. You can build the coolest imaginable product that might change the world, but nothing will come from it if you don’t know how to get it out there. No single person at Capdesk could have brought us to this point on their own – it's a team journey and we're in it together.
Along the way, there's been plenty of room to grow and develop, and even in a small team I’ve felt supported by those around me. I’m surrounded by talented, generous people – some of them junior, others experts – and this is what makes Capdesk really special. We all respect each other and we all know that each and every one of us plays an important part in the company’s success.
