Who sticks with engineering for *decades*? Jason Rubenstein shares.
Jason Rubenstein joined us to drop some paleolithic knowledge meteors from having spent several decades in software engineering.
Max: Hi, guys. Max of The Accidental Engineer here with you. Today, we have the honor of…for those of you who don’t know who this is it’s Jason Rubenstein. Jason’s held a variety of senior engineering roles in management as a director, as VP, a lot of different consulting engagements. Jason, do you mind kinda sharing what your last few gigs have been?
Jason: Sure. I was Director of Engineering of a platform group, a back-end API stack, basically, recently. Prior to that, I did a lot of consulting, anywhere from being an individual contributor writing Python, getting into Django, getting into Flask. Other things, too, being a CTO consultant for hire. A small startup of nontechnical people needed advice on technical strategies they were planning out, their marketing launch and hiring engineers, did a lot of recruiting. So wearing a lot of hats as a contractor, as a contract for hire, and the agency with which I work leverages variety of experiences that I’ve had.
Max: So a lot of people who are in their first five years of their career…or who might not even, yet, have gotten their first software engineering job, are kinda wondering what the career looks like 20 years, 30 years down the road.
Max: So one of the things you and I have talked about at length is kinda what the job requirements look like or how they change as you move up in seniority and into management roles. So do you mind sharing a little bit about just how drastically different maybe your last job was from your first job as a software engineer?
Jason: Oh, completely night and day. My last job was very managerial, lots of soft skills, lots of people skills. A lot of learning how to do those skills better, like learning how to run a one-on-one more efficiently, learning different ways to communicate ideas to people and find out from them what their ideas are, that sort of thing. A lot of managing up, managing up to the VP Engineering, to the COO, to the CEO, to the CTO, etc, which is a whole different set of skills then. My first job, which was programming IBM AS/400 computers back in the late ’80s, early ’90s…it’s a mid-range computer. It was based on…completely around RDBMS system, which, you remember, from the ’70s and ’80s was a fairly new concept.
Max: These are SQL databases.
Jason: These are SQL data…it was DB-2, IBM’s DB-2.
Max: That was like one of the first popular SQL databases, along with Oracle.
Jason: RDBMS…well, there were a bunch of things in IBM that were, you know, pre-dated, essentially, relational database algebra, joins and things. But you know, the first thing I learned, I think, was the Codd Normal Form, you know, the first three or four normalized forms of a relational database. Then I learned how you can’t really do that and have a functioning, you know…have a system that doesn’t bog itself down in, you know, queries that are loaded with joins. At some point, you have to denormalize, but anyway.
Jason: Completely different. It was all technical back then.
Max: Oh, no. And keep in mind that a lot of our audience probably doesn’t know who Boyce-Codd is or normal forms or any of the database software we just described. But are you surprised…I know a lot of job descriptions today still have SQL as a highly-valued skill. Are there skills like SQL that you’re very surprised are still popular in the job market or in the labor market?
Jason: Not really. Not really surprised, no. How do I put this? If you’re gonna do anything well, you really have to understand first principles, whether it’s karate, whether it’s music, whether it’s software engineering, first principles like how does, really, relational database work? What are the implications of normalizing something to the third or fourth form? You know, you go to Wikipedia now, and you can get a good description of what these are if you don’t know.
Jason: What does it mean if I’m gonna join six files together…six tables together, excuse me.
Jason: You know, that gets down to what I think of first principles, you know, sort of 80% of what you learn in the first couple years of being a software engineer, assuming you learn good habits and you learn it properly, like don’t nest your loops, learn how to do joins properly, learn when you wanna maybe do things in application memory, what the trade-offs are. Do you wanna bog down the database with a lot of work, or do you wanna transfer some of that database to your servers, which means more work on your servers? That sort of balancing act.
Jason: Yeah, you can’t do everything in a key value store in Mongo. You have to, at some point, have relational representation of your information.
Max: So some of this is retrospective, but some of this is forecasting. I mean, do you think SQL will still be the dominant querying language in like 10 years? I don’t know.
Max: People also define NoSQL super generally to virtually any data store that doesn’t use SQL, right, like Memcached or Redis.
Jason: Right. Well, Redis, you know, sure. Redis can make for a rather interesting key value store. But it’s a bit like…you know, technically-speaking, then, an IBM 360 mainframe from 1967 could be NoSQL. It’d be a hell of a way to brand it.
Max: If you argue it, yeah.
Jason: They’re missing some hip, trendy stuff here by not, you know…anyway, I kid.
Jason: Yeah, I think it’ll be around and mostly because there’s a tremendous weight of legacy in lots and lots of companies. But also, what are you gonna replace it with? It’s a fairly decent way to do relational algebra, right?
Max: Sure, which is largely what you might wanna do with data.
Jason: Yeah. You know, the object of these things is to get information lists. I mean, you wanna get data out of the database, but it’s to represent information that the business needs. And so, you know, having a tool that most anybody can pick up that can get the data from a table and then have it presented to you in a way that’s informative, so you can make business decisions, is pretty valuable. So I think, in that respect, it’s gonna stick around for a while.
Max: For people who are in their first few years of their career, they’ve got a long time ahead of you in your life and career.
Max: Hopefully. I think there’s some amount of specialization that people have to decide upon or else have decided for them about what area of the software ecosystem they’ll specialize in, meaning, like, what tools will you know? Like, will you know SQL, or will you be front-end or native mobile apps. Like, what were the…I mean, native mobile apps didn’t exist two decades ago.
Max: What was kind of the equivalent specializations that happened in the first dotcom bubble?
Jason: I don’t know. I was still in the IBM world in the first dotcom bubble. I was working on Y2K problems for Fortune 500s and 100s and making, you know, bushel loads of money. They were just panicky that the systems were gonna fall apart because there were only six-digit dates everywhere, and so I got a lot of work. And I didn’t get into consumer web until 2006 or 2007. I left the IBM world completely. I went to Python, which will get to the point, actually, about what do you need to know and specialize in. I had previously taught myself assembly in the ’90s because I got into 3D computer graphics. And assembly in C were the ways to go, and I didn’t really care for C, and I was really fascinated with assembly for 386.
Max: Well, even within IBM, what were the specializations if not working on a browser?
Jason: Oh, we’re looking at a couple decades. Like, when I graduated college, relational database was a big specialization, mid-range computers that utilized the DB-2, and then the DB-2 package for mainframes was still gaining traction. It wasn’t widespread. Most file systems were header detail, footer type systems, HFS type thing, you know, just a…I forgot. Not HFS, excuse me. That’s wrong, sorry.
Anyway, I can’t remember it. But anyway, it was basically you spooled the tape, and it read the header, which told you what to expect and all the detail records, identified by a character at the beginning of the row, an H for a “header,” a D for “detail,” and an F for “footer” was one way to do it. I’m sure there were others. I don’t recall. So that was a specialization. EDI, which was Electronic Data Interchange, was a pretty valuable specialization to have, and now I don’t know: SOAP, XML at some point now. You know, there are some industries that rely heavily on SOAP, but no, I couldn’t tell.
The key to all this stuff, I think, if you’re a junior engineer or a non-seasoned engineer, let’s say, where you’re still at the beginning of your career, is to learn how to learn. Learn what you like. That’s really important. I like managing people. I like the people thing. There are certain parts of management I don’t like and I have to get better at. For example, getting a really inexperienced engineer from zero to one, you know, and if they’re not particularly aware that they’re not even at one yet. You look at their code, and you look at the decisions they make and think, “Ooh, that’s gonna break the system.” How do you communicate and bring them up, and coach them up, as opposed to someone who’s got some experience who wants to learn a bit more.
Jason: Yeah, it’s smart, for sure, because the more you learn and the more able you are to do your job, the better it is for the company. It’s like, “Hey, how would you like to go solve vehicle routing problem? Guess what? The company is pivoting into a fleet of cars that are gonna go and pick up your water or drop off, you know, bottles of water for you.” I can’t, I turn that around, so I’m not promising that this company’s gonna do that for you.
Jason: But all of a sudden like the business pivots, in other words, and now the overworked engineering director and over-worked engineering staff now has to do something that they’ve never experienced before. I mean, unless you have done a VRP or… I think most people are gonna be generally aware of Dijkstra’s algorithm, right? But that doesn’t…you can’t just drop that in if you got a fleet of cars, you have to…there’s a more advanced thing. So if you learn how to do something completely new that’s going to benefit your career, in this case, it’s also gonna benefit the company.
The flip side is if you were interested in doing something that had no benefit to the company, you might have to say, “Well, learn it at home, and if we have an idea that we can prototype without risk to our business, then maybe we can talk about it.” And so you do have to negotiate what you learn and its value to the company. And as a manager, if you’re smart, you will encourage people to develop their professions. And I think, as a manager, it’s part of my responsibility to help people develop their careers and develop their technical expertise in whatever directions they wanna go, at the same time, making sure that the company’s needs and requirements are met, and, you know, making sure that these two overlap and mesh.
And that company understands…my bosses understand that personal and professional development and growth is super important, not just to the individual, but to them. And to the engineer to say, “Hey, look, you know, I understand you wanna rewrite everything in Elixir. I get it. But there’s value to the company that isn’t provide by that. On the other hand, getting into this other, you know, process, maybe we need a Pub/Sub setup that you might wanna use Elixir for or something, we can prototype that.” And then communicating to the engineer that they have to have the business interests in mind as well as their personal growth for making those intersections and communicating, is a big deal.
But learning, I mean, over…you know, I switched to… I left the IBM world programming in RPG III and RPG IV, which is this ridiculously arcane and antique language, and it was horrible.
Max: I haven’t heard of those.
Jason: Yeah, good. You’re lucky. COBOL and FORTRAN is crap. It’s still around, so that tells you something. And then I had learned Python, which is relatively easy to learn, and previous to that, I had learned other languages. Hey, Python. And…sorry?
Max: Oh, I was just cueing the audience that Python’s a great language to learn.
Jason: Oh, yes, yes, yes, love it. There are quite a few great languages out there, and then I happen to be partial to that one because I learned it. And it’s an amazing tool. I use it for almost everything I can imagine. There are some things that…like, I’ll use Golang for, you know, something that needs to be super fa… Instead of C, I’ll use Golang, for example, because it’s a nice C replacement, that sort of thing. Anyway.
Max: On the front of helping junior engineers or even senior engineers under your management learn empathy and soft skills aside, what’s kinda the toolkit, hard toolkit available to management? Who are the vendors trying to sell you products and services as a manager to help you level up your engineering team and whatnot?
Max: Are there tools that they use? Like, do you find people who are reporting to you as a manager are coming to you with tools and whatnot that they think make themselves more productive?
Jason: Not only garbage, but, I think…you know, I’ve discovered I can’t do that. So I’ve asked the, you know, the folks who are maybe just out of school one or two years or they’re only two or three or four years in their career, “Okay, how do I give you constructive feedback?” And then, that’s a whole other set of challenges in there, that’s probably a whole different discussion.
But the key is growth, and I say, “Look, it’s really important that you continue to grow and learn how to learn because the tools change. You can’t stay a Java programmer…” bad example. You could stay a Java programmer forever, probably. But you can’t stay on Ruby on Rails forever, you can’t stay in Django forever, because eventually those frameworks are gonna go away 10, 20, 30 years down the line.
Max: Scikit-Learn, ARKit. I don’t know if they’re machine learning.
Jason: You can go learn it…there’s stuff on the web…but, you know, learn the fundamentals of what makes machine learning work. You don’t have to become an expert tomorrow, but if you wanna do it, you have to start learning, you know, what’s a Markov chain, and how do you program one? And that’s just one element. That’s one tool and one piece of this. So I’m not a machine learning expert. I’ve been doing that. I’ve just been trying to learn the stuff and get a catalog of, “If I’m going to be interested in learning this nascent technological field, what do I need to get my first principles,” right? Have you’ve ever taken a martial art, karate, or whatever…?
Jason: They say that most of almost everything that you do has its foundations in the stuff you learn in the first month. You know, all the white belts you go through, it’s just learning the basics. The real learning, the real education doesn’t come until you’re a black belt, but even then, you know, a good sensei will just continually tell you, “This is the basic move you learned in the first week. You need to refine it. You need to really get it under your skin.” Same with programming, you know, 80% of your problems can be solved with 20% of the toolkit.
Max: When you were talking earlier about one-on-ones and how large a portion, maybe time-wise, of management one-on-one meetings are.
Max: What percentage of that time is kind of coddling people’s expectations about compensation. Like, I think, something especially true of people in their first five years of their software engineering career is they see these very lucrative base salary compensation packages, and they feel this was the right choice career-wise. But maybe they’re only in their first year of their career and they’re just not reasonably or likely to receive maybe the same salary offer that somebody shockingly gets when they’re fourth year, maybe.
Jason: Right. Or 10th or 20th year, yeah.
Max: Is this a contentious topic when doing one-on-ones with people in their first year of programming?
Jason: It depends, and it depends on the individual’s background, what sort of level of entitlement they have or don’t have that they’ve acquired, what their personal level of maturity is. You know, I’ve been lucky that I’ve worked with some first and second-year engineers who had previous careers in the public sector or in nonprofits or something like this, where they’ve worked in organizations and they’ve had to work in the types of organizations that heavily required soft skills and understandings of this stuff. So they’ve been a bit easier to work with.
It can get very contentious for a bunch of reasons. One is we’re not very good negotiators. We don’t like…we’re engineers, we’re very concrete, we’re very deterministic. “I want this much money, and I really don’t wanna negotiate.” And it rubs us the wrong way when we sit with a professional negotiator, a salesperson, a CEO. I mean, the CEO is a hell of a professional negotiator, [inaudible 00:22:09] one. That’s all they do is negotiate with boards and with businesses, you know? And who do we interview with? Essentially, professional negotiators, right, for our salary.
So usually, they come in, you know, underpaid, anyway, especially in a A round or B round startup. So that’s already a difficult position because they look at the salaries and somewhere else, and they feel like they’re getting ripped off sometimes.
Jason: Or if they do their research, then they feel like they’re ripped off. They may not have before, but as soon as they open a website… Or some friend working for Facebook says, “Oh, man, I’m making like 50 grand more than you are.” Oh, boy.
Max: They maybe have breadth, but not depth.
Jason: They have breadth, but not depth. Yeah, thank you. But they then equate that to value as a senior engineer, but I’m the guy that everyone goes to, to figure out how to fix this problem. Or when we have an on-call event, I’m the one who gets up at 10 p.m. and fixes it. And then you have to communicate, well, what a great engineer’s gonna do to is solve that problem and write the code, so that that event doesn’t happen again or is more easily mitigable.
They’ll understand that the query shouldn’t run two and a half seconds. You can’t just say, “Well, it’s because that has, you know, 4 million rows in it.” “Well, wait a minute, you know, there’s gotta be a way to mitigate this,” right? So lots of local, really localized experience, but not a lot of general experience about the profession, about, you know, the craftsmanship of…and the artisanship of being an engineer. And they conflate that experience with the value, you know, across the industry.
Jason: That doesn’t mean that, you know, I can drop you into Google tomorrow and you’re gonna be a level four, so.
Max: Yeah. Well, I think one of the other problems that exists besides engineers not being good negotiators or having good understanding of their context in the business when it comes to negotiating their compensation is that unlike sales, for example, compensation is not very performance-based, in a lot of cases, for people, especially in their first few years of their career. So in your career, so far, you’ve been with many different employers and businesses and organizations. What have been different experiments you’ve seen? I mean, equity as a portion of compensation has always been a tool to help incentivize engineers, but what are some variations or trends you’ve seen in engineers’ compensation over the decades?
Jason: It depends on where they are in their lives. Things like working remotely can have a lot of value to someone who, say, for example, doesn’t have kids.
Max: True. Or does have kids.
Jason: Doesn’t have kids. I mean, more like taking three weeks and going to Mexico and working from a beach somewhere.
Jason: Sometimes that can have a lot of value in lieu of salary, especially if you’re an A round or a B round company or a pre-A round company and you don’t have a lot of money, right? And as long as the work gets done, you know, then it’s the job… Of course, then you don’t really have a manager in that point, but then I think the CEO’s gotta recognize it. Sometimes getting the work done is more important than butts in seats. And that’s a whole different negotiation.
But let’s say it’s a slightly more advanced developed company, and they do have people like directors and VPs of engineering, whatever, offering compensation that has value but is not cash or stock options. So we experimented with that, making sure that they are clear that they have responsibility, that they have to still be accountable for the work, even if they’re working from a beach in Thailand, right? They’re accountable for communications. That’s usually the one that’s the trickiest. They disappear and don’t send you an email for four days. You know, you still need to tell us, right?
Jason: Teaching them how to communicate up, how to manage up. Everyone needs to know how to manage up. Always push information up the ladder, don’t have them come to you, so that helps. You know, telling them that, “Yes, we can compensate you in this sort of experimental way, but here’s what you need to do to make that work.” In other cases, if it is a family, you say, “Yeah, you can shift your hours around. You can work from home,” things like that.
Jason: Oh, boy. Specifically as a software engineer.
Jason: Okay. We speak a completely different language than anyone else in the business, right? Our language is about engineering, whereas your Biz Dev people and your CEO and your sales folks and your other folks who are nontechnical have a general sense of the same language. And their language is money and income and profit and loss and all the things around a business. We don’t talk about that. Our language is in, you know, pre-optimization of algorithms or optimizations of queries, or…we’re into the real geeky stuff.
We throw around words like technical debt, which are really loaded terms for us. It could mean a variety of things. It could mean “determine technical debt,” where, “Gosh, we don’t have enough time. I’m going to hack something in to buy myself time.” So you’re basically buying time on credit. It has to be paid back later. There’s accidental technical debt, where, “I wrote some operations, or I wrote some control code that I didn’t really understand the general abstraction of what I was trying to fix, or I didn’t understand the business” and, “Oops! I made some incorrect assumptions.” That’s accidental technical debt.
In other words, the technical word has, like, lots of meaning, even within engineering. When you say that to someone who doesn’t speak our language, completely, then you’re really screwing yourself over. So “managing up” for engineers means learning how to speak in the language of the people for whom you’re a service provider because we are providing a service to the rest of the company. If you’re managing up to a technical manager, right, then you can negotiate terms like technical debt and everything else.
That’s a very real conversation. I’ve had it, I don’t know with how many customers and how many places, where I’ve said, “Look. You know, a system is a snapshot of your business. Your business keeps changing and moving every time. Your system takes, boop, it’s gonna do this, and eventually, you’re far enough…” like, your customer base a year from now doesn’t look like it does now if you’re a young business and you’re trying to figure out produce market fit. So I’ll have to communicate in their language, “Hey, you know, we have a 67% churn rate. If we make these fixes, it’s gonna drop that by I don’t know how much, but we have to do some…” you know, putting it in terms of their…you know, “Hey, every time our system blows up, we lose $100,000 in income.” That’s a language that I guarantee that they understand. They’re gonna say, “Don’t talk to me about this. Go fix it. This is your job. Don’t ask me permission to, like, do your job,” right? Now, if you’re managing up to someone who’s technical, what it means is providing them with information, regular updates.
Those are examples of pushing information up. Don’t wait for your manager to come to you. That’s not managing up, right? You also build trust. Managing up is about continuing to build trust with your manager. For example, if you consistently provide information about what’s going on, I mean, one or two sentences, the less you need to get in technical detail, in which case book some time together, so that you don’t impede on someone else’s work they’re trying to do. One or two sentences is enough. “Here’s where I’m at. Here’s whatever.” Think about answering questions as, “Yes,” “No,” or “I don’t know. I’ll find out.” Those are three awesome answers, right? “Yes,” “No,” “I don’t know,” things like that.
Max: With the different companies you’ve worked with over the years, are there certain ones that kind of stand out in how aligned their engineering teams were with revenue and cost. I guess, there are many startups that aren’t making much in the way of money right now and are chasing kind of proxy metrics for money, that might be users, that might be engagement or whatever. Where you can’t say, “Okay, this engineer created this feature which translates to this revenue or these cost savings.” So are there any employers that…or companies you’ve worked with, that have had a better focus on that sort of thing, on the engineering team? And was that a better work environment or a worse work environment?
So it was really good because I happen to like cross-disciplinary groups, cross-functional cross-disciplinary groups, where Engineering and Biz Dev and Operations and, you know, Sales and everybody, we’re all working together for the common and with a lot of communication. That old T-shaped individual comes in handy if you look up the IDO. Tim Brown talked about T-shaped.
Jason: That’s in a whole other conversation, and I encourage you to go look it up on the web. It’s interesting. It talks about having empathy for other teams. Like, “Well, what would help sales? How do I get that information?” So, “Hey, Product, you know, Sales is talking about their OKRs for this or KPIs for this quarter. What can we do to improve that?” If that comes from Engineering, it fosters a cooperative relationship with the product folks as opposed to a confrontational one.
Max: Yeah. I guess, are there processes that a manager in Engineering can introduce to… For example, one practice, I remember, in a previous role I’ve held is to have engineer team members on a weekly basis go and either sit in on a client call or sit in on a sales call, which there’s not so much a measurable effect that I recall being concluded from that experiment. But are there things that you, as a manager, or you observed other managers do to try and get engineering teams better aligned with the rest of the business?
Jason: Well, we’ll do that as well. But for example, let’s take…I haven’t worked there, but let’s take a company we’ve all heard of, you know, that picks you up and drops you off, right?
Jason: Like a ride-sharing company.
Max: Oh, that could be one of many.
Jason: That sort of thing.
Jason: Not always youthful, but yeah.
Max: Not always youthful, but maybe inexperienced engineers. Maybe you can share some perspective from the other side of the table when somebody comes to their manager in Engineering and says, “I wanna do a rewrite and a different approach”?
Jason: You do it wrong. What changed is you get great managers who…you just get lucky with great managers. Or I seek out…you know, or you have a few failures and go, “Where did I go wrong, what did I do? Good Lord, I screwed that up.” And you go searching for answers as to where I screwed up. No, once I was contracting for a contracting firm, and it was on an IBM system and the code was ancient and ugly. It had been hacked on and with some weird combination of…a lot of go-to’s, a lot of spaghetti code, semi-functional, some sub routines, not a lot. It was a mess, and I couldn’t understand it. And I felt stymied every time I opened it. Like, you fixed one thing, and you broke three others. So I fought really hard to…and argued very strongly to rewrite everything, just rewrite the whole system because I can’t understand it, and I fought with my manager for weeks. And finally, the Director of IT, the Director of MIS, Management Information Systems is what we called it back in the Stone Age, when we were programming on rocks and chisels.
But from that side of the table, what I took away from my personal experience was a lot of personal frustration brought on by a lack of experience in having to maintain other people’s code. The misunderstanding that, most of our careers, we’re managing someone else’s code, right?
Max: This is a topic that you and I have talked about previously, and something you’ve said has made a very big impression on me, which was how you suspect that possibly zero lines of code you’ve written are in production anymore.
Jason: Acquisitions or shutdowns and, yeah.
Jason: I was thinking about it after we talked about this. I think I’ve got some code for a credit card manufacturing company, actually it’s a card manufacturing company, because I wrote code to create an interface between the internet and their credit card printing machines, which dated back to 1974. And I doubt if that code’s changed at all since I wrote it. Ain’t no one wants to touch it, but it works and it’s ancient technology. I did this in, like, 2002, so it was just a very unusual job. So that code might still be there because it’s really idiosyncratic and specific and the domain is like so narrow it doesn’t make any sense.
But in general, no, that’s true, mostly through acquisitions and companies just disappearing into the cracks of the Earth. Some codes are products that were shut down. I worked on a thing at Google that, you know, two weeks after launch, was completely sunsetted just because that’s, you know, they have to make decisions about what goes to market.
Max: Do you have any… I guess, is it an admirable goal to try and write code that will be around forever? Like, is that something to be admired or aspired to?
Jason: Yes, yes, It is, because you don’t know. I mean, my luck could just be bad. I’ve heard rumors that there is PayPal code that is still in the PayPal repo that dates back to, you know, seven guys in a room in Palo Alto, right? I don’t know if it’s true, but I wouldn’t doubt it. It is, because when we write code, especially in languages…well, in any language, really, other than assembly…when we write code, we’re not writing it specifically to tell the computer what to do. We’re writing it so that other human beings know what we’re telling the computer to do. You wanna tell the computer what to do, write in assembly language, and even then, you’re gonna put comments in. Why? To tell other human beings what I’m telling the computer to do. It’s super critical, and you don’t wanna… You know, most university programs… A friend of mine, one of the people that I go to for advice, and we’re talking about recruiting and things, and anyway, what came out of that conversation was so many of us who went through a classical computer science routine and degree learn how to write code once, that’s read once by a professor who, half the time, is too busy or just doesn’t care, because for whatever reason. Lots of professors care very deeply, but they’re overworked.
A good example is a function that says, “Clear water bottle,” and what the function actually does is empties the water bottle and refills it. That didn’t clear it. Actually, “refill water bottle.” “Empty and refill water bottle” would be an even better name for that particular function. But no, it’s called, “clear water bottle.” You know, my response, “Is the water bottle filled with water?” Which is not what I expected, and now I’m gonna run…now my initial assumptions about the stack have been shattered. Now I don’t trust the stack, which adds time and money and energy and frustration to the software development process.
Jason: …and will be around for a very long time. Which also means you wanna make things atomic, right? You don’t want to conflate data and function, you know? There’s lot of practices. This is not the only practice, but if learn functional programming, you will learn some great techniques and tools. If you learn OOP, you learn other great techniques and tools. Both of these particular techniques and tools can be abused. You can do some horrible things with them. Java’s a great language if it isn’t abused, right? Ruby’s a great language. All of these languages are great if they aren’t…frameworks are great if they aren’t abused.
Yeah. And this takes time and experience and one of the things that I’m afraid…you know, I didn’t know this stuff when I was an inexperienced and unseasoned engineer. It takes seasons. That’s why seasoning as an engineer is important because you start to get into code bases that have been written correctly and it’s like a breath of fresh air or maintained correctly. And you think, “This is wonderful. I never wanna go back to hairy, ugly, difficult-to-read…” Excuse me, code bases, not databases. You’ve had to maintain your own code over years, right? First of all, if you’re not embarrassed by code you wrote a year ago, you’re doing it wrong. You should always improve and be mortified at the stuff you wrote 1 year, 2 year, 5, 10 years ago.
There’s another great quote that I love, related to this, and that’s from Ed Catmull, as managers and as engineers, really. Again, I’m paraphrasing. It’s not our job to prevent failure. It’s our job to help people recover from failure. But it is our job to prevent catastrophic failure. Your whole company’s shutting down because you DDoS-ed a business partner.
Jason: Yeah, that’s happened, you know, accidentally.
Jason: You know, completely accidental, but it happened and oops. And it happened because we were all working really late, and there’s lot of… It doesn’t matter. There were no excuses. We took responsibility for it and [inaudible 00:48:02] to the partner, who laughed and said, “Yeah, we’ve done that before.” So they were really cool about it, you know. In my DDoS, I mean, you know, we had distributed network as servers. Each one was just hitting this particular endpoint pretty hard, and it was a careless and tired mistake. And so, that’s a catastrophic failure because then the entire company couldn’t take customer orders. But a regular failure is, you know, a query that times out and causes a couple of problems for a couple of users, and we get customer support calls. It doesn’t bring the company down. It’s a failure. How do you recover from the failure?
Max: Well, at this point in the interview, we ran out of disk space, so if you guys have any questions for Jason, let us know in the comments, or get a hold of us. Or you can reach Jason directly at his email address at jason@jasonrubenstein.com. For the spelling of that, check out the description of the video.
Hope you guys enjoyed it. We’ll have more videos coming soon. Thanks.