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.
Today we are featuring insights from Shem Magnezi - Co-Founder & CTO @ Wilco.
Shem has more than a decade of experience in software engineering in various domains: client and server-side, real-time systems, big data, mobile, and web. Shem is passionate about building a culture of growth mindset and obsessed with making teams work better together. After several years as a senior IC in WeWork and Meta, Shem is now the CTO and Co-Founder of Wilco, a platform that empowers every developer, regardless of their background or skill level, to unlock their full potential.
You can find Shem on Twitter, LinkedIn and on his personal blog.
We appreciate Shem taking time to share his DX insights with the community!
When did you decide to become a developer?
When I was in high school, I realized that I could make my life easier by building a few short scripts. They did things like solve my math assignments and help me find files on my computer. It was like I had superpowers at my fingertips.
What are the key ingredients to a really good engineering culture?
The key is to always think about what we can improve: in our system, processes, product, code style, monitoring tools and what not. There are countless aspects to building a system and it will never be perfect—but we should always look for ways to improve .
Let’s say you’re building something from scratch. What does your ideal stack look like?
React + Node (preferably with Typescript). I might use Next.js if the requirements are simple enough.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
Early on in my career, another engineer and I were tasked to make sure a specific part of the system could handle a big load of messages, so we created a loading test to check the volume that it could handle. We were both very junior and it was the first performance task for both of us. We didn’t know how to measure the amount of messages that the system handled so we just printed every time a message was finished processing.
In the beginning everything looked well, but as we put in more and more messages, the system started to drop some of them. We spent I don’t know how many hours on this, until one senior engineer came to check on us and said: “I hope you removed all the debug printing because those IO operations can slow things up”. Then we realized our mistake, removed the printing and everything worked smoothly.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
I think it’s very important, since engineering teams are getting bigger and the tools out there are just getting better. But I think that dev experience efforts should be split between all stakeholders in the organization and not just be the responsibility of one dedicated team. And maybe it should have its own dedicated guild like frontend, backend, devops, etc.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
I’m a big fan of mono repos! I really think that in most cases you shouldn’t complicate stuff and work on the same repo.
What will be the hottest dev trend/adopted technology in 2022?
I think training might be the hot topic right now, because while there’s a huge need for mid and senior engineers, there are not enough candidates. And on the other hand, there are many people who want to get into development but don’t have a lot of experience. Companies are breaking their heads over this problem, especially now, when they need to set themselves up for remote work. So training-related solutions could be a really big opportunity. That’s actually why we created Wilco.
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?
Yeah, we’ve heard about this for more than 20 years now. I remember those SOA-like XML editors with drag-and-drop features that were supposed to replace us all as backend engineers. I still think engineers will have plenty of work, and consider no-code tools to be more of a helper for the more repetitive work (like what Amplication are doing).
Share some tips to help remote teams collaborate better.
- Use good async communication tools.
- Take the time and configure the right notifications for each tool.
- Documentation, documentation, documentation.
- Remove bottlenecks - give your team members the power to do stuff without someone needing to approve each step.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
We’re building a really cool thing called Wilco. We’re still in beta, but are soon going to open it up. You can join the waiting list here: trywilco.com
