The home team welcomes developer and software consultant Ben Borra to the show for a wide-ranging conversation about developer productivity, the value of positive feedback and identifying quick wins, the impact of code assistants on devs’ everyday work, and the challenges of system rewrites.
Still thinking about developer happiness and productivity? Read Eira’s article about the real 10x developers among us.
Connect with Ben Borra through his website or LinkedIn.
Asked and answered: Stack Overflow user Jian earned a Great Question badge with How do I close a frozen SSH session?.
[intro music plays]
Ben Popper If you’re building AI apps with popular models like YOLOv8 and PaDiM, go to intel.com/edgeAI for open source code snippets and helpful guides. Speed up development time and make sure your apps deploy seamlessly where you need it most. Go to intel.com/edgeAI.
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here, joined by my colleague, Ryan Donovan, who edits our blog and handles our newsletter. And we are lucky today to have a long-time podcast listener on as a guest who spent time in the trenches of legacy code being a team lead on some greenfield microservices projects and wanted to chat. And we've been sort of shouting this out a little bit at the end of every show, but bringing on actual software practitioners who are fans of the show who have been users of Stack Overflow and have years of experience in the field is my dream. What we always wanted the editorial platform to be was kind of like Wired magazine but for software developers by software developers. And I am not a great developer, I am the worst developer, so we're lucky enough today to have Ben Borra on the show. Ben, welcome to the Stack Overflow Podcast.
Ben Borra Hi, Ben. Hi, Ryan. Thanks for having me.
BP So for folks who are listening, tell them about yourself. Where are you based, how'd you get into working with code, and what have you been up to the last few years?
BB So I'm based in Belgium. I have started in software developments for seven years now, and I got started basically as a lot of people probably do– I bricked the the family computer a couple of times, got to ask my mom to fix it for me, and she eventually got tired of fixing it for me and annoyed so I decided I’ll probably avoid conflicts with my parents and I started looking into it myself. From there, my love for computers started and it grew and I was always interested in how can this little flat green piece of plastic spit out an image that I can interact with? So I've always had the interest, and eventually started learning to write code. I went to school for it and now I've been a software developer for seven years.
BP In Belgium where you're based, what does the curriculum look like? What languages do you learn and how long does it take?
BB I took about three years and we got started with Java mainly, and then a year or something like that in .NET. I got started as a .NET developer and I haven’t really touched any Java since then.
BP Well, that's okay. People love to love and hate Java. We just had a whole episode on it yesterday. You learned it, you set it aside, more power to you.
BB Pick your preference, I say. Whatever works for you.
BP So we've had a few folks on here from Retool and we've had folks on from Spotify Backstage and other developer portals. Have you availed yourselves of any of these sort of platforms that, in a lot of cases, came out of, “Hey, we were working at a certain company– Spotify, Uber. We realized that building internal tools often is reinventing the wheel, and so we wanted to create a platform basically for folks who need to do that. They can pick from modules. They can pick from components. They can use things that are tried and true. And in an open source way, everybody can give feedback about how to fix things or where bugs are.” What's your work been like building internal tooling, and have you availed yourself of any of these sort of developer portals or SaaS offerings that aim to enhance your ability to do that?
BB It's been very limited. You notice that there are a lot of custom developments still being done, but of course we try to leverage tools and libraries as much as possible. As you mentioned, you don't need to reinvent the wheel. You have basically open source tooling available to you and you should try and use it as much as possible. Specifically to the Backstage of Spotify that you mentioned, I heard that episode as well and checked it out. It seemed very interesting, but I haven't really used it myself. It’s a lot like a small web portal to show your health status of your applications and stuff like that. There are a lot of tools that you can use and that you can leverage that are prebuilt for you. Not that big of a setup on specific services, but frequently minor tools to make your life a little bit easier, smaller libraries, packages, preexisting applications to build on top of it a bit. I think not one specifically that comes to mind currently, but packages and libraries as much as possible, but not saying the specific setup.
Ryan Donovan So we're talking about the developer experience platform engineering things that are going on. What do you think actually makes developers productive?
BB That's a difficult question. I think first and foremost, make sure that they're happy. Happy people make better products in my opinion, but to keep the developer happy, it's a hard sell. It's the environment that they're in, the technology that can play, if they want to get training, get education, that's all going to help them. It's going to help them get more productive. You've seen a big push recently for GitHub Copilot as well, and I've heard a couple of people in management positions: “Okay, can we try this GitHub Copilot, and is it going to reflect on the velocity and the features that we're going to get released?” I use GitHub Copilot constantly, but in my opinion, it’s something that you're not going to notice in your velocity. It's a tool, it's a useful tool, it's not that expensive, and for the price, in my opinion, it's definitely a help. What is also going to make your developers probably more productive is trying and get them to deliver the most value as possible. Try and identify the quick wins, the low-hanging fruits, the things that are going to have a lot of impact on the business, on the product that they actually deliver. I spent weeks on building a new feature, a big, big feature, and you hardly see any use of it, and then we spent a couple of days on a specific template system. So if you needed to fill out a form, we had a template that pops in there automatically that you just fill out the blank spaces. And we got a lot of feedback on that, how it was very useful, a big help to their day. And in the end of the day, it was a feature that was, I'm not going to say hardly any work, like a day, a couple of days maybe at max. Things like that, try to identify the big wins, the low-hanging fruits. There's sometimes a big push to get these big new improvements into your work, your product, your pipelines, but at the end of the day, it's often more beneficial to have frequent small improvements that scrum tries to push, for example. Frequent smaller improvements that at the end of the day have a big, big impact, big profits, a big advantage and your utilization rate of your developers, the value that they're going to be able to deliver with these small improvements is going to be something that's going to be ginormous.
BP One thing I find challenging in that respect is that I've seen chief product officers and CTOs at Stack Overflow sometimes work really well with the architecture and backend team to make changes that pay down a ton of technical debt and set us up for a future in which we can be much more cost efficient. But those often get recognized very briefly, sort of like, “Hey, this happened. Everyone says, great, wonderful, and move on,” and they don't really register with the sales or the marketing team and they don't get resourced the way, “Hey, we’ve got to build this new product that's got XYZ AI in it,” does. So I think there may be a frustration sometimes among developers that we're chasing the shiny object instead of, to your point, doing the things that would sort of pay dividends in the long-term.
BB Providing the positive feedback is something that easily gets skipped, unfortunately. When we're dissatisfied with something, people are quite vocal about it sometimes, but when people are happy about something, unfortunately, it's not always shared. So if you're happy with something that you use today, share it with your developers, share it with whoever is responsible for it. It's going to make their day a bit better.
RD So I want to touch on another thing. You mentioned the performance is a feature. This is something I've written about. Former co-founder Jeff Atwood wrote a pretty famous blog about it– performance is a feature. And when we started, Stack Overflow was very much performance-oriented in a lot of its code to the detriment to a lot of best practices. Do you think there is an argument to be made to always go for performance, or is there a case where it's better to work on other features, to devalue it as a feature?
BB At the end of the day, you're always going to be able to spend time on making performance a bit better. You can always shave off those microseconds, but you should always look at the performance that you're getting in the field that you're getting in the real world and evaluate if you should spend more time on it. Of course, you don't need to develop something and know that what you're writing is going to break the system and bring everything to a grinding halt. You need to be a bit realistic in what you're building, and that's probably something that's difficult to measure when you're writing it. It's something that maybe you gain with experience over the years. But you can spend a ton of time in writing caching, in making everything scalable and setting up for a giant storm, but as I alluded to earlier, most of us aren't working on giant scale. And I don't know where I heard this, but if you're prepared for your next order of magnitudes, that's probably fine in most cases. Of course, again, it depends on case by case, but I'm not going to say there's no value in spending sprint after sprint on performance improvements and caching and denormalizing your data and doing this and that if it's not needed today. There are probably a ton of things on the backlog that are also going to deliver value that you can spend your time on without needing to shave off that extra couple of milliseconds.
RD It's interesting, a friend of mine shared this video of somebody talking about how performance is important. The proof was that all these big companies eventually hit this point where they rewrote their entire system for a 15-20 percent performance hit. So I think that actually plays into your point that performance is important once you scale.
BB Definitely. I've heard a lot of pushback on Angular to move to React also for this performance argument. And depending on the size of your application, if you say, “Okay, today we're going to start using React,” you're basically rewriting your entire application, so you better hope that your development time and getting everything up and running again is going to be actually worthwhile of the investment.
BP So let me ask you, what's the impact of code assistants like a Copilot or more aggressive or ambitious systems that have agents running in them and are doing full code gen? What's the impact been like for you? Are you experimenting with them? Are you actually using some in production, and do you feel like they make a difference in your work life?
BB My biggest use today is, as I mentioned, GitHub Copilot, and I've been using it since it was, I think, even still in a closed beta that I signed up for and got early access to it. And it's definitely been an impact. It's been a nice addition to your set of tools to use in your day-to-day operation. I do have a feeling that it's been nerfed a bit, because at the time when it came out, you could generate entire ReadMe pages of some person's GitHub page that it just grabbed everything out of. But I do recall when I used it when it was still in a closed beta, it was only available for Visual Studio Code and I considered switching my entire workflow to use Visual Studio Code entirely just for the purpose of being able to use GitHub Copilot because I was blown away by its capabilities. But I do have a feeling about it, I do feel that it's been nerfed quite a bit since that time for the reason that I mentioned. And that's something that you notice with a lot of generative AI tools that you see today. It gets released with a ton of features and then all of a sudden there are these issues with it, like the Google assistant that was released earlier this week that suggested adding glue to your cheese toppings to make it more stretchy and advised consuming a small rock every day for your health. It's quite capable at the start, but to probably prevent a PR nightmare from occurring, they have to tweak it a little bit day after day, and in its process, nerfed. I see a lot of –I'm going to say younger developers. I've been only developing for seven years, so it's difficult for me to say, but I've grown accustomed to Googling my things. And being able to Google what you need to do, especially in software development, is skill in and of itself and it might be that AI chatbots of today are going to be the next big thing that you need to gain skill in, but personally I feel that I'm not getting the value of it that I'm getting out of just Googling something. The Gen AI systems are confidently wrong and at a certain point you start getting more specific issues that you need solving and it feels a bit shortcoming in that respect.
RD I think the part of that Google-fu that you develop is understanding what a good source is.
BB And Stack Overflow would be.
BP I've had some unbelievable results, and what is the balance between providing me, the user, the best information right away, but also acknowledging the human who created it or the value that should go to the webpage that published it? I say, “How do I tie this fly fishing knot?” I get a six-sentence answer that's perfect. I didn't have to scroll or read anything. But if I click the link and go in, there's a full article and one important paragraph which the AI basically rewrote 99 percent of, and that I don't think is an equitable way to do content to AI from a search, but I think these things will progress.
RD I think search in general has been moving to cut out the source for a while now. Gen AI is sort of the next step of that. So you also talked about not junking your whole system to make upgrades. Do you think that's always true, or is there a point where you’ve got to cut bait and move on?
BB At a certain point, you're going to have to indeed discard what you've built up. A different project that I was a part of was a replatforming where they replaced an old Delphi code base for a .NET and Angular code base. At a certain point, indeed, you need to bite the bullet. You need to transition to a newer framework, a newer platform. At a certain point, you're going to need to be discarding what you've built up. The big advantages there was that a lot of logic was in their database, their stored procedures, so they are rebuilding on top of their existing data sets. So at a certain point, they are still keeping that layer of the stack, but I think the argument there was that it was becoming difficult to find developers for the language.
RD That's a pretty good reason.
BP That is a really interesting thing that happens. I've had some great conversations on the podcast: “We started a Ruby on Rails shop. Everybody loved it at the time. We hired a bunch of people. We built our whole code base that way. We're in big trouble now. We can't find new people. There's a few OGs out there who do know it. They command double the salary of everybody else because they're such rare birds.”
RD Are there things software shops can do to avoid that big rewrite?
BB Try to keep your code base as simple as possible. When you need to transition to something new, that is going to be a little bit less painful to do so. But of course it's difficult to have that glass ball to know where the technology is going to go. .NET has been with us for a long time, but a couple of years ago we had the transition of .NET framework to .NET core, which the syntax and everything was the same, but the underlying framework of the libraries were being replaced. And I've been on a team that was tossed with that as well and it was not as easy as it would seem out of the box. So I'd say probably going with a tried and tested framework and packages is a good start, but it does feel like, especially for web development, that every 10 years we're building a new framework. It's now React, it was Angular, before that it was jQuery. At certain points, it's going to get deprecated and need to get replaced.
RD I think it's more than every 10 years. You’ve got Express, you’ve got Svelte. Frameworks are a dime a dozen these days.
BP Hey, hey, let's not make the guest worry.
RD No worries, no worries. That's right.
[music plays]
BP All right, everybody. It's that time of the show. Let's shout out a community member who came on and, through their knowledge or curiosity, helped to spread some great info among the community. Awarded five hours ago to Jian, a Great Question Badge for asking, “How do I close a frozen SSH session?” This was asked nine years ago and 20,000 people have benefited from Jian's curiosity. There's a great answer here with 160 upvotes, so congrats, Jian, and appreciate you coming on, asking a question, and helping everybody else who has that same question find the info they need. As always, I am Ben Popper. I'm the Director of Content here at Stack Overflow. Find me on X @BenPopper. Do what Ben did– Ben Borra, not me. Email us. Tell us what you work on, what your life in software has been like, come on the show, let's chat about it. If you're building something cool, if you're working in open source, we want to hear about it. Email us, podcast@stackoverflow.com. And then of course, if you come on the show like Ben, you have to leave us a rating and a review. That much is obvious, that's just quid pro quo. But if you're listening and you like the show, leave us a rating and a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And if you want to reach out to me for whatever reason, I'm on X @RThorDonovan.
BB And my name has been Ben Borra. If you want to reach out to me, it's easiest to do so on LinkedIn, that's Ben Borra.
BP All right, everybody. Thanks so much for listening, and we'll talk to you soon.
[outro music plays]