Programming Throwdown - Technical Arguments

Episode Date: July 1, 2018

Sunday is a non-traditional day for a new episode and this is definitely a non-traditional episode! Today we are talking about Technical Arguments. We cover the most common arguments/debates you will have on the job as a software engineer and how to make the best arguments to reach the best decisions with the least amount of friction. Patrick and I tried not to inject our own opinions, but it's hard not to add our two cents (yes, spaces really are better). This episode is the first of a potential new genre of show, where we talk about non-technical facets of being a software engineer. Listen to this episode and report back on whether we should do more shows like this one! If you want us to stick to our existing formats (technical topic and interview) let us know that too! Show Notes: https://www.programmingthrowdown.com/2018/07/episode-79-technical-arguments.html ★ Support this podcast on Patreon ★

programming throwdown episode 79 technical arguments take it away jason hey everybody so this is going to be an interesting episode. You know, we do every episode in one take, and this is going to be no exception. But this is going to have, it's going to be a pretty wild one. So, you know, usually we're covering a language, we're interviewing somebody, and, you know, we've talked to them beforehand. So we kind of know, you know, they're a subject matter in X and we know we know X pretty well This is gonna be something pretty different. We're gonna talk about arguing You know not in general although that might come up like more like I guess philosophical stuff But but really about arguing at work. We've both been in tech for a while Seen a lot of the canonical arguments. We'll kind of go through a lot of them

But I want to talk about blockchain. I actually took the time to really understand how blockchain works. So I'll spend a couple of minutes on that, like the actual technology. And Patrick, you can kind of fact check me on this. But basically, you know, when we did the blockchain episode with Amy Wan a while back, I had just started learning about blockchain. And one of the things I asked was sort of how do you keep somebody from just saying, oh, everyone gave me a million dollars, right? And what I learned is under the hood, there's this thing called basically a hash list. I think it's also called a Merkle tree or whatever, but the important takeaway is, you know, in this chain of events, every chain has the hash of the block before it.

And so what that means is, you know, you take that, let's say you're at block n and you have to make block n plus one. Well, block n plus one will have a hash of block n in it as part of the block. And so, but then if you think about it, it becomes this sort of recursive thing because block n has a hash of n minus one and n minus one has a hash of n minus two, so on and so on so on so forth so let's say you decide to change block you know two and give yourself a million dollars right for you to do that you have to change all the blocks afterwards right like you have to change everything because as soon as you change something um you know then the hash of the thing after that is different and that hash is part of the next hash and so it just it ends up being this huge thing

that you have to change um and and and doing that change like adding a block is is hard right i mean i won't go into a lot of details but it's something that will take your computer a long time and so you know people are constantly adding these blocks the change getting longer and longer there's a ton of machines out there, and basically you just can't really keep up and you can't just make a change in the middle without progressing all the way forward to the present. And you can't really catch up to the present by yourself. So for this reason, this is sort of how the system kind of heals itself. If I go and even if I can, there's a whole bunch of things around how to mine go and even if I can,

there's a whole bunch of things around how to mine the block and all of that. But let's say I get super lucky and I can mine a block. You know, I can't say, oh, you know, everyone gave me a million dollars because, you know, other people aren't really going to validate that. And then while they're trying to reconcile all of that, more blocks are getting added and i'm not going to be able to to add blocks as quickly as everyone else can well the simple way to to state that though is you need people's identities are tied

to a public key and you need a private key signing uh the transaction that that says you transferred a million dollars so if you mine a block and put all of these fraudulent records in, they wouldn't be cryptographically signed correctly. So you couldn't say Patrick gave me a million dollars because I'm the only one who has the private key that could sign such a message that you would include in your block. So if you made up one and put it in your block and then other people fact-checked you

they would realize that that block was invalid yeah you're right that's true as well yeah um but then the uh and so then the merkle the tree the the chain comes in from the fact that someone else could mine on top of my fake block but they're disincentivized to do that because they won't get the reward if it's if the majority of nodes participating don't accept that as a valid path if they basically say hey somebody has an invalid block here and anything after that block is also invalid then right you're incentivized to make to sort of fact check other people so that if you complete your mining of a block you will emit a block which is on top of one that doesn't later get invalidated. Right. But then so yeah, I agree. There's the there's the public private key thing. But then you need more like you also need the

proof of work and this whole like hash tree, because you could say, well, if I have the private public key, then what do I need all this other stuff for right and so so yeah i think you're right so let's say there's a list of sort of valid transactions right um at some point you still have to decide which sort of valid transactions you want to execute in the next block and that's where um you know if you limit it to the scope of valid transactions that's where the stuff i said originally right has an effect like like i can't just put all the blocks on myself and take all the credit for all those transactions because you know i'm having to solve this difficult problem and uh there's a whole bunch of other people doing it at the same time well the reason for

having the proof of work is is to say that that's exactly right like people are incentivized to sort of continue this chain on in a way that sort of adds credence to earlier things in the chain and they're incentivized to do that to do work and if it was if there wasn't a proof of work it would be too easy to just sort of make infinitely many of these things and and you would just get lost in the noise and so you see need some mechanism for sort of controlling the rate right yeah so it kind of makes sense i'll definitely read up uh maybe next month uh you know i'll post some links to the things that kind of explained it the best because i've read a bunch of them and uh you know obviously some are better than others but overall i was yeah it was really interesting it was a fascinating thing um you know i think i would love to see you know there

is some like i think it's called steamed but there's like a forum that's based on blockchain which i thought was pretty cool and uh it was a bunch of bunch of really neat stuff coming from that technology so your explanation of chain, also describes why you hear about cryptocurrency forks. So there's like Ethereum forked into Ethereum and Ethereum classic. Bitcoin has forked several times. And this is where people say you have if you had Bitcoin, now you have a Bitcoin and a Bitcoin cash token because there was a fork. And people talk about hard forks and soft forks. And those are basically paths where at some point in time, people say at block number n plus one, we're going to switch something in our code. And other people say we don't want to.

And there basically becomes a hard fork. There becomes two blocks minted with the same predecessor node. But then some group of people both authenticate those chains going forward. And so now you have two paths that were common at some point. So they diverge, they fork, and then they continue on. But from that point on, they don't always have the same sort of value relative to fiat for a cryptocurrency, or they have their own set of conditions that make or don't make sense so in the case of like ethereum versus ethereum classic whether the like dow the automated uh thing which had the hack whether that happened or not essentially in one they tried to undo that in the ethereum and in

the ethereum classic they said no that makes no sense to undo that i'm greatly simplifying so it makes no sense to undo that that was a valid thing happen. And so we're going to continue on saying as if it did happen. And so now the two chains diverge. They're hard forked from each other. So at some point, will one take over the other? Like, how does it? No, I mean, take over isn't the right. They can't because like you just described these chains.

There's no mechanism for sort of joining them. But one could be worth more than the other. So like Ethereum is worth more relative to fiat relative to us dollars or euros than ethereum classic because more people think that that's the right choice i guess um okay but this has different implications of whether you're talking about a cryptocurrency on the blockchain or a different use um so so take but then takeover is anybody could you could create a fork of bitcoin if you wanted you could just come up with a new set of parameters mine do the proof

of work mine the coin and you know declare yay verily this is jason's jason coin as a fork of bitcoin um that's what i always but then you have to convince somebody it's worth something oh that's the hard part you have to convince somebody to's worth something. Oh, that's the hard part. You have to convince somebody to join on your chain, right? And start building on it and then accept it as valid trade from other people. Okay, that makes sense. But you could do that. And then I think the term soft fork is where basically something changes, but the entire consensus agrees and also moves along with the change oh okay so

basically nobody bothers like mining the coins that would have been on the previous trajectory yeah so they're just they become worthless well just yeah just nobody ever bought there's no market for them yeah and so it's considered a soft fork versus a hard fork is some set of people agree to continue on to your chain oh i see oh it's interesting yeah that's wild but a soft fork happens every time i think basically every time you change some of like some parameter or an algorithm for how to do something yeah that makes sense because then some machines who don't have that change right will mine the wrong way and everyone else will mine it the right way is that right yes well right

and wrong is perspective but the way that dominates yeah um the way that holds the value i guess all right on to news um this is pretty cool so this is open ai 5 um which is basically uh there's a game uh you know um alpha go played go better than, you know, the world champion. And so there's always been, you know, sort of the frontier of AI seems to be now, you know, playing these video games and basically passing the Turing test on these video games. And OpenAI 5 is sort of the next iteration or the next evolution of that. So there's a game called Defense of the Ancients 2. It's called Dota 2. And it's a five-on-five game.

And so that presents a lot of really interesting challenges, right? So, you know, in theory, well, depending on the rules and what the AI is allowed to do, I mean, you could say, oh, let's have one brain for all five players, one AI for all five players. In a way, it's kind of cheating. But even beyond that, it turns out it's not very practical because that AI has to do exponentially more decisions. It's like, for example, just to keep it really simple, let's say you can go up, down, left, right, right?

But let's say there's two players. Well, now I could go up and you could go up or I could go up and you could go up, down, left, right, right? But let's say there's two players. Well, now I could go up and you could go up, or I could go up and you could go left. So now there's 16 actions. It's not eight, it's 16, because all the combinations, right? And so making one AI for all the five players is not actually that good. So what they did is they actually created an AI that can communicate and send some signals to the other players, the other AI. Or it's really to itself because it's one sort of brain that's just been replicated five times. It's really interesting. There's a lot of technical detail.

So I'm kind of hand-waving a lot of that. But basically, it's really amazing. Also, they ran it on a ton of machines, so they really scaled it up. And they just have all these machines cranking through all these defensive ancient games. And they were able to beat some amateur human players. So, I mean, this isn't like world-class stuff yet or anything like that. But it's still good i mean um uh you know being able to beat an average an average human is is an amazing accomplishment and um

they also develop some pretty interesting you know kind of um like altruistic strategies you know so one of the one of the issues with ai is that it's very sort of self-centered and so you know one of the ways a lot of these systems would fall apart at least early on is that it's very sort of self-centered. And so, you know, one of the ways a lot of these systems would fall apart, at least early on, is that, you know, there wouldn't be sort of coordination and altruism. And if one person was in any amount of danger, they would just run away. And then the humans would just pick them off one by one. Now there's definitely some coordinated effort. There's players players you know the ai make sacrifices sometimes and things like that um it's pretty amazing i have to admit uh so i'm i'm in this field i mean this is what i do for a living and so i am really really shocked that uh um that

this much progress was made in this amount of time it's truly truly remarkable and so it's it's gonna be really really fascinating to see uh you know where this all goes and did they this you know this research they did in this paper obviously like is very difficult relative to like the amount of hidden information the number of choices to make where they find like any sort of what they thought was the reason to not continue to make even like not just beat amateurs but beat pros it's just like processing power algorithm. Like they give it. Yeah, that's a good question. I think so. Okay.

I still don't think that they're the game. Theoretic part is being handled correctly. Right. So, so for example, if you look at, if you look at Dota, you know, the, the, the characters are stereotyped, right? So there's a carry who's supposed to carry the team, but basically they're the ones who are supposed to collect as much money as possible. You're not allowed to give money to your teammates, so they have to earn it.

But the goal is to make the carry earn as much money as possible and not the other players on your team. Then there's the support, and the support is responsible for for buying let's say all the items so so so the idea of altruism is baked into the character archetypes right and i think even in the model they they you know basically hand hand tune that right um and so then the the the real emergent altruism in in dota is this idea of like lane changing so for example uh for people who don't know dota real quick there's there's three little lanes like imagine like three little highways um all this battle this battle is sort of going on on these three highways and you're usually in one of them but you can spend some time to switch lanes and so

for example let's say you're in the middle lane and the left lane uh there's a there's an enemy who's really weak in the left lane maybe he got hurt or something right you could try to go across to the left lane and and catch him um you know uh trap him and kill that that hero and then you get a lot of money um and so you know this there's this idea of like oh if if uh if the opponent is sort of beating up on me uh you know i'm gonna kind of take take some hits and things like that and let the opponent think he's sort of doing well meanwhile my teammates are switching lanes and all of a sudden there's going to be four people attacking this one guy. He hasn't really expected

it. So, so there's sort of this like strategic, I guess I'll say strategic altruism or strategic coordination. That's something that AI does not do. Um, that is notably missing. And, and until they get that, um, it's, it's not going to be very good. So what I expect, if I was to predict the next thing that these folks would work on, I think they're going to really take a look at the game theoretic part of this. And they're going to try to do some kind of approximate Nash equilibrium or some opponent modeling or something like that so that at a high level, they can get this coordination, this altruism that they don't

have at the moment. At a tactical level, they have it, which is really surprising, actually. I watched one video where this player kind of got behind the enemies and then kind of trapped them and the player who trapped them you know ended up like not really being able to get a lot done but because he trapped them you know the other players on his team were able to go in and kill them all and so that kind of like tactical coordination altruism they've been able to crack that which is a surprise but the strategic part they're still missing so yeah it's it's uh it's really really cool i mean i i wouldn't be surprised i mean i thought that this was way far out and now i'm starting to think that this could happen in the next like three four years the yeah robot overlords are coming we're all doing yeah that's right yeah

and then then they're going to take this ai and put it on the stock market and then okay microsoft announced this month that they're acquiring github uh that's wild yeah this was really surprising to me when i saw the news not because it just clearly seems sort of weird like microsoft buying github like why um but people pointed out like there are some you know decent reasons and and you know we'll see sort of what happens long term but uh you know microsoft is not the company that you know when i sort of i don't want to call it like coming of age when i was sort of went to college and first started working as a programmer everybody loved to hate on microsoft and i guess in retrospect they did make a lot of bad decisions around that time. But they've come a long way.

And they really, you know, I've been looking through the list of things they've done recently. And they really have sort of seemed to kind of turn a page, which is pretty remarkable for a tech company to have been around as long as them and still be sort of in the running for, you know, impact on a day to day basis for people. Yeah, well well they replaced the CEO that was really when things turned around yeah and and the new guy I won't I'll mess up his name if I try to say I'll try I think Satya Nadella is that's pretty close all right sounds right to me um but he yeah so he does he's been doing a great job and you know they've they've bought github and continued to say like you know providing tools for job and you know, they've, they've bought GitHub and continue to say like, you know, providing tools for developers and, uh,

and integrating and they do a lot of open source work. They contribute a lot to, I guess, to Linux stuff. People were even saying, um, and bringing that into windows as well. So, uh, you know, initial gut reaction is like, what? No. Oh. And there was some reports of, you know, projects fleeing GitHub and onto other things other things um to avoid whatever um another part of this that a lot of people don't talk about i'm kind of surprised is is you know github made atom the the yes id and um microsoft released the visual studio code which is a fork

of atom and um and atom is unbelievably popular i, I bet Atom is really eating into their Visual Studio business to the point where they had to make Visual Studio Code. And so that's another thing is they really took a big IDE like off the table, you know, or at least they own it. So they turned it into a win-win. So they have announced that they believe that they are committed to maintaining both visual studio code and adam despite the fact that they're competing yeah i believe it so they came out later and did say they but yeah this is an interesting thing um i i don't have the the acquisition price i never know when they list acquisition prices if

those are i saw seven and a half billion i don't that's true i don't know how yeah how speculative versus real they are um i guess maybe they have to disclose because they're a publicly traded company um but yeah so the there's a high acquisition price and you know i hope it works well i like github i initially didn't really understand it or get it but but now i i like it and use it and we use it some for some peripheral projects I work on. And like the flow that they have for submitting code and reviewing code and managing projects has come a long way than when I had first was exposed to it. Yeah. So it's making improvements. And I know for open source projects, I mean, versus source versus source forge, which is what I used to know.

Yeah. Yeah. it seems to be you know crushing it so yeah i mean it's a very very solid product yeah it was pretty funny this idea like oh we're gonna leave i i don't feel threatened or i don't feel like my projects are threatened at all by this i mean i mean what what could they possibly do so i mean i guess some people didn't or people think about github as being you know just this bastion of open source and i guess it really is but they do a lot of closed source stuff as well and i mean i'm sure that's where all their money comes from is selling to companies for on-site licenses selling for companies to uh you know have private repositories um i mean that's their i don't even know if they

have donations for other stuff but i i mean they probably can't amount to much um so i'm sure they have a few really big companies that make a lot of money off of this and that's always been or they make all their money off of a few relatively large accounts is my guess that's typically how that stuff works out um and and my guess is that people never really thought about that because it happened sort of behind the scenes it wasn't the face of it but now and github was a startup you know they were a company um and now the fact that microsoft bought them though exposes you to this notion of wait but there is a company behind all this with profit motives and you know a desire to make, you know, product and sell it.

And so most of the people I saw were recommending going to GitLab, where if I understand, GitLab actually does open source the hosting itself. Like you can run for free your own GitLab instance. Oh, I didn't know that. I believe that's the case. So they are also a company, but I believe it's more along the lines of traditional open source companies where they open source it and then they hope you sort of like, you know, contract them for hosting of the data or for, you know, support or adding features. But I don't quote me on that, but I believe it's more in line with that style of project versus. That makes sense.

Or you need to integrate it with your like user system, and they charge you for that or something. Yeah. But GitHub itself was never really... It helped open source, but it wasn't itself open source. Yeah, that makes sense. Cool. My article is... This is a trick.

Families earning $117,000 a year now qualifies low income in California's Bay Area. So people probably know this. Patrick and I live in California's Bay Area. Obviously, I mean, there's like your gut reaction, which is, you know, that's that's that's crazy. But I actually want to talk a little bit about sort of like diffusing Silicon Valley, not diffusing as in like shutting down, but diffusing as in you would diffuse like water or something, right? So, you know, you're already starting to see it, but it's very slow. And yeah, I'd be really curious, Patrick, to hear what you think about, you know, I mean, a big part of Silicon Valley is communication over the internet, right? And so it seems like, you know, these big companies could at least move, you know,

branches of their organization to other cities and things like that. And, you know, that would fix or that would address this income issue, you know, traffic and all these other issues. But, you know, you never see it. Like you always kind of say, well, this is going to happen. You know, I always kind of expected it, but it it hasn't happened yet and so now i'm starting to think um that you

know it's just maybe it's just there's something like magical i guess about being physically close that makes these uh companies all want to consolidate in one spot right yeah i mean eric schmidt from google uh i i mean i heard him talk once and someone you know mentioned this like why does google feel that it has to have everybody in the bay area living or coming to mountain view you know it's a tech company they make all their money on the internet like this makes no sense like why everybody in one location um and you know he didn't have really a great answer for it. But then they asked us, like, what about this cost of living?

Like, this isn't sustainable. He's like, yeah, basically people have been saying that since, like, I want to say he said, like, the early 90s. I believe he came from, like, Sun Microsystems before going to Google. And so, like, he had been in that area for a long time. So I kind of expect he probably knows. But he's like, yeah, people have been saying that the Bay Area is overpriced and expensive and will never last for you know i guess three decades at least now um and they have gone through a couple boom bust cycles like obviously the dot-com crash

the 2008 housing crisis so although that that second one didn't really affect us if i recall correctly i didn't to the same degree. I mean, it did, but not in the same magnitude as a lot of other places. Yeah, I mean, I think it was like 20% versus other people were hit with like 50%. Yeah. So, I mean, there have been slight corrections. But in general, yeah, it's been just ever-increasing cost of living here. And as far as I know, and a lot of the articles around this mention this,

which is an interesting observation if you don't live in this area. And as far as I know, and a lot of the articles around this mentioned this, it's, you know, which is an interesting observation if you don't live in this area. In general, in California, some things are more expensive, like gasoline is more expensive. But you also, in my experience, coming from not in California, I drive, I don't have to drive as far. Well, California as a whole, it's pretty big, but the Bay Area tends to be pretty compact relative to a lot of other areas. Not obviously living in a big city, but so you don't need to drive as far as you don't spend as much.

So it's a little bit of a wash. But obviously there's a state tax that's pretty high. Not all states have taxes, but by far and away, the biggest thing is the actually housing cost. So housing is just really expensive. And the reason why you see something crazy like $117,000 a year, $117,000 per year could be considered, you know, low income is, is if you look, most people say you're not supposed to spend more than 40 or 50% of your income on housing. And if the median house, I believe I saw in San Francisco is now $900,000 for the median. Yeah.

You know, if you sort of calculate out how much you're spending, you know, and rents are commiserate. If you look at how much you're spending, that's a large driver of that is strictly just housing. Right. Right. Yeah, I think. So, yeah, yeah, The housing is really large. But but, you know, the the Facebook and Apple and Google and Amazon and all these companies are building even more offices in the Bay Area. So it's pretty clear to me that that these companies see, you know, that the marginal value is still very very very high for having your employees local um and and i agree with you like no leader has really you know given like a good reason you know i have heard things like um they say that if you're um uh what was this oh i

don't know if this is that relevant but they they said that basically, if you're in a different, if you're more than I think 100 yards away, or if you're in another city, it's basically the same, like in terms of, you know, you don't walk over and talk to someone if they're in a building that's 100 yards away. There is a time zone issue that is very real um so so it may be the only way to expand is is vertically um like like portland seattle redding la san diego like um to eliminate the time zone but yeah i just i can't imagine that the personally i can't imagine that the the value of having your employees here is really as high as people are saying. But I'm also not leading 1,000 personal organizations. Neither am I. They clearly know something that we don't.

I mean, I would love for some dispersing to happen. It would be great. Yeah, same here. But living here, being around all these people is a certain kind of interesting. And such a dense amount of tech people because you have a lot of concentration of people who like similar things to you uh so so there's a lot of catering to that which is nice um yeah i mean just to give it put it in perspective and i don't know if this story is really gonna do that but i'll tell it anyways i was with my son and he was sick

so i took him to my wife was also sick so I took him to Safeway which is the grocery store that's open 24 hours and as we were leaving Safeway there was I think it was it wasn't necessarily like a bar but it was like a restaurant that had a bar basically if that makes it was a bar and so these gentlemen are walking out of the bar and I got a little bit nervous because really late at night these people were definitely like very intoxicated and um we had to walk right by them and as i walk right by them one of them basically tells like and i'm not gonna say it's a little bit rude i won't bother saying it but but basically told like a chess joke it was like some like lewd chess joke and i was like like this is like the dregs of society it's like it's like two drug drug people

telling like jokes about chess like at two in the morning but that's basically what it's like here it's just there's just it's it's uh it's it's it's crazy too when you talk to the other people on your team or at your company and it's like everyone was like soliditorian of their high school at some part of the world or something. It's just like mind boggling. Yeah. And I mean, I think for some, what do you call it?

Like table stakes, like for some companies, startups of certain nature and need certain kinds of people, you can only have it in this area or it makes the most sense to have it in this area and a lot of people argue about that i feel like that's an unknown yeah so i mean there's this

there's this unknown and no one wants to take the risk because it's so expensive what is it it's like no one got fired for choosing ibm is that was like it's the same thing it's like you're not going to get faulted i mean you might it might be wrong you might fail but nobody's really gonna like look at you twice if you say you're making a startup in the Bay Area. Yeah, exactly. But yeah, there's this question. You know, I have this sort of hypothetical like thought. Was it called a thought experiment? You know, if you opened a tech company in like pick the place in America, that's and I'm yeah, I'm not going to hypothesize. But imagine the close your eyes. Imagine the place in America that would be the worst for a tech company.

Fargo. No, I don't know. Sorry if anyone's from Fargo. What's Fargo? Anyway, and let's assume Google opened a branch there. Well, some engineers are going to move from Mountain View to wherever that is. And that, I think think is an unknown quantity and and maybe when amazon finally builds this hq2 we'll be able to like at least get a measurement of that of that

number right but that's a different number than if you have a a startup and you're trying to build one in fargo yeah i feel like that's that's very different i mean because there are some engineers there but you're knows most of what i've seen has either been somewhere with a reasonable size tech scene and saying that's enough or we don't need the you know top 0.01 percent of the talent that exists in the bay area or um some something like that or they're just committing to being remote team so there exist people spread everywhere and if you're not committed to being remote team. So there exist people spread everywhere. And if you're not committed to this thing Jason said of having everybody within 100 yards of each other,

and you're already saying we're going to build a remote company, a remote team, your options open up dramatically. But if you say, hey, I need 30 really, really qualified people, and I want them to all sit within 100 yards, and I don't have to convince people to move, where am I going to go, you know, make my startup? Then your choices are much more limited. Yeah. I mean, I think with startups, there's a there's another challenge, which is most of the VCs are here and things like that. So for people to know, VCs venture capitalists. So those are

the people who are going to take the risk, you know, and give your startup money before you've really built anything. But yeah, I mean, there's there's no reason why. Oh, well, there are reasons. But like Google could easily build a, you know, Google engineering office in Fargo. But then there's this question of like, what would happen if they did that? And that's the big unknown. But yeah, the that being low income is interesting because of what it really means but also why and your question of is it sustainable is is unknown right everybody tends to say this time is different and the fact that this isn't the first this time leads me to sort of bet against it being different this time yeah just as Just as a general rule, it seems like there's no obvious

reason why it won't continue to be slightly worse and slightly worse. Yeah. I mean, I think, uh, I do think it will sort of plateau. Like there's been crazy growth recently. Um, I think, you know, at some point it will plateau, but I mean, I don't really see like a big crash. I mean, in general, I mean, I don't know if this, maybe this is just crazy talk, but, but I don't really see like a big crash. I mean, in general, I mean, I don't know if this maybe this is just crazy talk, but but I don't really think there's going to be these big crashes anymore. I mean, like in the market in general, in tech and real estate and just period, you know, like like the futures market is just so algorithmically dominated. And I feel like that gives it just a level of resilience that it just never really had before. And so even like if you look at the 2008 crash, it still took years or maybe at least 18 months for the crash. It wasn't like the 1930s or even 1998 where companies lost

70% of their value in two weeks you know so yeah so you're claiming is this time is different i just think that there will be if there is going to be a decline it will be a slow decline i don't think that we will wake up there's people who say that yeah that we're less prone to bubbles than we used to be we're getting better at managing our bubbles exactly like it'll just be like it is a hypothesis the median house price will go from 900k to 800k over the next 30 years or something sure anyways that's my two cents uh don't don't don't buy uh don't bet on that yeah this is not financial advice don't worry it didn't sound very good advice anyways sorry i'm just teasing hey god i have to pull this dagger out of my heart

well on something completely different it's not like uh it's not like i'm not reading economist books all the time right i mean you do so yeah i mean oh man that's your opinion man um that's true five react practice projects uh you can search that it'll be in the show notes um this was a page i found and in fact it's actually kind of bad i feel sad for recommending this because some of the links in here don't work anymore i guess they were referred to like a service that had some like kind of useful apis that is now down but this is really good collection i struggle with this a lot and you know a lot of people who are learning programming struggle with this which which is, okay, I learned like how to write a for loop. I learned how to make a web form. What next? Um, and actually coming up with well-defined beginner projects is really hard. Um, and so for me, this has always

been the case. Like I've always wanted to get into web development, get into, I mean, learn more about it. And one of the things I've struggled with is, oh, I know how to make a web page, like put HTML on a page. That's cool. I can, from JavaScript, from like a coding standpoint, I get, but there's a big gap in between that and making a full email client as a single page app

that runs on multiple devices or whatever, right? You know, like going from A to B, it's that, how do you draw an owl meme that's on reddit like first you draw like a circle and then you finish it and it's like yeah okay exactly anyways uh so this site i thought had some really reasonable or at least you know i'm not done web but they seem reasonable to me like a step of you know first try doing this then you can use it in the same way to do this other thing so the first one is like build uh what is it like a card like a social card like you would see someone who embedded a twitter message on their website and then build a weather app and how if

you build a weather widget app that you have like days of the week with some icons and you can just sort of like fake the data or or you know they recommend like oh maybe you could get this api um but those are like a series of those cards so it's sort of like building upon itself and i mean i don't know that these particular ones are the most amazing examples but i thought this is a good resource because i know for me it's really useful to have someone else who's already been down the path give a judgment on whether something contains an unforeseen difficulty that you won't be able to surmount yeah very cool yeah i've done some is this react native or react well i mean so i don't think i guess it kind of doesn't matter i guess it would be react web because most of this is talking about like a

card you would embed in a website but it might be applicable to both it's not uh here's a bunch of code on exactly how to do it it's more like here's something you could go off and try to do okay go off and have this so the classic one for me is always oh i learned c like i want to write a video game how do i write a how do i draw a pixel on the screen and it's like oh well you could learn that it's not going to be easy or hard but at the same time recommending you to go work with a you know c++ game engine isn't also a great first step. Like it's an awkward thing, you know, which we've talked about before, like making a text-based game is much more approachable

than making a full-blown graphics game. Yep, exactly. So something similar for the web. Anyways, if it sounds useful, check out the show notes or just search five React practice projects. Cool. Yeah, very cool. Yeah, I think React Native and React.js, they're both great. I use them both uh

in some some side projects and they worked out really well it's on my perpetual list of things to do one day nice nice um book of the show show my book of the show really quick is a critical play radical game design um yeah so i read this book uh i read this book last month and uh it was the only book i read last month last month was an extremely busy month for me and so i'll admit it wasn't that great i probably wouldn't buy it but you know sometimes we read books that that uh that aren't you know the best and you know we're totally honest i'll put the link up if you buy it we'll get some amazon money um but i but i wouldn't i mean i guess part of it was i was five stars would read again yeah this proves we're not shills right i was i was expecting um i guess i was expecting radical

game design to mean um uh like really um like a chronology of really innovative things like for example uh so one thing that comes to my mind is is tower defense so uh have you played these tower defense games yeah i think i've played a few okay like defense grid kingdom rush there's a gazillion of them now but the idea with tower defense games is um there's there's some enemies and they're just walking across the and they're just walking across the screen they're they have nothing to do with you they just want to get from left side screen the right side screen and what you could do is build these little towers the towers don't move but they have a little circular radius and anything in that radius is

going to take some damage over time um and the name of the game is you have to strategize and build and upgrade the towers so that the people can't get from the left to the the name of the game is you have to strategize and build and upgrade the towers so that the people can't get from the left to the right side of the screen. So if you build, you know, and you have to trade off, like, I could build three towers, or I could build one tower and upgrade it a bunch. And so you have to like really look at the, you know, the spec sheet to figure out like what is optimal and all of that um and space is a constraint anyways so so that to me was like a radical game design and someone actually made that as a mod to starcraft one at least that's the first time i saw it um and and the reason is is

starcraft the the editor you know it was pretty limited but this was one of the games that you could build in it and so it was sort of just emergent based on you know the the limitations of that of that editor and the fact that it was so easy to make a game inside of starcraft and deploy it to millions of people um so that that in my opinion like that was something i wanted to see but instead the whole book was all about basically games as art. And so it talked about like really things that were kind of out there. Like there was a museum that had a game where, you know, you like walked through the museum as part of the game. I guess it was just more about it was just much more connected to art.

It talked a lot about museums, talked a lot about museums talk a lot about different art styles um there were it was a lot of talking about like games that there's this game i guess that talked about kind of getting cancer and they spent a lot of time talking about that and so you know i think i guess what when they thought of game design they were really thinking about you know designing games to to affect a certain emotion. And they were really taking sort of that approach. And so in that sense, the book is pretty myopic. If you go on, let's say, Wikipedia and you look at different game genres and you take that approach to game design, this book's going of let you down which is what it did to me so if you're interested in seeing like really crazy games uh like there's

one game you might have heard this game patrick america's army have you heard of this the one that was paid for by the actual u.s army yes so so yeah there was a game that was literally made by the army and uh it was it was it was basically meant to to get people excited about the army. Or at least I was like, you know, I guess one of the goals. And so this book talks a lot about that and social implications of that and things like that. So I have to admit, like, I found the book interesting, but it just I felt like the title is misleading. And so it's kind of like, uh, um, you know, if someone hands you like a grapefruit and you bite it and it's actually like an orange, like a blood orange or something, you know, that's not going to taste good because you're

expecting one thing and you got something else. And that's kind of how, kind of how I felt with this book. Like, you know, it looked like, looked like one thing, but then when I read it, it was something totally different. It kind of let me down. My book of the show gets five stars. Oh, wow. I'm not going to tell you what it is. No, I'm just kidding. Unless you read the bad book first. After someone emails us a receipt of having read Jason's book.

So I actually had a different book, which I also would have probably given five stars. But I had a different book. And then somebody had contacted Jason because i'm a social media hermit um and this is true i have to relay yeah he sends me screenshots of people who uh who message him so thank you all jason will continue to serve as my secretary so if you have anything you would like to tell me just let him know hey carrier pigeon oh okay give credit words okay uh and he this was christian uh and he messaged jason was like oh hey patrick and i have a lot of the same taste you should recommend this book to him and turned out i was like uh of course i've already had that as my book of the show like

why did this guy like you know message jason about this is weird uh and then i said wait i've never had this as book of the show and then i was when we were getting the show notes together, I was, you know, looking through and it's, oh, the reason why is that there's two books in this series so far. And the first book came out before we started recording Programming Throwdown. And the second book came out before we started book of the show on programming throwdown uh and so i've never featured either the first or second book from the series and so i'll start off by recommending the first book but i have actually read them read them uh many moons ago and uh they are really good books but i will warn you the series is not complete uh and as you've i've already spoiled

die only two of the three books are out and the second book came out before we started having Book of the Show, and this podcast is going on many number of years now. The author is unknown as to when the third book will be releasing. So if you don't like reading unfinished series, which is now a thing, you have to be careful, then I would recommend waiting until the third book comes out. And that is The Name of the Wind by Patrick Rothfuss. So very, very, very, very good book.

Highly recommend it. But also very frustrating that the first two books and we're still waiting on a third book for going on 10 years now. No, the first book came out more than 10 years ago. The second book came out and it is not quite been that long, but it's been a long time. I'll have to look it up here. And anyway, so it's a book about a fantasy book.

And it was March 1st, 2011. So we're at seven years since the last book came. And so Name of the Wind is a book, a fantasy book about a man named kvothe and his uh experiences that i can't i never know what to say i don't want to spoil things uh but there's some magic in the book the way the magic works is is really good and interesting and i like it uh that's a very sort of um it sounds bad like a realistic approach to magic like is that i think i've said that about other books surely it's kind of based in some kind of alchemy or something yeah like they try

to come up with some consistent rules and how it would work and like trying to abide by those rules um which i guess is an art it's a game we all agree to play in our heads let's say that way but yeah this game has interesting rules um and they're well thought through and the world building is good um and i i definitely really really really enjoyed this book i think i picked it up a couple times and didn't really and then you know sort of had a little bit of a rough start was busy and then but when i once i finally got in like i'm gonna read this uh it was really good uh and then the second book um not quite as good as the first book but second books are always kind of hard to write i guess um and i'm not an author but authors say that the second

books are harder to write it makes sense i mean you're you're you're uh you're really like uh calcified by the first book like you can't go back and change history right and then and then the third and you're trying to set up like you're trying to wrap up some stuff have your own story arc but set up some stuff for the next book um unless you're just having a two book series in which case i don't know but if you're having a three or four or five book series um yeah that second one i think is a little tough sometimes um but i still enjoyed the second book so the one thing i will say that is sort of a funny uh instance if you do read this book in the second book so it's a book and in the book someone's telling a story and in the story they're telling there's people like writing books and telling stories and at some point you realize you're like four or five stories deep in this book

nice and so uh it's like one of the i don't know i almost feel like i when i realized this i sort of chuckled and felt like somebody was like challenging themselves like how it's the inception thing like how many recursive stories can i have going on at one time so like i'm telling a story to jason about a dream i had and in that dream i was reading a book and in that book there was a storyteller and the storyteller was telling a story about a man who wrote a book and you're just like oh what okay anyways that's got to be really hard if you put that book down which one to pick it back which where along the stack yeah you definitely will have a stack fault if you have to go back six months later and try to

remember what happened so and it's but uh yeah definitely so i'm not saying very much because i never do but name of the wind fantasy magic uh world building uh definitely not short book uh so if that if that seems to strike your fancy then you've probably already heard about it and you've probably already read it but if you haven't then do five stars don't read jason's book my book's better all right sounds good you can also get patrick's book on amazon using our link and uh that helps us helps out the show cool um we also if you don't want to buy his book uh on amazon the the the uh i guess the the written version the scripted version i don't know what the word is you can buy the written version, the scripted version. I don't know what the word is. You can buy the audio version from Audible. And you can go to audibletrial.com slash programmingthrowdown.

We have a link in the show notes. And you get a free book. And you start your trial. And that also helps us out. You can also donate to our Patreon, patreon.com slash programmingthrowdown. And I actually got all the thank you letters printed out and uh i'm waiting patrick and i have to meet up so that he can sign them oh i know this is this is the longest christmas present wait what i didn't really oh no well yeah we you have some

signing to do buddy oh oh boy so we'll meet up we'll uh We'll sign them all. And then we will send them off to you folks. And we have everyone's address. A couple of people emailed me, by the way, saying, hey, this is my address. You know, last minute. It's totally fine. Not a problem. We should probably recheck if anyone's moved. Yeah, if you've moved, tell us.

Yeah. Yeah, that's true. Well, yeah, I'll send them out ASAP. And if you moved, we'll send another one. Tool of the show. Wow, that was awesome. My tool of the show is Visual Studio Code. I actually made this tool before we decided to talk about GitHub.

But it's amazing. I actually, this is going to surprise people. I stopped using Emacs. I just switched to this. I take it back i still use emacs so this is like most of the graphical ids it's project based so um you know if you're editing like a random file in your home directory um it doesn't make sense like start a visual studio code um but uh for for all of my like projects i'm using visual studio code i love it um it's really really nice

um it uh it's extremely fast which is really surprising because it's it's much faster actually than atom and atom itself is is is so fast it almost doesn't matter um but this thing like doesn't you know burn up your battery um it's extremely slick now Now people might say, oh, Visual Studio, that's been around since the 90s. Visual Studio Code is totally different. So Visual Studio Code is an IDE written, it's a fork of Atom, and it has no relation to Visual Studio, I guess proper, or what have you.

It has an amazing sort of plugin ecosystem. So I was immediately able to get like a CMake plugin, a C++ plugin, a Python plugin. I installed, there's a, actually it was a tool of the show a while back, Editor Config, which is a style guide plugin. It has support for almost anything, even like Thrift and protocol buffer, syntax highlighting. It has all that stuff. The plugin system is great. Editor is great.

I actually know a buddy who switched to it too, and he loves it. And yeah, check it out. I mean, I am really, really surprised. If you use like Sublime or Atom or, you know, one of these editors that's kind of in the ballpark of Visual Studio Code, definitely check out Visual Studio Code. It might be worth the switch. I used to do a lot of stuff in just Emacs. And like I said, I pretty much switched. I spend 90% of time in this now.

So check it out. So one caveat is it's not a fork of Atom. They use the same framework, Electron, that GitHub built for Atom. Oh, I see. But it's not actually a fork, or at least so the internets tell me. Okay, yeah, I'm glad you mentioned that. I don't know how I knew that. I feel like somebody at work, I think, told me that, but I never really thought.

You probably read it on the internet. Just like I read my thing on the internet, and i don't know who we can trust either way it's uh it's it's it's really really well done um definitely recommend using it so the people who who built that again jason the adam engine electron oh yeah github my tool of the show is github your tool of the show is worth 7.5 billion dollars boom fortunately it doesn't cost that much to use yeah totally free no so jason and i were talking about this before but i mean github if you you know want to and maybe there's even been a tool to show before we try to check and we don't think it was but if you're you know trying to share your code with people um rather than emailing around in a file like we used to, I mean, you should be posting it on GitHub. You should be if you're not currently working and you're in school and you want to get used to sort of how teams do stuff, you know, and how source control works, which we've talked about before.

You know, you can get on GitHub, make a public repository and then you can put it on your resume, you know, fork people on GitHub, all that good stuff. We really take GitHub for granted. But I want to talk about it as a tool to show for sort of one specific use, which is going in and trying to find for, you know, projects that you know are in the language you're using or big and looking as examples on how to do stuff. So I found a lot of use of going in on big projects and searching for functions or things and just getting a feel for how they've decided to use something. So I'll try to find out if a project like, you know, an example, I don't, this isn't true, but like, oh, I'm using some boost library. And I'm really struggling with like, hey, how should I really use this? Or what's a good invocation pattern for doing this?

And I'll go on to GitHub and try to find a project that uses that Boost library and look at how they're doing it. So this sort of code searching ability. The one thing is that I wish they would do, which they don't, you have to already be in a repository in order to be able to search. And I wish they would let you sort of search across. Oh, I can give you a power tip. Oh, is it?

Basically, I have a shortcut which does a Google search, but it forces the site to be github.com. Oh, okay. There we go. All right. So there you go. GitHub's my tool of the show. Very nice.

Yeah, GitHub's amazing. You can actually see I'm in the middle of a technical argument on GitHub, actually, with the owners of HyperJS. Oh. You can see I'm trying to use all of these skills that we're going to talk about on the technical arguments show. And so we're going to talk all about uh you know we've been doing this for a long time and uh we've seen a whole bunch of different arguments um obviously any job has arguments we're going to try to we're not going to talk about like i don't know political arguments or argument over who has the best sports team or something like that i mean we're going to

try we're going to keep it very specific um but, you know, some of the things I'm sure we'll translate or we'll generalize. But, you know, we've seen a lot of, there's a lot of different arguments, a lot of contention, right? And as you can imagine, a lot of it centers around different sort of design decisions and things like that, but it can get all the way down to, you know, where you put the semicolons and all of that. So we're going to talk about all of that. So we try to break it down into a couple of sections and just sort of some themes. So we'll see how this goes.

But the first one I have is this debate about trying to get things done versus doing the right thing. This one's really tough. I mean, I don't know that there's, there isn't, in fact, almost all of these, there isn't a right answer, which is why they're hot topics to debate. That's right. This one, I would say even more so than maybe almost, I'm trying to read this list really quick while I

don't lose my talking pace. This one might be the hardest one. This one comes up all the time, just like on, and at every scale. So you could imagine like an entire company having the debate about, and that is like when to do the right thing versus when to just get it done. And this comes up at like, you know, should we ship this product? Should we, you know, ditch it and try another prototype? You know, all the way down to just things in your code like, you know, oh, I could just, you know, declare a global variable here and be done with this. Or I could sit here and try to think about what the right way to refactor it would be.

And, you know, it's from the start of your project when you're saying, like, let me just get something banged out and iterate it to like, let me sit down and come up with, you know, a full on UML diagram and architecture of everything I want to build. I'll write my test first and do test driven development. Like you're you might be doing it right, but your first bit of code, you know, might not come out for a long time. This is this is really tough. And a lot of this there's lots and lots of factors that come into here. But part of it is, if you ever have a deadline, and whether you were asked for input on when, what was a reasonable deadline or not, I mean, deadlines exist, they come up, and you always end up against the wall. And missing a deadline often has sort of bad consequences. And sometimes you need to sort of not do the right thing in order to hit the deadline. The problem is, if you don't strike the balance then you build up what we called sort of

technical debt and technical debt just means exactly that like you were trying to get something done quick or you didn't know the right answer and so you just did whatever came to mind and now you have some bit of code which later will come to need to be refactored or will slow down programmer efficiency or increase i always use this term a lot the increase the cognitive burden of your code which is like how many things you need to hold in your head to to do this or is it completely obvious on reading it um and these things is a really difficult balance to strike. But I think this one is probably the one that comes up almost continually while you're working. Yeah, that makes sense.

I mean, one thing I would add to that is, you know, sometimes you have these external deadlines, right? Like, let's say you have a product manager or some program manager and they're setting the deadlines or something like that. But then, you know, there's many times where you are sort of in charge of that. And even then, it's not trivial. Basically, you like, you know, the product itself is sort of an unknown, right? Like you don't know exactly what you're building and what it's going to look like and how people are going to react to it and all of that. I mean, if you are, like, for example,

if you are building like a chip and you're implementing the floating point operator or something like that, that's a very different environment. Those environments are usually just extremely controlled and regimented and they can be, right? But if you're building, let's say an app, the first few months of the app, you might just be trying to find out what people want and how to sort of reconcile the things that you want to offer with the market

and what they want to consume. And so your app, like on the surface, it might be changing massively from one day to the next. And you're incurring a lot of technical debt and the code is super ugly. And that is good, right? You don't want to take the approach of someone who's designing like, you know, the next Intel chip when you're making this app,

because then you can't really navigate that space quickly, right? And so that's why it's difficult is you're sort of trading off, let's say, learning and exploring with, as Patrick said, like building something that, you know, can allow you to scale to the next level. So if you just focus on exploring, you end up with something that's too fragile for you to, you know, use it as a platform for the next thing. And so yeah, trading that off is extremely difficult. And I think here, the way to sort of resolve arguments like this is to just understand that dynamic right and so um um so so what that means is you know if the app if you're still trying to figure out what you're doing

then uh you need then you sort of relax right a lot of these like just you know like over engineering like you don't over design things but then on the flip side, you know that you're going to have to pay that price later. So, you know, when the app is done and they say, OK, the app does music. Now let's make it, you know, play videos, too. And let's do the next version of it. That's when you just say, whoa, wait a minute. You know, we need to sort of redo this because we didn't even know we thought that this was a dating app and now we're a music player and so so along the way we've made a lot of bad decisions we need to now go through and like redo everything so i feel like if you can kind of gauge that ebb and flow of your project that will sort of give you the the um insight that you need to like win that, that argument or make the most compelling argument, you know,

when it comes to that. Yeah. I guess this one also is, is difficult because it comes down to the like true cost of things, which is if you take a long time to build the most amazing platform ever, and you never ship your product, you're going to go bankrupt. Right. Yeah. So like, what is the first, like in different industries

and in different applications, like first mover advantage is different. So if you're building an airplane, it needs to be safe. It needs to be a lot of things. It doesn't necessarily always have to be first. Although, I mean, maybe there's exceptions to that, I guess. But yeah, if you're making a dating app, yeah, whether or not your reliability is 100%, or is, you know, seven nines of uptime

and you use the most advanced algorithms for distributed consensus of consistent database updates, yeah, I don't know that anyone cares. Yeah, yeah, exactly. And so, you know, typically here like the the worst case scenario here is where you have someone who just doesn't get that and they want to write just extremely regimented code when you don't have a product or on the flip side um you know that you have a really hacky system it's constantly breaking and you can't really

use it as a platform for anything. And people just want to keep hacking on it, right? So those, those are the two extremes. And that's, that's, and so I think you're getting everyone on board with why those are extremes and why there is a better middle ground is the first step. So yeah, another one that you mentioned here is when and how to optimize. What's your take on that? So people love to quote, I think it's a Donald Knuth quote,

is early optimization is the root of all evil. Yeah, go for it. Yeah, okay. Which it's kind of a frustrating quote because I know what he's saying and it's true, but it gets to the heart of this idea of, you know, if you optimize some bit of your code that doesn't end up getting called very often, um, you know, that's not the right place to spend tons of time trying to make the most efficient, you know, selection for how to do your hash mapping hash function um because you only ever end up using it five times the whole time your program runs um and so early optimization really can cause a lot of problems it's true but deciding when to scale or not is and we've talked about this a number of times on the show before but like

if you sort of say i'm going to go build a web app that scales to 100 people um that's not necessarily a horrible thing or don't even worry about scale because you don't know if it'll be interesting or useful you need to go out and try which is what jason was getting at but at the same time the first time you get featured on uh you know on on reddit front page or you know on hacker news or whatever and your website goes down because you only anticipated getting one user per day and you have it running on, you know, the computer under your desk, you know, that's not ideal either. But building for something that's Facebook scale when you don't even know if anyone cares about your product. Yeah, this is really tough. I guess it's

a little similar to the doing it right before but optimizing means figuring out what parts of the system you're going to choose to design in a way that they you know sort of can scale as well as making sure to try to build enough of a system so that you can start taking measurements about where your performance bottlenecks are but this is something that i find is often comes into a hot debate because the more optimized you make something, you normally don't increase flexibility. You normally make the code harder to read and the systems more tightly coupled as a general rule. And so you introduce a lot of other issues the faster you try to get your processes to go, the more scalable you try to make them. Yeah, that makes sense.

I mean, I think if you have this type of argument, so I guess the two positions here that you could be arguing is one is someone wants to optimize something and you don't want them to optimize that. That's probably pretty rare. I mean, unless you're the engine manager and you don't want them to optimize that. That's probably pretty rare. I mean, unless you're the engine manager and you don't want them to optimize it. Well, I mean, I think the issue that comes up here is someone saying, oh, your design, like you should use a different algorithm here. Like, you know, you're doing something naive.

Like, oh, you're doing a bubble sort here. Like, why are you doing, okay, that's a bad example. But like, why are you doing merge sort here instead of using, you know, this new research algorithm that says it could potentially go faster, um, when no one really knows the data and you get these, you know, sort of drive by requests often in regards to optimization. Um, you know, like what's going to happen when we have, you know, four orders of magnitude, more data than we have today and it's you know I guess you're right maybe it's a manager to manage employee question that

comes up a lot but yeah I mean it's it's uh yeah I mean I think I think yeah for it to come from another team that other team probably has because most teams don't necessarily care how optimized other teams codes are unless there it's not an inter team this is yeah i think this would be within your team or a debate between you and your manager yeah exactly because i mean if someone comes to you and says i want to optimize code x then of course you just let them do it unless you're the manager and the issue there is i mean there's there's a bigger issue here which is i guess this ties into the first two questions, is how do you really reward

that kind of work? And I feel like unless it's releasing a safety valve, you know, so in other words, like you have some critical performance problem and this fixes it, you know, but in all other cases, like if it's even remotely preventative, it's very hard to justify that. And that's one of the reasons why I, it's very hard to justify that. And that's one of the reasons why I think the engineering leadership needs to be technical is so that, you know, those types of work, that type of work could be justified, you know. Yeah. But engineers love tinkering. So, like, I don't know.

I like tinkering. And it's more comfortable to stay in the same code and just keep making it better. Yeah, it makes sense. I won't spend too much time on this, but there's a whole bunch of arguments around languages, which language to use. That's obviously a really big one. One thing to mention there is a lot of people don't know this, but, you know, most big companies use a ton of languages

and they communicate. They use interprocess communication, they use TCP. And so you have like a Java program talking to a C++ program and things like that. Or if you're getting really sophisticated, you can use Swig or one of these things. But yeah you know you don't have to get like your entire company you know uh revolving around one language by any means um but you know still i mean that's that's going to be a hot debate right there's going to be people who like different languages and uh i think that's a very difficult you know situation um you know i think uh there's obviously a ton of research on whether you should use language X or language Y and people will refer to all of that research. I mean, one of the things to keep in mind here is that it doesn't matter as much as you think it does.

I mean, I've written PHP, I've written all sorts of languages that and hopefully this show kind of really conveys that message to people. If you've been following our show, then you already kind of know this um but you know if at the end of the day someone you know really wants to use language x and for whatever reason you know or let's just make it more obvious the whole company except you wants to use language x then uh it's it's actually not the end of the world it's not too bad. It always seems worse than it is, you know, using a language that is not preferred. But I mean, it's a real issue. It's very difficult.

I mean, we actually had this today. At work, we decided to rewrite something in another language. And so we built a prototype and it had a lot of the nice features that we liked specifically so we're porting stuff that was written in sql to a real programming language that has unit tests and things like that um and so you know we kind of agreed we had a round table we agreed that is a way to go um but i think part of the reason why we agreed is that we had been through so much pain

uh you know with the original approach um so you know if someone was brand new on the team they might not see the reason for for doing that um but yeah in general this i would say this is also in the camp of really really difficult arguments um like what would you do patrick if someone said we need to rewrite our whole thing and i don't know some other language yeah i mean i'm a big fan of the right tool for the right job. But I guess your contention that it doesn't matter as much as you think depends a lot on the situation. So if you're writing, you know, code that's distributed via inter-process communication and you want to write in a language that works fine via that mechanism, then yeah, probably

not a big deal. If you're writing a library that needs to be performance oriented that other people are going to call, you probably want it, or you're going to have to sign up to maintaining wrappers into the language that everybody uses. So if you're working at a video game studio and someone needs a bullet physics library, you're not going to be writing that in Java. Yeah, that makes sense. So sometimes it matters. library, you're not going to be writing that in Java. Yeah, that makes sense. So sometimes it matters.

And if you're writing a script that's just a one-off, like I mostly care about the data product, again, probably doesn't matter. And for me, though, for code that is going to be needing to be maintained and sort of stable in production and known and code reviewed, you need to have at least some body of knowledge, you know, on your team or commitment from everybody that they are okay with that language choice. So if somebody decides, you know, I'm going to go write this widget in, you know, language foo, and nobody else really is interested or wants to do it, you end up with

this problem, which I see happen sometimes, where that person goes and writes that tool and then later they leave the team and then you need to go use that tool and it's always everybody dreads it because it's like oh it's written in foo and nobody knows how to go in and fix it or and it breaks all the time and you end up with this problem of like you've saddled that team with something they didn't really want yeah that's a really good point actually if you want, if you want to be passive aggressive at work as a software engineer, probably the most passive aggressive thing you can do, like that's the most destructive, is to write something in a very obscure language. We had someone write, we had this system, and like Patrick says, is meant to hook into

not necessarily hook in but it's meant to it was meant as a library where people would would uh many people would add their own flavor to it right so think of it as sort of an sdk like open gl or something and you would the plan was to build something in open gl or in this case in this library in this sdk And the person wrote it in Haskell. And the issue there was, you know, now anyone who wanted to use our system had to learn this language. And so, you know, in the context of many alternatives, most people just said, well, I'm not going to learn a whole language when I could just use some alternate system that gets me, let's say, 90% of the way there,

but, you know, I can write it in Python. And so that person, after spending over a year writing the SDK, had to completely rewrite it in Python. And that was extremely painful. So, yeah, I think it's a really good point is you have to really look at your audience. And, you know, if you're at a company where everyone's writing in Haskell, then, you know, you really need to think about that before you make an argument. Like, unless, I mean, like, as Patrick said, like, if you have to do a physics engine, you're not going to do that. Actually, I don't know how fast Haskell is.

Let's say, I don't know, basic or something. I don't know. Python. You're not going to write like a physics engine in pure Python. But, you know, I mean, once you get rid of the kind of very obvious constraints, right, you should think really carefully before you do anything other than the, you know, most common language that your team or your organization is using, right? I mean, just don't underestimate, like try like try to really avoid having that argument you know and on the flip side if someone you know if 90 of your code base is python and someone wants to write something in erlang um you know i mean there there needs to be like a

really solid reason for that and sometimes there are but then i think what jason describes the right way i think you build a little prototype you try to shop it around to the team and you know say like hey i went and did this thing like look at advantage x y and z you know that this is really going to be a game changer for us yep yeah exactly like there has to be real tangible benefits yeah yeah so tabs versus spaces we brought this up and got emails about this from people so people are very passionate actually it's in the in the silicon valley show tabs versus spaces yeah um this is a debate just avoid it style you should have style guidelines uh and you know you should i i'm a big fan of like

pick something and stick to it and new people come to the team they don't like them they don't want them it's it sucks it's a struggle but everyone come to the team. They don't like them. They don't want them. It's, it sucks. It's a struggle, but everyone needs to have, you don't have to make them overly restrictive, but you need some guidance on not writing bad code. And if you don't have it written down, everybody's going to argue about it,

every code review. So it's better to write it down and like just hash it out. And hopefully your manager is technical enough to just come in and make a consensus decree yeah i mean i don't know if if this is just a benefit of python or if this is the way the team works but the team i'm on now this the um they have a very complicated um automatic style like a prettier um and the cool thing is basically the the team philosophy is if the automatic system whatever it does is is the truth so in other words like if you can write now you can obviously like you know uh you could write like really obscure obfuscated code and and you

could trick the the prettier right but uh you know no one's really done that yet hasn't really come up even once and then basically yeah the prettier is so sophisticated that people just they write code however they want and then once they run this it's like an auto formatter exactly yeah yeah it just automatically you know adheres to a certain style and um yeah i really like that i I mean, I honestly, I used to really hate getting style feedback on my changes. And I think the reason why is I always felt like, you know, it made me feel like just like this cog in the machine. It's like, oh, you know, this should be, you know, indented a little bit more or something.

And that kind of went away when i like clang format or uh you know the pie flake eight or whatever when these things came out that basically just did all of this for us it's like i mean in your case do you do you ever have to actually do this style manually like what kind of decisions you know but i mean somebody has to decide which of like you know i read a lot of c++ code like there are many different c++ style guidelines like should should you put a space before and after a plus operator you know the big one that always comes up is where should the pointer the asterisk go should it go on the variable should it go on the type should it go with the space on both sides it's got to go on the type right no it definitely should go on the variable we should it go on the type? Should it go with the space on both sides? It's got to go on the type, right?

No, it definitely should go on the variable. We're not getting on this. Hang on, hang on. No, stop, stop, stop. We will completely derail. We'll prove this point. You can create, there are legitimate arguments for both. So it ultimately just comes down to an opinion.

There isn't a logical, obvious. Well, I always felt like the pointer is what changes the type. But you can put multiple on a single line so if you do like int star a comma b b wouldn't be a pointer type oh well that's true yeah so then it's not it's not modifying the type in that way that makes sense i never thought about that yeah i mean that's the most succinct one i can give there's other more nuanced right okay we're not going to get off on this um the you know lots of style guidelines and i think this is an argument that gets had and this is one of the things where when you join a new team and they either don't have a style or they have a style you disagree

with it's a really tough situation you really got to weigh your options about what are you going to do so if there's no style i was in an instance where I joined a team, didn't really have a consistent style. They weren't really adhered to it. And I came in and, you know, sort of was the one who began enforcing the style. And it took a lot of goodwill out of my sale from being the new person on the team to coming in and having my boss sort of tell me that, yeah, that's what I want you to do. And, you know, have to go in and tell people, yeah, the way you've been writing code for the last two years is bad and it's confusing and doesn't look good. Um, and so if you go on a team and they have a style guideline,

I would say, try to go with it for some period of time and try to, if there's really things you think don't make sense or are inconsistent or aren't great, like try to work on them like as small things, um, as opposed to just coming in and like erupting with this sucks. This is a completely wrong. You guys are horrible. Don't do that. Yeah. That makes sense. I think, you know, like any, you know, uh, I guess artists, right. I mean, you can think of it as an art, uh, you know, there's a stereotypical, like the artist is super self-critical and critical of the medium and things like that. And it's easy for people to be that way. And so it's really important. I think the overarching lesson, if I could say one thing, is that it's really important to step back and say, okay, take myself out of the equation.

And think about, is this really that big a deal? So, yeah, another thing is, you know, IDEs or text editors. This is less of an issue now that there is, you know, automatic styling. Because a lot of the, there might be some people who, you know, where the IDE is actually carrying a lot of weight. Like you have the build system integrated with the IDE. Yeah, this depends a lot on the the project whether this is a personal choice or a team choice yeah if you're building an iOS app or something for example you might be well there you might not have a choice at all so there's not really an argument but in some cases like you said

if there's like a plugin that needs to be hooked into a custom build system or something and if your team is creating or maintaining that plugin and whether you maintain it for IDE A or B or sometimes like for people will be really into Emacs and have a complex set of Emacs plugins uh yeah that's right and uh you know they share that around the team and everybody uses it and if you're trying to use VI yeah that's anyways yeah yeah I mean this is more I think this is mostly a personal opinion like oops right over time oh no i was just gonna say like yeah this this this argument is pretty rare especially nowadays that the ide like before you know

like visual studio would also be your build system um now people don't really do that anymore and and so especially now if you want to do continuous integration or something like that you need to have a build system that's sort of orthogonal to your, or separate from your editor. And so, yeah, I mean, at most jobs, you should be able to use whatever ID you want. So I guess the only argument would be, you know, like how much work is it going to take and maintenance is it going to take to let you use the editor you want? And, you know, will everyone around you, so you might be in a position where you need everyone around you to make, let's say, a small sacrifice, like, for example, learning make so that you don't have to be forced to use Visual Studio, for example. And I think this is actually I would echo Patrick's advice from earlier that basically you don't come in on day one and say, everyone, we're going to switch to make. So you're going to have to bite the bullet and do some Visual Studio, at least in the beginning. But one thing that would be good is,

you know, take the initiative to, you know, redo your entire build system and make, present that to the team and say, look, we have something, you know, I can run it on in the cloud, has all these advantages. You know, also I also be able to use any editor I want. But they kind of show up, show up with a solution. I think that makes a really big difference. Now, that's going to take a lot of energy and it might be wasted. But I mean, if you're that passionate about, you know, using Emacs, for example, then that, that, that's, um, that's a risk you want to take, right? So, so showing up with a solution is always, um, a way, way better. Um, even if you

have to sort of do it, you know, on your own time, um, you know, like, like, you know, on the, if you have to come into work on a weekend or something to do it, it might be worth it because, because it could, you know, kind of pivot the whole team then so we're running quite a bit long but uh let's talk a little bit about how if you do get yourself into one of these arguments some uh some good guidelines to stand by yeah that makes sense i mean i think uh we covered a lot of it but just to summarize um you know really you know and be honest with yourself and really reflect on why you want what you want. There are some people who you could see them, they show up on day one, they're like, oh, everything has to be written in Scala or something like that. And really think about what do you, and be honest with yourself.

For example, maybe you want to use Scala because you want to learn Scala. Maybe you want to use scala because you want to learn scala maybe you want to learn scala it's a skill for you and you have a chance to learn it um while you're working so basically like learn it for free like on someone else's dime and and now have be more marketable right but i mean that could that's fine you know but but and you obviously you have to you know speak with some tact and you know, just go into the meeting saying, hey, I want to learn a new language on your dime, boss. But but beyond but, you know, internally, be honest with yourself. Right. So know what your values are, why you want the things you do and have clarity there. Also, you know, think about the compromises or the alternatives. Right. Like what is alternative?

What are you going to lose? And that's going to really tell you how much energy you need to spend or risk, let's say, on getting the change you want, right? So this gets back to the whole building the prototype and make, right? Like if coding in Visual Studio is so frustrating to you that you're going to lose a lot of productivity and it's going to frustrate you, it's going to make you not like this job,

then it's worth spending an extra 40 hours off the clock porting the whole thing to make and trying to convince everyone to do that, right? If you think about it, then you might think, oh, it's not that big a deal. I'll just bite the bullet and do Visual Studio studio right but but figure that out kind of beforehand um and the second part of that is is you know when you have this argument and the argument could be impromptu where you don't really have time to figure it out right but whether you've had time or not um don't necessarily like force a decision right away. Like this isn't, you know, like a criminal

trial or something, right? So, you know, have a discussion about it, try to keep things open-ended, at least initially, you know, go home, think about what was said, think about how that might change, you know, the state and the compromises you have to make, and then show up the next day sort of with the next sort of evolution of this argument, right? And, you know, kind of slowly converge to a solution that's often way better than, and if you have that expectation

that this is a convergence process and not like a jury, that's really going to sort of change the attitude and you could actually, you could lose the argument and have to use Visual Studio to extend the example, but actually gain a lot of respect based on sort of how you handle yourself in that situation. Yeah, I think that's one we don't have on here, but picking your battles, even though technically, right, you might be correct

across all of these things. People are, you're not going to be a very popular person if you're fighting everybody on every front all the time yep yeah there's this saying like uh you know don't be dead wrong but don't be dead right right so so i think that the metaphor that they use is you know you're driving on the highway uh you know some like country highway two-lane highway and a semi is coming the other way, they're driving on the wrong side of the road, right? You don't just like hit the semi head on just on principle, you know? And so it's the same thing here where, you know, at the end of the day, like part of this is just respecting other people's values. And so if the whole team has one set of values,'s the semi right and and

and whether they're right or not you're gonna have to handle that situation sort of very delicately and other thing i'm know i struggle with sometimes is be careful to pay attention to other people's demeanor their feelings even if you're having a technical argument some people become passionate and are okay having a heated debate and other people begin to have a very personal reaction and don't necessarily take well to having their choices questioned or something. Even if you're well-intentioned, even if you don't mean it that way, but you know, do it. And also the venue for having these discussions you know if you have a weekly whole team meeting some people might be fine discussing stuff in that other people might

rather you talk to them at their desk or schedule a special meeting or have this discussion over email where they can think about their responses um and be slight you know be sensitive as you can to how other people prefer to have these exchanges. Yeah, that totally makes sense. But definitely always do them loudly in the middle of your building. Like that's the like definite goal. Yeah, that's right. Oh man, we actually just decided we moved

and the new desk area, we got there, we're like, this is amazing. We're all super excited. And it's even a new building so we don't really have any bearings um we're so unbelievably excited and then we realized that we sit right over the the restaurant a restaurant and uh around noon it's just like a total madhouse you can't hear anything and i never realized it's the first time i've really been in this position.

But, yeah, noise pollution is, like, actually a huge problem. But, yeah, so don't have your big arguments in the middle of the room. Also, as I said before, like, you know, converge slowly. You know, there's very few things you actually need to rush. Yeah, you don't, like, need to decide whether you're going to rewrite the whole thing in Java today. That almost never needs to happen. And so, as Patrick said, some people, I mean, it might be a combination of shyness, but it also might be some people just, they don't have, they just need to think about things, right? And everyone, you know, when they sleep on things, they come back with sort of a slightly different perspective right and so you want to take

advantage of of of that latent perspective or push for your victory yeah you know yeah if you have the majority that just try to close the deal right away i'm sorry it's like buying a used car or something um cool well yeah let us know i'm really curious to think uh to hear what you think about this episode um you folks out there um you know we this is i would say this is like a completely different uh you know style of of episode for us because this is just very ad hoc um we're really just kind of relaying like life experiences and let us know what you think. So, you know, we have the interview format. We have the something where it's like a very specific subject format, like machine learning or C++ or something like that. This is almost like a,

I look at this as almost like a third format. And so I'm really curious, this is sort of us dipping our toe in this. Let us know what you think, if this was interesting to you. You're based on the time we can clearly talk about this forever. So that part was good. But let us know if you found it entertaining. Till next time. See you later. The intro music is Axo by Vynar Pilot.

Programming Throwdown is distributed under a Creative Commons Attribution Share-A-Like 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I and share alike in kind.