Speaker 1: And we're live for anyone who doesn't know. We also
Speaker 1: live stream this on LinkedIn, YouTube and twitch. At what
Speaker 1: time is it? It's uh what ten thirty Eastern time
Speaker 1: on Tuesday morning? It's two thirty pm UTC. If you're
Speaker 1: not in one of those time zones, you're gonna have
Speaker 1: to do the math yourself. But I love you for
Speaker 1: listening and watching the live stream. Meanwhile, what's up born?
Speaker 2: Hey, thanks for turning that up. And I always get
Speaker 2: the time zones, you know, totally wrong living in Switzerland
Speaker 2: where at plus two UTC at Yeah, I mean some
Speaker 2: of those special ones in North America are quite challenging.
Speaker 1: Yeah yeah. On my team currently, I'm in GMT minus six.
Speaker 1: I have a person in GMT mine three, one in
Speaker 1: GMT plus one, and one in GMT plus two.
Speaker 2: So you know, I only is thickering here because we
Speaker 2: built a product a stand up bought called the stand
Speaker 2: Up and Prosper and it was part of an old
Speaker 2: product that we had built a long time ago, and
Speaker 2: very quickly we realized, you know, we may actually be
Speaker 2: one of those companies that now has to understand really
Speaker 2: lots of intricacies about how time zones work. Because like
Speaker 2: we have to send we'd send messages to people when
Speaker 2: it's eight pm or eight am in their time zone,
Speaker 2: and we try to rely on like the Slack time
Speaker 2: zone for that and it's not always valuable. And then
Speaker 2: we also have to display it an RUIS and also
Speaker 2: get it right on Slack display and trying to schedule
Speaker 2: in a different time zone is always such a challenge there.
Speaker 1: Yeah, I worked at a startup.
Speaker 3: One time.
Speaker 1: We did medical imaging for trauma hospitals on their trauma
Speaker 1: patients and they decided to rewrite the core application in Java.
Speaker 1: We're not going to go down that path, but that's
Speaker 1: what they did. Right the very next time that daylight
Speaker 1: savings time went into effect for the US, we had
Speaker 1: about two thousand trauma patients disappear from our system because
Speaker 1: they didn't account for daylight savings time. So that was
Speaker 1: a good time.
Speaker 2: Yeah, I mean, there are definitely some things where we
Speaker 2: allow events in the future and then we try to
Speaker 2: hide them being displayed, just because prepopulation of data is
Speaker 2: so important for production scale applications because you don't want
Speaker 2: to wait until you know something actually happens before having
Speaker 2: those events in your database. So I can totally imagine
Speaker 2: that they're omitted in the future, so don't display them
Speaker 2: in any of the UIs to users because that would
Speaker 2: be confusing.
Speaker 1: Right. But speaking time, it's that time of year that
Speaker 1: we're coming up on the end of year, the holiday season,
Speaker 1: which can have a lot of it can mean a
Speaker 1: lot of things depending on what industry you're in, how
Speaker 1: your company handles closing the books at your end, and
Speaker 1: so that's what this episode is all about, is just
Speaker 1: kind of I think it's kind of just us talking
Speaker 1: out loud as reminder to ourselves as well as a
Speaker 1: reminder to the listeners of our show that those things
Speaker 1: are coming and to start thinking about them, because we're
Speaker 1: going to be executing those tasks here before you know it.
Speaker 2: You say that, and the first thing that comes to
Speaker 2: mind is when it hits to be cyber Monday, I guess,
Speaker 2: or you know, three weeks ahead of that, because realistically,
Speaker 2: that's when every year it just gets soon and sooner.
Speaker 2: And I remember working at so many companies where someone
Speaker 2: was telling me, you know, something's going to be different now,
Speaker 2: But as an engineer, I'm just like, I don't. I
Speaker 2: don't know what that means. I don't I don't know
Speaker 2: how to what do want to do that information right?
Speaker 1: For me, the hardest part has always been getting that
Speaker 1: information out of marketing because they spend a lot of
Speaker 1: time and effort doing campaigns, marketing campaigns where this's ads,
Speaker 1: email blasts or whatever to build up these big sales events,
Speaker 1: And in doing this for three decades, I have never
Speaker 1: been successful in convincing someone from marketing that, hey, if
Speaker 1: you're gonna funnel an extra two million people to the site,
Speaker 1: did you ever think about giving someone an engineering like
Speaker 1: a heads up?
Speaker 2: Yeah? I mean that's always the most ridiculous thing. I
Speaker 2: think it leads the conversation sometimes in an disappointing direction, though,
Speaker 2: because it goes from like, Okay, well we're going to
Speaker 2: sign out two million emails, but how many? How many
Speaker 2: of those are going to be opened? And then you
Speaker 2: realize by many marketing departments, the answer is we have
Speaker 2: no idea, and it's like, is that two million users
Speaker 2: coming to our site? Or is it two hundred thousand,
Speaker 2: is it twenty thousand? And so a lot of times
Speaker 2: that stuff happens and there's zero impact to the business,
Speaker 2: And the most effective thing you can do is, you know,
Speaker 2: just stop performing those experiments in that way unless you
Speaker 2: actually know what the click through rate is, what the
Speaker 2: conversions are going to be. And that's interesting you say
Speaker 2: that because when we build authors a while back, one
Speaker 2: of the most common concerns we heard from our customers
Speaker 2: that we're using our competitors is how they charge by
Speaker 2: monthly active users. And that means if you sign in,
Speaker 2: you get immediately dinged for a user count that then
Speaker 2: is amateurized through the whole month, which means you're basically
Speaker 2: paying for thirty days worth of your advertisement, which is
Speaker 2: a huge cost, especially when these marketing campaigns go out.
Speaker 2: But yeah, I mean yeah, engineering very rarely knows what
Speaker 2: to do there, and so we went to a pure
Speaker 2: charge by usage, so you know, if they only log
Speaker 2: in once, there's not a problem. But I still think
Speaker 2: most of those marketing organizations they have no idea how
Speaker 2: many users are going to actually come to your site. Yeah.
Speaker 1: I think the big takeaway from that is that I
Speaker 1: chose the wrong career profession. I chose one where my
Speaker 1: performance can be measured. That's my fault.
Speaker 2: Oh you say that, and now I really wonder how
Speaker 2: are you? How are you being measured? Because performance measurement
Speaker 2: in selfware engineering, I think, like anything is, it's much
Speaker 2: more difficult than widget production, which is, you know, highly
Speaker 2: repetitive in which you can actually measure the throughput and
Speaker 2: you know, quality metrics of the individual machine that's that's
Speaker 2: manufacturing those widgets, whether it's human or automated.
Speaker 1: Yeah, from my perspective, since I'm mostly infrastructure based, a
Speaker 1: good bit of my performance evaluation is based on uptime
Speaker 1: and ease of deployment and error rate and things like that.
Speaker 1: But I would I don't have any data to back
Speaker 1: this up, but I would say that a bigger part
Speaker 1: of my performance evaluation comes from perception of the teams
Speaker 1: that I support. Do they feel like they're being Do
Speaker 1: they feel like they're getting the level of support that
Speaker 1: they need? And that just comes down to customer service.
Speaker 1: Recently had a situation on that exact same topic where
Speaker 1: someone felt like they were not getting the level of
Speaker 1: support that they needed, And the only thing I changed
Speaker 1: was at the end of every meeting asking them, Hey,
Speaker 1: is there anything that you are blocked on because you're
Speaker 1: waiting on us to do something, and just doing that,
Speaker 1: just calling it out to attention, you know, was enough
Speaker 1: to change the perception of the performance.
Speaker 2: Yeah, I mean, I think that was one of the
Speaker 2: biggest learnings I had from when I started professionally, is
Speaker 2: I thought that my deliverables as I coded them, as
Speaker 2: I architected them, was worth something. But I knew that
Speaker 2: there was this thing of No, you're judged by politics
Speaker 2: is the word I would use to describe it, which
Speaker 2: I really think is a misnomer honestly, because you aren't
Speaker 2: fairly or equality judged on what your outputs. You know,
Speaker 2: it is really about the perception. And talking with whoever
Speaker 2: is in charge of promoting you is really the first
Speaker 2: important step that everyone really needs to take on day
Speaker 2: one when they get a job. How am I actually
Speaker 2: going to be evaluated and over time whether the things
Speaker 2: you're working on are actually relevant to being promoted or
Speaker 2: even just staying in your job.
Speaker 1: Yeah, for sure, that's the whole like social side of
Speaker 1: your career. Like your technical skills are only part of it.
Speaker 2: I mean, if you can get by working like not
Speaker 2: writing any code every single day and just you know,
Speaker 2: saying like spitting a good game to your managers, you know,
Speaker 2: you can get really really far, so much so you laugh,
Speaker 2: but so much so that there's actually a name for this,
Speaker 2: and it's called effective managing up And you actually see
Speaker 2: a lot of not helpful, probably not good managers doing
Speaker 2: this and that's how they got to those positions that
Speaker 2: they're really effective. It commits other people that they're doing things.
Speaker 3: Yeah.
Speaker 1: Yeah, it's which goes back to your earlier comment that
Speaker 1: is very political in the US, that's the basis of
Speaker 1: our entire government. Without turning this into a political comment,
Speaker 1: let's not go there.
Speaker 3: We shouldn't do. Yeah.
Speaker 1: But so back on topic here, you're in what does
Speaker 1: what does your end look like for you or office?
Speaker 2: Honestly, we don't really pay too much attention to it
Speaker 2: because we don't go through the marketing cycles. Uh, there
Speaker 2: is usually some amount of uptick that actually starts at
Speaker 2: the beginning of the year, especially for for two reasons.
Speaker 2: One for our products that deal more around the ASIC nature.
Speaker 2: So I mentioned we have a like number one or
Speaker 2: two slack bot for handling stand ups. And at the
Speaker 2: beginning towards the end of the year. Beginning of the year,
Speaker 2: there's a lot of vacations. You know, people aren't all
Speaker 2: in office. It's more remote work, and so figuring out
Speaker 2: how to manage your stand ups in an acinc way
Speaker 2: is usually valuable for authors, which you know, obviously is
Speaker 2: our main product. Budget comes in at the beginning of
Speaker 2: the year, and so that's when a lot of teams
Speaker 2: start thinking about more what's going on there, and towards
Speaker 2: the end of the year they're dealing with all of
Speaker 2: the tech debt, all of the mistakes they've made in
Speaker 2: the previous six to nine to eleven months before they
Speaker 2: get to that point. And I think one of the
Speaker 2: biggest ones is the marketing spam, you know, having actual
Speaker 2: users come on board. And I actually remember that earlier
Speaker 2: on in my career, I was working at a company
Speaker 2: that was had billions of dollars in revenue coming in
Speaker 2: every year at the cyber Monday, Black Friday, you know,
Speaker 2: huge deal days, right for getting in lots of users
Speaker 2: to the site, like not even having to ship out orders.
Speaker 2: I mean, the biggest problem is actually the manufacturing world
Speaker 2: having to then turn around and manufacture and then ship
Speaker 2: that stuff out when it's not just sitting on your shelves.
Speaker 2: So much so that I remember that frequently management quote unquote,
Speaker 2: I don't know who these people were, you know, you
Speaker 2: hear it through the grapevine, like it's coming. You know,
Speaker 2: there's going to be a massive wave. You need to prepare,
Speaker 2: prepare for that, so only really important software should be
Speaker 2: done at the end of the year. I feel like
Speaker 2: it's the even more ridiculous version of don't merge code
Speaker 2: on Friday afternoons. This is don't don't even think about
Speaker 2: code between now and after Christmas. And also there aren't
Speaker 2: any people there in the office, so maybe also you know,
Speaker 2: push that out to like, you know, January eighth, so
Speaker 2: from now until January eighth, everyone's on vacation. And that
Speaker 2: just always struck me as so utterly ridiculous that a
Speaker 2: software engineers could anyone really, but I'm gonna blame software
Speaker 2: engineers could determine the difference between like a critical thing
Speaker 2: that needs to get the production and like feature and
Speaker 2: something that's not because you're often driven by that perception
Speaker 2: of this needs to get done, and you're often not
Speaker 2: in the situation of being able to even make that decision.
Speaker 1: Yeah, you know, up until recently, I had never participated
Speaker 1: in the year end code freeze strategy. But at Polygon
Speaker 1: we actually have certain platforms where we do a year
Speaker 1: in code freeze, and it's frustrating to me because I'm like, no,
Speaker 1: just just just know. This is the part of the
Speaker 1: show where I could wish, where I wish.
Speaker 3: It could cuss.
Speaker 1: But but the truth is is where we have some
Speaker 1: very very early stage products and some we've built some
Speaker 1: things that, for all practical purposes, have never been done before.
Speaker 1: So when it comes to monitoring and alerting, we have
Speaker 1: room to improve on that because like, if you've never
Speaker 1: done this thing, how do you know when the thing
Speaker 1: is doing the thing that it's supposed to do and
Speaker 1: how are you going to alert on that? And there's
Speaker 1: there's certain stages where we don't We just kind of
Speaker 1: watch it until we get a like get the pulse
Speaker 1: of it, and then we can put monitoring on that.
Speaker 1: And so that's the I think that's a big reason
Speaker 1: why we're reluctant to do.
Speaker 3: Your end releases.
Speaker 1: And then also, you know, combined with that, like you mentioned,
Speaker 1: a lot of people are out taking vacation and then
Speaker 1: we're completely globally distributed to so we you know, async
Speaker 1: communications are very very async.
Speaker 2: Yeah, I mean there's a platform thing there, right, Like
Speaker 2: if you write games as your company's product, there's a
Speaker 2: validation process, same with I mean similar to if you're
Speaker 2: in healthcare some other apps, if you're deploying a mobile
Speaker 2: app for iOS or Android, there's a turnaround time there.
Speaker 2: And so even if it's even if your company is
Speaker 2: absolutely perfect, we do live in a more just in
Speaker 2: time world, a more agile world where you are depending
Speaker 2: on third party partners. So even if you do the work,
Speaker 2: you know realistically it's not going to be actually able
Speaker 2: to get to production. So rather than having it stack
Speaker 2: up where you're creating a lot of waste there that
Speaker 2: someone still like, you don't want tons of merger requests
Speaker 2: sitting open waiting for someone to come and test and
Speaker 2: review your code. You want to get those production as
Speaker 2: soon as possible. There's no reason to start that work
Speaker 2: because you know it's going to be blocked somewhere. So
Speaker 2: I do totally get that, especially if you're depending on clients, right,
Speaker 2: you actually don't want to do any work unto your
Speaker 2: client already says why is it not delivered already? Right,
Speaker 2: Because if they're not already waiting on you for a chance,
Speaker 2: you're going to do the work and then have to
Speaker 2: wait on your client and then you're like, Wow, those
Speaker 2: three weeks to three months are longer. Unfortunately in some
Speaker 2: concern cases that I'm sure you've got well, that you
Speaker 2: could have been doing something more valuable in that time.
Speaker 3: Yeah, for sure.
Speaker 1: That makes me think of doing mobile development and getting
Speaker 1: your app approved to go into the Apple App Store?
Speaker 1: Is that three days? Is that three months? Who knows?
Speaker 3: Is it consistent?
Speaker 2: Nope?
Speaker 1: It could be one right after the other every single time,
Speaker 1: and that makes it really challenging to roll out new features.
Speaker 1: And then compounding that, just because you release a new
Speaker 1: version in the App Store doesn't mean people are going
Speaker 1: to update. I remember when I was active, we had
Speaker 1: a very very small group of people, I mean less
Speaker 1: than ten that hadn't updated their app in two years.
Speaker 1: They were running on a two year old version of
Speaker 1: the app and perfectly happy, but it was causing us
Speaker 1: some painful technical debt. And we finally had our marketing team.
Speaker 1: They did a marketing and customer service. They jumped through
Speaker 1: all kinds of hoops to actually figure out who these
Speaker 1: people were, and then I think they were able to
Speaker 1: contact them and ask them and send them a gift
Speaker 1: card or whatever to upgrade their app.
Speaker 2: I got two great stories on that point. Actually, the
Speaker 2: first one is having built a very technical API. People
Speaker 2: talk about deprecating old stuff, but realistically, if you write it,
Speaker 2: you should just pretend it's never going to get removed.
Speaker 2: It's so much like the amount of churn challenge, complexity
Speaker 2: of trying to convince your customers, as you described, to
Speaker 2: make a change there where there's zero, like, there's negative
Speaker 2: value in making the change. Right, it's all work, it's
Speaker 2: working today. Why would they why would they realistically change?
Speaker 2: It's just not worth thinking about in most cases. And
Speaker 2: there are so many companies I've worked with who had
Speaker 2: this mindset of, oh, we'll get them to change, and
Speaker 2: so they then have like five or six versions, like
Speaker 2: one every couple of years. Every time there was a
Speaker 2: new engineering lead team you know, owner of that product
Speaker 2: roll out something new. And so we started having version
Speaker 2: numbers in our endpoints and things like that, and so
Speaker 2: you see all of them available in production. Still some
Speaker 2: of those companies I worked with, you know, they still
Speaker 2: have those oldest versions still there because they don't have
Speaker 2: that amount of pull within their organization with their customers.
Speaker 2: So actually, one of the things we did when we
Speaker 2: wrote Authoris is that we just completely discarded that notion,
Speaker 2: like there are no versions, it's will be like this
Speaker 2: forever likely. It's it's so totally unrealistic. Now, we do
Speaker 2: make some changes where we then like update our documentation,
Speaker 2: we may remove reference to fields that we still support,
Speaker 2: but we don't remove them because the amount of overhead
Speaker 2: it goes in it is really high. The other thing
Speaker 2: I'll say is I am totally that person that has
Speaker 2: old apps on their phone, like from multiple and I
Speaker 2: think there's sort of like a two sided extreme here
Speaker 2: where both of them are not great. It's there are
Speaker 2: tons of apps out there that every single time there's
Speaker 2: a new version, it's like you must update to use
Speaker 2: the app, and I hate it. And I'm gonna call
Speaker 2: out Signal in Google because they both do this. They
Speaker 2: tell me all the time, Hey, there's a new version Google.
Speaker 2: At least you can skip it. But the pop up
Speaker 2: always happens at the wrong time where I'm like, can
Speaker 2: you interact with me at the end of my workflow
Speaker 2: because then I'll accept the upgrade, and Signal just says no,
Speaker 2: I'm sorry, you can't look at your messages until you upgrade.
Speaker 2: And that's just an incredible pain and I totally get
Speaker 2: the other side where people are using the app multiple
Speaker 2: years later. I'm just so afraid of it breaking something
Speaker 2: or draining my battery life because I can't trust these
Speaker 2: apps and there's no way to stop them from interacting
Speaker 2: with the Google Play integrations to get battery hell or
Speaker 2: send messages, notifications, et cetera.
Speaker 1: Sure that's the I'm the same way, Like as a developer,
Speaker 1: I'm like, why are these people not updating? But as
Speaker 1: a user, I'm like, I'm not updating that it's working
Speaker 1: just fine. There's no way I'm going to risk this
Speaker 1: thing breaking.
Speaker 2: I'll tell you a secret. And maybe this is letting
Speaker 2: the cat out of the bag here. I upgrade apps
Speaker 2: when something looks like it doesn't work, and I won't
Speaker 2: know why it doesn't work. So you could, for sure
Speaker 2: if you had some way of feature flagging, like a
Speaker 2: couple buttons just breaking in a weird way, right, Like
Speaker 2: you know, I use Plex and if you hit the
Speaker 2: like you know, if I hit the play button and
Speaker 2: it like pauses it or you know, starts playing and
Speaker 2: it like does it weird jump in the video and
Speaker 2: it keeps like it just starts happening, I'll be like,
Speaker 2: oh man, I got an upgrade. So that's the secret
Speaker 2: for convincing your users to upgrade is really, you know,
Speaker 2: have something where they don't think is really your fault,
Speaker 2: that you would have done intentionally to get the benefit.
Speaker 1: And now if you productize that as a service, you've
Speaker 1: got you next huge startup idea.
Speaker 2: Yeah, graceful like non graceful degradation. And yeah, we like
Speaker 2: our core metric for our ICP would be like the
Speaker 2: number of broken apps we have in production at that moment,
Speaker 2: right our customers are currently destroyed the user experience of
Speaker 2: one million users that could.
Speaker 3: Be that's funny, write that down right.
Speaker 1: But meanwhile, back to your end, Yeah, because that was
Speaker 1: our chosen topic till we wandered off, I.
Speaker 2: Think it's really challenging.
Speaker 1: Yeah, So in my mind, there's a couple of different
Speaker 1: categories of things that you have that come up at
Speaker 1: your end. One of which you brought up that I
Speaker 1: hadn't remembered until you brought it up is budgeting for
Speaker 1: the next year. So you got to start campaigning for
Speaker 1: whatever it is you want to do and building a
Speaker 1: use case so that it makes it into the budget.
Speaker 1: And then like we already mentioned potentially depending on your industry,
Speaker 1: increase in traffic for your end sales and special and
Speaker 1: you know, for a lot of companies that's just largely
Speaker 1: a scaling issue, Like, yeah, I've got auto scaling, it's fine,
Speaker 1: but I always like to go ahead and just kind
Speaker 1: of cross check everything before we get to that point,
Speaker 1: because we've probably made a lot of changes throughout the
Speaker 1: years since we last tested this really hard, and so
Speaker 1: I just want to make sure that we didn't inadvertently
Speaker 1: turn something off that we were counting on or something
Speaker 1: like that. And then their category for me is like
Speaker 1: ye're in closing of the books, you know, which in
Speaker 1: my mind that's that's a financial thing, but I also
Speaker 1: think there's an infrastructure side of it too.
Speaker 3: It's a good chance to.
Speaker 1: Check all your backups and your data retention policy and
Speaker 1: you know, restore from backups into a dev network and
Speaker 1: validate those and just make sure that all of that
Speaker 1: stuff is working as well.
Speaker 2: Yeah, I mean, you don't want to be that Australian
Speaker 2: pension fund company where they lost all of all of
Speaker 2: their one hundred billion dollars worth of financial bookings for
Speaker 2: all of the citizens of the country because they were using.
Speaker 3: One cloud platform that.
Speaker 2: Decided to be extra helpful in setting up their environment
Speaker 2: one day. So I don't know if you know the
Speaker 2: story here, but apparently yeah, so apparently there was an
Speaker 2: internal So the first the first knit is that they
Speaker 2: were using VMware and on prem which I totally get,
Speaker 2: I've been there. But then they wanted to do a
Speaker 2: lift and shift, so they did it and were hoping
Speaker 2: that the cloud of choice we're going to offer them
Speaker 2: VMware as a service, and they did so they shifted
Speaker 2: to GCP and the problem was the configuration that GCP
Speaker 2: provided for VMware was not sufficient to meet their needs
Speaker 2: memory ram zpu, I don't know what it was, and
Speaker 2: so they filed the support ticket to ask for them
Speaker 2: to basically create a sphere cluster for them manually. And
Speaker 2: if you've ever built a technical product that has a
Speaker 2: high requirement on reliability or quality, you'll know that the
Speaker 2: thing that you really want to do is make sure
Speaker 2: you go through the public interfaces. And if the public
Speaker 2: interfaces don't support that, then you know that someone's going
Speaker 2: to have a bad day sometime future. And realistically, it's
Speaker 2: a it's a good reminder where requests from one team
Speaker 2: to another one like the support team to the ops
Speaker 2: team or product engineering team should be quick to resolve
Speaker 2: either know we're never going to do that, or support
Speaker 2: it or yeah, of course we'll get that in in
Speaker 2: this case updating whatever public API. They had to be
Speaker 2: able to utilize it to actually generate the cluster in
Speaker 2: a needed way. But instead of going through that in
Speaker 2: the good old fashion and we can do it ourselves strategy. Uh,
Speaker 2: this is the team responsible for solving this task for
Speaker 2: the pension fund. UH ran some scripts to dynamically generate
Speaker 2: a cluster using a tool that was built for non
Speaker 2: production environments to automatically self implode after a period of time.
Speaker 2: Uh that you the default was one year and uh,
Speaker 2: you know, probably to stop probably to stop development environments
Speaker 2: from consuming a lot of resources after they lost their value.
Speaker 2: And it was used for this, and so a year
Speaker 2: later after creation of their environment, it disappeared, just as
Speaker 2: decided by the engineers of this internal tool.
Speaker 3: Nice.
Speaker 4: Yeah, so you know, if you may need to look
Speaker 4: all the way back to what happened last year at
Speaker 4: this time and use it as a metric for what
Speaker 4: could possibly be going wrong.
Speaker 2: I remember one year at one of the companies I
Speaker 2: was working with. We had a production outage soon after holiday,
Speaker 2: and that's who we called it. And it was related
Speaker 2: to the fact we had a table called calendar table,
Speaker 2: and I kid you not, the calendar table ran out
Speaker 2: of days and so it crashed production for all of
Speaker 2: our one thousand windows services that we had running. And
Speaker 2: the calendar table, you know, may sound like it's a
Speaker 2: pretty clever thing, but I what it actually was is
Speaker 2: a day count number as the index, followed by the
Speaker 2: day of the week that that day was, and that
Speaker 2: was the whole table. And so if it didn't know
Speaker 2: what today was, it wouldn't know what the day a
Speaker 2: week it was, so it wouldn't be able to do
Speaker 2: planning to figure out how much actual planning, both on
Speaker 2: the manufacturing side but also planning how many people that
Speaker 2: needed to be in the office manufacturing plan in order
Speaker 2: to run the plan effectively. And so the fix, of
Speaker 2: course was to insert more dacent the table. And of
Speaker 2: course the fix was someone runs a sequel script that
Speaker 2: just inserts, you know, one hundred thousand more rows into
Speaker 2: the table and no one thinks about this problem. Ever.
Speaker 1: Again, this sounds like mayan calendar as a service.
Speaker 2: I guess I guess. You know, maybe the lesson learned
Speaker 2: here is that when it comes to the end of
Speaker 2: the year, things are going to break it away.
Speaker 1: Yeah, because there's always always things like that where someone
Speaker 1: you know hard coded a year or didn't you know
Speaker 1: they're doing like math between months and then so whenever
Speaker 1: the month number decreases, it screws something up. And that's
Speaker 1: a really good point. Those are things too. I don't
Speaker 1: know that you can effectively look and identify those ahead
Speaker 1: of time without just a complete audit of every piece
Speaker 1: of code that you have, but it's something to keep
Speaker 1: in mind after the at the end of the year,
Speaker 1: when you go into the new year, when something starts
Speaker 1: acting really weird, don't rule those kinds of things out.
Speaker 2: I wonder if there's a framework that could actually be
Speaker 2: used and executed here, like like the thing to do
Speaker 2: on January second is control shift F through your entire
Speaker 2: code base or grock or whatever you're using and search
Speaker 2: for like WTF or slash slash to do and see
Speaker 2: what actually comes up.
Speaker 3: That's a great idea.
Speaker 2: Just schedule a reminder, like every team could potentially do this.
Speaker 2: I mean, I hate these comments. They don't there's so
Speaker 2: completely worthless in a lot of ways because it's like
Speaker 2: there's something wrong with the code that I'm looking at,
Speaker 2: but I don't know, I'm too lazy to do something
Speaker 2: about it, or there's just a time bomb here waiting
Speaker 2: to go off. At least explain what the problem is, right,
Speaker 2: like what am I looking at? Why is this weird?
Speaker 2: Why is it confusing? And maybe twods are okay, but
Speaker 2: realistically I feel like either it's something you want to do,
Speaker 2: in which case you know, file a ticket, or be
Speaker 2: like this is intended behavior. And actually one of the
Speaker 2: things we do is we add an explicit log statement,
Speaker 2: so we don't actually implement those cases, but we do
Speaker 2: log whenever there's a weird thing that gets hit, so
Speaker 2: it doesn't instead of WTF, it's like WTF, like log
Speaker 2: track this message? Why is this even happening? And someone
Speaker 2: should investigate so that if we do hit that use case,
Speaker 2: we know to do something, and if we never hit it,
Speaker 2: no one.
Speaker 3: Has to care. Yeah, for sure, I tend to.
Speaker 1: You know, I can't say I've never created those, but
Speaker 1: I have gotten better over time at in the comments
Speaker 1: putting heywill or if you're reading this, so that it
Speaker 1: kind of stands out and then try to set the
Speaker 1: stage so that future me knows why past me screwed
Speaker 1: me over like.
Speaker 2: This, Yeah, yeah, I totally hear you. I'm definitely Like
Speaker 2: there's lots of paragraphs related of content and comments in
Speaker 2: front of things that just aren't super obvious if you
Speaker 2: look at them, like why are we comparing this to
Speaker 2: the number seven, for instance, and like you don't want
Speaker 2: the comments like we compare this to the day of
Speaker 2: the week, Like that's not helpful, Like it's helpful when
Speaker 2: you explain why from a business standpoint or a product standpoint,
Speaker 2: this whole code section is split this way. Like if
Speaker 2: you're doing a like a merged sort or any sort
Speaker 2: of sort algorithm, or you're trying to find a maximum
Speaker 2: value or a minimum value or some arbitrary P value,
Speaker 2: Like don't say, oh, we try to find the P
Speaker 2: value of ninety nine, Say we want to find the
Speaker 2: P value of ninet ninety because and then fill that
Speaker 2: out so that you're actually explaining why the code is
Speaker 2: the way it is, because often that's not going to
Speaker 2: be included in the ticket. Maybe it is that generated,
Speaker 2: but usually not. And obviously you don't want it to
Speaker 2: jump to that or look at the code comment that's
Speaker 2: that's related there.
Speaker 1: Yeah. I think it was Don Felker that had to
Speaker 1: tweet a really great tweet that said that comments should
Speaker 1: explain why you're doing something, not.
Speaker 3: What you did.
Speaker 1: The code itself tells you what you did, but the
Speaker 1: comment should tell you why you chose to do that.
Speaker 2: Yeah, for sure, one hundred percent agree. But I don't
Speaker 2: think anyone's going to explain to my previous senior engineer
Speaker 2: who is working on a different team in a previous
Speaker 2: company at the end of the year, who at my
Speaker 2: request to not run production software on their own machine,
Speaker 2: decided to run production software for on their own machine
Speaker 2: for a critical piece of software for the entire company,
Speaker 2: And during a long vacation break in the company, the
Speaker 2: cleaning staff unplugged the machine and crushed the service. I
Speaker 2: kid you not. And the really ridiculous part about this
Speaker 2: story is it was actually right around a holiday. Like
Speaker 2: it was not not a good story. The ridiculous part
Speaker 2: is we were migrating to AWS at that time, and
Speaker 2: this particular engineer, who I actually think was a like
Speaker 2: a equivalent of a staff or senior staff right now,
Speaker 2: said I don't understand why we're going to aws. We
Speaker 2: have working software on prem in all of our data centers.
Speaker 2: That's sufficient. We have you know, x or it's running
Speaker 2: these data centers. And well, I think that statement sort
Speaker 2: of stands for itself.
Speaker 1: Yeah, I'm sure you've seen the meme of like the
Speaker 1: laptop where the lids partially closed with the sticky note
Speaker 1: on it that.
Speaker 3: Says, this is a production server. Please don't close lid.
Speaker 2: It's not a joke. Like I have seen that in
Speaker 2: my career like four or five times now, Like somewhere
Speaker 2: I am. That is a thing, And it's always in
Speaker 2: places that have a really experienced engineering division, and they
Speaker 2: have engineers in not experienced engineering divisions or staff that
Speaker 2: aren't it focused who were forced to install something and
Speaker 2: run that application themselves. So if you're on an OPS
Speaker 2: team and you tell one of your customers, hey, we're
Speaker 2: not going to do that for you because that's not
Speaker 2: our job, this is what they go and do. They
Speaker 2: go and install that production requirement that the marketing software
Speaker 2: that ends out all the emails to your customers on
Speaker 2: a single laptop somewhere and put a sticker on it
Speaker 2: and then actually find out about a problem. Like I
Speaker 2: would be sitting somewhere there'll be a laptop there and
Speaker 2: someone will go over and unplug it and I'll be like,
Speaker 2: you just turn that off? I have no idea why
Speaker 2: it was like that. It's weird, Like you should know
Speaker 2: that it was weird. Why did you do that? And
Speaker 2: then like two hours later, someone will randomly show and
Speaker 2: be like, hey, this laptop. Did you see what happened here?
Speaker 2: Did someone like turn it off? Like what happened? This
Speaker 2: has to stay on? And we're like, I don't know.
Speaker 2: Someone just came over and unplugged it and then laughed, right.
Speaker 1: And my favorite part is when that happens is someone
Speaker 1: gets really mad that you had the audacity to turn
Speaker 1: off that laptop, like how dare you turn off a laptop?
Speaker 1: It's like, wait, no, why are you running production software
Speaker 1: on a laptop? That's the core issue here. It's not
Speaker 1: the fact that I turned it off, it's the fact
Speaker 1: that you're running production software on your laptop.
Speaker 2: Yeah, you know. I try to think of it from
Speaker 2: a multiple perspectives. If there's a way to some how
Speaker 2: put myself in their shoes of they just don't have
Speaker 2: an understanding of what the criticalness is or the interim,
Speaker 2: the lack of flexibility, the likelihood of this causing a
Speaker 2: problem of the actions they're taking. I think human beings
Speaker 2: by nature are so myopically focused on short term and
Speaker 2: not deal it thinking about the long term. But also,
Speaker 2: I mean, we're the ones in the position of thinking
Speaker 2: about reliability and the operations of the software that's running
Speaker 2: and how to keep it reliable, and you've got to
Speaker 2: imagine that other people are not. Yeah.
Speaker 1: Absolutely, it's so hard to look at things from other perspectives.
Speaker 1: Oh for sure, because like, whenever I'm doing infrastructure work,
Speaker 1: you know, I'm pretty tightly focused on you know, high availability,
Speaker 1: fault tolerance, redundancy, all of that kind of stuff.
Speaker 3: But then.
Speaker 1: Like the next day, I can be writing code and
Speaker 1: you can look at the code that I'm writing and
Speaker 1: be like, has this guy ever heard of high availability?
Speaker 1: Because you just get so focused on solving that problem
Speaker 1: and fail to step back and think, wait, what other
Speaker 1: what other pieces do I need to make this?
Speaker 2: That sounds like there was a story there.
Speaker 3: Oh, there's probably a lot of stories there.
Speaker 2: And it's those that like at the time, you're just like,
Speaker 2: I'm all read in the face I'm like, I can't
Speaker 2: believe this is happening right now. I have to totally
Speaker 2: chill out. And they're the ones that make for the
Speaker 2: best laughs later. I mean, maybe it's a little cliche,
Speaker 2: but those really terrible experiences that you're you're gonna have
Speaker 2: between now and the end of the year, Uh, they're
Speaker 2: great stories. Like I got another one. We were the face.
Speaker 2: I was running a team that was the face for
Speaker 2: our customers U I and a bunch of back end services,
Speaker 2: and we didn't get any public praise. Is all about
Speaker 2: the perception like our stuff just ran no problem, And
Speaker 2: when it came time for the end of the year
Speaker 2: and increased load, we would often say, we don't need
Speaker 2: to do anything. We've looked at last year and the
Speaker 2: year before, and also what's happened in the last couple of months,
Speaker 2: and it looks like we have tons of capacity. What
Speaker 2: we're going to do, anyway, is just allocate twice as
Speaker 2: much capacity for no reason whatsoever and just run like that,
Speaker 2: because who cares. It's our infrastructure. We've done a lot
Speaker 2: of cost auto optimization, so we don't have to worry
Speaker 2: about if a couple of months or even a week
Speaker 2: or so we just bite the bullet there and it
Speaker 2: was always a good idea, but totally unnecessary in almost
Speaker 2: every situation. That's one team now we dependent on. The
Speaker 2: reason we were so we were so critical of the
Speaker 2: organization is because we depended on a lot of services
Speaker 2: from other teams who did not write such reliable software,
Speaker 2: who were not as concerned about soft were services that
Speaker 2: would never be interacted with directed by the customers. So
Speaker 2: we had a lot of things in our code like
Speaker 2: automatic retries, acing processing, pre caching, loading from cash like.
Speaker 2: We would call lots of services and they would fail,
Speaker 2: and then we would have really complex workfloths to figure out,
Speaker 2: like predict what the value was going to be in
Speaker 2: order to utilize it in most cases where we could.
Speaker 2: I mean, obviously you can't do it in every case,
Speaker 2: otherwise you wouldn't need the service. However, there was this
Speaker 2: other team who had problems. Every single week, there was something.
Speaker 2: It was always firefighting one hundred percent, and because it
Speaker 2: seemed like they were constantly under pressure, that means there
Speaker 2: were also constantly solving problems, which gave them a positive perception,
Speaker 2: and when it came to a huge load, their services
Speaker 2: would always get pounded into. So the moral of that
Speaker 2: story is actually two more teams had to be spun
Speaker 2: up just to support the load of when something went wrong.
Speaker 2: So a support to teams in a support organization to
Speaker 2: talk to customers and deal with integrations, because those software
Speaker 2: issues of having a service that's not reliable have real
Speaker 2: reaching impacts to customers, and they got rewarded for that,
Speaker 2: which has just always been not a thing I've looked
Speaker 2: kindly back in my career over but they would say
Speaker 2: the most ridiculous things ever where, Like on the surface
Speaker 2: may sound really intelligent, but if you dig down into it,
Speaker 2: it's like, so, here's one. We know that there should
Speaker 2: be high load all the time that we often can't handle,
Speaker 2: so when there's no load, in order to make up
Speaker 2: for it, we know that load is going to come later.
Speaker 2: So whenever we experience a drop in volume, we scale
Speaker 2: up all of our services as much as we can
Speaker 2: to prepare for that waterfall that's coming next. And on
Speaker 2: the surface, it's like, well, that's actually kind of clever.
Speaker 2: You know, if you expect one hundred requests per second
Speaker 2: and you don't get any or ten seconds, well where
Speaker 2: did those thousand requests go? Someone was maybe hoarding them
Speaker 2: for that period of time. I mean, that's at least
Speaker 2: the thought. However, you also realize, well, like that's not
Speaker 2: really a good sustainable scaling strategy. You might as well
Speaker 2: just figure out how to deal with the burst load
Speaker 2: when it comes in, you know, figure out use asynchronous
Speaker 2: software to use services that will actually allow you to
Speaker 2: support pulling or pushing that load off and so you
Speaker 2: can actually normalize the curve over time. Don't rely on
Speaker 2: superstition or tradition to determine what your scaling policy should be.
Speaker 3: Seems reasonable, you know.
Speaker 1: That type of scenario makes me think, and I think
Speaker 1: this is specific to the topic of today, of your
Speaker 1: end preparation, where you have a lot of different pieces
Speaker 1: coming together. There can be certain scenarios where it's useful
Speaker 1: to create a temporary team and pull in people from
Speaker 1: different disciplines, different teams that are just focused on that
Speaker 1: temporary problem. You know, like say, okay, we know that
Speaker 1: we're going to have a massive increase in traffic because
Speaker 1: of the holiday sales this year, and that's going to
Speaker 1: impact that's going to be driven by marketing, but also
Speaker 1: it's going to affect the mobile app team and the
Speaker 1: back end API team and the infrastructure team bears the
Speaker 1: brunt of that. So rather than try to manage all
Speaker 1: of those separately, it's often a good good time to
Speaker 1: just pull key people from those teams into a temporary
Speaker 1: team and set their scope. Your scope is to manage
Speaker 1: this incoming load and make sure that we're successful at
Speaker 1: handling it from our customer's perspective. And then after that
Speaker 1: event's passed, the team disbands and goes back to their
Speaker 1: normal job.
Speaker 2: Yeah. And I think a product a project team in
Speaker 2: that regard, in that situation is like the one time
Speaker 2: where it actually makes sense. And as long as they're
Speaker 2: not they're not building anything. They're actually trying to prevent
Speaker 2: problems by using only what's already available. And because there's
Speaker 2: no long term output really from that process, you don't
Speaker 2: have to worry about disbanding. And at the end, like
Speaker 2: that's a really good idea.
Speaker 1: Yeah, And I think one of the reasons it's successful
Speaker 1: is because you clearly define the scope. And when I
Speaker 1: talk about defining the scope, I'm talking about not only saying, hey,
Speaker 1: this is what you're going to be focused on, but
Speaker 1: you have full authority to say no to everything. That
Speaker 1: is not that thing, which is really important. I've seen
Speaker 1: that a lot throughout my career. We say yes to
Speaker 1: things almost with like this hidden assumption that there's always
Speaker 1: more bandwidth available, So we'll do everything that we were
Speaker 1: doing plus this new thing. And at some point you
Speaker 1: reach critical mass where you in order to say one
Speaker 1: more yes, you have to say one more no to
Speaker 1: something else that you're not going to be doing.
Speaker 2: I actually put it stronger. Everyone should be at that
Speaker 2: point already right now, whether you think you are or not.
Speaker 2: Like if you like, even if you think you have
Speaker 2: three pre capacity, you probably don't. I know it may
Speaker 2: feel like that, but realistically, I know as individuals we're
Speaker 2: very bad at evaluating our own free capacity and be
Speaker 2: able to do things. And if you actually had free
Speaker 2: capacity to do extra things, do the thing you're doing
Speaker 2: more like faster, like why is it just not already
Speaker 2: getting done? There's no reason to put something else in
Speaker 2: that spot. So I think realistically, everything you do something
Speaker 2: next like I would always use this, especially for inexperienced
Speaker 2: engineers at the beginning of their career. You know, we
Speaker 2: should solve this, we should fix this problem, we should
Speaker 2: refactor this code, we should switch to. Now it's Rust,
Speaker 2: which I can finally get behind. But it used to
Speaker 2: be you know, have assembly, or we should switch to
Speaker 2: whatever fancy new version of React that's out there. I'm
Speaker 2: so happy we don't use React office for so many reasons.
Speaker 2: There are so many better alternatives. And I'd always say
Speaker 2: the same thing, like, you know, great, we can absolutely
Speaker 2: do that. Which thing that you're working on right now?
Speaker 2: Do you want to stop working on so that you
Speaker 2: can work on that instead? And really having that priority
Speaker 2: first conversation, because well, most of the time of the
Speaker 2: year may actually be practiced, it doesn't matter if they
Speaker 2: pick up this extra thing. It really helps to think
Speaker 2: about the priority order. So when huge important events come up,
Speaker 2: like the end of the year closing or whenever you're
Speaker 2: end of the year closing in, or if you have
Speaker 2: a big marketing event, whenever that happens, whether you can
Speaker 2: know or not, it really is the production version of
Speaker 2: can I prioritize effectively?
Speaker 1: Yeah?
Speaker 2: For sure.
Speaker 3: So that's a.
Speaker 1: That's a it's sort of along the same topic here.
Speaker 1: You talked about, you know, Rust, and a lot of
Speaker 1: times as we talk about end of year and we're
Speaker 1: looking at projects for the coming year, and there a
Speaker 1: lot of times there is a topic, you know, like
Speaker 1: oh we should we should rewrite this in rust, or
Speaker 1: we should rewrite this in you know whatever.
Speaker 3: You know, you can pick whatever.
Speaker 1: How do you go about making the case for that, Like,
Speaker 1: if you're campaigning for time and budget for the coming year,
Speaker 1: how are you going to structure that campaign?
Speaker 2: I mean I get to make those decisions, So I
Speaker 2: guess I should. I'll I'll put this maybe in the
Speaker 2: flip side of like what I'm looking for when someone
Speaker 2: comes and excellent point to create this whatever that change is.
Speaker 2: I mean, I don't feel like I go out and
Speaker 2: hire engineers, Like that's sort of like a skill capability
Speaker 2: you have. Maybe you're systems thinker, like you're able to
Speaker 2: understand how doing one thing impacts doing another thing. Yeah,
Speaker 2: for sure, you can write in some a couple of
Speaker 2: different languages, But realistically, the teams exist to solve some
Speaker 2: business problem. That's why they're there. And so looking at
Speaker 2: the business problem short, medium, and long term is what
Speaker 2: I care about. So you know, tell me a story
Speaker 2: that solves short, medium and long term problems. So maybe
Speaker 2: there's a problem today and it needs to get resolved,
Speaker 2: and so you know, you want to deliver quick little
Speaker 2: improvements today, you know, what does that look like to
Speaker 2: solve that? And then medium you want to do you know,
Speaker 2: a bigger project to make sure that we never have
Speaker 2: to worry about that again. And long term, like why
Speaker 2: are we even discussing this problem? Like this problem is
Speaker 2: too small scale for us. It should get automatically solved
Speaker 2: by what we have, by our infrastructure, by a single
Speaker 2: new feature ticket. And so think about conveying those things
Speaker 2: when discussing potential ideas of what to work on. So
Speaker 2: the change to rust, talk to me about error budget,
Speaker 2: Talk to me about speed of delivery for new features.
Speaker 2: Talk to me about maybe they're all ability of what
Speaker 2: we have, the quality of what we have, the ability
Speaker 2: to deliver new things based on the frameworks that are available, etc. Etc. Right,
Speaker 2: the actual impact of doing that and nothing comes for free? Right?
Speaker 2: You know, I want to know the cost of if
Speaker 2: we make this switch, how long are we going to
Speaker 2: pay paying the cost? Short term, medium term, long term?
Speaker 2: And I got to see some benefit there. Now. I
Speaker 2: don't expect a perfect financially planned strategy for every single
Speaker 2: part of the process, but some thought has to have
Speaker 2: gone into it. Right, how many engineers know about this
Speaker 2: programming languages? How many of them want to know hiring
Speaker 2: in the market is.
Speaker 3: A challenge there?
Speaker 1: Right?
Speaker 2: Maybe maybe not? Do we have big projects coming up
Speaker 2: where we already started with something we have and now
Speaker 2: we need to potentially put that on hold in order
Speaker 2: to do the switch, or we'd have to write it twice. Right,
Speaker 2: So they's throwaway work, and an understanding of that tells
Speaker 2: me that you've thought enough about this problem that I
Speaker 2: could let you go and run with it, can delegate
Speaker 2: it to you effectively. Otherwise you're basically saying I want
Speaker 2: someone else to solve this problem. Right when you come
Speaker 2: up with a problem and you share with someone else, Hey,
Speaker 2: we should do this thing, try to figure out what
Speaker 2: you're doing. Right. Are you complaining about it I don't
Speaker 2: like X, or are you saying I want you to
Speaker 2: fix why? Or are you saying I want to do this?
Speaker 2: This is what it will look like. This is the
Speaker 2: impact to the team and the organization, and then I'll
Speaker 2: say great, sounds good, or if it's a bigger impact
Speaker 2: of the business and some way, it'll probably get into
Speaker 2: our initiatives for the next quarter and our quarterly planning
Speaker 2: and they will just show up there and someone who
Speaker 2: is most relevant to be working on that at that
Speaker 2: moment may or may not be you. Right, you know,
Speaker 2: just because you came up with a good idea doesn't
Speaker 2: mean that it makes sense for your team to work
Speaker 2: on it. We'll take over and start running with it.
Speaker 1: Yeah, for me, the starting point of all of those
Speaker 1: conversations has to be one of two things. How does
Speaker 1: this increase revenue for the company or how does it
Speaker 1: decrease operating costs for the company?
Speaker 2: I think you're maybe being a little bit too unfair there.
Speaker 2: I mean, I totally agree that should be the actual
Speaker 2: impact at the end of the day, Like, it has
Speaker 2: to be one of those two things realistically. I mean
Speaker 2: there's also social capital as well, right, Like, maybe you're
Speaker 2: scaling up longer term and hiring additional people is important.
Speaker 2: So you know, maybe you've got PHP or Ruby you're
Speaker 2: using and you want to sell it's difficult for us
Speaker 2: to get engineers. It's difficult for us, you know, two
Speaker 2: or three years down the line, we're going to have
Speaker 2: to make this switch at some point. It has nothing
Speaker 2: to do with the operating cost today or making future
Speaker 2: making revenue right now, but longer term there's a lot
Speaker 2: of trade offs. I it needs to be thought about,
Speaker 2: but like you don't have to come to the table
Speaker 2: with like this is the number of dollars that we're
Speaker 2: going to say now maybe, I mean, will your boss apparently,
Speaker 2: I mean it's much better, right, you know, if you
Speaker 2: could actually do some sort of analysis, you know, feel
Speaker 2: free to take that. But it's sort of the thing
Speaker 2: where like a pull request on architecture, you don't need
Speaker 2: to come with the code perfect all written for the
Speaker 2: whole feature. You know, I have some idea. Should I
Speaker 2: even start thinking about what the next step is here?
Speaker 2: Or should I forget about it? Like, you know, give
Speaker 2: me some feedback because this is a good idea to
Speaker 2: switching to RUSS maybe a good idea. And I will say,
Speaker 2: could be maybe you know, tell me about it. And
Speaker 2: then you say, I actually don't know, let me go
Speaker 2: do some investigation. I'll be like, okay, sounds good.
Speaker 3: Yeah. Now I'm still stuck on those two I think.
Speaker 2: You know, for a long time I was as well.
Speaker 2: The thing that broke me was companies that focus on
Speaker 2: some sort of social good which is neither necessarily cost
Speaker 2: reduction or revenue generation. So if there's a tragedy of
Speaker 2: a common situation where you want to get out from
Speaker 2: under it, you know, take the climate crisis, right, we
Speaker 2: have a thing that's neither revenue nor cost. I mean,
Speaker 2: of course, you can model the the criticalness of our
Speaker 2: direness of our human society at this moment, it's a
Speaker 2: huge problem. You could measure the rate of temperature asmospheric
Speaker 2: increase or oceanic temperature increase as your metric they're going after. So,
Speaker 2: I mean, whatever it is for your business, right, you know,
Speaker 2: if you're making money, then for sure, I'll say profit,
Speaker 2: not necessarily revenue. Both of them are bad metrics for
Speaker 2: different reasons, depending on how you're abusing them, right, And
Speaker 2: you're right startups care about revenue, not profit, and real
Speaker 2: companies care about profit and not revenue. But you could
Speaker 2: just be making a lot of money a return on
Speaker 2: investment that really isn't worth it. So you know, what
Speaker 2: is the important thing for your company? I totally agree with.
Speaker 1: You, will, yeah, for sure. And that's probably something that
Speaker 1: happens in my mind that I don't express enough is
Speaker 1: whenever I talk about currency, it's not always dollars. It's
Speaker 1: the product itself. Like if you're an open source company,
Speaker 1: you don't sell your software, but you still have a currency.
Speaker 1: The currency is the number of people who download and
Speaker 1: use your software and build on top of it. So
Speaker 1: when you talk about increasing when I talk about increasing revenue,
Speaker 1: it may not be US dollars or euros, it's whatever
Speaker 1: currency measures the success of your product.
Speaker 2: So Solona or Ethereum.
Speaker 1: Yeah, or Polygon, you have your you have your own
Speaker 1: toke gun we do yeah, Matic okay, yeah, yeah.
Speaker 4: So yeah, that one, that's that's that's the most.
Speaker 2: Important currency to to actually own, so to measure everything
Speaker 2: in madic and then you'll know whether your idea is
Speaker 2: a good one.
Speaker 1: But that's that's a really good point because as we're
Speaker 1: an open source company. Yeah, and so for us, the
Speaker 1: currency is getting people to build on the Polygon network.
Speaker 3: Matic.
Speaker 1: The token itself is actually a byproduct of that. That's
Speaker 1: just a an exchange ticket that all of these people
Speaker 1: who build on top of our network use used for transactions.
Speaker 1: The success of Polygon itself is building a network that
Speaker 1: enables people to do that. So for us, revenue is
Speaker 1: the number of people adopting the Polygon network as their
Speaker 1: blockchain framework or blockchain.
Speaker 2: I mean, I mean it is money in a way.
Speaker 2: Each transaction that happens is you're getting the revenue out
Speaker 2: of that that the number of transactions can be your revenue, right.
Speaker 1: Right, Yeah, And the actual ematic monetary mattic associated with
Speaker 1: that goes to the validators who Polygon is some of
Speaker 1: those right now, but mostly is other people. So we're
Speaker 1: we're even only partially affected by that, with the longer
Speaker 1: term goal of not having anything to do with that.
Speaker 2: I mean, arguably it's not even necessarily relevant for you.
Speaker 2: I mean, that's happening outside. You're a contributor in some way,
Speaker 2: and so whatever that is is more important than what's
Speaker 2: necessarily happening in the network. I mean, well, the network
Speaker 2: is super critical and important for success, it may not
Speaker 2: be something you can directly affect, right.
Speaker 1: Cool, So all right, closing thoughts on your end.
Speaker 2: You know, I never met an engineering team where if
Speaker 2: I said, like, you know, today, you've got to do
Speaker 2: everything differently because it's a particular set of numbers on
Speaker 2: the calendar, and then actually went and made some fundamental
Speaker 2: changes in their process. I don't think it really works
Speaker 2: that way. Unfortunately, like you it's not like you change
Speaker 2: how you're doing code reviews. You're not all of a
Speaker 2: sudden more secure. You don't automatically change what you're doing,
Speaker 2: or maybe you add extra reviewers. You don't change the
Speaker 2: values of your team, the identity, or your processes just
Speaker 2: like that. I think preparing for this is a cultural chef.
Speaker 2: It's what happened throughout the whole year that got you,
Speaker 2: that makes you prepared for situations like this. As well
Speaker 2: said testing your backups, other out of band processes that
Speaker 2: you want to validate, or potentially building specific teams that
Speaker 2: have an identity that matches the execution you want. But yeah,
Speaker 2: telling software developers to you know, don't commit as much
Speaker 2: code it doesn't doesn't whole lot of water.
Speaker 3: Yeah, I would agree with that.
Speaker 1: I think for me, the big takeaway is it's a
Speaker 1: good time of year to pause, think about it, figure
Speaker 1: out how it applies to your situation, and then take
Speaker 1: action away from that may have an impact, it may
Speaker 1: not have an impact, but I think it's worth taking
Speaker 1: a moment to just stop and think about it because
Speaker 1: we get, you know, so focused in the day to day,
Speaker 1: like today, I'm focused on these tickets and here's the thing,
Speaker 1: And so I think the big takeawy for me is just.
Speaker 3: The call out.
Speaker 1: Today's ticket is to take a step back and look
Speaker 1: at things from an entire organizational perspective.
Speaker 2: I mean, I think that's a really good point that
Speaker 2: is lost. I was reading a paper about improving based
Speaker 2: on training and the tickets. The standard work is sort
Speaker 2: of your production mode. You're doing the work, you're delivering it.
Speaker 2: In order to become better or even sustain yourself, you
Speaker 2: need a practice mode. You need to go where there's
Speaker 2: it's safer to learn new things even and when do
Speaker 2: you actually deliberately go and do that. If you don't,
Speaker 2: then you're going to just you're burning your ability to
Speaker 2: deliver effectively. And could be a good reminder that at
Speaker 2: the end of the year it's time to start doing
Speaker 2: some things deliberately that's different than your standard strategy. Actually
Speaker 2: thinking about how you do that work or what it is,
Speaker 2: and even a simple thing like validating some of your
Speaker 2: processes huge benefit.
Speaker 1: Yeah, for sure, even if you're Yeah, maybe especially if
Speaker 1: you're junior in your career. It's a good training exercise
Speaker 1: because as you advance in your career, these things are
Speaker 1: going to be more relevant to your role. So it's
Speaker 1: a good chance to think about that and then have
Speaker 1: that conversation with your manager or your boss and start
Speaker 1: gaining some perspective that way to help yourself.
Speaker 3: Later on in your career.
Speaker 2: Yeah, for sure.
Speaker 3: Cool. Should we do some picks?
Speaker 2: Yeah?
Speaker 3: All right? Which good?
Speaker 2: So I've been playing a lot of one particular game
Speaker 2: since the summer Steams sale. I bought a couple, and
Speaker 2: I mean, I am I just like keeping old apps
Speaker 2: on my phone. I'm playing games from years ago because
Speaker 2: they're cheaper, and I don't mind playing out of date content.
Speaker 2: It's like thirty more years and I'll probably play Breath
Speaker 2: to the Wild. Okay, So my my pick this time
Speaker 2: is actually a game called frost Punk. It's the best
Speaker 2: way I can describe it is it's a rts against
Speaker 2: the cold weather climate, and you, instead of trying to
Speaker 2: defeat an alien race or some other civilizations that are
Speaker 2: out to attack you, you need to deal with the
Speaker 2: temperature rapidly decreasing in a ridiculous scenario, and so as
Speaker 2: a resource collection and et cetera. Except but you know,
Speaker 2: civilization building, it's not not that you like you link
Speaker 2: get to like six hundred people or something so good
Speaker 2: number And it's not technically an RTS, but I think
Speaker 2: RTS against the weather as how I'll categorize it right
Speaker 2: on cool, it's good, it's really stressful. I'll say, like
Speaker 2: I I will go at like actually during the day
Speaker 2: because I played it into the night, you know, And
Speaker 2: I'm not signed kind of person that gets stressed over things.
Speaker 2: But if you ever, like worked, and you said something
Speaker 2: that you felt like was stupid to your manager, and
Speaker 2: or you didn't you didn't think it was stupid, but
Speaker 2: then your manager said something it made you feel like
Speaker 2: what you said was stupid, and then you think about
Speaker 2: it all the way into the night and while you're
Speaker 2: sleeping on it. Like, that's what happens to me with
Speaker 2: this game.
Speaker 3: Gotcha, I am.
Speaker 1: I don't hardly play games anymore, and I do miss
Speaker 1: it because I used to love playing games. But the
Speaker 1: few times I've gone back to play games, like, my
Speaker 1: skills are so rusty. I just suck so bad that
Speaker 1: it's not even fun. The exception to that, I'll have
Speaker 1: to actually make this my pick. Did you ever play
Speaker 1: the half Life series?
Speaker 2: I did not.
Speaker 3: I loved the half Life series.
Speaker 1: That was just such a great game for me, and
Speaker 1: I've got the Oculus VR headset, and so there's a
Speaker 1: new relatively new this game is several years old.
Speaker 3: Now. There's a new addition to.
Speaker 1: The series called Alex that's in VR, and the game
Speaker 1: mechanics of it are just so well done. When you
Speaker 1: put on the headset, whenever you pick something up, you know,
Speaker 1: you get the little vibration slap in there, and it's
Speaker 1: very intuitive, you know, you put the headset on and
Speaker 1: within like thirty seconds top, you're completely immersed in this world,
Speaker 1: having tuned out the real world that it's just that
Speaker 1: well done. So, wow, that was a cool game.
Speaker 2: So no Half Life three, but there's a subset for VR.
Speaker 2: I mean, that's gotta be the biggest joke of them all.
Speaker 1: Yeah, yeah, no half Life three, but there's four add
Speaker 1: on expansions for Half Life two and the side quest
Speaker 1: half Life Alex.
Speaker 2: Wow, that's that's a very ridiculous.
Speaker 1: You know.
Speaker 2: I used to play all sorts of games, many different kinds,
Speaker 2: and I never really figured out what time of gamer
Speaker 2: I was, And over time I realized there are certain
Speaker 2: things I just don't want to feel like work, and
Speaker 2: so like a lot of games I realized just became
Speaker 2: work like like RPGs that are the JRPG style just
Speaker 2: felt like like boss grinding, just so much work. Lots
Speaker 2: of games just ended become like resource management games, just
Speaker 2: like a lot of extra Like I just spent all
Speaker 2: day thinking about architectures and software and then I go
Speaker 2: home and I'm playing basically a game where I have
Speaker 2: to do something. It's just a huge nightmare. And so
Speaker 2: like trying to really narrow down the types of games
Speaker 2: I play. I did play fps IS for quite a
Speaker 2: long period of my life. Though.
Speaker 3: Yeah, I hear what you're saying on that.
Speaker 1: I'm the same way, Like I don't want to be
Speaker 1: challenged in the game. I'm not here to level up.
Speaker 1: I'm looking for more of like an interactive movie. No interesting,
Speaker 1: that's my gaming style. I want to be entertained.
Speaker 2: If there's no plot to the game, that's like immediately
Speaker 2: I don't know why I'm playing this as well be
Speaker 2: playing with a fidget toy. So that's for sure number
Speaker 2: one requirement. The second one is it's gotta like I
Speaker 2: almost don't like combat, honestly, like it just it feels
Speaker 2: so as like an extra chore. Puzzles, I like, I
Speaker 2: like puzzles in a game, so like those two things
Speaker 2: super important for me. But most of the other things,
Speaker 2: like if I got to do the same thing over
Speaker 2: and over again, I'm just it's not for me. So
Speaker 2: it sort of eliminates a lot of things, like I
Speaker 2: don't know how people do the rogue like games like
Speaker 2: The Diabolos, which you just go into the dungeon and
Speaker 2: murder a bunch of things over and over again.
Speaker 3: For hours time Slaughterfest.
Speaker 2: I mean, I've done it. You know, it's sort of
Speaker 2: interesting the first couple of times, but after that, it's
Speaker 2: like I've seen the story, I played the game, is there?
Speaker 2: I mean, maybe this is a second ending somewhere. You know,
Speaker 2: it's got to be something at the end that you get.
Speaker 2: I used to be achievements driven, but after I realized, yeah,
Speaker 2: it's pretty much just extra work.
Speaker 3: I don't get anything for it.
Speaker 2: Then. I mean, if a game pulled me, if I
Speaker 2: get through all the achieved, they would give me like
Speaker 2: like a tenth of my money back. I would totally
Speaker 2: do that. I would play the game longer. I would
Speaker 2: definitely play all the game through for sure.
Speaker 3: Yeah, would you do it?
Speaker 1: For like social validation achievements like you get this, you
Speaker 1: get this special icon on LinkedIn or whatever.
Speaker 2: I did the Xbox achievements way back, a long time ago.
Speaker 2: I did. I tried to do all of them. I
Speaker 2: used to be a completionist, and the game that broke
Speaker 2: me was Assassin's Creed. I absolutely love the game. I
Speaker 2: know everyone's going to telp me. If you've ever played, oh,
Speaker 2: two and three or three and four, whatever, you know,
Speaker 2: the ones with scot artillery are so much better than
Speaker 2: then what was his name, Desmond playing al Tayer, But
Speaker 2: I'll say that much better. But there were a thousand
Speaker 2: of these flags in the game. We had to go
Speaker 2: around and find all of them, and there's no indication
Speaker 2: of where they are or which ones you've gone. So
Speaker 2: even if you know where all the flags are, you
Speaker 2: have to go to every single location in this giant
Speaker 2: open world in order to actually find them. And I
Speaker 2: just like, after the third time of going through literally
Speaker 2: the whole game, in every single place where every flag is,
Speaker 2: and I still couldn't find some, I'm just like, that's it.
Speaker 2: I'm done. And I realized, like, who is looking at
Speaker 2: these achievements like they're a sort of for me, like,
Speaker 2: I don't have like tons of friends who are like,
Speaker 2: oh wow, Warren has all the achievements for all of
Speaker 2: these games like social validation. I mean, what is that so.
Speaker 1: Supermodel sliding into your DMS? Hey, I saw your achievement there.
Speaker 2: I mean, if that happened, I think I'd be a
Speaker 2: different person today. But so I guess it's safe to
Speaker 2: say that never happened. I mean I don't know, you know,
Speaker 2: I guess I wish I had lived your life will
Speaker 2: where you know, that was something to look forward too.
Speaker 3: That keeps the voices in my head entertained.
Speaker 2: So that's what's important, right, Well, there are all there
Speaker 2: are all all the voices.
Speaker 1: In your head. Sure, yeah, go with that, all right, cool, Warren,
Speaker 1: thank you Free Time. It's great with you today, and
Speaker 1: thank you for listening to this episode. And we'll be
Speaker 1: back next week. I don't actually know what next.
Speaker 3: Week's topic is. I have no idea, but uh, you
Speaker 3: will all be surprised.
Speaker 1: Yeah, all right, thanks everyone, We'll see y'all.