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 Jason Bosco - Co-Founder at Typesense Search.
Before founding Typesense, Jason was the VP of Engineering at Dollar Shave Club & Verishop.
Jason is a respected technology Leader and Entrepreneur with experience in building, nurturing and scaling Product, Engineering and Design teams to build delightful technology products. Also a hands-on Software Engineer, Generalist and Polyglot with experience in architecting & building Scalable and Highly Available web-based systems.
Jason is a huge DX advocate and we appreciate his taking the time to share his insights with the community.
When did you decide to become a developer?
[Jason Bosco]: I started programming when I was 11, started with C and then Java and then discovered Visual Basic at the time, and that’s when it felt magical. I loved being able to build Windows applications by just dragging-and-dropping controls and writing some code to make it do useful things.
What are the key ingredients to a really good engineering culture?
[J.B.]: Some of the key ingredients for me are: Reducing the time it takes between an engineer writing code and users using it, paired with effortless rollbacks; making sure engineers know the business problem they are solving; and promoting blameless learning-driven postmortems.
Let’s say you’re building something from scratch. What does your ideal stack look like?
[J.B.]: This is going to sound uncool, but my preference for a (web) stack continues to be server-side rendered HTML with Ruby on Rails and a dash of Javascript for interactive stuff. I find myself the most productive in this stack, vs having to wrestle with time-consuming plumbing.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
[J.B.]: That time when I thought I was making a seemingly innocent change to fix a long-standing edge-case bug. I verified that it worked in my browser and pushed it to prod on a Sunday night. The next morning I come in to hear that my “bug fix” also ended up breaking the signup flow on IE (RIP). Not sure if I’ve still learnt the lesson well enough, but cross-browser testing for frontend stuff is important. Or maybe with IE less in the picture, it’s less of an issue? Not sure. But I might have to relearn this lesson sometime soon.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
[J.B.]: 100% - I think this will continue to evolve. I see a Developer Experience team as a force-multiplier within a larger engineering team, to improve productivity. This function has been described with various names over the years, but I think “DX” captures the essence of what this team’s primary charter is. That said, I think it’s best if engineers working in other teams regularly rotate into a DX function for a period of time, so they can scratch the itches they’ve seen in their stack when working on other projects. Carving out dedicated time for every engineer to focus on DX at some point in a given year is a good way to make sure the DX team has sufficient context on the day-to-day.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
[J.B.]: Yes, if you have the same team touching multiple projects most of the time to get their work done, mono repos reduce overhead.
What will be the hottest dev trend/adopted technology in 2022?
[J.B.]: We’re going to come full-circle and do more server-side rendered HTML, but this time with “frontend” frameworks doing this heavy lifting.
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?
[J.B.]: No-code tools have been around in some form for decades now. Remember MS Front Page, Macromedia Dreamweaver, etc? But front-end as a discipline has only gotten more specialized in recent years. While no-code tools will lower the floor for non-technical folks to become makers, I don’t think no-code tools will be able to provide the flexibility that developer tools provide. So I don’t see the frontend specialization going away any time soon.
Share some tips to help remote teams collaborate better:
[J.B.]: I personally prefer written, long-form communication over short IM exchanges or video conferences. It might feel like it’s time consuming, but it ends up saving time in the long-run by avoiding unnecessary back and forth, and it helps the team to avoid any uncertainty.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
[J.B.]: I read this somewhere: One developer’s clever workaround is another developer’s ugly hack. An architecture decision that you find to be a head-scratcher might have had additional considerations and constraints of time / budget / people when it was originally conceived. I’ve found it helpful to learn this and keep this context in mind when trying to read a code base.
