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.
Gil Tayar is a Senior Software Architect @ Roundforest. He has 35 years of experience (!) and they haven’t yet managed to dull his fascination with software development.
His passion is distributed systems and figuring out how to scale development to big teams. Extreme modularity and testing are the main tools in his toolkit, using them to combat the code spaghetti monster at companies like Wix, Applitools, and at his current job as software architect at Roundforest.
You can find Gil on LinkedIn and on Twitter.
We appreciate Gil sharing some of his DX insights and perspectives with us and we’re excited to share them with the community.
When did you decide to become a developer?
[Gil]: I decided to become a developer somewhere around my Bar Mitzva, when I got my first computer. Subscribing to and reading “Byte” Magazine only cemented that resolve.
What are the key ingredients to a really good engineering culture?
[Gil]: To me, the key ingredients to a great engineering culture are: Nice people. Not a lot of ego. Professionalism and pride in the craft. These elements establish a creative environment and without these ingredients, it’s hard to create a positive, productive culture.
Let’s say you’re building something from scratch. What does your ideal stack look like?
[Gil]: For web, it would be the current one. For backend, it would be: Node.js, K8s, microservices. or frontend I’d take: React, SSR, Microfrontends in some way or another. And a monorepo with lots of modular packages to tie them all.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
[Gil]: What comes to mind is spending a year and a half of going the wrong way choosing the wrong infrastructure for Wix Code. After a year and a half, after realizing it was the wrong infra, we pivoted and went in another direction. In retrospect, we should have measured performance to check if we can live with what we had done. And I also learned that it’s never too late to make a necessary, correct change.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
[Gil]: Developer experience is amazingly important. DX is what defines the velocity of a team. If you take the time from feature requirements to production, and remove the designing and coding part, then the better the DX, the faster that is.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
[Gil]: Yes! But not the way everybody does. Everybody creates a monorepo with very tightly coupled packages. That’s the worst of both worlds. Create a monorepo where all packages are independent of each other: they can be understood independently, developed independently, tested independently, and if they’re microservices/microfrontends, also deployed independently.
Fail to do that, and you’re back in Spaghettiland, just inside a monorepo.
What will be the hottest dev trend/adopted technology in 2022?
[Gil]: I have no idea… but I can’t want to see for myself!
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?
[Gil]: My initial reaction is: Hahahahahahahahahahahahahahahahaha!
And my second thought is: Again?! We became “irrelevant” in the 90s too! History never repeats itself, it only rhymes with itself.
Share some tips to help remote teams collaborate better.
[Gil]: I honestly don’t know. I never really worked remotely. What I have heard and tend to believe is that a successful remote team is all remote, and never partially remote.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
[Gil]: YAGNI and KISS. The two most important tenets of programming.
And ditch DRY. Go with WET (Write Everything Twice)
