Jason Rubenstein joined us to drop some paleolithic knowledge meteors from having spent several decades in software engineering.

I had the opportunity to ask him about:

  • which job skills have stood the test-of-time (hint: SQL)
  • what’s the difference between his last job and his first job
  • what “moving up” into management really means (hint: lots of “1-on-1” meetings)

Audio:

Play in new window || Download

Video:

For a text transcript:

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.

Jason: Right.

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: That’s right, yeah. I think Oracle came out first. They jumped IBM’s, you know, thing. It was all based on…

Max: IMS was previous to RDBMS…

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.

Max: Are you…I mean…

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.

Max: Sure.

Jason: What does it mean if I’m gonna join six files together…six tables together, excuse me.

Max: Sure.

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.

Then I think SQL’s one of those basic things you need to know if you’re gonna be working with Amazon, you know, AWS, RDS, right? You can’t do everything in Mongo…

Max: Can’t do everything…

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.

Jason: I guess so. I’m counting on it. It hasn’t gone away yet. It’s now become a part of lexicon, a standard. You know, there are so many code bases that are stuck with it. You know, the move to NoSQL hasn’t been the stampede everyone thought it was gonna be. “Oh, it’s this cool fantastic thing.” It’s still too young. And it stands for Not Only SQL and not…there’s no SQL. That’s a big…I’ve actually run into people who are like, “Oh, we never use SQL. We’re using NoSQL.” I said, “Well, it actually stands for Not Only.” So you can use it, but there’s other tools as well. I don’t use them particularly often. I don’t get a lot of the calls to do that kind of work. But…

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.

Max: Sure, sure.

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.

Jason: Hopefully.

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.

Jason: Right.

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.

Learn how to learn. Learn what you like. That’s really important. Click To Tweet

Max: So learning independently is kind of a…not such a selfish exercise, but when you’re employed by someone, that employer or that manager has a really maybe also selfish interest in you learning things, too. So…

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.

The more you learn and the more able you are to do your job, the better it is for the company Click To Tweet

Max: Sure, sure.

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.

You do have to negotiate what you learn and its value to the company Click To Tweet

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?

Jason: I delete those emails. I don’t know. I rely on my network of people, you know, for whom I’ve worked before, my previous managers. And I will say, “Hey, you know, I could use your advice on these things I’m doing that I could do better and these things that I think I’m doing wrong.” Feedback I get from my reports. I ask my reports for feedback…

[Crosstalk]

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: Very rarely. The kind of tools…managing people, there’s techniques and things you do, having regular one-on-ones and how you structure those one-on-ones, asking questions that start with what and how, instead of why, learning the psychology of interactions when there’s a power imbalance. Whenever there’s a manager and a report, there’s a natural power imbalance, and honesty sometimes takes a back seat. Because you don’t wanna tell your boss they suck at something, right, even though that’s sometimes the most valuable feedback you can get. So then one of the tools is, “How am I doing? What could I have done better, when we had this meeting?” And it’s easy to get off track, and I think my personal record on one-on-ones is probably 50%, where they go is… Where they go where I think we’d want them to go, sometimes this just turns into a bull session, which is also important. It’s important that, you know, you can just sort of hang sometimes and go, “Phew! Boy, what a week, man!” And you don’t get anything done besides just sort of, you know, shooting the breeze for a little bit. That has value as well, but…

Whenever there’s a manager and a report, there’s a natural power imbalance, and honesty… Click To Tweet

So no, they generally don’t. I have to ask them. And I have to ask them, “What makes you happy? Where do you see yourself professionally in one or two years?” And it’s okay if they say, “I don’t know yet.” “Great. What interests you? What makes you happy? How would you like to be recognized for your work? How would you like your constructive criticism?”

Different generations handle it very differently. I’m a Gen X, and we’re…I don’t know, we’re just different, and the millennial generation does not take to the way we talk to each other. We could be pretty brutal, and we’re very DIY, you know, the do-it-yourself thing, the old Peter Gabriel song. I keep going back to that. You know, and my Gen X friends and I we’re like, “Yeah, I just built this cool thing.” And the millennials do that, too, but we’re brutal with each other about it. “Yeah, you know, that guitar you built, it’s, you know…”

Max: Garbage.

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.

You want to, you know, invent a quieter truck horn maybe. You wanna get into machine learning, which is nascent. You know, it’s not enough to just go download OpenML or whatever, or what’s…whatever Apple’s…

Max: Scikit-Learn, ARKit. I don’t know if they’re machine learning.

Jason: Yeah, ARKit, yeah. MLKit, I think. It’s not enough just to learn the front-end API. You should get in and understand, “Oh, my gosh. I need to go back and relearn linear algebra,” or, you know, multivariate statistics and multivariate calculus, because that’s all parts of ML. I had a recent discussion with an engineer who really wanted to get into machine learning. And I said, “Oh, great. Man, you want some advice?” And they said, “Sure.” And I said, “Go hit your multivariate calculus again.” And he said, “I’ve never heard of that.” He just had no clue what I was talking about. I said, “Oh, okay.”

Max: It’s a subject in colleges and…

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…?

Max: A little bit.

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.

Jason: Yes.

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.

Max: Yeah.

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.

The other problem is if you take an engineer who’s been working for a company for two or three years, four years, and they learn that idiosyncrasies or that company extremely well. They know the API of that company without really understanding all the underlying infrastructure. They don’t really know how to handle, for example, a big join query that’s got six or seven tables that are all joined together and left out of joins, and how to analyze that in Postgres and take a look at what’s the differ… You know, like, they don’t understand the implications of a sequential…

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.

Max: So I guess…

Jason: It’s challenging, and that gets contentious, because he says, “Well, I want the same money that, you know, someone who’s been at it for 15 years gets because they can’t answer the question about our invoicing system and I can.” It’s like, “Well…”

Max: Okay.

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.

Max: Got it.

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.

Sometimes getting the work done is more important than butts in seats. Click To Tweet

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?

Max: Yeah.

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.

Max: I think the phrase “manage up,” while it’s probably pretty, popular lexicon at this point, it might be very helpful for you to explain for the audience what “managing up” means, because…

Jason: Oh, boy. Specifically as a software engineer.

Max: Sure.

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.

So the most important thing, if you’re gonna manage up as an engineer to non-engineers, is learn their language. Don’t speak in terms of, “Well, if we don’t change this algorithm…we’re gonna…” Because all they’re hearing is the Charlie Brown, “Wah, wah, wah, wah, wah,” right? That’s all they’re hearing. If you tell them, “Hey, if we don’t fix this thing, you know, your churn level of customers is going to continually increase because we’re pissing people off.”

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.

Like provide them with the bad news. If you work for someone who can’t handle bad news, find someone else to work for. You gotta communicate the bad news. “Hey, I got into this thing, and I thought it was a 2. It’s really an 8. And it’s gonna take me an extra week to, you know, remove all the uncertainty from the story, so I can actually execute it properly. This story has…I’m speaking in Tracker but it applies to JIRA. This ticket has too much uncertainty. I don’t know what’s going on. I need to do some research and find out, you know, more about the business request or the product request or some technical requirements. I need another three days.” Or, “Hey, this one was easier than I thought. I’m gonna have it done tomorrow.”

If you work for someone who can’t handle bad news, find someone else to work for. Click To Tweet

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?

Jason: Yeah, I have. I think it’s a better work environment when the engineers are very passionate about the company. They want the company to succeed, and they’re very tied into the metrics. I worked with a company recently where the engineers, every time there was an all hands, would raise their hands and ask about business data, KPIs. One said, “What’s the KPI for this quarter?” And couldn’t get an answer, which made some of the folks realize, “Oops! This was coming from engineering.”

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.

Max: I am familiar.

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.

It is good. It’s good when an engineer raises a, you know, a yellow flag and says, “Hey, this thing that you’ve asked me to work on, I don’t think it’s gonna move the needle for the company.”

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: I have, yeah. I’ve seen some great managers do this for every department, you know, in the company. Have sales people go, you know…

Max: Sit with…

Jason: Sit with…

Max: …engineers?

Jason: Whoever.

[Crosstalk]

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?

Max: Oh, sure.

Jason: Like a ride-sharing company.

Max: Oh, that could be one of many.

Jason: One of many. And I haven’t worked there, but I’m just using them as an example because it’s a nice abstraction. Like, this senior-level manager would say, “Hey, Salespeople, go ride with a driver all day and see what they deal with.” “Hey, Engineers, go do the same.” “Hey, Engineers, go on a sales call.” They would mix…they would have people go on each other’s jobs. “Hey, Finance Folks, you know, go sit in the engineering planning meeting for a little bit and see how they approach these problems and see if you can start to create dialogues.”

Institute hack days where everybody in the whole company gets together and comes up with sort of off-the-book solutions that really aren’t on the road map and may or may not solve a primary KPI, but could have an effect on the secondary KPI. For example, “Hey, you know, ARKit just came out. Maybe we can create an app that would allow a driver in this mythical company to pick up their thing and figure out, you know, how many meters or how many yards a landmark is in front of them.”

Max: Sure, sure.

Jason: That sort of thing.

Max: Okay.

Jason: Which…

Max: So hackathons, embedded team members…

Jason: Embedded team members, cross-functional meetings, things like that. So just mix and match the folks in all departments. Keep them from getting isolated. One of the bigger problems is that engineers are usually two or three steps removed from the actual money making at a company, and a lot of engineers who have experience just don’t care. I’ve had people say, “It’s not my problem. Money’s not my problem. I’m gonna go and, like, rewrite everything in Ruby because this stupid language sucks.” So you go, “No, no, no. You can’t do that because it puts a tremendous amount of technical risk and there’s money involved,” you know? And you have to get into this litigation with this well-meaning, but misdirected engineer who… And that’s, you know…

Max: So for these misdirected, youthful, or at least…

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: Right. Well, that was me, once upon a time, you know, when I was…

Max: What changed?

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.

Max: Pre-2000?

Jason: Yeah. Pre-2000, yeah. And explained to me why we couldn’t do it, the time, what situation the company was in, and how we needed to just make it work and keep generating income. And then, maybe someday, someday, someday, we could, you know, fix this stuff. And he said, “In the meanwhile, you just have to suck it up.” And then what I did is I found a new company where the technology wasn’t so bad because I really hated my life and I couldn’t stand it. And in that sense, I was like, “Well, you know, what can I tell you? I’m not the right guy for this job.”

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: Right.

Max: Whether that’s due to other people making changes or replacing systems or acquisitions and…

Jason: Acquisitions or shutdowns and, yeah.

Max: 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.

Max: It’s academia.

Jason: It’s academia. Some of them just, you know…whatever. You’re not always guaranteed to get the best attention because it’s just not the way it works. That comes later. Anyway, it’s written once, it’s read once, and that’s it. It’s not ever used again, and you fall into some terrifically bad habits, right? Writing readable code, which means using idioms that are simple…John Carmack has a great quote, l want to paraphrase it, but it’s basically, “Sometimes all you need is a function.” Not a framework, not a class, right? A function, super simple, super easy. Things like every function’s signature should be similar and should be clear. Naming things should be very specific and coherent, right? And what the name of the thing is should represent what the thing does or what the thing is. Any hidden magic gotchas and you’ve miscommunicated to another human being. Computer still works, but it won’t after they…

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.

So communication is a very, very big deal. You should absolutely aspire to write code that is easily readable…

Max: And will be around for…

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.

But out of that lesson comes, “Boy, I would do this differently this way.” Learn how to be less careless. I once got called out for a Python-swallowing an exception. I was writing some prototype code, you know, make it work, then make it pretty. And I was being careless, and I missed…I basically had, you know…I just caught an exception and then passed. So I swallowed every single possible exception you could possibly get. It was basically, you know, a…

Max: A black hole.

Jason: …exception. It was a black hole. And you know, I always sent my stuff to someone I was working with and said, “Could you have a look at my code?” And boy, he hit the roof. He’s like, “What are you doing? You can’t…” “It was an accident. It was carelessness.” And I learned you really gotta be careful being careless. It’s an easy mistake to make, maybe you’re too tired. Like, don’t commit anything late in the day. Get up in the next morning when your brain is fresh and clear, and look at your code again to make sure there’s nothing, you know, that you’re shooting yourself in the foot at. You know, he admonished me pretty well, and I was embarrassed. And that was a great lesson to have, that I think I would have gotten very defensive, you know, maybe 25 years ago. I probably would have not reacted as professionally as… And I see that a lot in inexperienced engineers. Teaching them that you’re not your code and that accidents happen, but it’s more important to…

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.

Max: That’s happened?

Jason: Yeah, that’s happened, you know, accidentally.

Max: I mean, no names, but…

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.

View on YouTube.