The Pragmatic Engineer
01:16:13 · Gergely Orosz
[01:16:13] S0: Thank you to co founder and CEO Luca Ferrari, CTO Francesco Mancone and product lead Federico Simionato for sharing all these insider details with us. You can find all of them on LinkedIn and other social media channels as linked in the show notes below. Here are my three biggest takeaways from this conversation. Takeaway number one. Even inside a single company, you should choose engineering processes based on the maturity of the product you're working on. The CTO of Bending Spoons found it completely normal that each team decides on their approach for example, on testing. More mature products have more automated tests like unit or integration or UI tests, and new products or less mature ones will have less. Same goes for releasing and experimentation. So more mature products will have more stages of releases and experimentation, but products that are just being built will not necessarily invest in this. Takeaway number two, the concept of radical simplicity. Now this is something that could be applicable far beyond bending spoons. Bending Spoons believes, as a principle, that they should seek out the most radical simple solution and approach. When adding complexity, the person or team approaching should build proof why this complexity is beneficial. Those who retain the simpler status should not have to defend this unless there is evidence and data that adding more complexity truly helps with whatever you are trying to do. All of this sounds pretty common sense, so it could be worth trying it out at your workplace or team. Takeaway number three. You don't need to copy popular approaches in order to become successful as a product or engineering team. Bending Spoons seem to have come up with how it makes sense for them to operate and didn't copy common approaches from other companies. Here are a few examples. Their most popular language is Python. It's pretty rare for most companies, but not for Bending Spoons. At the same time, teams can choose what they use. So for example, team uses Rust and they have plenty of known and TypeScript usage. Another example is how they do not have career ladders like most companies their size would do, at least for now. They do have some concept of levels, but for example, they have no bonuses because they figured it doesn't work as efficiently for them.
01:18:13 · Gergely Orosz
In some ways, Bending Spoons didn't follow any particular approach because they didn't really get too much advice in the early years. They struggled to even attract investors. Still, they figured out on their own what is it that works for them. Now if a small company in Italy with five developers could do this and they kept figuring out what works for them even as they grew, what is stopping you and your team from doing the same? Figuring out what works for you and not just copying approaches that you see that work for others. Thanks for listening and watching. If you enjoyed the episode, I'd appreciate if you subscribed and loved a review. Thanks, and see you in the next one.