Guy Podjarny (Founder & President of Snyk.io) on optimizing developer experience, introducing security to developers, and when to offer a freemium product.
Developer Den is a series of interviews with notable developers in our community to learn more about their journey into engineering. We sat down with Guy Podjarny, founder of Snyk.io.
How did you get interested in computers?
I got interested in programming in high school. Around that time, I think at age of 16, I taught myself Pascal from a book. (I'm old—42!) My first program was a keyboard piano where I sat there with a guitar and tried to tune the MIDI number to the notes that I heard on the guitar. It took an excessive amount of time.
I subsequently built a bot that did online gambling—without real money—in MIRC rooms. I think that predated actual gambling on the internet.
I got a programming job when I was 18 to build web portals—they were all the rage at the time. This company wanted to put a portal in front of all the schools in Israel. I don't think it ever actually saw the light of day, and I was a full-time student at the same time. The upside was that I had access to a room full of computers on a fast network. I might have, you know, dropped by with some friends at night to run programs and download things from the fledgling internet.
My professional programming skills came to be when I got into the cyber division of the Israeli army. I built up my skills in Java and C++ through the four and a half years I was there, and when I got out I was a pretty good developer.
What was your first job in the industry like?
It was in cybersecurity at one of the first application security companies. I was working on pretty low-level code, trying to understand performance and bottlenecks and memory leaks in C. Subsequently, I moved to work on Java and .NET. That company got acquired by a Canadian company, and then by IBM.
How did you get your start as an entrepreneur?
I founded a web performance company called Blaze, which made a front-end compiler for web pages. It was an inline proxy for web pages, and it could optimize everything—reorganizing scripts and compressing images.
When I built that company, I just worked constantly in my cave. I had a newborn son at the time. From March of that year until July, I would code away in my room for hours, only stepping away to see my son. At night, I would stay up until about 4:00 AM. I was a night owl—I'd go to bed during the day so my wife could take the morning shift with our son, and then when she went to bed I'd take care of him until the morning.
During that time, I asked someone who I respected, “What's the best path to becoming a CTO?” And they answered, "Found a company and call yourself CTO."
That's what I did—and then Akamai acquired the company I was working on, Blaze, and I became CTO for real. I was working on the web performance business there. At that time, my skills had gotten to the point that I wasn't coding anymore. It was the same with Snyk—I understood what the technology could do, and I was involved in code reviews, but I didn't write any notable amount of code.
What was the hardest technical problem you've encountered?
Intermittent memory leaks in C++. We had this product that scanned websites called AppScan—it's still one of the market leaders. It would scan sites for many hours and slowly accumulate a memory profile. I was the guy that needed to analyze the source of memory leaks for that. That was hard.
The project that I'm most proud of was Blaze. I built an asynchronous analysis engine. It would take the web page and funnel up all parts of it into a central system, which would output transformation instructions of how to modify the HTML page. That allowed us to make minimal changes that were extremely effective. We could use all sorts of existing infrastructure—CDNs and load balancers, for instance—to apply the transformation instructions of that system.
It was pretty nifty. The business proposition there was more limited, but I think the architecture was the right one for the job.
You've had a lot of experience at security companies. How do you introduce security to developers?
Every developer would rather write secure software than write insecure software. But, there are two big problems. The first is that most security tools aren't built for developers. They're built for auditors and sometimes retrofitted to work in a developer environment. The second is that security is invisible. It doesn't hurt until it hurts really bad. So, developers don't know what they've built is insecure. As tool authors, we have to build artificial visibility mechanisms—otherwise you wouldn't know that the problems are there. That's a unique problem to security—or at least, more extreme in the world of security.
When you talk to developers, developers need to understand the importance of security. Security is boring, but hacking is fun! Show developers some hacks, especially on code that they have experience with. That's way more effective than a boss telling you, "You have to do this."
What I think we've done at Snyk is lowered the threshold of how hard it is to do the work. We made it a question of, "Well, why wouldn't you use Snyk?" Why wouldn't you want to know if you're using a vulnerable library? Why wouldn't you want to know about this minimal change that would fix a vulnerability? That was the key to getting developers engaged.
Can you identify any specific features of Snyk that made it easy for developers?
There's a bunch, but the primary thing was distinguishing a developer perspective from a security perspective. When a security person sees a vulnerability, they zoom out and see risk—they see an attacker and what they can access. On the other hand, when a developer thinks about a vulnerability, they see the app—what might go wrong and the maintenance cost of mitigating it.
Existing open-source tools will tell you: you're using these 500 libraries and this one is vulnerable, so remove it. That's not very helpful—it's an exercise for the reader to figure out which vulnerable library is a dependency of what other libraries, and whether it can be easily removed. Instead, we built a dependency tree to show the relationship of the vulnerable library with each other library, which was dramatically easier to use.
Another difference is that for security people, breaking the build is a good thing—that means you've found something real. But for a developer, you try very hard not to break the build! Breaking the build means more work. We discovered that the correct place to surface security problems was in the pull request, where code reviews happens. That was much easier on developers.
What did you learn about optimizing developer experience?
Truly great developer experience comes from experimentation and feedback. It's one of the reasons that the vast majority of successful developer tools have some form of open-source or freemium service. That kind of user base creates a feedback loop where you can see the effect of a certain feature on developer experience. Being able to experiment with: at what thresholds do I need to alert developers? What is an acceptable amount of build time to add? Developer feedback will make your product that much better.
What advice do you have for companies that make freemium products?
Focus on use cases, not features.
Also, the number-one mistake that software creators make is constraining their freemium product. They limit it so that it doesn't interfere with their commercial opportunity. Then they expect everyone to use their freemium product. What they haven't realized is that they've made their freemium offering not fit for any purpose. Or, fit for only very small companies. You need freemium users that will eventually turn into enterprise customers! When you build freemium, you need to think: what use case do we want to satisfy? And for whom? Then, does a big enough audience care about this use case? How much pain does their problem cause them, and how much friction does using the tool involve? If the technical friction of your tool is low, requiring a credit card, for instance, adds a lot of friction. You also need to understand what the commercial use case is, so you don't give too much to the freemium tier.
What have you been reading recently?
I recently read this great book called Think Again by Adam Grant—it talks about rethinking your decisions. It's about getting stuck in your assumptions, and how modern tendencies to view the world in black-and-white make it harder to question those assumptions. I found that very enlightening. I also recently reread Hamilton's 7 Powers, about how to accumulate business power and use it to provide value.
Aside from Snyk, are you working on anything?
Two kids! Plus, house renovations.
Do you have any advice that you'd give to a developer early in their career?
The primary way to grow is not to be afraid to try new things. Don't get stuck believing that something can't be done—sometimes it hasn't been done yet.
I'll steal an old Marc Andreessen quote: swap career planning for strategic opportunity taking. Be in a position where you're involved in things that interest you. Don't disqualify opportunities that come your way—give them proper thought. That's how I ended up relocating, and how I founded my companies—both good things.
Thank you so much!
If you enjoyed this interview we encourage you to share it, and tag @guypod and @osohq! We'd also love to hear from you on who you think who we should interview next, tweet at us or join us and hundreds of developers on slack!
