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 Seif Lotfy - Co-Founder & CTO @ Axiom
About Seif: Seif describes himself as “a highly motivated, creative, overenthusiastic and quick learning software/data engineer, with a competitive yet team player attitude.” He’s a respected development leader who’s achievements have included highly recognised production code and open source contributions. He’s currently focused on building real-time analytics optimised databases, storages and platforms.
About Axiom: Axiom is a leading logging and observability application for developers that gets all your data, all the time.
You can follow Seif on Twitter and on LinkedIn.
When did you decide to become a developer?
I don’t think it was ever a specific decision. I was always attracted to solving logical problems and liked computers. At some point I was programming and then eventually somebody paid me money for it.
As a kid, my mom taught me COBOL but I outgrew her quickly. So we found someone from the local university to teach me everything they were learning. When I was 16, they bought me a book called “Teach Yourself C++ in 21 days” (the title was a complete lie by the way, because it actually took me two years to go through that book).
When I turned 18 I went to Germany, started working with alternative desktops (it was actually Solaris). I went through code and fixed stuff here and there and eventually somebody paid me for what I was working on.
So I never really decided to become an engineer because I wasn’t even officially studying computer science! It just evolved naturally.
What are the key ingredients to a really good engineering culture?
One thing that really helps is autonomy. I think it really leans on to what Dan pink talks about in his book “Drive - The surprising truth about what motivates us”. He introduces autonomy, mastery, and purpose as key motivation factors. So when you give developers the autonomy to master their craft, they also develop a purpose that creates a great culture.
Beyond this, I think it’s also important to develop an underlying assumption that everyone means well. This is particularly important with distributed teams who are on different time zones and schedules.
Another thing that helps is to ask why. Make sure you understand the thought that went into other people approaches and decisions. That way, even if you disagree, you can take everything into consideration and try to find the best possible path forward.
And finally, I think that developing real relationships helps. Beyond the super-professional relationship, give the team the freedom to move around an be themselves and appreciate each other for who they are.
Let’s say you’re building something from scratch. What does your ideal stack look like?
I’m very much a back end person and computer science person. So when I start projects it’s usually a library or algorithms or data structures.
In terms of the tools I’d use - I like VS Code. The programming language should be based on what you’re trying to do, but these days, I would probably lean towards Go.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
The biggest fail was probably when I deleted a production database at a company I was working at.
What did I learn from that experience?
Sleep :-).
There are obviously other mistakes I’ve made that were a byproduct of not doing enough research or making assumptions. But those are different types of mistakes that end up manifesting themselves as bugs or architectural problems.
But the deleted database was the mistake with the biggest impact. So make sure you get sleep, and also don’t forget to have proper backups and snapshots.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
Absolutely, developer experience is important and it’s being rightfully discussed as a critical aspect of what we do as an industry.
I think it can be broken down into a few distinct areas of focus:
For example, here at Axiom, we have a dedicated developer experience team. They’re the ones who came up with the integration with Vercel. The idea was to figure out, ‘how do I get developers to onboard quickly?’ You don’t want developers to have to change their stack or move too much to accommodate your technology. So the idea was to find ways to get developers onboarded quickly. And that’s one very important part of developer experience.
It’s is also the ability to appeal to different types of developers and accommodate different stacks. One thing we’ve been trying to do is to be compatible with existing API. So for example, instead of reinventing the tooling and telling engineers to install a tool so they can send us data, we told developers - weather you’re using Blockstash or Honeycomb or any other tools, we will support that end point.
And then there is the question of how to keep developers around and make the tool sticky. Getting them on board is one thing, keeping them there is something else. It’s similar to the relationship between sales and the customer success. I think you’ll similarly see these two types of roles evolve int he developer experience realm - the developer experience of getting developers on board and the developer experience of keeping them around.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
We recently did a transition to monorepo. We had a sprint then took a step back after 3 months to discuss the pros and cons of our experience.
One thing monorepos gave us was quicker deployments, because of all the dependencies that were scattered around. With monorepos, its all in one place which is an improvement. We also have a better overview of what all different components are so there are fewer no surprises. And this makes it easier from a management perspective because the monorepo lets you see what’s actually happening throughout the whole project.
One complaint I’ve heard from developers is the challenge of scoping down on one specific module now that he project is getting too big. Another issue they’ve raised is that Github gets too noisy with issues collected from different parts of the project since it’s no longer scoped to just one thing. I thought that was an interesting observation. One thing we started doing internally was having developers use Linear or some other issue tracker to track their own issues. This keeps issues organized and separated from the rest of the project, but this approach has downsides as well. So we’re still trying to figure out the right balance.
Another potential downside of monorepors is that the CI/CD pipeline takes longer but we’ve found ways to work around that.
Weather or not you should use monorepos comes down to the culture of your engineers and if they like that approach. From management perspective, I think it does makes things easier because managers get a better overview. But I think engineers need to have some kind of ownership and input over what they’re doing and how they’re doing it. After all, they’re the ones writing the code.
What will be the hottest dev trend/adopted technology in the next 12-24 months?
Jamstack is already a big trend that I think is only going to keep growing, I think it’s going to redefine how people do development in general.
I also think that we’re going to see big movements in how products are designed and planned. I’m not sure exactly what this will look like but we’ve seen so much progress on the coding side of things with things like Copilot and other AI tools. At this point, people are basically writing code by not writing anything at all. They’re just writing comments. But the gap that’s not yet filled in completely is the critical gap between product and engineering. I think we’ll see more tools showing up in this space. This is what makes me excited about what your team is doing at Livecycle. You’re building tooling to fill this gap in the engineering workflow. I think this is going to become more of a trend and we’ll see more hype around these types of tools.
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?
If it was going to happen, it would have happened already. No code is good for simple things like a really simple CRUD application, but that’s about it. It’s not going to help you with anything more sophisticated (at least not the tools I’ve tried). So I think front end developers are here to stay for a while.
Share some tips to help remote teams collaborate better.
Always have a good mic set up for communications because you want to communicate via voice, not just text. Video is even better.
Text-based communication can be effective, but it depends on who’s listening and who’s reading on the other side. There’s lots of room for interpretation and misinterpretation so communicating via video definitely helps reduce any kind of misunderstanding.
When you’re building a remote team you also want to make sure you’re hiring people that are intrinsically driven. If the people you hire are just doing tasks you hand them, then that will become a problem with different time zones. So you want intrinsically driven engineers who can just carry on and move forward without needing an explicit prompt or invitation to do so.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
My personal advice - don’t don’t force tools on engineers. I think you should let your engineers choose their own tools. Empower them with autonomy and ownership.
Want to upgrade your developer experience? Get Livecycle 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
