Software Engineering Efficiency in Action: Insights from Tsvetan Tsvetanov on Speed, Quality, and Cost

Have you ever wondered how you could take your business to new heights?

His involvement in mob programming exemplifies Camplight‘s commitment to collaborative problem-solving and mentorship within the development community. Today, we have the privilege of delving into Tsvetan‘s insights on aligning business and engineering, his approach to quality software development, and his experiences with mob programming and mentorship.

Hi Tsvetan, it’s so good to have you here today. Can you tell us a bit about your journey into software engineering? What initially sparked your interest in this field, and how has your passion evolved over time? 

Hey there!

Yes, definitely. I first started with software development around 8th grade. My dad had a Mac II emulator installed on our Windows PC. I got a really old book about the BASIC language and started to experiment with things. It didn’t stick though.

The breakthrough came 2 years later when I got into game development. I was an avid gamer myself and had always dreamt of making games. This felt impossible at the time, but bit by bit I started ploughing my way through it. We gathered with some friends and started work on our first game: A space-based strategy where you developed your own solar system and fought against other solar systems. We didn’t get anywhere but this helped me land a job in a game development studio in Sofia.

Then I got disillusioned with the game development industry and switched to web development. This was fun, but the best part was that I could do it as part of Camplight. At first my main passion was related to helping people organize. I was the type of guy who always gave advice but rarely did the work 🙂 Fortunately, I realised this mistake. Now my passion is to first prove that I’m a really valuable contributor and then start mentoring people on how to work better together.

Before we delve into your professional experiences, could you share a bit about your background and the core values that drive your approach to software development?

I shared most of my background above, so I’ll focus on core values. For me, people and humane interactions are the most important in a software development organization. Sadly, too many places treat people as resources. Cogs in a machine who have to be instructed what to do and pushed to do it. Sprint after sprint. And a lot of the current “agile” methodologies are covering that up.

Apart from that, people should understand how to drive quality in the product. Quality is not having a QA department or letting ChatGPT write your unit tests. On the contrary, quality is built-in the software development process through practices like Test Driven Development, Mob Programming and Continuous Delivery. Everything else is mediocre work.

We cannot help but ask, why do you like being a Camplighter?

I’ve always enjoyed responsibility. But not too much. Being a part of a cooperative let’s me have an ownership mindset without stressing over every part of the business because I know there are people I can rely on.

Another big reason is the fact that all of us are friends in Camplight. We enjoy working together, make grandiose retreats and share common values and interests.

So, you work on various projects. Apart from being a prominent Camplighter, you’ve gained a lot of recognition from Akooda. Tell us about your role there.

Yes, I’ve been working with Akooda for the past 6 months. So far, it’s a great experience! The people there are really friendly and care about improving their process.

I’m a senior software engineer. My role hasn’t been tied up to any particular part of the system. The Akooda guys see me as someone who gets things done fast, so they rely on me to work all-around the system. Which is fun.

I’ve also taken the initiative to improve our processes as a team. Things like release cadence, building-in quality and working better together. People love that.

How do you ensure that business and engineering objectives are aligned in your software development projects, especially considering your role as a Camplighter recognized by Akooda?

I think that’s the toughest part of every software engineer’s job. A lot of people just come into the industry and accept that business won’t be happy with engineering. And if we want to term ourselves “professionals” we can’t afford this friction.

And this friction is removed when:

1. You always choose the solution based on the business need
2. You build quality in and don’t wait for an approval from the business.

You mentioned your commitment to developing high-quality engineering solutions efficiently. Could you share some strategies you employ to achieve this balance of speed and quality?

Yes, the techniques I use have been around for a couple of decades. Nothing new and fancy, but a person has to have the guts to use them. Because, for some reason, they’re frowned upon in the industry.

The main philosophy comes from Continuous Delivery. These are a set of practices that let you build software that’s easy to change. And this gives a big competitive advantage because:

1. You have less bugs
2. You can ship innovation faster

Continuous delivery is enabled by practices like TDD, Mob Programming and Trunk-based development. All of these have some learning curve, but are immensely beneficial in the long run.

Mob programming is a significant aspect of your work. We find the idea fascinating. How has this collaborative approach influenced your development process, and what benefits do you see in it?

To be frank, I don’t like mob programming 🙂 But I think everyone should do it. Personally, I’m the type of guy who doesn’t like to be around people too much. However, software engineering is a team sport. And without mob programming, you don’t have a team. You have a bunch of people who compete about who’s going to finish their next Jira task first.

Mob programming forces the team to have focus and work together to achieve the needed results. It also makes you resolve whatever interpersonal issues arise and make the environment pleasant. Otherwise, you won’t have an effective mob.

Currently, I’m not doing it as much as I’d like to. However, this practice has changed my mindset. Now I rarely think about how to do my tasks first. I know that, even if it might be detrimental to me, the most important thing is to help the team achieve their goal. Frankly, no one has scorned me for being late on a task because I’ve helped X amount of team members.

As a mentor to junior and mid-level engineers, what advice do you typically offer to help them navigate the complexities of software development and accelerate their growth?

Work in small steps. I find that lots of inexperienced engineers do programming in big chunks. Then they try to run or build the code and everything crashes. All of a sudden they’re in a big rabbit hole of possible causes for this crash. And it’ll take them a huge amount of time to get out of it.

My second, correlated advice: learn TDD. This will force you to work in small steps. It’s not a trivial technique to be mastered, but the sooner you get over it, the better. I bet that with it you’ll be more productive than a lot of seniors out there.

Balancing speed, quality, and cost is a challenge in software development. How do you address this false trichotomy to ensure optimal outcomes for your projects?

Again, practices like TDD come to the rescue. When you start to put quality first with TDD you find out, bit by bit, that you have 1) way less bugs to care about, 2) way less outages that wake you up at 3am, 3) can deliver features that took you weeks, in days. In this way, you have quality that drives speed of development and low cost of change. Of course, you can’t do TDD in isolation. There are other practices that can improve things even further.

Can you share a memorable experience from a mob programming session where innovative solutions were developed, highlighting the effectiveness of collaborative problem-solving?

We were mobbing the architecture for a big e-commerce provider in Bulgaria. It was me, the dev team, one architect and one PM. For several sessions of about 2 hours each we managed to design the new architecture and get everyone on board with it. Maybe this isn’t so innovative but it prevented the conflict between developers and architects standing in the way of improvement.

In your experience, what are some common misconceptions about software engineering, and how do you work to dispel them within your teams or the wider community?

Well, I’ve already shared the misconceptions:

1. That software development is an individual activity
2. The false trichotomy of quality vs. speed vs. cost.

Working to dispel them is hardly just about the tools you use. I mean, I can explain TDD, mobbing and continuous delivery to you in a day. However, the process to integrate these practices inside an organization might take months. Mainly because of the human factor.

As I said, people are really sceptical about these practices. So a lot of the work should go in building trust with people first. What I do at the beginning is to prove that I’m delivering on promises. Even if I have to adapt to an inferior methodology. Then people start to appreciate my efforts and this makes introducing new practices way easier. After that I start nudging here and there. Trying a bit of TDD, trying a bit of mobbing, pushing people to review PRs faster and not to leave undeployed source code. When I see enthusiasm about a particular effort I double down on it and support it. Then, when it’s fully implemented, I move forward.

I also share a lot of articles and books on good practices, so people can understand them themselves and become more eager to try them out.

Leveraging your expertise, how do you foster a culture of continuous learning and improvement within your engineering teams, particularly as a recognized developer by Akooda?

Mainly I do TWO things:
On the one hand, I constantly share articles and books on topics which I find valuable. And I try to discuss them with people.
On the other hand, I try to show an example and create a space for people to try out new stuff.

Communication and collaboration are crucial in software development. How do you ensure effective communication and coordination, especially when working with distributed or diverse teams?

Well, this greatly depends. If the team is doing mob programming full time, you don’t need anything else.

Otherwise, people should start to get into the habit of putting the team first. This is done by prioritizing PR reviews, always being available for the team, making sure code is deployed frequently. Communication and coordination should also be transparent. In Akooda we have the great practice of discussing things in public Slack channels separated by topic. This allows us not to be blocked and to find information with ease.

Reflecting on your journey and experiences, what key lessons have you learned that you wish you had known earlier in your career, and how have they shaped your approach to software engineering?

There are TWO lessons:
First, quality is important. Don’t overlook it to get a false sense of speed.
Second, before you improve the process, prove that people can trust you. I’ve wasted so much effort on improving teams where people see me as the guy who gives a lot of advice but does little.