Interview by Thomas Peham
November 17, 2015
Photos by Productive
From agency work to building a SaaS company.
Jan Varljen 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.
Share this interview:
Thanks for your time, Jan. Could you please tell us a bit about 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. Actually it works great for any kind of agency that handles project based work. Productive integrates different business areas that are typically scattered over multiple applications: CRM, sales, project management, time tracking, and others.
Productive's essential goal is to give you insights about your business profitability and it helps you to earn more money.
Personally, I'm interested in almost anything related to web development. And I really enjoy researching about testing and continuous integration.
Can you give some insights on your personal path and what made you start at Productive?
Infinum was the main organization where we started developing Productive. Infinum is a digital agency and we created that 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.
We then created the brand Productive and we created an own company with it’s sole focus on Productive.
How many people are currently working at Productive?
Can you share some challenges when it comes to building a SaaS tool like Productive?
Sure, we had a lot of challenges, both technical and conceptual.
I would say the biggest challenges is that we work on a tool that integrates into so many different business areas and it is difficult to incorporate all of this in one tool and still be simple enough.
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 own mistakes.
How do you handle feature requests and how do you make sure that your product remain 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 at discussion and see if our employees find them useful.
We also ask other customers. We usually use Intercom for that kind of communication.
We even roll out features for a certain group of our users just to conduct some beta tests.
We are really trying to keep our feature count to a minimal level.
Has there been any special moment which you would call a big influence in your career path?
I started programming quite late. Actually, I began to programm after I started my Computer Science studies at University. I then fell in love with programming.
Before that I was that guy who was repairing all computers in my neighborhood. But I never had that idea that one day I would become a programmer.
Can you tell us a bit how you handle testing and bug tracking?
We have a continuous integrations and deployment system build around Semaphore, Github, CodeClimate and Slack.
Every branch we push to Github is automatically sent to Semaphore.
Semaphore then runs our test suite against that build and if everything is OK, 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 notification inside our Slack channel.
We use CodeClimate for code analysis and driving code refactoring. We do code reviews between peers in our team on weekly basis.
We find it important to maintain a good code quality and fight technical debt on a daily basis. 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 actually use Productive for managing Productive development! Everything we do is actually 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 programing paradigms like functional programming and how could I use them to solve some specific problems we face in web development.
Any programming paradigm has its pros and cons, its use cases when it's much better to favor one concept over another.
The understanding of object oriented programming paradigm helped me so much 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 1.400 tests and it was running on our CI server for around 10 minutes. Today our test suite is much bigger (around 3.200 tests) and it runs for around 3 minutes on our CI server.
I like the trend of larger and faster tests. Let's see where we go next.
What are the biggest pains in software testing from your perspective?
The biggest pain in software testing is manual testing. I'm not kidding. 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 on 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.
In most cases it's not the developers fault that they're not writing automated tests. It's theirs CTO's, product manager's fault that 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 on how to write test and why they should write them in the first place. Then set up 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 shelf?
I would say hold in there kiddo, you're doing fine.
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 the CTO of a company.
Can you recommend some influential resources?
As I said before being a CTO is all about reading and researching about technology. I have some blogs I check regularly 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 favourites would probably be "Growing Rails Applications in Practice" by Koch and Eisenbarth and "Confident Ruby" by Avdi Grimm.
We also have our own 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.