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.
Amir Shevat is Head of Product - Developer Platform @ Twitter (which acquired his previous company Reshuffle where he was Chief Product Officer). Amir was also VP Product at Twitch, Director of Developer Relations at Slack and has held senior positions at Google and Microsoft.
Amir is an accomplished technologist and entrepreneur who believes strongly in giving back to the community. He is a respected investor, author, advisor and a sounding board for countless people in the space who regularly seek his counsel. He is also a proud investor in Livecycle.
We appreciate Amir sharing some of his DX insights and perspectives with us and we’re excited to share them with the community.
You can follow Amir on Twitter and on LinkedIn.
When did you decide to become a developer?
[Amir]: I’ve been coding for as long as I can remember. I was a PC kid, writing in C with my friends because it was cool (in a geeky way). So when I was 7 or 8 years old, I was already writing in C, Logo, Basic and Pascal.
I learned some coding from these small booklets that were sort of like “C for Dummies”. They were called C1, C2, C3 and C4. My grandfather bought me a computer because my parents couldn’t afford it themselves, and I loved coding and building things. And it wasn’t just coding - it was other things too, like robots. I had all these awesome things that I created that I loved.
So, although I was sure that I wanted to be an astronaut when I grew up, I knew that coding and creating would be an ongoing hobby.
What are the key ingredients to a really good engineering culture?
[Amir]: Transparency - Transparency is very important. This means creating an environment in which engineers can see the bigger picture - where we’re going, why we’re doing what we’re doing. Creating this type of environment for developers will enable them to create better code.
Be open to feedback - As a general rule, engineers that are open to feedback from each other are much better at doing their job.
Collaborative - I think that a team of people who are collaborative will always outperform a less collaborative team, even when that less collaborative team is filled with “amazing” individual engineers. I’ve personally been part of engineering teams that were not so collaborative. They had awesome, amazing engineers, but they didn’t really share what they were doing. It’s far more beneficial when people start to collaborate, share, provide feedback and talk about the interfaces between what each person is working on.
Delivery Cadence - Having a healthy cadence of delivery is also very important to engineering culture because when a team continues to deliver, they are able to regularly reap the benefits of happiness and satisfaction from their work.
Let’s say you’re building something from scratch. What does your ideal stack look like?
[Amir]: These days I’m a product manager and not a super high-end engineer. So I’d keep things simple. It would probably involve Node or Typescript if I feel like I have a lot of energy for typing, and a simple NodeDB and Heroku. I don’t code production-level solutions personally. I design them, but I don’t actually code them. So this would be my stack for proof of concepts.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
[Amir]: One of my funniest ones, I think, was with a company I was with back in in ‘99, before the cloud. We were playing football in the engineering room and we ended up kicking the server. That’s when I learned that “the server is down” has two meanings…
What I learned from that experience is not to play soccer in the server room.
Another great engineering fail I witnessed (but didn’t cause myself) was when I was at Google. There was an engineer who sat next to me and one day I noticed he looked really sad. Turns out he had caused this crazy bug. He was writing Gmail for Android, and he put up a loop to check for new email every second (instead of every minute). When he realized his mistake, he calculated the number of phone batteries worldwide that he had drained with his code and let’s just say he wasn’t happy. But he lived to correct his mistake and he was still sitting next to me the following week.
At the end of the day, this is what we do. We mess things up and then we learn from them.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
[Amir]: I believe developer experience is incredibly important. More and more companies are recognizing its value and it will be a core driver of success going forward as well. Building tools and cultures with developers in mind, and allowing developers to do their best and most creative work will directly impact the quality of products and the success of the companies who build them.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
[Amir]: I think it helps with simplicity and I’m a sucker for simple solutions. Simple solutions will outperform complex solutions most of the time, and if the mono-repo approach allows us to reduce complexity and improve simplicity, then I’m all for it.
What will be the hottest dev trend/adopted technology in 2022?
[Amir]: I think developer productivity is going to be big. You’re going to see a lot more solutions for developer productivity (like what you’re doing at Livecycle) and for source control and introspection. For example, there is a new startup called Diversion that is doing a nice job of starting to think about the next generation of source control.
Then there’s the idea of the new web of creator tools and creator economy, which I think is interesting. I’m still on the fence as to whether decentralization and Web3 will be a thing or not. It could be, but it needs to have concrete use cases to be useful. I think for big companies like Twitter, it could be very relevant and important.
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?
[Amir]: I don’t see it happening.
Share some tips to help remote teams collaborate better.
[Amir]: My suggestion is “ABC” - Always Be Communicating”. Communicate through multiple channels, like Slack, your dev tools and through all-hands. Enable asynchronous loops, especially when the teams are in different time zones. The key is to enable bi-directional communication and enable collaboration through asynchronous loops.
Do you want to share anything else?
[Amir]: That’s a pretty wide-open question, so I’d say “42”. And after that - wear sunscreen.
