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 chat with with Tom Snelling - a software engineer focusing on all things front-end and leading developer experience efforts at Northflank, a developer platform to deploy code, jobs, and managed databases in a matter of clicks.
He previously founded start-up Check Me Out, which produced software to automate popular online shops so that users could beat the competition and purchase limited items before they sold out. He has been writing software professionally for 5 years.
You can follow Tom on Twitter and on LinkedIn.
When did you decide to become a developer?
I think I probably started programming when I was around 13. I had always liked messing around with computers, and wanted to learn how things worked at a lower level. I bought a couple of intro to C# books and made some basic .NET applications in Visual Studio, before getting into making games using the Unity game engine. I, together with a friend at school had a little ‘game studio’ on the go, where he would do the 3D modeling and I would write the code. Unfortunately, those projects are long lost to time!
Fast forward a few years, while at university I discovered a love of web programming, front-end in particular. Being able to spin up new projects using a mixture of both technical and creative skill and then exposing them to the world was an awesome experience.
What are the key ingredients to a really good engineering culture?
I think the best thing a team can have is genuine passion for the product that they are building. Having worked on projects that I both have and have not been invested in, the difference in morale (and thus output) is amazing. When engineers really care about what they’re working on, I think culture improves tenfold. Hire smart people that want to work on your project.
Let’s say you’re building something from scratch. What does your ideal stack look like?
JavaScript all the way. Being able to use the same language on both front-end and back-end is great. Front-end has got to be React — depending on the goal either a Next.js app or just plain React with an Express server, using the awesome esbuild for bundling/transforming. styled-components and styled-system for styling, and normally MongoDB and/or Redis for any data storage needs.
And of course, it’ll be built, deployed, and hosted on Northflank!
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
While at university I had a reasonably successful app in the form of a Chrome extension. I had worked on a massively improved desktop application for months to replace the Chrome extension, and my existing users were keen to upgrade. I announced a time, set the new software live, and… had forgotten to update an API key somewhere from dev to production. Users got charged, but their licenses never got activated. Lots of manual intervention later, I had learned to check, check, and check again before going to production.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
Developer experience is hugely important. The more time engineers waste fiddling around with rubbish tools and struggling with confusing interfaces, the less time they have to be productive. It certainly evolves all the time, as new ideas hit the market with some new concept of how to fix a problem that engineers face. DX is the name of the game at Northflank — everything we do is with the goal of making developers’ lives easier.
Let’s take the mono-repo question once and for all - should you ‘go mono’?
I think it probably depends quite heavily on the project, but it certainly works for us. Having independent, self-contained modules within the same repository makes a project easier to conceptualise, and being able to share modules between different places in the codebase can be very useful. Of course, it doesn’t come without its own challenges sometimes.
What will be the hottest dev trend/adopted technology in 2022?
As others have already said, it could be moving away from using raw Kubernetes in favour of platforms and services that do the heavy lifting for you. DevOps can be a massive time-sink when things get complicated, and in the spirit of improving DX, that time could probably be better spent elsewhere. Of course I am biased as that’s exactly what we’re trying to build at Northflank — but there are lots of other people out there trying to solve the same problem too. It will be all about harnessing the power of Kubernetes without any of the hassle.
Another thing I am keeping an eye on is the adoption of super fast Rust-based JS bundlers and transpilers. I mentioned esbuild already, as well as others like SWC and bun. Any improvement build & hot reload times means less time wasted.
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?
I don’t think so. No-code tools and drag-and-drop site builders are great for getting people into the world of front-end development, but (at the moment at least) they only allow you to do so much. They can be great for putting together a quick site, but give quite a ‘cookie cutter’ feel to the final product. I think for anything bespoke, you’ve still got to write the code! Hopefully, if anything, they can succeed in getting more people interested in front-end development.
Share some tips to help remote teams collaborate better.
Regular social / team building sessions are important I think. Whether it’s playing a game, solving an interesting problem, hacking on a side project, or just a team catch-up — being able to chat about things other than work makes a big difference. Another thing is giving members of your team enough responsibility to get things done without constantly having to ask for approval or some other decision from higher up. Having to stop and wait for an OK all the time does nothing but slow the team down.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
Another engineer once told me: “make it work, make it good, make it fast”. It may sound obvious, but solving problems in that order has made life easier for me many times!
Do you have DX wisdom to share? Apply to get featured in an upcoming Dev-X Project episode.
