Season 1 Episode 3 May 27, 2020

Unpopular Opinions in Software Development

Pitch

We get into our most unpopular tech opinions, wtih Kelsey Hightower, staff developer advocate at Google, including monoliths vs microservices, different languages, and even mechanical keyboards.

Description

Developers can have pretty strong opinions about their industry, and we wanted to air out our most unpopular ones, your most unpopular ones, as well as Kelsey Hightower's, staff developer advocate at Google.

Hosts

Ben Halpern

Ben Halpern is co-founder and webmaster of DEV.

Jess Lee

Jess Lee is co-founder of DEV.

Guests

Kelsey Hightower

Kelsey HIghtower is a staff developer advocate at Google.

Show Notes

Audio file size

65358910

Duration

00:45:27

Transcript

[00:00:01] JL: This season of Dev Discuss is sponsored by Heroku. Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?

 

[00:00:21] BH: Fastly is today’s leading edge cloud platform. It’s way more than a content delivery network. It provides image optimization, cloud security features, and low latency video streaming. Test run the platform for free today.

 

[00:00:35] JL: Commerce.js is a headless ecommerce platform built for developers. With Commerce.js, you can rapidly build and ship custom ecommerce integrations without needing a ton of experience or a big engineering team behind you. Head to commercejs.com/devto to sign up for free now.

 

[00:00:53] BH: DigitalOcean offers the most easy to use and developer friendly cloud platform. It simplifies managing and scaling apps with an intuitive API, multiple storage options, integrated firewalls, load balancing, and more. Get started on DigitalOcean for free with the $100 credit DO.co/devdiscuss.

 

[00:01:16] KH: So an unpopular opinion should be like computers were a mistake. Was this all worth it?

 

[00:01:35] BH: Welcome to Dev Discuss, the show where we cover the burning topics that impact all our lives as developers. I’m Ben Halpern, co-founder of Dev.

 

[00:01:42] JL: And I’m Jess Lee, also a co-founder of Dev. Today, we’re talking about unpopular tech opinions with Google Staff Developer Advocate, Kelsey Hightower. Many of you may know Kelsey through his contributions in the Kubernetes ecosystem. Kelsey, thanks for joining us today.

 

[00:01:56] KH: Awesome to be here.

 

[00:01:57] BH: We thought you’d be a really good guest on this show. We just kind of had the idea that this topic was kind of up your alley from what we’ve seen about you on the internet, but do you want to tell us a little bit about your background in general?

 

[00:02:10] KH: Yeah. I started in tech maybe about 15 years ago, big operations background, and around the midway point, I made the transition to software development through Puppet Labs, doing co-contributions to the open source configuration management project. And I guess since then, there’s been a few enterprise stops along the way, but now I’m at Google working in cloud, trying to help people adopt all of these kinds of open source technologies, including things like Kubernetes.

 

[00:02:37] JL: Can you tell us what a staff developer advocate does?

 

[00:02:41] KH: I have no idea. Right. So the HR titles are kind of funny. So I guess internally, I’m at the director level, and there’s some executive work that we do in terms of diversity and inclusion, retaining, growing talent. On the outside world, a lot of people know me for giving talks and keynotes, but I also do a lot of product work and prototyping. So a combination of all of those things, including helping our customers kind of adopt what we’re building goes into it. So you could say a developer advocate traditionally is someone who attempts to advocate for the people we serve.

 

[00:03:16] JL: Are there any projects that you’re working on right now that you’re particularly excited about?

 

[00:03:20] KH: I think all the tech stuff is kind of cool. In the last 5 to 10 years, there’s been this rethinking about how we build distributed systems and how we share ideas around them. So this whole Kubernetes cloud native space where we’re starting to standardize some of the practices different companies have been engaged in and we’re sharing it through tangible, open source projects. The things that motivate me the most though are things like serverless, right? This idea that a lot of people can focus on building and shipping applications and not necessarily managing infrastructure. And I think we have that in some areas like DNS and email that I’m really anxious for serverless to provide that same thing for general computing.

 

[00:04:03] BH: Yes. Serverless seems like one of those sorts of things that transition from unpopular opinion to popular opinion sort of like gained the sort of best practice ethos like just recently, I think, maybe in some fields.

 

[00:04:16] KH: Yeah. You could say, depending on the circle, if you’re maybe talking to an operation specific crowd, I think it’s still an unpopular opinion and for good reason. There’s a lot of lack of trust in terms of will that serverless offering be there when you need it most? Can it run all the workloads you need it to run? And the answer to any of those is no. You’re going to have a lot of people who will resist and continue to desire to run and manage their own infrastructure.

 

[00:04:45] BH: So as a developer advocate, I think part of your job is to be opinionated and to sort of help form the opinions of developers all around. What’s your sort of big picture thought about like unpopular opinions in tech? Like what is being missed? Like why an opinion that you think is valid is sort of unpopular, stuff like that?

 

[00:05:05] KH: Yeah. So I think anyone that’s building, if you are writing code or building a product, or you’re a CTO or a founder, there’s a bit of advocacy that’s part of your job, right? Getting people to understand what you’re building while you’re building it, and then to establish that feedback loop so that they can tell you what they need from that thing. And when it comes to unpopular opinions, it’s really based on like there’s like cargo culting or some people would describe this as best practices, right? This is what the majority of the people are doing, so I’m just going to do that regardless of by understanding what that is. Anything that goes against that, it could be considered an unpopular opinion.

 

[00:05:46] JL: So Kelsey, you’re a person of opinions, many of them good, and I’m really excited to hear which of your opinions you think are the most unpopular.

 

[00:05:53] KH: I think the ones that are most unpopular right now, especially where I’m involved in, like the whole Kubernetes world, right? So the Kubernetes community has been optimizing for microservices architectures. Same thing for things like service mesh, right? Things that will allow you to do things like traffic management, identity management for your applications. Both of those tools have the most value when you have lots of applications to deploy. In my holding though, mentally, I think most companies are not quite ready to adopt a microservices architecture and that’s a very unpopular opinion in my core community because microservices have so many perceived benefits, and a lot of the stuff that we’re working on is to help make microservices easier to adopt. But I still push back and say, “Look, microservices come with a tremendous amount of overhead,” and most companies should consider building what will be traditionally described as monolithic applications and get really good at that before considering a new architecture pattern that may come with a lot more requirements than what they’re currently doing.

 

[00:07:05] JL: Can we actually quickly define microservices versus monoliths just for our audience who might not be so familiar?

 

[00:07:12] KH: I guess if your engineering background, there are only services. That’s all there is. You can have one big service that does a lot of things like a calculator app, and may be able to add, subtract, divide, authenticate people that want to use the calculator. And for the most intense purposes, that’s a service. It just happens to do a lot of things. There’s one school of thought that says having all of those services in a single deployable artifact could be considered a monolithic service, right? Everything is baked in there and it presents some challenges, meaning if you have a bunch of developers, they all have to figure out how to get their code to play nice in that one deployable, and it may also constrain the number of technologies that can be used, right? Like if you pick Ruby as your programming language, then all of the other services will have to use Ruby as well because they’re going to have to tie in at the code level. And then microservices, I’m not sure anyone can define this correctly, but someone thinking about services from the microservices lens would say, “Hey, maybe we should split out, add, subtract, division and authentication into their own deployables,” and then that will give us the ability to pick different programming languages for each of those particular services. And in that case, you would say, “Maybe now I go from one deployable to four, and now I have a set of microservices. They’re smaller in scope and I can iterate on them at different speeds. But at the end of the day, they’re all services. It’s just the way you think about them architecturally.

 

[00:08:54] JL: Yeah. We’re a Ruby shop over here, and as a small startup, we are working with a monolith, but we’re not afraid to break out certain things. What sort of advice do you have for folks on like when they might want to consider working with microservices?

 

[00:09:11] KH: Honestly, I think it’s more of you’ll know when the time is right, right? Most people will start with everything kind of in maybe a single deployable, one big service that does multiple things, and when it makes sense, maybe you’re doing some new functionality that just has nothing to do with that big service that you have, great. Break it out. That might be the most natural thing to do. Background jobs, cron jobs, file processing, a lot of those services easily can live standalone. So I think most people know when it feels right because it seems like the obvious thing to do. And going in the other direction, stuffing all of that stuff in the single service that you have starts to feel a little bit unnatural and it feels like you’re forcing things where they don’t belong.

 

[00:09:56] BH: Yeah, I mean, I think that’s how we’ve had to think about it, like what is the purpose, what is the organization of our code, our community, like what are we sort of trying to get out of this to us. So we’ve leaned in. We’ve actually tried to kind of lately go as more monolithic than even before just to kind of organize things like as they’ve kind of played out. Our entire code base is open source, so we get a lot of like opinions coming in and stuff. Occasionally, we’ll get this like notion that everything we’re doing is wrong because it’s not like thinking in terms of microservices and we can’t like totally debate the criticisms in and of themselves. What we sort of have to know that like we’re sort of on a journey and we have like sort of an identity in a way we do things and we sort of have to do them kind of how we do them. It’s so contextual and that’s why you sort of need these different opinions and you need to sort of be opinionated about what you’re doing.

 

[00:10:51] KH: Right. So I think it’s important to pull on the thread of why something like this would be considered unpopular. A lot of people are already actually doing this kind of opinion already, right? And most people will feel that their infrastructure is either networking or it’s not as good as it could be. So when someone says the thing that I’m not doing is probably a best practice, it seems to be very obvious, like, “Oh yeah, something other than what I’m doing as to where I should be going.” And if I come and say, “Nope, the thing that you’re currently doing is probably a good fit for you. The problem lies elsewhere.” That’s what makes this unpopular.

 

[00:11:32] BH: Yeah. Like there’s no silver bullet, kind of like it’s the hard pill to swallow is that this isn’t going to solve your problems.

 

[00:11:40] KH: Or may make worse problems that you didn’t account for, and then you’ll deal with a whole another set of unpopular opinions because you took maybe the wrong direction.

 

[00:12:07] BH: Empower your developers, connect with your customers, and grow your business with Fastly. It’s the most reliable and performant-edge cloud platform. Fastly CDN moves content, data, and applications closer to you users at the edge of the network. It helps your websites and apps perform faster, safer, and at a global scale. Test run your platform for free today. We use Fastly at Dev and we’ve been really happy with the results.

 

[00:12:29] JL: Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that. It allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], which explores code, technologies, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

 

[00:13:11] BH: Jess, what unpopular opinions do you carry?

 

[00:13:14] JL: So I think that code can repeat itself and that you don’t always have to be dry and dry stands for don’t repeat yourself. I think that sometimes people take it a little bit too far and yeah, I think that people just shouldn’t be afraid to repeat their code sometimes because sometimes it’s just necessary. One of my favorite quotes that sort of like clicked, made it all click for me was from SANDI METZ and she says like, “Duplication is cheaper than the wrong abstraction,” and that just, yeah, resonates true with me. What do you two think?

 

[00:13:47] KH: Yeah. I think there’s limits, right? If I see a code base where the same function is copied. 5,000 times and I have to update each of those, I might say, “Wow!” We probably crossed the line somewhere, but I do agree with you that you see this represent itself the worst when people import third party dependencies. When all you really needed was to read a file from disk, but you import a one-million-line file obstruction library. Now you’re starting to get into that dangerous area where you try to remain dry at the expense of a large dependency.

 

[00:14:26] JL: Ben, what are some of your unpopular opinions?

 

[00:14:28] BH: I’m going to say that being on the bleeding edge or on brand new technology is usually a pretty bad decision and is kind of to be avoided unless you absolutely need to be. I think that’s influenced a lot of our choices in terms of just being on stuff that’s been around for a while and gradually adopting new things.

 

[00:14:50] KH: And my guess, the reason why it’s unpopular is because like for example, COVID-19, right, we’re all struggling through this pandemic and you have, I think it’s the state of New Jersey, saying, “Hey, we have this 60-year-old code base that we can’t find anyone to come work on it.” And I guess some people feel that if you’re not staying on top of what’s coming out, whether it’s on the bleeding edge or just newer than what you have, you run the risk of doing this call for action 60 years later looking for people to work on your tried and true technology.

 

[00:15:29] JL: Kelsey, will you hit us with another unpopular opinion?

 

[00:15:32] KH: Oh, this idea that you will have your own data center, your company will have its own data center and be able to buy servers and rack them and install operating systems and patch them and do whatever you want will one day go away.

 

[00:15:48] JL: Which type of companies do you think would be the last to let that go?

 

[00:15:52] KH: I think the last companies would be like your ISPs, Comcast, your Netflix’s of the world who stream a bunch of data. They’ll need the ability to control their own destiny. And in some cases, having their own footprint closer to their customer base makes a lot of sense, but that’s not necessarily the same as having a full-on data center where you run all your applications. The larger companies in the world would be some of the big, big brands that you see. But if you’re a bank, most retailers, smaller businesses, which kind of dominate at least in the US, all of those probably wouldn’t be a good fit. You can also see governments even moving in this direction. So if you think about the stock exchange or some of these shared services that we have in our lives, those kind of represent a place where people can actually transact and do work without necessarily having to replicate that on their own.

 

[00:16:48] BH: Is there anyone in the sort of cloud ecosystem that would I disagree with this? Like is this something where you’re going to get in one group of people like everyone hates this opinion. I think it’s kind of ridiculous that no one is going to be doing on-prem and then over here you’re thinking like nobody’s been thinking about on-prem anymore? Is there a group of people that are sort of like kind of in the middle and would sort of argue with that based on sort of a hand in each side of things?

 

[00:17:16] KH: If you go by it, let’s just use the US cloud providers for an example. So we’re going to try to answer this question based on their actions. Amazon, Microsoft Azure and Google Cloud, in the Azure case, a lot of their products work on-prem in the form of Azure Stack, right? You can get virtual machines, Hyper-V, and some of their other managed services. If you look at Amazon, they have an offering called Outposts where they will send you Amazon Rack to put into your own data center and connect it back into their broader cloud network and then Google Cloud has an offering called Anthos where a lot of the things that we host in the cloud will run on-premise, and then you would say, “Wow! Those are monumental amounts of engineering effort to allow and make sure that it works a lot of your cloud portfolio on-premise.” So by those actions, you can kind of see that that is something that no one sees happening anytime soon. Right? A popular opinion right now is there will always be a need for on-prem and this is why most cloud providers need to figure out how to get those necessary services to also run on-prem.

 

[00:18:27] BH: But in your opinion, it’s ultimately just not worth it and the cloud is going to swallow pretty much everything with a few folks kind of holding on until the end.

 

[00:18:38] KH: I would say today it’s definitely worth it, to be clear. But if we zoom out 10 years from now, does the cloud not innovate to the point that they could do something that you couldn’t do on your own? Right? Think about airlines, for example, probably buy a two-seater, a four-seater plane and find somewhere to park it, but there is no way many of us would ever become pilots that can fly a 747. We don’t have the infrastructure for that. So once you start to get to that kind of scale and efficiency, then I think that’s a natural evolution that most cloud providers are on. And if we ever get to that part, then it will be very hard to find economic value in trying to replicate the new standard, the new bar on your own. It will be very expensive and it may not even be worth it in terms of what you can actually get by using shared infrastructure like we do in other parts of our daily lives.

 

[00:19:40] JL: Well, for anyone listening and you are still on-prem, perhaps you should consider going to the cloud soon or 60 years from now, you might be having a call to action on who knows how to do any of this stuff.

 

[00:19:55] KH: There were reports that where people have lost servers like they literally don’t know where the server is, like someone quit and that was the last person who knew which data center they were paying the bill. So all they have is an IP address and they will call for help and you reverse engineer where that IP address is and you will find that data center and say, “Hey, I think my servers in there. How do I get it back?”

 

[00:20:22] JL: Wouldn’t it be great if there was a way for all those people who lost their Bitcoin on their tiny USB drives to be able to map that back?

 

[00:20:47] JL: Commerce.js is an ecommerce platform that is changing the way developers are introduced to and experience the world of custom ecommerce. Commerce.js sits around your code, your designs, your stack, not the other way around. This means that you can actually take full control from the storefront, to the checkout, to the receipt. Head to commercejs.com/devto. It’s free to sign up with platform wide features and no trial windows.

 

[00:21:12] BH: With DigitalOcean’s cloud infrastructure, you’ll be able to build faster and scale easier from predictable pricing, to flexible configurations, to world-class customer support. You’ll get access to all the infrastructure services you need to grow. Plus, DigitalOcean’s community provides over 2,000 tutorials to help you stay up to date with the latest open source software, languages and frameworks. Get started on DigitalOcean for free with a free $100 credit at DO.co/devdiscuss.

 

[00:21:43] BH: We asked the community about unpopular opinions in a thread on Dev and got hundreds of replies. There was no shortage of people who wanted to weigh in on this subject. Ironically, anything that rises to the top of the thread is like defacto popular, but it’s a good way to find kind of what people want to rail against. So our first response is from Brett Butell.

 

[00:22:07] BB: I think that engineers are overpaid and that a lot of the time software engineering work actually isn’t valuable and provides very little value to A, to society then B, even to companies. So yeah. I don’t know if that’s unpop or they’re not, but I have a feeling it would be unpopular.

 

[00:22:26] BH: This opinion is presumably unpopular among software engineers. They sort of have a stake in not thinking this. Kelsey, what do you think about that?

 

[00:22:35] KB: I might fall in that well-paid category. So I understand it though, because I think I delivered the most value in my career when I was able to step away from the keyboard and prevent things from being built that shouldn’t have been built, understanding the problem and then being able to communicate the why behind what we’re doing. And I think those skills, in aggregate, they’re like, “Why are we doing this? If it’s to educate a million people, there’s a lot of value in that and it kind of justifies the work that’s being done on the keyboard.” But I think there are a lot of situations where some people start with the software and then go find the problem. And in that world, I can see where someone would have that opinion, but I definitely think it’s unpopular because of the opportunity that software presents. You can solve a problem at scale even when the software engineer is gone, right? So if I write the software today and it has very little bugs or a manageable set of bugs, think about video games, for example, most video games contain bugs, but most of them are still playable. You can ship millions of copies of that application, AKA game, and benefit from years to come even when the work stops. And I think that’s why there’s a lot of value at the software engineering layer.

 

[00:24:01] JL: I just want to note that the caller wanted the audience to know that they are an engineer, in case it was just a disgruntled person being mad that engineers get paid well. So I actually can definitely see this caller’s perspective. And my assumption is that they’re referring to engineers who work in the Us or Europe because there are many countries where software engineering work is like many would consider undervalued. So yeah, I think it really depends on where you are right now.

 

[00:24:34] BH: Yeah, and I think it’s kind of this weird dynamic where like nobody is getting paid strictly based on the value that they’re providing. It’s kind of this crapshoot where like most software development doesn’t really pay off, but then like one percent of it pays off like crazy and it’s averaged out on like what people are willing to pay for, but it’s going to be interesting to see how much of software development continues to be this kind of like hyper niche field that’s kind of hard to break into and few people do it for many or whether we sort of get into this point where there’s a little bit more of a blue-collar software development type of industry or maybe that’s already a thing and we just don’t call those sort of jobs software development sometimes. But if these private companies are kind of willing to shell out the money, it’s kind of hard to stop them.

 

[00:25:29] KH: Yeah. And I think this question is also about relative to what. Right? Are teachers not paid enough? Are nurses not paid enough? There’s lots of professions that society definitely needs and definitely adds value, which may not be being paid anywhere close to what the average US software engineering salary is. I think that’s where that question starts to hold a lot more water is because we would ask ourselves relative to these other professions, why should software engineers be paid so much more.

 

[00:26:03] JL: Yeah. I mean, I think especially in this pandemic right now, like I personally have just been thinking about what is the inherent value of what I do versus people who are really at the front lines supporting everybody who’s at home.

 

[00:26:18] BH: Yeah.

 

[00:26:19] JL: Another response that popped out is from Bruno, and Bruno says, “I can still be more productive and integrate web apps much faster when using VanillaJS and jQuery in literally any JS framework.” I can say that that kind of resonated with me. So I’m not coding day to day anymore and much of the Dev code base was in VanillaJS for a long time. I think the bulk of it still is, and so I personally am just more comfortable in VanillaJS than frameworks. Like when we started incorporating Preact into the app, it just stressed me out a lot.

 

[00:26:53] BH: Yeah. When you don’t have dependencies, you sort of know what’s there and know what to do. Like if you get frustrated by build tools, I think this really resonates if you want to jump right in there and actually kind of see what’s in the file and get going with it, but this is probably about like the inherent startup time that the JavaScript community sort of has. They’ve replaced sort of get running quickly, just open up your browser, anything works with kind of the opposite situation where nothing quite works on its own and everything is like, “There’s a lot of boilerplate and startup frameworks and stuff like that.” It’s hard to say that you’re going to be productive down the road with VanillaJS and jQuery compared to literally any framework designed to scale.

 

[00:27:38] KH: Yeah. For me, it’s how many browsers do you have to support? And that’s where I saw the power in some of those frameworks alone, just working out the differences between the various browsers. And I think that’s been the biggest challenge. So if you’re very skilled in JavaScript and you know how to do that already or you only have a limited set of browsers, I think that probably could be true. But I think for a lot of people, the frameworks kind of represent all of those sharp edges, kind of hidden, attempting to give you a different dialect so you can focus on the thing you want.

 

[00:28:12] JL: Yeah. Speaking of the dialects that different browsers need, Christina wrote in, “Well, all they wrote him was Firefox greater than sign Chrome. Implying that they prefer Firefox over Chrome and then somebody else, Josh, from our team who is a full on Apple person jumped in and said that Safari is a great web browser.” What are your preferred browsers?

 

[00:28:35] BH: As a paid Google employee? Let’s see what the answer is.

 

[00:28:37] KH: Let me see. My non-bias opinion is Google Chrome. To be honest, I was using Chrome before joining Google because there was a point in time when Chrome was the underdog and Chrome’s philosophy, and it still holds true today, is around a lot of these web standards and a lot of those web standards I think Chrome really pushed forward in favor of things like Flash and some of the other technologies back then, ActiveX being another one of those, and I think Chrome did a decent job of keeping their momentum high so much so that like Microsoft has even re-platform their browser on top of Chrome. So I would probably say just being a Chrome user for so long, I have an affinity towards it.

 

[00:29:21] BH: I once made a tweet that said nice things about Safari and discovered quickly how unpopular that opinion was. It’s kind of a hard conversation because we want to support browser diversity. I think there was a lot of heartache when Edge went with Chromium. Whether or not that was like immediately better for the end user, probably was, but kind of hard to separate sort of like opinions from like the underlying ecosystem and stuff like that, like what people want the web to be like. I’ve recently adopted Firefox from Chrome when I changed computers thinking I wanted to try something new. I thought it would also help me gain more awareness about the different ways different browsers react kind of as an end user to get like, “So I don’t just do it when I’m testing stuff,” I’ve been really happy with Firefox. I really hope it continues to progress, continues to do well. I hope it succeeds and he’s finding users and maybe being the more like the better choice for a lot of folks while Chrome is still kind of really well positioned and really well built and thought out and obviously has Google behind it.

 

[00:30:37] KH: I will admit though, I do use Safari when reading on the web, right? They have a little button you can click that just hides everything unless you just focus on this kind of minimalist like set of texts and you can just read.

 

[00:30:51] BH: Christina also essentially said the same thing as Bruno in the CSS world. They said that CSS, especially Flexbox or Grid is a hundred times easier than figuring out bootstrap or other frameworks. And I think that’s kind of pretty easy to agree with as well, except with the caveat that you’re also going to give up a lot of browser support in doing that and kind of the same argument, Kelsey, you were making on the JavaScript side.

 

[00:31:16] KH: Yeah. I found myself about two years ago struggling to center a website still. I don’t know if that was more about me or the state of web design, that that is still a thing that isn’t super obvious on how to do.

 

[00:31:33] JL: Well, on the note of CSS, Ben Holmes wrote in and said, “I prefer writing raw CSS to using Sass.” Yes. I’d rather lose nested styles and mixins over adding an extra second to my build time. Sue me.”

 

[00:31:46] BH: So far like all of these opinions are just a radical backlash against building anything.

 

[00:31:55] KH: So an unpopular opinion should be like computers were a mistake. Was this all worth it? Right? If we were to have a retrospective and say, “Was introducing computers to humanity worth it?” And I think that would be unpopular because so much of our daily lives there’s a computer involved, and I think that’s where you start to get into something that has enough meat on it to kind of debate and probably, yeah, that will probably be unpopular if you went around and said, “All right, we’re taking all the computers back.”

 

[00:32:29] JL: That’s an extreme one. Very difficult to imagine the world as it is today without computers. If we’re looking for more extreme opinions, Diane wrote in and said, “Swift is one of the worst languages with a hardly functioning tool chain and a language full of inconsistencies and it lacks a shit ton of basic features. Objective-C, in comparison, is much cleaner and well structured.”

 

[00:32:52] KH: Yeah. Tell them how you really feel.

 

[00:32:56] BH: This is funny to me because I feel like this is a perfectly fine opinion to have because arguing about languages is kind of like the essence of like opinions. But I’ve tried hard to write Objective-C and I can’t make it work for my brain and Swift seems just easy. Regardless of it’s like properties, it just kind of gets the job done for me, and I really have to think that that makes it a good language. And my issues with Objective-C seemed to be just like centered around what other languages I’ve written in and how it just looks different and it’s kind of weird, but I can never get it to click.

 

[00:33:36] KH: Same.

 

[00:33:37] BH: Here’s one for Kelsey. “Docker and Kubernetes are not solutions to your scalability problems.” That’s the whole comment.

 

[00:33:44] KH: Oh, I liked this one because this is unpopular with me. It is probably alone, not the solution. Agreed. But for a lot of people, if you ask yourself a very honest question, what are you actually building? And without Kubernetes, you’re probably building something like Kubernetes or some distributed system and it’s probably not following any particular design, and it might be based on not a lot of experience. So Kubernetes design solves the scalability of the deployment workflow, but it will definitely not solve like your app is slow. Yeah. Kubernetes will just deploy a slow app. Right? It’s not going to turn your thing into a faster application. Right? It can’t do that because there’s a line there between the data your application receives and the fact that Kubernetes placed your application on a particular server. And I think that’s where you have to decouple things. But for a lot of people, there’s other parts of dealing with scalability, like knowing how to easily scale something horizontally. So if your app, even if it’s a monolith, if you can handle, let’s say, a hundred requests per second and you’re really struggling to build infrastructure tools that allow you to go from one VM to let’s say 50, then for some people in that situation, having Kubernetes kind of run on top of maybe 10 machines might give you better tooling of giving you that horizontal scale situation in a more consistent way than writing a bunch of scripts or bringing in maybe five or six different tools to attempt to do the same. So this is why I think a lot of people, even if their code didn’t get any better, they felt like bringing in Kubernetes, gave them this perceived value of, “Wow, I can now manage to scale horizontally.”

 

[00:35:43] BH: Yeah. I got to think this is the kind of opinion which Bavani is sort of sharing, like at someone else they’ve been in an argument with because they’re trying to use Kubernetes wrong or something like where if everyone was kind of on the same page about what the whole purpose was in the first place, they wouldn’t have disagreed on the scalability issues.

 

[00:36:01] KH: Yeah. There’s a lot of people. If I asked, “What is Kubernetes?” And they draw a blank. So it really hurts the rest of the argument, right? If you think Kubernetes is like an application platform that will change the way you write software, it’s not quite that and that’s why I think a lot of people, if you go in with that expectation, you will be definitely disappointed because you still have to write the software yourself.

 

[00:36:25] BH: I think once technology has transcended to the point where like most people know the name, but there’s still a lagging of kind of people using the software or like actually kind of understanding the problems they’re facing, like it becomes this kind of namedrop syndrome and Kubernetes definitely is sort of ripe in that territory.

 

[00:36:45] JL: So this next one is from David Eddy, and they wrote in, “There is no such thing as junior dev ops.” I thought this was really interesting because when I had just gotten out of the bootcamp, I had a fork in the road where I was working as a product manager, but they were looking for an additional person on their dev ops team, and I had the option of going down that route, which was really enticing at the time because I didn’t really feel like there was anywhere you could learn dev ops, like that’s not something they bring up in bootcamps. So yeah. I’m curious like what it would mean to be junior dev ops and whether or not you all think that’s possible.

 

[00:37:23] KH: So I actually have a different opinion. There’s no such thing as dev ops, but I will say that one for a second because what does that even mean? I think there is going to always be a place for people to start that has to remain universally true or we’re in trouble. So that to me is kind of this kind of gatekeeper philosophy, right? Like if you’re not as good as I am, even though I got to be a beginner once, you don’t, like that doesn’t make any sense. That doesn’t really add up too much. Maybe that’s not even what they’re saying, but I think when you start to think about when we use this term dev ops, there’s a lot of skills that go beyond technical abilities, and a lot of them are based on experience, right? Like how to communicate, how to work and collaborate with others, and all of those skills I do believe can be taught and learned if you’re willing. So when you’re new to the field, the hard part is being able to contribute at whatever the expectation is of all of those attributes on day one because you may have never done it before, right? So you’re going to have to ramp up a little bit. And the thing that I do see a lot is there are people who have been practicing “dev ops” for like 10 years, and they’re still at the junior level. They’re not actually good at it. They just have been doing the same six months’ worth of experience for 10 years. They download a bunch of software from the internet that have dev ops somewhere in the mention and believe that you can solve a lot of this with tooling, but they may not say that directly. They may say it’s about all of these other things, and you ask, “Are you doing those other things? Are you even good at those other things? And show me the results.” And a lot of people in our industry struggle with the results part. In that case, it’s a person that has 10 years, 6 months’ experience.

 

[00:39:16] BH: Yeah. It’s hard to tell what exactly the next part of this comment is, like what does it mean that there’s no such thing as junior dev ops? Does that mean like if you do dev ops, you’re not junior just because you’re doing ops and then you kind of have to be doing something that touches operations? I don’t know. But the ops part of dev ops is also context specific like solving company problems, like doing ops the way the company needs it to be done. On that level, like we have a team within our small organization called ops, which doesn’t have anything to do with dev. It’s just like organizing the team and doing operations and stuff. I feel like the folks we do that kind of work, they’re like one step away from being able to do dev ops if they just kind of want it to be oriented that way because it’s so based on like organizational structure. So I don’t know exactly what they’re trying to get at here, but I see the kind of ops thing as just the function of how the organization solves problems at all. As we grow, it seems like it’s more and more ops and less just strictly product and stuff like that and even strictly kind of the dev side of things. It’s like an interesting thing I could see like any kind of path into ops and it’s definitely a lot less clear than into sort of other parts of development.

 

[00:40:39] KH: Yeah. If you just drop dev ops and this designation of what junior means, then you can actually get somewhere because, like I said, junior does not really mean much other than I hope someone that’s willing to learn and is honest about what they’re learning in a particular area. I think sometimes we use a blanket statement like this person is just a junior in life. There are some people who have lots of other valuable experience, but they’re learning a new technology and that doesn’t represent the whole person.

 

[00:41:11] JL: Yeah, absolutely. I could not agree more with that statement. Let’s wrap it up with this next response from Nadia. They say, “I will make tons of enemies with this statement, but for me, mechanical keyboards should be banned from offices. In my dev room where up to 20 people, and 19 of us, so not me, have a mechanical keyboard. The noise is very annoying, especially when my fellow coworkers go berserk and start to tap on those damn keyboards at the speed of light. I put my headphones on, but I cannot listen to loud music eight hours straight every day. So please, I don’t use mechanical keyboards.” So I have to ask, do either of you use mechanical keyboards?

 

[00:41:52] KH: I doubt that my best friend does, and I was, based on this opinion, a victim of said a mechanical keyboard for a number of years, and I think this is really more about are open offices being a bad idea, right? Because if we all had doors that could close, maybe a little bit of soundproofing, I don’t think we would care too much about the mechanical keyboard. But since we’re in this open office configuration, we get a lot more of this. And yeah, it’s kind of bad when I’m trying to think or read some documentation and then I hear this typing competition happening between two cubicles. It’s like, “What? What’s going on?”

 

[00:42:31] BH: I use a mechanical keyboard from the comfort of my home. I don’t really fully buy like why I need to use it. I actually just took it from someone else’s pile of keyboards when mine broke, but I like it. It gets the job done. It is loud. I’d be happy to give it up if people complained. I work from home. Nobody has a big problem with it. But mechanical keyboards definitely have a huge fan following. It’s hard to draw people away from them and there’s the personalization aspect. That’s pretty cool.

 

[00:43:02] JL: Well, I am an owner of a mechanical keyboard, proud owner of an Ergodox, and. I bought it for ergonomic reasons. It’s one of those keyboards where it’s cut in half and it really helps me. It helped my carpal tunnel, like if you look at a keyboard, it’s not very wide. And then if you look at like just your shoulders, you kind of naturally have to hunch in if you are not able to just have it be like right underneath your shoulders. I feel like having this ergonomics has helped my posture in general. But also, yeah, it’s really fun to have like led lights and it lights up and it’s a great party trick, but I haven’t done the full custom setup on my own. And I don’t know if I’ll ever get there. But for Nadia, I almost wonder, great point on the open office layout, and yeah, if this is such an issue for their productivity, it might be worth just talking to the organization about it a little bit. Maybe they can find a different area or something along those lines because it sounds like they’re unable to communicate their frustrations right now.

 

[00:44:12] KH: Treat it like smoking, designated areas.

 

[00:44:15] BH: Well, thank you for joining us, Kelsey. This has been a lot of fun.

 

[00:44:17] JL: Thanks, Kelsey.

 

[00:44:18] KH: Awesome. Thanks for having me.

 

[00:44:28] JL: I want to thank everyone who sent in responses. For all of you listening, please be on the lookout for our next question. We’d especially love it if you would dial into our Google Voice. The number is +1 (929) 500-1513 or you can email us a voice memo so we can hear your responses in your own beautiful voices. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, please email [email protected] and make sure to join our Dev Discuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on Dev using the #discuss. Also, please rate and subscribe to this show on Apple Podcasts.