Adam Gordon Bell is back on the show again!  Today he shares his views on language tooling, new articles he has recently written, documentation for Ruby, software consulting, and insights into other programming topics.

Hey there folks, welcome back to another episode of the Ruby Rogues podcast. I'm your host today, Valentino Stoll, and we're joined by our co-host, Luke Stutters.

 

Hello.

 

And we have a special guest today, Adam Gordon Bell. Adam, why don't you introduce yourself and tell us a little bit about why you're joining us.

 

Yeah, thanks for having me. I'm super excited to be here for a second time. I must have done something right the first time, I guess. Um, yeah, so I'm Adam. I, uh, I also have a podcast and I work for this company called Earthly that makes an open source build tool. I think I'm here to talk about some of the writing I've done in the past about, about programming, uh, languages and software development. Yeah.

 

Yeah, you know that we discovered kind of two articles that you came out with recently, the slow march of progress in program language tooling, which is incredible. It's a hot topic in the Ruby community, getting our tooling up to speed kind of with some of the other languages that are out there. And another article that you wrote on the other kind software engineer, which is

 

Yeah.

 

kind of an amusing title, but I think is a great breakdown on what it means to be a staff software engineer and how that kind of differentiates from a, as you put it, a line software engineer. And we could dig more into that. I'd like to focus for now on the language tooling because it's a super interesting topic. kind of give a quick like high level, what are we talking about when we are talking about, you know, language tooling, and what

 

Yeah.

 

are some of the items that you maybe focus on.

 

Yeah. So, you know, the, the stock overflow does a survey every year of what tools people use and whether they like them or not. And one of them is they ask what programming languages you use, uh, regularly and then whether you want to continue using it. And then they kind of piece this apart into what they call like loved languages and dreaded languages. So. If you use it, you know, every day and you don't want to continue using it, it's dreaded. And if you use it every day and want to continue using it, then it's loved. And the list, you know, kind of changes over time, year by year. But I guess the big thing that you would notice looking at it is that newer languages tend to be loved and older languages, uh, tend to be dreaded. And Ruby at some point was like one of the new loved ones and has drifted into the dreaded category. So I started thinking about this issue and started asking people some questions about what they liked about languages. And a lot of it was just the tools, not the syntax of the language, not the way you could do things concisely here or the way that this language looked versus that language. A lot of it was just tooling. Right. And so if you, if you think about an older language like C plus plus, which has been in the dreaded list on Sackoverville for a long time, it doesn't have a lot of the built in niceties of, of newer languages. There's no like equivalent of Ruby gems or actually there's like eight equivalent of Ruby gems, which is like actually worse than, than just having one. And like, nobody can agree you know, like standard way to put documents, documentation in your code. There's a more limited standard library than some things some people might be used to. So the article is about this. It's about how newer languages get to kind of take a fresh crack at what the tooling around a language looks like, which is much easier than bolting it on after the fact. That's what you got out of it as well.

 

Yeah, I totally got that out of it. And one of the biggest things that jumped out to me to kind of put this in perspective was Go's auto formatter,

 

Yeah.

 

which there's kind of like the Ruby auto formatter that you can use that kind of goes along with RuboCop, right, to auto format code based on styling rules. I would love to see that. But if you've never worked in Go before, that is definitely something where, you know, your code is just magically formatted right to work. And when you get it at that level, it's, you know, you make a lot less typos. Because

 

Yeah.

 

you get that instant feedback, right, where it's like, oh, it's not formatting, right? Like something must be wrong, right?

 

Yeah. And because like Go format was put out along with the language and it has like no knobs that you can turn. It's just like, this is how you format the code. Like there, nobody, it's not a discussion point, right? Like I, I assume the, the Ruby formatter I haven't used it has a lot of knobs that you can tweak and not everybody agrees with all the standards. And it's hard to add something like, like Go format retroactively, right? that there's all these code bases that exist and don't conform to it. So like nobody, no programming language that existed before Go format will get the like 99.99% code format compliance that the Go now has with all their open source code.

 

Yeah, yeah, for sure. I'm trying to think of, I'm not really sure what Ruby's, targets are as far as their tooling goes, what's missing. What's something that jumps out at you as far as what could we do better as, the Ruby community to make some of this tooling better? I mean, package management is definitely one thing, I think resolving, with Bundler historically has been problematic, which has gotten a lot better over time. But what are some thorns in your side?

 

Yeah, I mean, I got to be honest, I don't write a ton of Ruby day to day. So it's, but like, you know, you mentioned, um, like code linting, right. And if you, if you look at, at go or rust, like they have the linters built right in, you know, to the, to the tool, you use cargo to compile your code, but it can also provide linting options. Um, not to say there's anything wrong with having a tool that comes off the shelf. Uh, sorry, not to say there's nothing wrong with having a third party tool that to grab and download and configure, but it's so much easier for a new person when from day one, like the linting is, is built right in, you know, to the package manager or to the compiler. Um, and, and has same defaults that you can agree with. So I would look at taking a lot of the tools that people use, um, to the side and finding a way to kind of roll them all into, you know, into the tooling around the language. It's weird. I find that I feel like there's not good names for this, right? Like Cargo in Rust, you know, like it'll run your unit tests. It'll do linting. It'll suggest things. It'll do code formatting. Um, you know, it has fuzzing capabilities or whatever, right? So what is that? Is it a package manager? I don't know. It's kind of like all of the little things that you want to do with your language rolled into one and a lot of other languages, these are, these are secondary things.

 

Yeah, I'm trying

 

I have

 

to think of all the ones. Go ahead, Luke.

 

I have worked with a very disgruntled Ruby developer who moved to JavaScript. And one of the things he cited about why he liked moving to JavaScript so much was that he could add an automatic code formatter and mentor to his Git pre-hooks. The reason why this caused him so much joy is that he used to continually fight with his fellow Ruby developers code

 

Yeah.

 

on commits and I will say that it's not just the fact that you can reformat the code, it's the fact that there is now an agreed way of formatting the code. So it's not so much that the tool exists, it's that you no longer have to fight your colleagues about it.

 

Yeah, it makes a huge difference on like PR reviews and stuff. And like in the article, I talked about Python. And I included like an XKCD comic where like, you know, you have like, pip install, and then you have like, py environment and the conda and like all these different tools just to get the right dependencies in place. Like that's another example, like code formatting where, you know, when something straightens that out, like, why do I have to to tell things what version of Ruby to use all the time. Like these are all little paper cuts, I guess. Like I guess the sum of the article is like all these little paper cuts add up to make people kind of not like the onboarding process. Oh, I cannot hear you, Valentino.

 

I'll say the first time I worked with Go, the setup was painful.

 

Ah, there

 

And,

 

you go.

 

and mostly it was, you know, the specific directories that everything has to be in as a language, right? And even where you're working from within, like has to be kind of like bundled with the language, right? Like,

 

Yeah.

 

that was hard to wrap my head around that, like to get it to work, right? Cause I wanted to work where I wanted to work.

 

Yeah.

 

just like no.

 

Yeah, with like the go path, they

 

Right.

 

like they have changed that now.

 

Okay.

 

Um, yeah.

 

So I mean, there's an example though, right of, you know, making the tooling better.

 

Yeah.

 

But

 

I could see like Ruby gems, somebody in one of the comments mentioned like Ruby gems, you know, in terms of the length of the existence of Ruby, it was added fairly late in the game, but that, you know, great addition, right? Makes it like it wouldn't be the same language without it.

 

And I mean the same with Bundler. I remember the days of rails and you inlined all of your gems

 

Yeah.

 

in the configuration files. And there's kind of hope that it worked. Yeah, there was no pulling from a central dependency resolver. Right?

 

Yeah, maybe that's what the person was talking about. Sorry, I can't keep everything straight in my head here.

 

It's hard to keep track, right? Like it's kind of funny to think about now. Like if I were to restart Ruby, I feel like I would have an easier time onboarding, I would

 

Yeah.

 

like to think, right? Cause there have been so many improvements kind of to these things where, okay, like I can just run Ruby right away. There's Ruby build, which is a great tool to just install Ruby right away, no matter what platform you're on. And it's great. It works every single time. And, you know, I struggled so many times to install Ruby. Like when Ruby version managers like started becoming a thing, like that was a new challenge, right? I feel

 

Yeah.

 

like, you know, and I feel like every language goes through these pains, right? Like you'd think that there would be a defined path. Okay, like if you want to make a new language, like, you know, these are things that you got to like make sure you have an order, right? Instead of kind of like, all right, language, like, we'll figure it out as we go, I guess, right?

 

Well, I think like a lot of it is things get added on later. Like there's innovations, right? Like, yeah, like a code formatter wasn't a thing that people worried about when, when Ruby came out. And like when C plus plus, uh, was, you know, in its early days, there was no such thing as like, uh, you know, a third party package manager that you needed to have integrated and it's just, it's hard to add these things after the fact, cause things work, you know, you work in this environment and you just understand like, okay, this is how you do things. Uh, so like the standards always moving, I guess is what I'm saying, but, but I'm interested to hear like, what do you think, um, is, is the tooling holes that are the areas that should be polished in Ruby?

 

That's a good question. I mean, getting Ruby on Windows is still a bit of a challenge. I know it's kind

 

Oh

 

of

 

yeah.

 

just been like, it's still, it's been a constant battle, I feel like

 

Yep.

 

over the years. And it's definitely a barrier to entry for people just starting out, right? Like maybe they just wanna get a Chromebook and try and run Ruby. Or Chrome is a bad example, but you know, of a Chromebook, you know, just something, a cheap machine that you just want to try starting on. And it's hard to do that, which I'm hopeful that kind of this WebAssembly stuff can fix a lot of that problems starting out, right? Where you could just visit this webpage. And I think that's how tryruby.org works now, where

 

Oh,

 

you

 

what?

 

can, you can just go to the browser and try to play with Ruby just in the browser, which is pretty cool. But, you know, it's limited to dependencies. You can't just install gems, right?

 

Yeah.

 

So I feel like that multi-platform issue will continue. I'm trying to think.

 

They should just put the whole of active support into Ruby Core.

 

I feel like it's like whenever somebody's learned, like if you get a chance to try to teach somebody, you should write down all the things they struggle with because you become blind to them, right?

 

Yeah.

 

Like you miss them.

 

I know that the documentation is a common one that comes up, right? Like, because there are so many different documentation websites for Ruby that it's hard to follow, like which one is the official one. And then there's the new, like, Ruby API site, which is like kind of like a fresher user interface for the documentation. That's pretty nice. heard that maybe that is going to be the official, you know, don't take my word for it. But it's that is still unusually a hard part of the language, right? Is like, you go and you Google search, and, you know, there may be three different sites listed on the first page of the Google results, right? And you don't know which one to pick.

 

Yeah.

 

And you just hope that, you know, the first one works. And a lot of times, you know, result will be an older version of the language that is that first pick, right? So I feel like discoverability for documentation is definitely a hard problem to solve specifically for Ruby. It seems that this time

 

Yeah, that's the hard one too. But, but so key, right? Because you want people to be able to solve their own problems. Yeah. But yeah, I think

 

Right?

 

one of the

 

central.

 

things. One of the things you wrote about Adam in your article was the idea that if you have a standard documentation system, you can link that into an IDE. So when you kind of mouse over, then you can kind of just instantly see what all the parameters are to that method and what it does. And yeah, I hadn't really thought about that before, but that is an incredibly powerful tool when you're just starting to work on a code base.

 

Yeah, like for discoverability for sure. And then yeah, like having a central website is useful too, where if you're like, you know, every package, you know, we're going to generate docs for it and throw it on this one website in a familiar format, um, that's also super helpful.

 

I did see recently, I feel like it was Koichi that gave a link to displaying something like this in an editor where you could just hover over and it would show you the, you know, RubyR docs for whatever method or class that you're in. I feel like that's hopefully coming soon. There's a, I don't use VS code enough, but there's a lot of plugins out there that I think can give that.

 

Oh, I've got another thing to say about Ruby documentation too. All right, you got me started now. Here we go.

 

Ha ha

 

So

 

ha.

 

I'm using some like gem, okay? And I'm in the R doc. I'm like, okay, what's going on, right? Let's have a look, click on the R doc. And on the left-hand side of the page is an enormous list of classes, which I will never touch, which no one will ever touch. They're all just kind of total implementation. No one's ever gonna touch that stuff. But the whole left-hand side of the screen right? You know what I'm saying? Yeah? And you're looking at this kind of massive list of classes thinking, oh my word, I don't know what's going on here. Where do I start? You know, where's the entry point? Which of these am I actually going to use? So some way to kind of tag those up and say like, you're never going to do this, you know, hide all of these, put all these right at the bottom of a list, you know, you only want these four to use this library. That that would save me a lot of time.

 

Yeah.

 

So some kind of meta tagging in documentation. Now, I'm not sure if I've seen it in another language. So this isn't, I don't know if that even really exists. The idea, you know, where you say, yeah, this is a kind of implementation. These are the ones you want when you're actually using this thing. I don't know if that exists in Go or anything else.

 

But this is where innovation happens, right? Like if the Ruby community thinks hard about that, it does a really good job of it. Then, you know, people will be leaving Ruby and ending up somewhere else and being like, why isn't there a way to highlight, you know, what the main things in the docs are, right? And then it will spread.

 

I know you're supposed to look at the tests, alright? I know I'm supposed to look at the tests, but believe me, that doesn't always help.

 

Yeah. of valentino i see your lips moving but i can't hear you Can you hear him, Luke?

 

No.

 

I don't know, is it? Am I just not able to hear you guys?

 

I'm sorry about that, I had a phone call come in from the kids daycare.

 

Oh no.

 

Oh, that's okay. I thought I was missing something. That's fine.

 

Ha ha. Uh, anyway. Uh...

 

Are they okay?

 

Yeah, they're all right. We can edit this out, but my son brought in too much money to his trip today, and they were concerned that he had a lot of money with him. I don't know. I don't know where he even got it from so...

 

Oh

 

Anyway.

 

man.

 

I don't know.

 

Um, where were we? Uh, programming tools.

 

I was proposing a system of a semantic documentation.

 

Yeah, let's do it.

 

Yeah, I would love that.

 

I think anything that makes it easier for,

 

I mean,

 

you know.

 

there's been so much work with the parser lately and the Ruby grammar. I feel like being able to pipe that into, you know, some new tool should be easier this day and age where it could just, you know, automatically pull from source locations kind of thing. I don't know. I feel like maybe there could be something there.

 

Another big thing that came about that wasn't covered in the article, for those of us who use VS code like me, is the LSPs, like the Language Server Protocol. Is that what it stands for? I think.

 

I think

 

I didn't

 

so.

 

really understand what that was, the LSP. What is the LSP?

 

So Microsoft came up with this idea for, I guess, solving the IDE problem. If you think of it, the text editor slash language problem is if you come up with a new programming language, you need to add support for it to like all these various editors that people use. So like, if you use a heavy IDE with like refactoring support, you know, that support needs to be built into that whatever, IntelliJ or Visual Studio or whatever. So it's kind of like an N times M problem, right? Like every Visual Studio needs to know how to do all these things for each language. So to kind of cut this knot in half, they came up with this language server protocol, which is basically a protocol where your compiler or can tell the editor about the code, right? Tell it like, you know, where the definition of this is and things like that. So that way, if you build a new editor, you just have to support the language server protocol. And if you build a new programming language, you just need to support the language server protocol, like on the emitting side. And then every language and every editor can work together.

 

I feel like I saw something recently where somebody was doing inline Ruby evaluations. So you could see, you could just open up any Ruby file and you could see line by line what the code evaluated to kind of in a sidebar. And I thought

 

That

 

that

 

is

 

was

 

cool.

 

pretty neat. Because that instant feedback you can get anytime, that's kind of the power of the Ruby console, right? But it'd be nice to just like open a file and get that right.

 

Yeah, I don't think LSP goes that far, but yeah, Shopify has built like a Ruby LSP that I assume there's probably a VS code plugin you can use with it to get some nice, you know, like go to definition type features. But because Ruby came after the LSP concept, right? It's not like built into the compiler where in some newer language, they might just like, you might just ship with LSP. all the like parsing of Ruby and send this through. It's like some things are just harder to add after, right? It's like when you build a

 

Yeah.

 

house, it's like, it's easy to put in that gas line when there's no walls, but then once there's walls, you know, things become a lot more complex.

 

I think two of, you know, standards that get put in place that aren't official, right? Like

 

Yeah.

 

for Vim users out there, like Tim Pope's, like Vim Rails is like the de facto standard for like finding the definition of something within a Rails framework. And so you can like open up a model and a controller context that's related to it. There's just a whole bunch of extra things. And so like for people that have been around Rails a while, you know, you just, you know, and that are Vim users, which is quite a few people, right? You get all these standards in place, and then for new things to come about, it's like hard to kind of change your behaviors. You know, the longer you're around, the harder it is to change, right? And I feel like that's kind of the problem that Ruby is into now, right? Where we have all these people that have been around with the language for so long that are working on this tooling that have, you know, adjusted kind of to those, you know, ways of doing things that, you know, maybe aren't people, you know, new to the language that are using, right? So you get a lot of people using VS code as an example, where, you know, maybe some of the older people in the Ruby community aren't using VS code or aren't using some of these other tools that they would be missing out otherwise. First, how do you discover about them other than, you know, scouring Twitter or something like that and hoping that you pick it up someday, right, or from a co-worker? And second, like how do you readjust your whole way of working with the language, right? Like

 

Yeah.

 

it's definitely that's a hard problem to solve

 

Totally.

 

I don't have any answers.

 

got a fun one for you. At what point does a language become unfixable? Because that's the implication here, right? At what point is it too far gone that you just got to kind of throw it all away and start again just like they did with Python 2?

 

Well, the interesting thing to me is that like all of this stuff is actually not a technical problem. It's all actually a community problem, right? There's no reason why, you know, why it will be hard for, for, you know, wide adoption of the Ruby code formatter to happen, but it could happen. Like the limitation is everybody agreeing on a standard way to format the Ruby code. exists, right? Like it's just nobody, it's less common in usage, right? Or in C++, where they have at least eight package managers, like they could all agree on one. The issue isn't they don't know how to build a package manager, they keep building them. It's that they haven't come together to say this is the one. It's a community problem. And sadly, these are the hardest things to address, right? Because you can't just crank out some technical solution, you need to get everybody to agree.

 

It's kind of funny too, because people use languages in so many different contexts, right? Like, you know, everybody's not just a web developer, right?

 

Yeah.

 

Like, are people using Ruby for mobile development, right? Like, or like embedded systems, like so many different kinds of applications and contexts. And how do you like make core concepts like the same for all those different contexts where you even have completely different environments sometimes, right? different workflows. I totally understand the Ruby core's hesitance on a lot of features.

 

Yeah.

 

Because so many features just don't make sense in so many contexts. And to focus attention or change things too dramatically, you can collapse the entire ecosystem with the wrong decision.

 

Yeah. And if you look at it's, if you look at the, you know, in my article, I mentioned Go and Rust a lot because they've put a lot of work into a lot of tooling, but they also have a lot of resources comparatively for programming languages, like, you know, Go is coming out of Google, Rust had, you know, Mozilla support for some time. Like this is a lot of work doing all this stuff. Like that's the truth of it.

 

Yeah. I mean, I'm trying to honestly thank goodness for the amount of, you know, money that Shopify is pouring into Ruby. You know, especially recently, I hate to, you know, with their huge layoffs recently, I hate to talk too much in positive light. But they are doing some great things, right. But, you know, we all we need more. more people you know funding and and uh propping the languages up right uh i don't know if you know go would be as popular as it was if it didn't have something somebody like google saying you know sponsoring it um or if it was just like some third-party organization non-profit right if it would also uh have the same effect which maybe it is now but uh It's kind of funny to me to see what becomes popular of languages based on who's funding it, right?

 

Yeah.

 

Because there are so many smaller languages that a lot of people use, too, right? Like Lua as an example,

 

Yeah.

 

or what was that one with the Z? Zig, right? alternative if you will as

 

Yeah.

 

far as applications, right? So it'll be interesting to

 

Yeah.

 

see what else comes out is kind of what I'm getting at, right? Like there's a lot of big companies out there, right? Like that all want to, you know, take advantage of the next thing.

 

Yeah.

 

I'm kind of interested to see what will come out of it. Or if, you know, because once you've, let's say that, you know, a program lineage has made all the tooling the most incredible thing to use, right?

 

Yeah.

 

You know, people get tired of it.

 

Yeah, so

 

Right?

 

previously, so previously I wrote this article called like Brown versus Green programming languages. And it was about this topic where I said like, you know, when you are working on like, so it was about the same thing, the Stack Overflow developer survey and about maybe a possible different answer, which is that people like to use new programming languages because they don't want to work on their old code bases because they're a mess. It might be great fun to work on a new Rails project, but if you have one that's super old and has not been given the most care, like you might think differently, right? And how much does that rub off on the language, right? If you're doing a new project, if you're working in Zig, you're probably doing something new because it's a fairly new language, right? So you might not have all this old code that you have to worry with. You

 

What is dig?

 

might. What's Zig?

 

What is sick?

 

Oh, it's a cool new programming language. It's like close to C, I guess. It's like a modern take on C development with like, you know, raw memory management.

 

I know when they were... when they're trying to merge the new, what was it? The word is escaping me, but... new compiler or not compiler but uh

 

Purser.

 

parser maybe for Ruby. Oh, man.

 

Grammar?

 

Why JIT? The new

 

Oh,

 

JIT. So

 

yeah, yeah,

 

they're

 

yeah.

 

trying, right? They're, they were trying to figure out whether they should use Rust or and they were considering Zig, right? Like,

 

Yeah.

 

for their practicality with kind of extending C for more like higher level abstractions, right? Because that's one of the biggest problems with C is you don't really have that like class structure that and make it a little more modular. And so I don't think Zig had the maturity that it needed at that stage, but I know it was in kind of close consideration.

 

Do you want to talk about the staff software engineer article?

 

I do. I'm curious what a staff software engineer is. I know

 

So

 

you, you,

 

that.

 

you, the article does a great job of kind of summing it up, but I kind of, I, I love to make fun of titles. I feel like everybody is just, you know, that the word engineer kind of in, in a software title, you know, I get a lot of, my wife is an engineer, a

 

Ha ha ha.

 

So, you know, anytime that I say engineer in my title, you know, I didn't go to engineering school, right? Like, I don't know engineering principles, like, I know software principles. So I'm curious, you know, what what to you as a staff software engineer, or staff software developer, if you will.

 

Well, so this is the aspect of the article I got the most feedback on. It wasn't positive feedback, but

 

Ha!

 

like, so in, in big tech, there is a role above senior that it's called staff. And, and so, yeah, it's just like a, you know, a, a step on a higher, you know, hiring ladder or whatever, right. But, um, so I wrote about what I called the other type of staff engineer, which When I was in school for software engineering under the computer science school, but don't tell the engineers about that one. But I had to take a class in the business school at university and it was like this management class and they talked about like staff versus line employees, which was like a traditional way to think about people's roles within companies. So basically it's a different meaning of staff. might work on the line assembling the car, or you might be staff. You might work in the office somewhere. You might do HR or accounting. And it's true for every business. You either are in a supportive role or you're actually like building or selling the product or service that the company makes. So, I was trying to say in this article that whether you're line or staff in this sense, like affects your job a lot. Like if you, you know, you could work on billing software at a utility company as an employee of the utility company, or you could be a consultant who comes in as part of a consulting team to work on the software for a billing company. And these two jobs, although you're doing the same software will be vastly different, right? If you're an employee of the utility company, you probably mainly work with on a small development team, you mainly interact with non-developers. You probably have like a really wide scope of what you do, there's like a lot of software and you mainly try to keep it running. On the other hand, like if you work at a software company, you know, there's probably a lot of software developers. You probably specialize a lot. There's probably a lot of competition for roles. It probably pays better than at the utility company. But I guess what I was trying to say in the article is that there's a lot of differences between these two jobs and people act like they're only is working for like Fang But there's all these other jobs that are under discussed. And I know Luke was telling me that he has a preference, I think.

 

Yeah, I've done both. And I never before I read this article, I never kind of really realized that was the difference. So I started off doing software in a software company kind of clawing your way to the top doing that. And I changed over working for a manufacturing company, also doing the software role, but they were a manufacturing company. The factory was for the giant machines that made sheet metal and injection molded. And they needed It was all kind of aggressively outsourced as much as it could. But the opportunities in the manufacturing company were much, much broader than they ever were in the software company.

 

Yeah, I think that's common. Like you'll have a wider scope. Like my friend who works for a utility company, like there are very few software developers there, but he, you know, his boss reports to like the COO of the utility company. So if, if he was hungry to climb the corporate ladder, you know, he gets a lot more exposure to how a business works and, and things like that. jealous of and is uncommon in the software world. So there are

 

through

 

differences

 

true.

 

for sure.

 

And let's face

 

Where does

 

it,

 

he

 

standards.

 

work again?

 

A utility company. Utility companies have like the highest rate of like unionization and pensions of, you know,

 

Yeah, let's

 

of

 

not

 

many

 

talk

 

fields.

 

about Enron though, right?

 

Yeah, he doesn't work for Enron.

 

hahahaha

 

But yeah, I think their pension went bust, didn't it? Down with the whole ship.

 

Yeah, that's a joke for all the mums and dads out there.

 

Ha ha ha!

 

The yeah, I was gonna say the other thing is standards, right? If you're working for a software company doing software, the standards are going to be much higher if you're going to sweat the details. But if you're working for like a utility company doing software, those standards are going to be right away down the bottom. And

 

Yeah.

 

anything you do is going to be seen as a miracle.

 

It's true. And like, if you, um, I mean, you also have more ability to sneak by like a weird pet project, I guess, if you're not at a tech company, because nobody's going to question it. If you're like, oh, of course, this new thing has to be built in Zig. Like at the tech company, they're going to be like, what, why? But at the utility company, they'll be like, oh, that he knows what he's talking about.

 

Oh yeah, Zig, yeah, sure, we know, Zig, yeah.

 

Carry on.

 

Yeah, no, I mean, the downside, of course, is that you are no longer in a company with a whole bunch of software engineers. So the opportunity for personal improvement and actually learning stuff is much, much lower. So even though the

 

Yeah.

 

overall professional opportunities are going to be much bigger, it's not a great place to learn more about software.

 

Yeah, I totally agree. The couple of people that I've talked to that have done this did what I called retiring to staff. So it's kind of like, you know, they worked at a tech company where it was high pressure and they got really good at it, but they got a bit burnt out on it. And from there, you know, they transitioned to a more slower paced, more, yeah, I guess just slower paced job at a larger non-tech company where they as much, but they're consciously making that decision. I don't think it's a good place to start your career. Like that, that's my thinking.

 

I think everybody should start their career in consulting.

 

Yeah.

 

I think you just work on so many different things and are at the whim of the customer that I think it just shapes your mind, right? Specifically for software. I feel like it's easy, like kind of in a product sense to get trapped by the product, right? Like if you're trying, if your goal is to just work, like, okay, maybe it doesn't matter. But if your goal is to become like good software engineer, and you want to discover a lot of new concepts, it's going to be harder to, you know, dive into a product first. I don't know, in my experience, you know, because I kind of did that. I jumped into trying to make my own product. And maybe that was also a problem on my end. But I feel like I joined a consultancy and just was like thrown at the wall, basically at so many different problems. And over time, a lot of the core components came together and having the experience of seeing a large array of ways to do things, I feel like it made me better a programmer.

 

Yeah.

 

I don't know if that's true of everybody, but I feel like it's... It's hard to start in a very, I don't want to say controlled environment, but when the design decisions have already been made, it's hard to learn from that, right? Because you're just learning those design decisions,

 

it.

 

right?

 

Yeah, no, I totally

 

So.

 

agree. It's like you're saying, yeah, cause in the conception of this article, like that is a very clear like line position, right? You're getting thrown, like you're selling your time, right? And

 

Right.

 

you, you know, you get to learn from other consultants. I hope, I hope it wasn't just you on a thing alone, but.

 

No, it was definitely with other

 

Yeah.

 

people. I was pairing quite a lot, thankfully.

 

Yeah, it's a good way to level up your skills, right? But it has the downsides of these line positions. Like it's high pressure, right? And the standards can be hard. I mean, maybe that wasn't your experience.

 

Yeah. It was, it's definitely overwhelming to start no matter what. Right.

 

Nah.

 

So maybe it's, maybe it's easier, like a more calm experience starting in a more controlled environment. Right. So I guess it would depend on your, you know, how you learn. If you're, you know, if you need things to be, you know, more delicate to start and then, you know, ramp yourself up, maybe it would be better to be in a more controlled environment. Right. But yeah, I mean, consulting is definitely chaotic. right like you're at the whims of the customer and you know sometimes you know the right consultancy can help you know buffer between the client enough but it's never gonna be perfect and you're always gonna be you know there's gonna be something where the the customer is just like doing something crazy and asking a lot of you right and you're like I don't know if I could do this right like I'm learning

 

Yeah. It's like somebody had described, um, everybody I know who's done consulting only did it for a certain amount of time. And it makes me think of somebody who was talking about working at Amazon as a web developer who said that they would burn through developers like they were tea candles.

 

That's

 

I can't believe that. Jeff Bezos always strikes me as a very nice man.

 

Very relaxed.

 

You know, it's kind of funny though, this line staff, you know, analogy, I think it makes a lot of sense, like even outside of software, like my wife, she works at a pharmaceutical plant and you know, they have tons of consultants

 

Yeah.

 

come in, right, and do various things and they are their line, right? Like they have, you know, they won't do work unless you ask them to do something, right? And so they have very specific things you line up their work and they get it done, right? And as people are growing as part of the staff, like, you know, supporting basically for when, as they call it, the real work

 

Ha!

 

needs to get done. You know, it definitely makes a lot of sense to me. But I still have this thing with titles. The whole, I know I get the origins of the military nature, right? And there has to be, email phrases for things that everybody can come together and agree on. I feel like titles though are, they're

 

Yeah.

 

still not great, right? Like you, you stamp a label on somebody and then they're, you know, that doesn't travel to different

 

Yeah.

 

companies, right? Like let's say just senior, software engineer, right? Like that's different at so many different companies, right? Like, uh, I feel like, enough and they're not standardized, right? So like just go just saying, you know, staff software engineer, maybe that paints a certain picture maybe as far as like, you know, what some of their abilities are but I don't know, it's also funny just staff software, like

 

Yeah.

 

isn't everybody part of the staff, right? I Definitely throws me.

 

What we need is like maybe a Pokemon based system.

 

Yeah, something that's completely

 

Yeah.

 

different from our reality, right? Where we could be like, all right,

 

Thanks for watching!

 

well, it's definitely, you know, it's defined,

 

Yeah.

 

clearly defined, right? It has this hierarchy, like.

 

could just use the github system

 

That would

 

and

 

be

 

say

 

great.

 

you're like a 15,000 star general

 

Just how many stars you've accumulated. I like it.

 

So Adam, you're in quite an extreme position. You're not only a line software engineer, right?

 

Um, I don't know.

 

in that you your company is a software company.

 

Yeah, that's right. So my, my company is a software company. So I work for earthly and we make an open source build tool. And actually, um, something cool. I thought I'd mentioned here is we we've just gone open source. Well, I mean, it was in April, but relatively recently we were, um, we were using a open core, uh, model, I guess for our build tool, but we switched now to a MPL too, so we're open source. The code was always on GitHub, but now all the legal asterisks are gone.

 

But I was going to say was

 

I have

 

not

 

so many

 

only

 

questions.

 

is it a software company, but you are selling software to other software developers, which has always struck me as a bit extreme because it's not like you're kind of making a product for just e-commerce or a particular industry. You're selling it to other developers, right?

 

Yeah, that's right. It is

 

that

 

extreme.

 

is that the complete nightmare that I dream it is?

 

Uh, I think it's great because like as software developers, we have a very good understanding of what our customers would like. I mean, you know, I'm sure it has, uh, upsides and downsides, but, uh, yeah, we definitely have a good grasp on, you know, the needs of our customers since we, you know, are similar to them. I don't know. I don't find it a nightmare. What's your concern about it?

 

I just imagine it'd be like cooking for Gordon Ramsay.

 

Yeah, that's true. You think software developers are hard to deal with? You're like, I could have any customer I wanted and I chose you guys.

 

I've done a lot of software products where people kind of phone me up and say, hey, you know, why doesn't it work like this? Why doesn't it work like that? But I've never done a product where those same people can look at my code and say, hey, why have you done this? Hey, why have you done that? That's another level, right?

 

Yeah, no, that is true. Um, so

 

So

 

I don't, I don't know.

 

on that note, why did you decide to go open source?

 

Yeah. So we, um, yeah. So, so Earthly is like, it's a combination of like a make file and a Docker file, if you want to think about it, like it's, it's an easy way to build. Software. Um, and it's, it's open source and then we're commercializing it by, by building like a, a CI that people can, can use. Um, so originally we use this license, uh, BSL license that was originally created by Maria DB. And it basically says like, this software is completely open source, except unless you use it to compete with us commercially. And Maria DB came up with this because of Amazon. Mr. Jeff Bezos, we were talking about earlier, right? They wanted to offer a hosted version, I guess, of Maria DB and they didn't want to have to compete with AWS. So they came up with the special license and then lots of other companies followed it. We're open source, you know, just with a asterisks, but you know, that's very confusing for people. I think, you know, they haven't heard of this license. They don't understand. Like you're only trying to preclude, you know, somebody directly competing with you. People understand open source much better than like open source with an asterisk. And when you want to convince a developer to use, you know, your open source software, you don't want them to have to go talk to you. to legal and try to figure out like what the ramifications of this might mean. Um, so we just change it for simplicity. Go for it.

 

I have so many questions. I mean, it's kind of like It's kind of a dream for a company to like be able to take what

 

Yeah.

 

they've worked on and get other people to contribute it to it. Right. Is is that what you've experienced like have when you took this you know open were people already kind of contributing to it. Like do you see a

 

Uh,

 

huge

 

no.

 

uptick after you

 

So,

 

did make

 

I

 

it

 

mean,

 

officially

 

it was

 

more

 

always

 

public.

 

source available. So the source, it was always on GitHub. Um, we were always working out in the open. Um, and people did contribute, um, somewhat, although most of the development is internal. Um, but what did happen is like when we would get some publicity somewhere, people would be like, well, you know, it'd be nice if it was open source. Like we kind of got more like the occasional snide remark about like, what's this weird license, um, you're using. that aspect of it, like people, but like the people, I don't think the people who are excited to contribute, you know what, it's hard to say, right? Like if people were being scared off because of the license, we would never know, we would never hear from them. So it is hard to say, but yeah, we get some contributions,

 

Right.

 

maybe a little bit more than before, but we've always been working out in the open. But my job is developer relations. And so I contribute to the product in a minor way. I'm not the primary developer. If I put in a big PR, it gets looked at closely.

 

I will say that having

 

Oh, that's funny.

 

Go ahead.

 

So I mean...

 

I would say that having tried to get open source products

 

Go ahead

 

into

 

Luke.

 

very large corporations a couple of times, both in America and Japan, licensing is an enormous barrier to entry. The more corporate it is and the more money they have, the more they're going to worry about the legal status of the license. I had the most incredible showdown about using GPL-based

 

Yeah.

 

software in a product because part company was just utterly convinced that this meant that they had to release all of their source code for different products that weren't actually in that product, which was obviously not true. But there's a very large amount of nervousness when it comes to licenses, especially when dealing with bigger companies and bigger accounts. So I think it's definitely the right way to go.

 

Yeah, no, I totally agree.

 

I'm surprised it's not like a can I use, right? For a repo on GitHub, right? Where you

 

Hmm.

 

could just click a button and say, okay, this is what I'm doing with it. You know, kind of like,

 

Oh,

 

you

 

yeah,

 

know,

 

that's

 

HTMLs

 

a good idea.

 

can I use for elements and selectors and stuff? Because I mean, I don't even think about it often. I'll just like use it and be like, oh, this is great. And then after the fact, right? Look at the license and be like, oh crap, right? I've definitely started looking at it more now that our company has grown. But licensing is just so

 

Yeah.

 

funny. If it's on GitHub, people just think you can use it. And so people do, and it doesn't really become a problem until something happens with the company that you're using it with. Let's say you wrote this incredible new application. And you've gone and used all these things and then you know you went to sell whatever

 

Yeah.

 

you've made right and they'd be like Oh, well, you sorry you can't sell it Like and people scramble to you to swap it out with something else right like that's typically what happens and so It's it's funny that you mentioned that like, you know people would complain about license

 

Yeah.

 

because I feel like for the most part You know people don't really look at it, right? Like of curious, have you gotten any new feedback since you've like, you know, changed that license or, you know, what advantages are you hoping like long term to get out

 

Yeah,

 

of this

 

I

 

other

 

mean, that's

 

than

 

the

 

just

 

big

 

maybe

 

one.

 

like corporate

 

But I mean,

 

adoptability?

 

we were always source available, right? So it wasn't a huge change. Um, like the code was already always out there. And that's

 

Right.

 

important because like, I mean, we've been talking about developer tools here today, but like, people don't want a proprietary developer tool, like if, if you, especially like we're making something. To, to do your builds and to, to do your CI and like, you don't want for us to disappear and then you can't build your software anymore. Like that sounds horrible. Right. it all open source, all out there like on homebrew or on your various package managers and you can audit the code if you want. Like, I feel like that's the big advantage. You know, just from a developer safety point, if I'm thinking about it, I'm like, well, I don't know what this thing is. Um, but yeah, the legal question. Yeah. I mean, I think it

 

Right.

 

comes up and that, and then like, it depends on the size of the organization, right? Like we've definitely talked to companies who they just want to use open source tool, but first they have to set up a meeting with us and there's like eight people on their side. And I assume that those companies think very carefully about the licensing if they're having meetings with every tool they pull in. I mean, I wonder how they get anything done, but these places do exist.

 

Yeah, I wonder if like, has there been anything else that you've had to kind of focus on to help support, you know, now that it is truly an open system to use, I know it's been, you know, the source has been available. But you have you had to add like extra documentation or anything like that that you focused on?

 

Uh, you

 

Like,

 

know,

 

what

 

before,

 

was your next step

 

before

 

after

 

we

 

just

 

even

 

like

 

changed

 

changing

 

the license

 

the license

 

file,

 

file?

 

we did, um, participate in Haktober Fest a couple of times. Um, and to do that, we spent some time like making sure we had a contributor's guide and then, you know, we also tried to collect like easy issues, you know, like it's actually hard to do where it's like, if you see a small problem, like don't just fix it, like put in an issue and label it as like a good first issue. It's just some minor little thing. A lot of times people need that to get their feet wet, right? They need something that they can, you know, go through the whole process, but just make a small change, like this flag, you know, isn't, you know, the help for this flag at the command line is wrong or something, right? Just, um, those things become like kind of on ramps where, where people can understand how to contribute, uh, to the project, but, but honestly, like most of internal. The whole process is external. You can see what we're working on. But it's mainly done by us.

 

Yeah, I remember seeing that methodology used on was it the Rails mini profile or gem, which basically like if you're familiar with the rack mini profile, it's like this tiny little tab at the top

 

Yeah,

 

of your

 

yeah.

 

Rails pages that shows you like how fast things loaded in various parts of the stack. And this guy made this new like version that was Rails mini profile, what gives you like this slicker like UI to kind of in the stack and the timing of it. And I went to look at his repository and it was great. Like he would just put like, he was just like loaded up the issues on the repository of everything that he wanted to get done. Everything that he wished to, right? Like just basically did like a mind dump, like in the issues and then just like slowly started like chipping away and tagging stuff. But

 

Yeah.

 

like just seeing that all the issues there, it like made me wanna jump in, right? Like, I'm like, oh, like this looks like interesting. right? Like, you know, just seeing where the trajectory

 

Yeah,

 

would

 

that's

 

go

 

a good point. Now that

 

can

 

you

 

kind

 

mention

 

of like

 

it, like,

 

bring

 

so

 

in

 

we,

 

more contributors that

 

we

 

way

 

get

 

I

 

a lot

 

feel.

 

of interaction in terms of yeah, issues and proposals. So we, we do proposals up as, uh, tickets in like, GitHub. We have like a roadmap on there with, has like some swim lanes where we can put, you know, this is experimental. Like we actually have this, but it's not, uh, guaranteed. Like we might remove it at some future point, you know, some things that were just planning, um, and we put together these proposals. discuss it on the GitHub issue. And a lot of times people will suggest something and then we're like, this is a good idea, let's turn this into a proposal, right? Like this is the change you might be suggesting. So yeah, we get a lot of contributions that way. And in a lot of ways it's a lot more valuable than, yeah, like somebody just fixing a minor bug, right? These are people who use the product, who are trying to help shape what it would become. Sort of similar. Sorry, go ahead.

 

uh... kind of taking your So have you noticed, have you noticed anybody like...

 

Oh yeah, like we definitely see people using Earthly

 

you know

 

to build

 

seeing

 

their software.

 

something out there that

 

Yeah,

 

are like oh no they've taken it and they're you

 

I

 

know

 

don't

 

making

 

know.

 

their

 

I'm

 

own

 

sorry,

 

thing

 

I don't have a good story of

 

if

 

like

 

we're in

 

this

 

running

 

guy

 

with it

 

was like, finally,

 

like

 

now

 

was

 

I will

 

that was

 

use

 

anybody

 

it. And then,

 

higher up

 

yeah,

 

like you know that

 

let's

 

was

 

just

 

worried

 

pretend

 

about

 

he's out there.

 

you

 

His

 

know

 

name

 

the change in the licensing

 

is Jeff and legal told him no, but once we changed things, then he ran with it. Yeah.

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Thank you, Jeff.

 

Ha ha ha!

 

Yeah. Yeah. Yeah. Yeah. Yeah, Elasticsearch is a great example. So it's like what Amazon's they changed its name from Elasticsearch, I think, but they like put it in brackets. But anyways, yeah, Elasticsearch, uh, you know, you can, what, do you know what the AWS one is called? I don't know, but Elasticsearch, the company was not happy that like everybody's using Amazon's version of it because everybody's on AWS. Legitimately, I think they have right to be upset about this. So, yeah, we're taking that risk. If you're listening, Jeff Bezos, please don't crush us. Yeah. Yeah. I mean, also, so MariaDB was the BSL license and they're a database and Amazon will Amazon does sell databases, right? Like they're directly, I think in the, in the line of fire. Um, you know, CI is, they do have, uh, they do have build products, but it's, it's less directly in their wheelhouse. I mean, maybe it's more in Azure's wheelhouse. Maybe that's who we should be worried about. But the bet we're making is that we're making really valuable and people will want the earthly brand and you know that we have advantages that we can add on. Yeah, so hopefully that works out. Yeah, see they changed the name. They're like, it's not. dangerous game. Oh, okay. Yeah, I think there was a lawsuit or something. No, I don't think so. This has been fun.

 

Yeah, I mean, to call back to my earlier point about languages that are too far gone to save, the obvious one I'm thinking of is C++. And Google this week have announced there would be C++ killer called Carbon Lang. I'm not sure if you've seen it, but it's caused a lot of discussion, shall we say. So everyone should go and learn that doing C++ anymore. My next two picks are from, of course, Adam's own podcast called Co-Recursive. Now the first one is for older people and it's an interview with a guy called Jeff Schrager who was involved in the first ELISA protocol. This was a kind of early chat bot. Now I actually had an ELISA in Basic which I got from which I ordered through the mail. So this episode has a certain amount of magic for me. It's not going to appeal to younger generation at all. But I loved every second of it. It was absolute gold. And if you want something more up to date, they've also got my personal heroes on there. By day, I mean you, Adam, which is the interview with Casey Muratori, who is absolute and there's a great episode with him on there as well.

 

Do you see Casey's terminal, like Windows terminal stuff?

 

My favorite video of Case Miratoria is how to use Git video on YouTube. That is fantastic.

 

He's a harsh, he can be harsh.

 

It's very, very entertaining.

 

Yes.

 

We're all very aware, we're

 

Yeah.

 

all painfully aware. That's not

 

Weird.

 

funny,

 

Yeah,

 

that's gruesome.

 

that's strange.

 

I'm pretty sure Will Smith was in that movie, right?

 

Um, so my pick's unusual. So I got a Peloton tread, the Peloton treadmill. Um, so.

 

Oh wow, like a peloton but without all the awful cycling.

 

Yeah, you run instead. So I had a treadmill that I didn't use very much that I got rid of. And I used to like walk on it sometimes, but now I have the Peloton tread. The classes are amazing and have got me like actually exercising. So there's like, I don't know what type of music you're in, but I'll do like a Pearl Jam class and it's all like Pearl Jam songs and somebody, you know, getting you to run and also telling you facts about the history of Pearl Jam and there's some nineties rock ones and system of a down one. I think you can see just by what I've named, like the genre of music that I listen to, but it's been great. So hard, like turns out running is hard and it's not like jogging. They're like, they'll yell at you, tell you to keep going faster. So yeah, Peloton Tread has been awesome. I'm loving it. That's my pick. Ha ha. Yeah, it hasn't happened to me yet, but I've worried about it too. And they're like, faster, go faster, go faster. I'm like, I'm going to get thrown through the wall. Like if I turn this up any higher. Yeah. So I'm on Twitter at, uh, Adam Gordon Bell also on Pelton. Uh, although I don't really know what that means. If you, if you track me down on there, I guess you could see what my runs. Um, yeah. And check out my podcast. The that's co recursive.com. Yeah. I think that's enough plugs. Awesome. It's been fun. I like your on air light. Does it, is it hooked up to something? Like is it?

 

Thanks for watching!

 

Oh. That's awesome.

 

Huh.

 

Oh.

 

Hmm.

 

That's cool. That's super cool. Ha ha ha. Awesome guys. Well, this has been fun. Do you know when will the episode come out?

 

Duh. We do now get a notification. I got an email saying an episode has gone out, but it doesn't tell us when it's going to go out.

 

Yeah, no worries. Yeah, no worries. I'll survive either way. It says 99% uploaded. I'm not at 100 yet.

 

Yeah, mine too. Just having to think about it. Mine said recording.

 

Yeah, mine's recorded too. Uh, I've had some bad luck. Like I've been using Riverside for my podcast too. I have occasional bad luck with it. Yeah, one time I, the episode ended and then, yeah, the, the guests would never get past 99%. And then, uh, yeah, I had to reach out. I reached out to the Riverside people, like we ended the call and then they said, Oh, it's lost. Like we can't get it back. Right. Yeah. So I like, I tweeted it out and I like CC'd Riverside and I was like, you guys are calls or whatever. I got like a sport ticket like three minutes later. They had like sent me a link to it like an S3 bucket that had that in there. Yeah. Yeah. Yeah, and then I deleted the tweet. I felt like there's like a Yeah, but yeah, it didn't it didn't feel right though, right? It's like You shouldn't need to threaten them to get results

 

I'm just gonna let it sit there, but I'm gonna call it a night, because it's half three here.

 

Yeah, I'll just hit leave studio, but leave it running and upload. Thanks guys, this has been fun.

 

Yeah, I wish I was in better shape, Adam, but I'm dying here.

 

I'm out. I hope you start feeling better.

 

The Imodium does nothing. It does nothing.