The Dev-X Project is a series of features with industry leaders sharing their developer experience insights. In each “episode”, we ask an industry leader 10 interesting questions about DX, collect their responses and insights and share them with you.
In this episode, we’re featuring Liran Haimovitch - Co-Founder & CTO @ Rookout.
About Liran: Liran is the Co-Founder and CTO of Rookout. He’s an Observability and Instrumentation expert with a deep understanding of Java, Python, Node, and C++. Liran has broad experience in cybersecurity and compliance from his past roles. When not coding, you can find Liran hosting his podcast, speaking at conferences, writing about his tech adventures, and trying out the local cuisine when traveling.
About Rookout: Rookout is a developer-first observability platform that provides an unparalleled ability to collect any piece of data - including logs, traces, and metrics - from the deepest levels of live code in their production environments, with the click of a button.
Unlike traditional monitoring tools and APMs, which tend to focus on metrics that DevOps engineers and SREs care about on the infrastructure level, Rookout is built from the ground up for developers, who care more about the actual code and business logic of their applications.
When did you decide to become a developer? (What inspired you to start your journey?)
My first recollection of computer programming is making a black turtle move about the screen. I started learning Logic in an after school program and haven’t looked back since.
What are the key ingredients to a really good engineering culture?
I like to say that “culture eats strategy for breakfast” because culture allows your teams to act in predictable ways in unpredictable circumstances.
Some elements of great culture are ubiquitous, but many are not.
I find ownership and accountability to be the most important element in any great culture. On top of that, you’ll definitely want to include teamwork, excellence, and a focus on impact.
In many other elements, different (great) companies may choose different paths. Work-life balance, for instance, varies greatly between companies and geographies.
Let’s say you’re building something from scratch. What does your ideal stack look like?
When building something from scratch it’s important to keep it simple (also important when building it in any other way, but that’s beside the point 😅).
I don’t have any strong opinions on frameworks, but I would probably pick React (which I’m fairly familiar with) or Vue (which seems the simplest option) for a Web application. On the backend side, I would probably stick with Express.js (old and tested) or Nest.js (which is fast becoming a leader).
For databases, I always start out with a managed SQL database on whatever cloud provider I’m using. That will rarely prove to be the wrong choice.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
Midway through my career, I led my team through a fairly large project which took almost three years to launch. It was a waterfall kind of thing, so of course it launched about a year too late…
As successful this project is over a decade later, during the launch everything that could have gone sideways - did. In particular, I remember a specific bug that haunted me for about six months.
During that time, we released over fifteen versions with the sole purpose of investigating that bug, most of them containing little else besides additional log lines for data collection. Each of those versions involved multiple workdays and stakeholders, to build, test, approve, and deploy them.
Through this ordeal I learned about the importance of agile development and the true pain of lacking CI/CD pipelines. Most crucially, I learned the fact that you will never know ahead of time what piece of data will save the day.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
Developer Experience is named as if the investment is only in the well-being of the developers. Nothing could be farther from the truth.
Developers are craftsmen, and while I wouldn’t necessarily go as far as saying they are the kingmakers of the 21st century, they possess the knowledge and a set of skills that make them highly valuable to modern businesses. As such, they are high in demand and always short in supply.
To make the most of this precious resource, companies should strive to give them the best tools to do their jobs. And just like every other profession, those tools raise a series of questions. Autonomy or Standardization? Build or Buy? Top down or bottom up?
Different companies are going to find different ways to answer these questions, but as a rule of thumb I would say that the smaller you are, the more you should give autonomy for individual teams to buy the products they need.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
I wish. Mono repos really are the ultimate way of building software, if CI/CD didn’t suck so much at handling them.
If you think about it, in multi-repo scenarios, there’s some glue stitching them together, making a sort of a “meta-repo” on top. This meta-repo is (probably) going to be poorly versioned, without all the benefits we have come to love about Git.
Unfortunately, this is definitely the lesser of two evils, as modern build, testing, and deployment tools are going to have a much easier job making sense of it all.
Naturally, if you are Google, you can go ahead and build your own CI/CD that does support a huge mono-repo. If you are not, don’t try to use brute force and have a traditional CI/CD tool process the entire repo for every single commit. Trust me that it’s not going to work - I have tried.
What will be the hottest dev trend/adopted technology in the next 12-24 months?
Definitely developer-first observability, which empowers engineers to own their code in production. :)
The second hottest though, is the adoption of ARM as a mainstream computing platform. The ARM platform has been powering your cell phones and tablets for ages, and have now become a viable option for laptops, desktops, and (most importantly) cloud instances.
Depending on your language and framework of choice, moving to ARM can be anything from a simple configuration change to a major rework. On the other side though, you can expect a major performance boost at a lower cost.
Some claim that front-end developers will become irrelevant in the future of no-code tools. Do you see this happening? If so, how soon?
Haven’t they been saying that about all of us for twenty years or so?
Share some tips to help remote teams collaborate better.
The obvious answer is that even if the teams are not colocated they should find ways to spend as much face-to-face time as possible. Unfortunately, this is often as useless as it is true, as whatever is restricting the team from being co-located in the first place is probably also limiting their ability to meet in person.
When working in remote teams, especially in different time zones, it’s important to prioritize async over synchronous communication. This has a couple of big drawbacks, such as making the communication way less personal and much more time consuming.
Potentially, it does have the advantage of creating a huge body of knowledge that can easily be shared with other team members, across space and time. I find that most teams spend way too much time trying to compensate for the downsides and not enough time capitalizing on the upside.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
If you are interested in learning more about code ownership throughout the software development life cycle in general and production in particular, check out my podcast, The Production-First Mindset
Want to upgrade your developer experience? Install Livecycle’s SDK and start collaborating in context on top of your PR deploy previews.
Like what you see here? Want to get featured? Check out our DevX Project for other great features and to apply to share your own developer experience wisdom