Meet the CTO: Talking to Jan Varljen from Productive

Meet the CTO is a new series about CTOs, their daily lives, roles, and responsibilities. This week, we talk to Jan Varljen, CTO of Productive.

Jan shares his story of starting out as a web developer at one of the largest agencies in Croatia. As the CTO of Productive.io, Jan is now managing a team of developers building the next generation of agency software.

[otw_is sidebar=otw-sidebar-1]

Hi Jan, could you quickly introduce yourself?

My name is Jan Varljen. I studied Computer Science at the University of Rijeka, Croatia and later at the University of Ljubljana, Slovenia. I’m a Ruby on Rails developer and CTO at Productive. Productive is a web-based tool for managing digital agencies. It works great for any agency that handles project based work. Productive integrates different business areas that are typically scattered over multiple applications: CRM, Sales Pipeline, Project Management, Time Tracking, Scheduling, Profitability, and others.

Productive’s essential goal is to give you insight into your business profitability and help you to earn more money.

Personally, I’m interested in almost anything related to web development, but I mostly enjoy researching about testing and continuous integration.

Can you share a bit about working at Productive and how you got there?

Infinum was the central organization, in which we started developing Productive. Infinum is a digital agency, and we created an internal tool which helped us in our daily work. We were working on Productive for about four or five years when we realized that other organizations were interested in using such a tool as well.

And then we realized that we could spin it out in a different product, which we did.

We then created the brand Productive, and we founded our company.

How many people are currently working at Productive?

Currently, we are still a small team. There are eight of us. Mainly back-end developers who’ve been Rails developers. We also have a designer, some iOS, Android and JavaScript developers.

Can you share some challenges when it comes to building a SaaS tool like Productive? Especially since you started out as a digital agency.

Sure, we had a lot of challenges, both technical and conceptual.

I would say the biggest challenge is integrating with so many different business areas and still make our core features very simple.

I have seen a lot of software that fell short because it had too many features and was way too complex to use.

“ I think if your software needs on-site support you are probably doing something wrong.“

We had the advantage that we were our very own client. We learned from our mistakes.

How do you handle feature request or how do you make sure that your product remains as simple as possible?

Well, we have a certain array of core features. We know that these are needed in order to run a digital agency. And then we get a lot of new feature requests from our customers.  We put those external requests up for discussion and see if our employees find them useful.

We also ask our other, current customers. We even roll out features for a certain group of our users just to conduct some beta tests.

Has there been any particular moment which influenced your career path in a meaningful way?

I started programming quite late and only after I enrolled in computer science studies. I fell in love with programming. Before that, I was that guy who was repairing all the computers in my neighborhood. But I never had that idea that one day I would become a programmer.

[otw_is sidebar=otw-sidebar-2]

Can you tell us a bit how you handle the topic of tracking bugs and testing your software?

We built a continuous integrations and deployment system around Semaphore, Github, CodeClimate, and Slack.

Every branch we push to Github is automatically sent to Semaphore as well.

Semaphore then runs our test suite against that build, and if everything is in order (if all the tests are green), the code is automatically deployed to our servers. If anything goes wrong (e.g. some tests fail, or the deploy fails for some reason) our team gets instant notifications on our Slack channel.

We use CodeClimate for code analysis and driving code refactoring. We do code reviews between peers in our team on a weekly basis.

We find it important to maintain a good code quality and fight technical debt on a daily basis rather than when it’s too late. One thing, I find very useful with CodeClimate is finding code duplicates in your code base, especially when your code base becomes huge.

But the most important tool we use is Productive because we use Productive for managing Productive development! Everything we do is a task in Productive. Our product roadmap is a set of task lists in Productive and all the expenses, time entries, and costs are managed through Productive.

Is there any project or technology out there which you would like to explore more if you had more time?

I would like to learn more about other programming paradigms like functional programming and how could I use them to solve some particular problems we face in web development.

I know how much understanding object oriented programming helped me to become a better web developer. I would like to explore more concepts and improve my developer skills this way.

I’m also very interested in automated testing and writing good and fast tests. I enjoy trying out new testing frameworks, learning new techniques and tuning test to run faster. For example, a year ago our test suite for Productive had around 1400 tests, and it was running on our CI server for around 10 minutes. Today our test suite is much bigger (around 3200 tests), and it runs for around 3 minutes on our CI server.

I like the trend – bigger and faster – let’s see where do we go next.

What are the biggest pains in software testing from your perspective?

The biggest pain in software testing is manual testing. A lot of people still test their code manually, and they’re just not aware they’re doing it. A good friend of mine once asked the audience in his conference talk: “How many of you test your applications?”. Somewhere around half of the audience raised their hands. Then he asked: “How many of you make a change in your code and then refresh the browser to see the change?”. Almost every hand in the audience was up. Point being – we all test our code, either automated by writing tests or manually.

Most often it’s not the developer’s fault they’re not writing automated tests. It’s theirs CTO’s, Product Manager’s, superior officer’s fault they don’t educate and motivate their developers to write tests. Sometimes they’re even against writing automated tests because project deadlines are short and there’s no time to write tests. That’s wrong on so many levels.

Writing automated tests is hard and running them is usually slow but there’s a lot you can do to improve that. First, educate developers how to write test and why they should write them in the first place. Then set a good continuous integrations system where all your tests are run on a fast CI server. Everyone in your team should be comfortable with your CI stack and feel confident about pushing their code to production every day.

In our team, we have a rule that newcomers have to deploy to production on their first day at work.

It might sound a little scary, but our CI stack ensures that everything goes smoothly. We give them a straightforward task just to push some code that triggers the CI system and deploys the application to production.

Is there any advice you would give you fourteen-year-old self?

Don’t take life too seriously. You’re doing fine and just be passionate about what you’re doing and maybe one day you’ll even become a CTO of a company.

Can you recommend some important resources?

As I said before being a CTO is all about reading and researching about technology. I have some blogs I regularly check like Giant Robots Smashing into Other Giant Robots from Thoughtbot and Signal vs. Noise from 37signals and Codeship’s blog.

But most of my resources come from Twitter and newsletters I’m subscribed to like Ruby Weekly and Rails weekly.

I read some books but mostly related to technical stuff, and one of my favorites would probably be “Growing Rails Applications in Practice” by Koch and Eisenbarth and “Confident Ruby” by Avdi Grimm.

We also have our blog at Productive called “Working with clients” where we talk about new features we’re introducing in Productive, but we’re also giving some know-how about managing agencies and working with clients.

[otw_is sidebar=otw-sidebar-4]