Blog
Bio
The Technician
No Imperfections Noted
The Jeff and Casey Show
Jeff and Casey Time
Casey Muratori
Seattle, WA
The Wolf Doesn't Want to Come Anymore
"The mountain is floating in mid air, and you haven't a flying machine."
Original air date: April 14th, 2014
Topics. Google rankings. Steve Jobs. Scrum. Agile programming. Software engineering research. Software testing. Wii U. iPhone. Windows. APIs. Sanguinary programming.
Subscribe. If you’d like to have the latest episode of The Jeff and Casey Show delivered fresh to your computer every Monday, you can check out our list of RSS feeds and other subscription options here.
Transcript
Jeff:
Hey, everybody. Welcome to the Jeff & Casey Show.
Casey:
Hello, and welcome to the Jeff & Casey Show, the only Jeff & Casey Show on the internet that I'm aware of.
Jeff:
That’s true. There is a Jeff & Casey that we slowly have pushed down lower.
Casey:
Oh, they are totally pushed. If you search for Jeff & Casey now, they got pushed.
Jeff:
It’s all us and then someone that got married, like…
Casey:
Yeah, we’re fighting with a wedding site for top Google rankings. That’s where we’re at. This isn’t a Yahoo!-Google thing. This is battle of the 200-view sites.
Jeff:
Well you know, in any battle, the smaller the number of participants, the more brutal…
Casey:
Fearsome it is. You think so?
Jeff:
Yeah. Just in general, because it gets to be really bad blood… It’s way worse to find somebody like…
Casey:
Okay. This is personal. This is personal between us and the Jeff & Casey who got married.
Jeff:
Yeah. Anyway…
Casey:
Welcome to the Jeff & Casey Show.
Jeff:
That’s right.
Casey:
You know what, I should actually bother to try to turn this tablet back on even thought we know ostensibly… Ostensibly, we know what we’re talking about. It’s not McGruff the Crime Dog but we do know what we’re talking about. But I want to look because someone actually wrote in to prompt us and I will say their name.
Jeff:
Oh, okay. I see.
Casey:
Before we get into the topic…
Jeff:
That’s true.
Casey:
It is a person who’s name… And I apologize for mispronouncing this… I feel like everyone should… When they write in to a show that’s spoken, they should say how to pronounce their name.
Jeff:
Oh, that’s true.
Casey:
You know, they could just say, “Here’s how I want you to say it.” It doesn’t have to be right. You can just say it however you want me to say it. If you want to say it’s “throat wobbler mangrove” is how you pronounce it, no problem.
Jeff:
We’ll do that.
Casey:
It’s however you want it said on the air.
Jeff:
It’s true.
Casey:
And we are marked explicit on iTunes so we can include a fucking swear word in your name.
Jeff:
That’s true. You could do whatever you want.
Casey:
You can have anything you want in there.
Jeff:
Yep.
Casey:
So anyway, Anders Leno (I’m not sure how to pronounce it), he writes…
Jeff:
Not Anders McBigtits? That’s what we’re gonna get.
Casey:
But that’s fine. That’s what I was saying. We can say that on this show.
Jeff:
We’re okay. We’re not gonna get kicked off iTunes.
Casey:
We won’t get kicked off ‘cos there’s nothing to get kicked off of.
Jeff:
Alright.
Casey:
So yeah, on Games, apparently you can say anything you want on a podcast. Fuck you, Steve Jobs. Anyway, even from the grave, from the last, he strikes at thee, that asshole.
Jeff:
No, he… I just… Yeah, that link that I just tweeted was another one of those ones where they have a bunch of… In that lawsuit where all the tech firms were colluding to keep wages down…
Casey:
What? I didn’t hear about this.
Jeff:
No. So there’s a lawsuit going on where Apple and HP and Compaq at the time and a bunch of people all sign these agreements saying they would not poach each other’s employees at all. And so…
Casey:
Really? And that’s not legal at all, is it?
Jeff:
That’s totally illegal.
Casey:
I didn’t think so.
Jeff:
And so, one of the interesting things is the owner of Palm refused to go along with it. And he said, “Okay…”
Casey:
[inaudible 2:58]
Jeff:
He’s like, “Well, okay, I don’t think… And he’s very rational here. He’s like, I don’t think that’s good for either of our employees. You hired about 2% of our entire workforce to come work on the iPhone that came out…
Casey:
Yeah.
Jeff:
We’ve hired twenty people. And the reason is came up, was this is not [ Palm ] fighting. This is… I don’t know if it’s class action or if it’s labor and industry suing these companies. But they’re in a lawsuit and this discover came out of email exchange between the President and Steve Jobs who is the worst if you read the set of emails where he’s just like, “I think if you look at our respective with companies, the size we have that do this and our patent portfolios, you probably don’t want to do this. You really should just sign this agreement like everybody else.” And he’s like, “I don’t think that’s good either of our employees and I don’t think it’s technically legal anyway.”
Casey:
Yeah.
Jeff:
Like, he says it. And then they go back and forth and Jobs is… And it’s one of those things of no matter… I have never seen a backdoor, a behind the scenes thing with Jobs that hasn’t made me like him less.
Casey:
Right. Yes.
Jeff:
He was a horrible human being. And even from the standpoint of, “Oh, he did this and this and this,” like, he turned it around, he’s a great… Even when they talk about those things, he wasn’t really good. They hit… They were the first to put touch with the capacitive screen on a phone. They hit that time. That would have happened a couple… Within 18-19 months, no matter what ‘cos all that tech was coming together. It wouldn’t have been as smooth as the 1st iPhone, certainly. It wouldn’t have been as easy to use ’cos they did spend time on that. We would’ve got [inaudible 5:00] stuff. But a lot of their success was a lot of the touchability of the thing. And that was coming anyway. So even the thing that is, like, “Oh, he brought them back,” it is a good chance that Apple, having worked on iPad would’ve won that anyway. So even things that they say he’s good at, I don’t even give him credit for that.
Casey:
So I guess… I don’t know that I would necessarily go that far because I don’t have enough information for that sort of thing. I think it’s entirely possible that Steve Jobs actually is a good motivating force for that company. But it’s important to understand the distinction between what a good motivating force and whether you’re a nice person or a good person or even a person with good ideas because none of those are the same thing, right?
Jeff:
Yes.
Casey:
So it’s entirely possible that having an asshole in charge of Apple is the thing that made it work well. I’m not willing to say that that’s not true because I don’t know. That’s something I can’t possibly know.
Jeff:
If you read…
Casey:
But one thing I do know and that we can say for sure is that he was an asshole because I’ve never seen a single story about him from anyone including Steve Wozniak, for fuck’s sake, who wasn’t like, “This guy is an asshole and he fucked me.”
Jeff:
Right. And if you read, there are some stories about how the initial iPhone was developed and all that. If you read that, it really feels more like a confluence of events, not… And certainly, he made things happen in the sense that at that company, if he decided that’s what the company was gonna do, it happened. Like, there are people like… At [ Valve ], things don’t really happen until either a critical mass happens or in [inaudible 6:36] as we’re doing this, right? And that’s a little bit of what… You get the sense of Jobs’ role at Apple was, of cutting through all of the bureaucracy and saying we’re doing this, period.
Casey:
Well, I think he had other value, too, though. I mean, like I said, I don’t like the guy. And if I could rewrite a history where he’s never in charge of anything, I’d actually prefer that history. I like none of the things that Apple has ever done. I’m not on their side. But that said, I think Steve Jobs had other qualities. Like one of the qualities was he can sell things to the public at large. And that is also a motivating force because if you’re at a company… Let’s say you’re a person who’s… Let’s say Steve Jobs has none of the ideas, he’s not essential at all for producing the product. But I’m the genius working at Apple of whatever the fuck who does have these ideas or I’m the team there, right… If I’m at Apple and I know that when I put together this flashy device that Steve Jobs is gonna walk out a stage and every last person in the entire mainstream press is gonna lose their shit when he presents it versus I work at Microsoft and I know some asshole buffoon like Steve Ballmer is gonna get up and everyone’s gonna laugh at him, there’s a big difference between those 2 things. and so, even if he never had a single effect on the company in terms of direction, he still had a quality that very few people in Silicon Valley actually do. And I wouldn’t want to undervalue that because I do think the man has some talents.
Jeff:
I actually think he was way less than people think. And I’m not sure that…
Casey:
That may be true…
Jeff:
If you see the first iPod ones where they try doing the thing in the room with the black curtain behind them and the light up, they were awkward and stilted. It was something that… It took a long time for them to good at. And they definitely got good at it but I don’t know if that was Jobs. Even now, I feel like if you watch their presentations versus other people’s, they’re like… They’re just night and day better. Whoever does that for them is very good. Like, whoever is… And I don’t think that’s the CEO. I think that Jobs… The thing that works for that is in the mythology of having the massive inventor who is the God of all design works well in selling stuff, too. So it kind of feeds the thing. Like, it’s similar to the Edison thing…
Casey:
But it’s the same thing as a successful president, at some level. The dude isn’t the person who’s actually doing most of the stuff, right? It’s about a figurehead and about whether people are rallying behind that person when you need to get something done. And so, yeah, I don’t know. It’s entirely possible that Jobs could’ve been replaced by anybody for all I know.
Jeff:
I’m not trying to say that. What I am saying is…
Casey:
I’m just saying, for the data that I have, it does seem like he may have some positive stuff. I don’t like what they did so I don’t like the fact that he existed because I don’t like the things that they have brought to the industry. They have always made it worse in my opinion. But that’s separate from saying whether he was effective with what he did or whether, you know, whatever…
Jeff:
I think he’s effective time was not the iPhone, not the iPad, all the stuff that people associate with him. I think it was that…
Casey:
The old, 1976 to ‘84…
Jeff:
It was coming in to Apple the second time and turning them around.
Casey:
Yeah.
Jeff:
He made a lot of good decisions then.
Casey:
Oh, yeah.
Jeff:
Which were not immediately apparent ‘cos everyone’s like, “License the OS. License this. License this.”
Casey:
Okay.
Jeff:
And he did the opposite.
Casey:
Right. He was like, “No, we’re not [ closing it down ].”
Jeff:
“We’re gonna close ranks. We’re gonna make money on the hardware.” And because he did that and [ ticked the sock up ] and turned it around, that gave him all the clout to do all these next things. So I would say the thing that was… He was a good turnaround guy at that point. But the people that worked for him at Pixar, the people [ that worked for him at Next ] was very mixed. They’re like…
Casey:
Yeah, I only know [inaudible 10:37]
Jeff:
But that turnaround time was very good. And if you can get that God-like status… Any time you can get a God-like status, things happen.
Casey:
You get a bonus.
Jeff:
You get an extra plus bonus. And that’s a good thing. Yeah. Anyway, we’re not going to McGruff the Crime Dog this…
Casey:
We’re not gonna Crime Dog that. This is no Crime Dog. I don’t even know how the fuck we got on that subject.
Jeff:
Let’s not… We go down that then we… This is what happens to us…
Casey:
Focus, people!
Jeff:
Yeah, focus!
Casey:
Focus, goddamn it.
Jeff:
We’re only 20 minutes in. We’re gonna do this.
Casey:
So this poor fellow who’s now possibly listening to this podcast, he got teased by thinking we’re gonna start talking about his topic…
Jeff:
We’re still on you, Anders.
Casey:
We’re still on you here. Anders writes in and says, “I’d like to hear your thoughts on the ‘software’ development methodologies,” and he quoted that, “software”, so he’s distancing himself already from this, “called Scrum/Agile. Here’s my ranty motivation for the request and a bit of background. I write ‘Scrum/Agile’ because I honestly still cannot tell them apart even after having been subjected to one or both of them for about a year now in my day job as a ‘programmer’,” he also quotes that, “for a very well-known Finnish mobile ‘games’ studio.” I like how sort of skeptical he is, right off the bat, of almost everything in his life. He sounds like our kind of person.
Jeff:
Yeah. He sounds like our kind of guy.
Casey:
“Yes we have ‘Scrum masters’, ‘daily standups’, and ‘Scrum exercises’, the works. The reason I don’t know a lot about them is that every time I try to read something about these methodologies, my BS detector goes wild and forces me to do something more productive.”
Jeff:
I’m right there with you.
Casey:
“My colleagues seem to love Scrum/Agile, which is not is not terribly surprising to me since I think they are mostly incompetent and have given up on trying to improve as engineers in any objective sense. I’d like your opinions not just on Scrum/Agile in particular but in software development methodologies in general. My take on it is that I’d like to try becoming a responsible, well-rounded, and intelligent person who applies a mix of opinions, competence and engineering experience to traverse a complicated space in order to make a good product.” He’s ahead of the curve just by even saying that.
Jeff:
Yeah.
Casey:
I don’t think I need to explain why this is incompatible with any methodology and why I find them to be a huge turnoff. He closes by saying, “Now, I assume that the whole Scrum/Agile thing has mostly passed you guys by without notice but maybe you’d be intrigued to find out what’s going on in a different part of the software world, how shall I say this? With less evolutionary pressure for competence… I suspect that a lot of listeners will be familiar with this topic, as well. Note, I’m not looking for advice. This is my first programming job and it’s obvious to me that the correct thing to do is to take a step back, course correct, and look for another job and a direction where I can get away from this kind of crap.”
Jeff:
He’s wise beyond his years, it sounds like.
Casey:
A fabulous letter. Thank you, Anders for writing it.
Jeff:
Yeah, that’s great. That’s, like, good content. And we didn’t have to do anything for the content. That’s like the ultimate…
Casey:
If we can start getting people to write in longer letters, we could just read it, and then call it a day.
Jeff:
And then fuck off, have another steak…
Casey:
We can have one of those automated mouth programs that’s like, “Thank you, Anders [ Leno ] for writing in with your insightful letter.”
Jeff:
I would like that just to see what would happen when we talk on top of each other and everything. Like…
Casey:
Yes.
Jeff:
Does it put me on the wrong… We just start… Yeah. So…
Casey:
Did you want to start…
Jeff:
I think about this a lot.
Casey:
You do? Okay.
Jeff:
And not about methodologies ‘cos I think… And I’m not trying to say the stupid thing of, like, there’s no silver bullet. I think there probably are a lot of bullets that we could do that would make things better.
Casey:
Okay.
Jeff:
But I think the biggest problem with people who spend time thinking about software development and how to improve the process don’t do any software development. It’s pretty clear that they are more trying to manage people and trying to manage… And that’s fine.
Casey:
Okay.
Jeff:
The psychology of managing people is interesting in that.
Casey:
Is a whole separate thing.
Jeff:
I just don’t… That’s not the part that I find interesting. And it’s not the part that’s gonna make software development in itself better.
Casey:
Okay.
Jeff:
It might make the company that you’re working for better. But in the big scheme of things, who cares if one company is better than another like you write better software… It doesn’t fucking matter.
Casey:
Okay.
Jeff:
But research and science into how to make software better is very interesting to me. And I don’t think any of the people think about it like that.
Casey:
Or actually doing that.
Jeff:
Yeah, they’re thinking about it more like empowering people or taking people who aren’t great and making them slightly less shitty…
Casey:
Yeah.
Jeff:
And that’s fine. That’s a big problem in the world. But that’s not… That’s like saying that you study mathematics and then your paper is mostly about trying to get children to add better.
Casey:
Right. Yeah.
Jeff:
That’s not how we get better at math.
Casey:
Right.
Jeff:
It has to be studying people who are really good…
Casey:
There’s 2 separate problems [inaudible 15:41] How to make [inaudible 15:43]
Jeff:
Can make really complicated stuff and who are doing things way beyond that. And that’s unexplored territory because it’s not really… It doesn’t… It’s a small win, I think, in terms of the personnel part and the monetary return which is how people think about this. Like if there was some magic way to make everybody at RAD twice as effective but doesn’t help average programmers, that’s not gonna make that difference in the world. And RAD is certainly not gonna be able to pay your Agile company enough consulting to fix that. Right?
Casey:
That’s true. The value is [inaudible 16:21]
Jeff:
It’s not that kind of thing. I’m not trying to say RAD is, like, crazy. It’s just RAD has very good people that work on their own in isolation and who are very, very high end people. But making them better and that is something I think a lot about. And I don’t think anybody… I know I’m not a good enough person to do that. Like, I know for us, there are certain things that I would like to see research in that people don’t.
Casey:
So the first thing I’ll say about that just as a response is there actually are… There are very few but there actually are some researchers who do actually know what they’re doing. Not surprisingly, the one lecture I think I’ve ever seen by one of these guys was a lecture that basically said exactly what you just said. It was like, “Most of the people who are writing papers in this field do not know what they’re doing and have no metric. They are literally not measuring anything and why are they able to get away with all these publications because…”
Jeff:
Really, it’s hard ‘cos even in the isolated case of, like, we just want to get some beginners to be a little better… I mean, that’s even hard. Like, what does that mean? Like, less bugs or more code or…
Casey:
That’s what I mean. Yeah. So there are people who are in the academic field who are clued in. They are few and far between, unfortunately, as you would expect. But at least, there are some. I don’t know that they are making very much progress because, hey, it’s probably a hard problem but at least… It’s not quite as bad as you might think but it is almost as bad as you might think.
Jeff:
Things that I think we end up with… The thing that I think is the biggest unsolved problem is not a methodology of how to write more software. I think… And certainly, like, writing software, being able to write it efficiently and less buggy to begin with is important and good debuggers and good tools and all that. Yes. But the thing that I see over and over and over is that there just is no good way to test code in the long run. Like, your tests get old… We are constantly fighting… Take a complicated product like [ IGGY ], there’s a huge amount of test checks.
Casey:
Yeah.
Jeff:
And things still break all the time. And sometimes… Because it’s complicated… And it would be nice for people to start doing research on how do we write… Is it writing software that’s testable? Is that the solution? Or is there a way to write tests that they don’t… Because with tests, you have the horrible thing of you have code, you have another piece of code, both of which may or may not have bugs. You also have the thing that calls those. Those might bugs. And we’ve had all of them. We just recently had one where, like, something had been failing for a long time and the test worked. The test was failing but the thing that was recording failed…
Casey:
Yeah, yeah, yeah, right. It’s like a Russian nesting doll problem.
Jeff:
And then, like, how you write code that needs to be testable over a long term when you’re modifying the code… ‘Cos everyone can write an awesome test.
Casey:
Day 1, right. Yeah.
Jeff:
Day 1. But that your code changes and then, you’re fucked. And usually, what happens… And this happens to me. This is what I do every time is I have a test and it breaks because I change what that program does or I re-factor it and I don’t go… It’s just changing… Now I don’t remember exactly how that test is supposed to work or the data that I used to test it is no longer valid so I have to re--… And so, it just doesn’t happen. So that seems to… I know that sounds stupid but if that problem was solved, that’s 10 times better than me writing more code.
Casey:
That would increase software quality quite a bit if you had better… If you had a better ability to do those tests which is a problem right now, [inaudible 20:42]
Jeff:
And that’s something that as… The difference from a researcher from me as a practitioner of the thing is, like, I imagine a researcher being able to look at the problem from an angle that I can never imagine as a person actually doing it.
Casey:
Yeah.
Jeff:
But a lot of what I see in research is just very… It’s stuff that is either just stuff that you do… Practicalities or practices that you follow that seem to be slightly more successful or they don’t seem to be any more enlightened or more looking at things in a higher order than I do as someone who’s in the middle of it which is depressing to me because… I’m not saying they’re dumb. It just means that maybe this isn’t a solvable problem. I don’t know. But that is the thing that if I could push one magic button, it would not be a better language. It would not be a better debugger even though that’s what we’re working on. It would be like, “Here’s the way you test code.” And that can run for… You know, for us, the speed in which something is originally written is not that important at RAD. We have guys that are crazy fast. But for the most part, we write something that is used for a decade or two decades. I have code that’s still from Smacker in 1993. So I have stuff that old. So anything, any way to solve the testing problem that allows for code to age is a big deal. And there’s nothing that [ we have ]. Our tests run for a while and they go away. Sean’s better about that but it’s only because he’s so disciplined. And since it is a critical thing, it seems like it has to be something beyond being disciplined. But I don’t know. It’s my personal…
Casey:
If I may summarize, so literally, your answer to the Scrum/Agile question is laterally… You think the only thing that makes a difference is if someone could develop a testing improvement and the rest of the stuff is noise?
Jeff:
The rest of the stuff is like… Well, let’s imagine in a case where it takes us usually a year or 2 years to develop a product and then we sell it for 20 years…
Casey:
Yeah.
Jeff:
If you can cut the 2 years to one year, that’s nice. You can make the other 18 a lot more robust.
Casey:
I see.
Jeff:
That’s so much more valuable to us as a company and so much more valuable, I think, in terms of how those libraries go out.
Casey:
Okay.
Jeff:
And, I mean, you had some of this when you did all that really complicated [ big ] stuff is that there was so much to test…
Casey:
Yeah. And that did work really well…
Jeff:
Yeah, but it was because it was a black box kind of thing…
Casey:
It’s pretty simple. That was a simple problem to test.
Jeff:
And then you have things that are input-related or even timing-related, just stupid shit. And it blows up so fast…
Casey:
Yeah. [ Bing ] is a nice product in that sense because it’s so testable compared to [inaudible 23:59]
Jeff:
Right. Exactly. Big and huge and they have interface…
Casey:
Even [ Miles ] might be kinda hard to test but maybe that would be the next easiest probably.
Jeff:
Yes. So I don’t know. In general, when people talk about being a better programmer, I think if you program, you become better. It’s one of these things you do. You start learning things and you… If you’re an aware person… Like a lot of times, people just go through the motions. But if you’re an aware person, you’ll get better and Anders sounds super thoughtful…
Casey:
He’s aware of it.
Jeff:
Yeah. And those are things you just naturally get better at. But I’ve been doing this a long time and I have no idea… I have no idea how I would even approach the test problem. I don’t know if it’s tools. I don’t know if it’s editors, language… I have no idea what works. And that’s kind of a crazy thing in the sense that I feel like I’m very experienced with what I do and I don’t even have a glimmer… I guess you could put it this way. When I see a complicated piece of code doing something amazing on the screen, as someone who’s written code for a long time, I can usually take it apart and go, “Oh okay, I can see how they did that.” It might take me a long time to write that code if I’m not familiar with it. But I know…” I’m like, “Yeah, okay, I can see how that’s possible.” Occasionally, there’s a piece of software where I’m like, “That seems magic.” And sometimes, it’s because there’s tricks that I can like… Like [ Scribble ] [inaudible 25:23] is a great example where you’re like, “I don’t feel like that’s a product that should exist.”
Casey:
Okay.
Jeff:
Because you’re just like, “There’s no way,” and then you’re like, “No, I guess if you just do enough words…”
Casey:
Yeah, there’s only a thousand words [inaudible 25:34]
Jeff:
But it doesn’t sound like… But in any case, most things, you can imagine testing, I have literally no idea. We write the little tests that we have and I don’t have a test that, after a few years, is ineffective or is testing something that’s not that important like I spend all this time writing and that turns out to be… You know, it’s like [inaudible 25:56]
Casey:
Okay.
Jeff:
So I don’t know. But that’s what I want. The rest of that, all that stuff… I’m sure in a big company, there are techniques that are important like that.
Casey:
Yeah.
Jeff:
But I think I agree with him that most of the time, it feels like its covering up for… It’s giving bad people something to do with the 20% of the time that otherwise, they’d get in and break something. Like, making those kind of programmers slightly less effective.
Casey:
Yeah. Okay. I can see that.
Jeff:
I don’t know. What is… When you program, do you have things that are…
Casey:
I have a very different perspective on it than you do, I think, based on what you said. Now, I would say… Obviously, for a frame of reference since most people don’t know, you and I, we tend to work on very different sorts of things. So I think my perspective is definitely gonna be sort of skewed in a different direction ‘cos of that. You tend to work on small problems with an incredible amount of engineering to make them optimal is the way I would typically do it, right?
Jeff:
Okay.
Casey:
So it’s like, yes, I’ve worked on [ play back ] video for 30 years, right? And we never really wanted the video to do anything other than play back video.
Jeff:
As fast as it can.
Casey:
But it keeps getting more ridiculous on more platforms and higher speeds with better compression, blablablablabla… You know, with less and less resources on the fucking 3DS, goddamn it or whatever, right? And I never work on stuff like that. Like, I almost never do that thing.
Jeff:
Yep.
Casey:
I’ve helped you with it once. But I’ve never done it myself. And I don’t think it’s something that I ever would do myself. I am not the guy who’s gonna come up with the fastest X that there is. I just don’t… I don’t really enjoy it. Like, once something is solved within 20%, I’m happy with that and you’re the person who looks at the 20% and goes, “We got 20% to get here,” and like, goes in there, right? So I think I tend to look at things a lot more from a “how can I do a lot of stuff”. I want to get a lot accomplished and that lot is not necessarily going to be at the hundred percent optimal. It’s gonna be lower. And I accept that. So it’s gonna be less efficient. It’s gonna be… I don’t go all the way down to where web programmers are where they’re like, “It’s 100 times slower than it should be.” It’s fine. It’s Ruby running on top of Apache running on top of an emulated Jave VM that then runs on another [ instance ] of Apache that [inaudible 28:27] that, which runs through PHP, through a virtualization layer, all of which is running on a hypervisor inside of [inaudible 28:34]” And I’m like, “This is why my Gmail takes 7 years to load? Because you fuckers couldn’t just write the goddamn code in C and pile it?” So I definitely… I have standards. There’s a line I’m not willing to go.
Jeff:
Sure.
Casey:
Like, I want native code. I want it to be written reasonably. But I definitely am someone who likes to write new things that do more than they could do before rather than focusing on something with a more laser-like precision and wringing it out like going, “Okay, we can get better. We can get better. We know we can get better.” And 80-20 is a bad thing. It’s probably more like… I mean, you guys… If I did Bink, I’d probably be at 25% of where you are. I wouldn’t be an 80. That’s a misnomer but you know what I mean.
Jeff:
I would need to say sometimes it’s not even iterating on performance, it’s iterating on just robustness under fire, stupid shit like that…
Casey:
Right, yeah. You do like [inaudible 29:27] All that stuff. So 80-20 makes it sound like I’m getting a lot more. So probably less than that but you know what I mean. There’s the “good enough” and then there’s the “excellent”. And I’m not going for the “excellent” usually ‘cos I’d rather do two “good enough’s” than one “excellent” or whatever that tradeoff works out to be. So when looking at that as a thing, I tend to focus probably on things that are a little closer to what a company would focus on. Like, I think my needs are more aligned with the company probably than yours are. I think very few companies are developing the software that you’re talking about developing.
Jeff:
Yeah.
Casey:
They’re probably developing more like the software that I’m developing. That said, I probably still don’t have a similar opinion to them. But the way I look at it is no matter how many programmers you have, in general, you can look at them as sort of having two (I want to say) watermarks or two levels that you want to look at. There is what the programmer is capable of understanding to do and then what the programmer does. And these things are very far apart everywhere I’ve ever been. Period. Meaning, a programmer may very well understand the correct way to write something. They may know that the most optimal thing here would be to use a heap that writes directly to a memory stream, the things in order as they come in sorted on 3 threads with this locking mechanism. Like, maybe the programmer is that good to just know all of this stuff. Then, there’s what the programmer actually writes because that thing may take 6 months because it’s so fucking complicated to create or whatever and they don’t have the code. But they have the code lying around for a couple other things they could reuse and it’s very simple for them to write it in this other way. And that’s good enough. So that’s the thing that they write, right? I tend to look at programming methodologies, styles, code-based structure, all of that stuff, and languages as what that bar differential looks like. If I can take a language, if I can have a programmer programming language A and then I moved him to programming language B and that distance shrinks…
Jeff:
Okay.
Casey:
That is a better language.
Jeff:
Okay.
Casey:
So one of the big reasons that I think C++, for example, is not a better language than C is because I have yet to see any evidence that that bar shrinks. I see a lot of people saying that they’re getting something from it. I see a lot of people tying a lot of code. But the actual output does not seem to be any better than the output they were having with C. If anything, it seems to be worse. It looks like the bar is separating because the thing I know these programmers are capable of understanding what to do, they’d end up spending a lot of their time with all of the C++ stuff that doesn’t actually end up making the thing that they end up implementing any closer to the thing that they knew was good enough. So I’m not even…
Jeff:
My exact example there is the reason why I like C better than C++ is there’s already a big problem of trying to write something as complicated in a language as simple as C.
Casey:
Yeah.
Jeff:
When you have a C++, you end up spending a lot of time thinking about C++ and not the problem which hasn’t done anything except distract. So that’s a big part off [inaudible 33:07]
Casey:
Okay, so let me keep going on my example or the example of my framework, I should say. So you have to start looking at what are the contributing factors to that delta, right? And a number of them are not obvious and are not often discussed overtly, which is unfortunate. Sometimes, they are. But it’s actually somewhat rare when people talk about programming or, “Hey, there’s this thing I did and you should hear about it” whatever… They often don’t mention these. Some of them are how often the programmer is actually typing the code into their machine. Now, this is an incredibly complex factor that involves stuff like whether they were enjoying the act of programming, whether the programming takes too long, the editor sucks, the debuggers sucks, the platform is crashing, it takes too long to compile the code, you know, like I sit around waiting… There are all these factors that go into whether the programmer is just fucking typing stuff in or that they’re checking Facebook or getting up out of their desk and going to talk to somebody else about something when they didn’t really need to do that. There are so many things that go into that that are underappreciated. And you see this a lot when people say that they don’t think, like, compile times that big a deal or even a 2-minute, 5-minute, 30-minute compiled times are okay… They are discounting the degree to which lots of factors affect whether your programmer is actually working during the day, how much of their time they’re actually working because talking to another programmer is fun. It’s more fun than coding when the coding is rough. And the program can be rough for reasons that have nothing to do with whether the actual code you’re writing is hard. It can be all these other things that you’ve put in place that thwart you — Your source code control sucking, there are so many things… So those things…
Jeff:
You’re scared, like…
Casey:
Yeah, you don’t know what’s going on…
Jeff:
Yeah, or you can’t change something [ as scary as ]…
Casey:
Or people are arguing all the time about shit or they’re stupid code convention [ rules ] [inaudible 35:06] those, I would say, almost the first thing to focus on rather than Scrum/Agile or any of that stuff. That’s, like, way down the line. It’s just what is the actual cycle of programming like at your company and what can you do to improve that? And a lot of time, most companies have loads of work they could do to improve just that thing before you even started talking about how I was assigning tasks to people or what their methodology was. Methodology is way above that unless you include in methodology how long the fucking compile takes. Now, granted, some things like Agile programming thankfully do emphasize turnaround, those sorts of things… I think that’s good. But it’s worth talking about that as a separate thing which is, like, it’s not just about because turnaround takes time. It’s also the demotivator of that that’s important.
Jeff:
Right.
Casey:
Like, how much momentum you have in your coding, right? So there’s all those things. Once you get above those things, so once you’re at a point where the person is happy with their editor, they’re happy with their source code control (happy enough), they’re happy with their debugging, they’re happy with their deployment scheme, and they’re happy with their running… So the whole cycle of programming is clean and efficient, right, which is actually very hard because almost no tools vendors focus on this. Microsoft Visual Studio is so far from satisfying any of those needs, for example.
Jeff:
Right.
Casey:
It’s really kind of ridiculous. But in the old days, you could imagine Turbo Pascal or something hitting this high point. There’s like this editor you can type in. It works really well. You hit run and it’s blazingly fast. The debugger’s right there. It steps instantly, all those things we’ve lost. You know, stepping now takes a fucking minute in Visual Studio, right? And oh, my God. Today, I even… I was thinking to myself how ridiculous it is that now when you step, the variables don’t update. They take a while…
Jeff:
Yeah.
Casey:
So if you step 5 times, you’re seeing old ass data on your [inaudible 36:57] I’m like, it’s so bad. It’s worse than 1986, people. How is this possible?
Jeff:
Well, the demotivation is getting worse. Period.
Casey:
Oh, it’s just getting worse and worse and worse. Tools are getting worse.
Jeff:
And just the way people think that this is how it should work like deploying something to another device, this [inaudible 37:19] of signing and [inaudible 37:21]
Casey:
Oh, God, yes. Like android STK? Shoot me in the head. Or iPhone signature and all this shit.
Jeff:
All this shit is like…
Casey:
Fuck you all.
Jeff:
It’s so distant and, like… And the worst thing in the picture for me in this very specific example is that at any one time, when I go to work on something, I will have forgotten what it takes to, like… Today, getting something running on the [inaudible 37:45] was 2 hours of me goddamn [ swearing it ], goddamn [inaudible 37:48]
Casey:
Yes. Right.
Jeff:
And it’s like, that’s not fun. It took me for hours to do something that was literally 10 minutes once I was able to [ Print F ].
Casey:
Yes, absolutely.
Jeff:
I didn’t even need a debugger. I couldn’t get the debugger. That was ridiculous.
Casey:
[inaudible 38:00]
Jeff:
This was like, as long as I could as I could just fucking [ Print F ] and I’m like, “Okay, this was your bug. You’re misunderstood.” That’s all it took. It was 4 hours to find out it wasn’t even us.
Casey:
Yes.
Jeff:
And so, that’s just a bummer day.
Casey:
Yeah.
Jeff:
I was just… It sucks.
Casey:
Absolutely. And not only that but the programmer knows this and they will be reluctant to start work that day. They will do whatever it takes to not start debugging the [inaudible 38:26] problem. They’ll fucking go get coffee. They’ll go to lunch. They’ll talk with their friends. They’ll do whatever, Facebook, Twitter, it doesn’t matter what… If you know what your next 2 hours is gonna be is completely unproductive fucking around with the [inaudible 38:39] kit, then that’s what’s gonna happen. And so, I think that stuff is tremendously important. And if there’s anything the industry could be doing right now to fix that at a systemic level, that would be the one to focus on because it’s actually not that hard to solve. You just have to care. People have to realize there’s a priority and start demanding it and stop fucking buying a new… Just be like, “We’re not buying any more Visual Studio ever. We’re not buying this product until you fucking fix this, right?”
Jeff:
Yeah.
Casey:
Like that alone would go a huge way towards it. But okay, after you get past that point, now we get into some other things. So now, there’s the degree to which the language allows you to type in what you know to be the correct thing to do.
Jeff:
Okay.
Casey:
Right now, we are way far for that. That is a really big problem. So C is good at one level of that problem which is that if I have something that I want the microprocessor to do that involves non-parallel, non wide instructions…
Jeff:
Right.
Casey:
C actually solves that problem pretty well.
Jeff:
Right.
Casey:
It was good at that. So if you were sitting down to type something that a microprocessor with single wide execution units and no threading needs to be able to do, C was a very good language for that. It is unlikely that a programmer who know what they’re doing, who has that problem to solve will have a problem typing that in, right? However, 2 problems — 1, once you extend it to a modern day, no one has made a language that allows you to actually have that ease of use. So the highly threaded and wide C doesn’t do very well.
Jeff:
Why, I think, if you lock down a platform it’s not terrible at ‘cos you just get used to the intrinsic that are there and you’re fine. But the problem is it doesn’t abstract well across them but that’s…
Casey:
I don’t really agree with that and the reason that I don’t agree with that is because if you… And it’s mostly because maybe I’m setting a higher bar for what I want this language to be. But basically, when I look at what C did over assembly, it picked some very important things that are the time-consuming things and eliminated them — register allocation being the number one. And when I look at the extension from single to wide and I go, “Is it doing that same amount with, say, the intrinsic?” The answer is no because a lot of swizzling and stuff like this that actually could be automatically solved in pretty good ways…
Jeff:
Yeah, that’s true.
Casey:
And again, it’s never perfect just like register allocation isn’t as good as a human…
Jeff:
That’s true.
Casey:
Who really [inaudible 41:29]
Jeff:
I agree. Yes.
Casey:
So something more like IPC or whatever… We’ve done some things that show that we could start building languages that actually did what we want here. The technology exists but we haven’t main-lined it, right? So there’s that. The second thing is code that takes a long time to type and debug is currently, even in C, not able to be reused properly. And C++ also failed to allow that code to be reused properly. Templates and classes are very bad layers of abstraction for code. I feel like they were clearly written by people who actually don’t think about how code is reused very well and probably haven’t done much code. In the case of both classes and templates, that was true. I don’t like the people’s mentalities who made those things, originally…
Jeff:
I think they’re fairly different. I think classes were just a silly thing in a sense you made an entire language construct thing for something that just doesn’t happen enough to dedicate a lot of mental energy for. And once you have a big system like that, then they started relying on it for other things.
Casey:
Well, they’re…
Jeff:
That’s a separate, like…
Casey:
Yeah.
Jeff:
I feel like you could ignore that part of C++ and be fine. Templates, I could not agree with you more that those people were looking at things in a [inaudible 42:57] way…
Casey:
’Cos they were trying… You’re right. They’re trying to solve a problem that we actually do want solved but they did it in the worst way possible.
Jeff:
Yeah, they did not get what we wanted.
Casey:
I actually see them both as the same. So I see them both as attempts to break down combinatorial problems, right? So in the template case, I’m trying to say that I have a particular algorithm. I have a particular set of piece of code, set of instructions that I want to be able to map to a number of different things which may have variations in them, right? And the classist thing was trying to solve the problem of I have a number of different sort of logical entities that I would like to be able to treat the same way at different times depending on the circumstance. And they’re both valid things to be trying to solve. They’re both valid approaches to the combinatorial problem. They’re valid ways to sort of thinking about the combinatorial problem. Neither implementation actually has the elements that you need to successfully make those combinatorial things work, right?
Jeff:
Well, I think… Yeah, I think especially they don’t allow you to not think about them in the way that you’d want that problem to be solved.
Casey:
Well, they also just don’t work. Most people think that these things work but they don’t work. If you actually try to go, “Here is a solid concept that we understand,” like I said with [ heap ] and we try to implement it with either of those things, it actually fails. And it fails in ways that I don’t think people understand. But putting that aside for a second, I feel like there’s a big gap that’s just language-based right now which is that programmers aren’t typing in the thing that they know that’s right because it simply will take too long to do and they have never been able… They have never been given a tool see that would adequately allow them to write those things once and use them as tools later in a way that didn’t incur substantial interconnect overhead. And that’s what you see with C++ a lot. So people try to bridge this gap with C++. They embrace the promise of C++ and go, “We put all this shit in templates or classes and now we’ll be able to do all these great stuff,” but then, what actually comes out the other end is something that has a massive interconnect overhead in one of three places and oftentimes, all. And those are things like, number 1, the fact that the code becomes entirely unreadable or debuggable, right? This is a huge problem especially with templates, right. But it’s equally the same. Even with classes, there’s stuff that people don’t appreciate there which is that the ability for someone to read class-based code is incredibly difficult, actually, right now. Someone who is unfamiliar with it, getting up to speed, it’s a big difference from C when you just read the code and it was very clear what was going on, right?
Jeff:
Yep.
Casey:
And there has been no real good solutions to this problem yet. But templates, obviously the more obvious one, where even in a simple situation, just the act of trying to go through what the fuck is going on quickly gets out of hand when you try to actually do something real with them.
Jeff:
Right. And also, the concept of once you have templates, a very good set of template library, then you can plug these things together and not have to understand how those algorithms work…
Casey:
Right.
Jeff:
The problem is whenever you take to these 2 things and try to combine them, the only way that you make that interconnect really work is you writing template code…
Casey:
Oh, yes…
Jeff:
[inaudible 46:40]
Casey:
Yes.
Jeff:
Which means you have it… Yes, you don’t have to write an AVL tree or something but now, they have to understand the very complex and interrelated way that the AVL tree might call your other class that is your… Like, you’ve made them have to understand the algorithm without having to have written it which is nuts.
Casey:
But number 2 is internet cost that’s just speed. A lot of times, the template or class-based code…
Jeff:
I take the speed [inaudible 47:12] if there was a magic [inaudible 47:14] but continue.
Casey:
Well, it has nothing to do with taking hits. I’m talking [inaudible 47:19] about that gap I’m measuring. And speed is a big part of that gap because if your programmer knows how to do things fast and he’s not doing it fast, that’s a big part of that gap that I’m talking about because there’s a difference between optimizing code where it’s like what I’m talking about here where it’s like, you know, I’m making Bink and, you know, I sat down to write it. And like I said, I only did 25% of what you guys could do because I didn’t want to spend 5 years or I just don’t even have the skills necessary to crank it to that level. That is not the gap I’m talking about because I’m fine with that. I’m fine with taking that speed hit because it’s like the only way to do that would be a lot more work or a lot more learning on my part, right, and that’s fine. I’m talking about the speed hit of let’s say I know how to make the optimal Bink, I know how to make something 4 times faster [ when typing in ] but I just don’t because the language makes it take way too long for me to do that. It has nothing to do with me working. I’m not figuring anything out. It’s just the actual act of fucking typing it in and debugging it takes too long. It’s just not a good use of time. And so, that is an important gap on the template side of things because a lot of times, what it ends up generating is not the optimal code, it’s not the smart code, but you take it because actually trying to get the templates to do the smart code, it’s way more work, it’s way harder to bug, it’s way messier, whatever, right? And that’s the bad part of the gap, right? And the third thing is that oftentimes, it just doesn’t work. So you create something that is reusable to a point but it’s really not that reusable in the end. It turns out that there’s just a lot of constraints on how it gets implemented in the end. So it’s like, “Oh, yeah. Okay, now we wanted that to work with double. Oh, well, alright, so add another template parameter that’s the type,” and like, “Oh, wait. Now we wanted it to sort of work with complexes but it has to work with complexes in this other way. We have to put this in…” You end up actually having to rewrite the thing every time almost anyway so you don’t actually get this win even if you knew how to write it correctly the first way. The templates oftentimes make it more costly to write something in the fully general way even though, conceptually, it was no harder to conceive of it in the general way. And that’s a big part of the gap, as well. You see that a lot with more complicated pieces of code like storage-style stuff or things that want to execute stuff out of order and all this stuff. The language just does such a poor job of encapsulating those things. And so, I think that’s a really big part of that gap, as well. Finally, when you get to the top of the gap, that’s when I start to see things like Agile or Scrum-based stuff having any relevance which is why I kind of don’t really think about them much because they…
Jeff:
So they may actually be valuable but we’re so far from them being necessary… We’ve got so much of the gap…
Casey:
So where those things… So there’s 2 places that that can have an effect, something like Scrum or Agile can have an effect. One of them, I think, could be valuable. The other, I think is not. So the one that I think is valuable is if simply having the Scrum… If having that system in place makes a programmer more likely to fucking do work during the day, then that is valuable. So if your programmers don’t do any work when they don’t have the little corkboard with the things on it or whatever the fuck, right, if they’re not focused and they’re not doing work, then I do see those systems as potentially being valuable as a motivational tool. It’s not so much about the methodology. It’s just…
Jeff:
It’s just getting [inaudible 50:50]
Casey:
If having a system makes them do more work, then that was valuable regardless of all the other stuff because, like I said, the first thing I listed was whether the programmer’s doing work. That attacks that bottom thing which is valuable at all times.
Jeff:
Right.
Casey:
So I don’t dismiss those methodologies out of hand because I think they can have an effect on that. Whether the actual methodology makes any sense as a methodology for producing work, if it just happens to motivate people more than not having it, then that was good, right? The place that I don’t think they really have that much of an effect necessarily is in actually taking care of the higher end parts of the problem that we actually do have if you took care of all the rest of this which is why I say I don’t think it’s that relevant because even if it was effective, we’re so far from that being a higher order effect. And that is like solving the end-way communication problem or keeping people from locking up on each other and having dependency. Those sort of things, while they are important to resolve, are so far down the food chain from what it…
Jeff:
Right.
Casey:
We have so many more fundamental problems than that that it’s hard for me to get excited about even thinking about is Scrum a good way to handle that. It’s like, if that’s your fucking problem, you’re in great shape because I’ve got problems that are way worse than that in terms of just the things we could attack here, you know?
Jeff:
Right. Well, it’s also that’s the kind of thing that you notice in the sense that, like… Hey, when somebody blocks on somebody else, you think, “Oh, my God. We can never have that happen again. We can never hire the smart guy that everybody relies on because that screwed us…”
Casey:
Okay. Yeah.
Jeff:
Those are the very visible things whereas the thing where everybody is just 10% less effective…
Casey:
They’re not 10%. . . They’re like…
Jeff:
Let’s say it’s 10%.
Casey:
They’re like, 90% less effective…
Jeff:
Over a 2-year project, that’s still way more than the blocking time. It’s just not visible. It’s that tiny little bit of stuff.
Casey:
Right. Yeah. So the one thing, just the thing that I’m trying to hammer home, I guess, though is that gap is the thing. Because we can talk about stuff that moves the top bar up, meaning making your programmers better themselves. This programmer now knows how to do better shit, right?
Jeff:
Right.
Casey:
That, I think, helps you not at all anymore because most programmers are actually not even operating to what they know how to do because of all of these impediments that really where our primary focus should be is just taking any given programmer who you pluck and going, “Why isn’t this person writing code that I know they could write. No matter how dumb they are, I guarantee you, the code they’re writing is worse. It’s true for me. It’s probably true for shitty programmers everywhere in between.
Jeff:
Well, I notice that all the time. It’s like, even me when you’re like… Even when I look at myself when you’re like, “I really like to solve problems with programming…”
Casey:
Yeah.
Jeff:
“So why don’t I want to do this?”
Casey:
Right.
Jeff:
You find that all the time.
Casey:
Yes. Why am I not looking forward to this?
Jeff:
And for me, it’s always because the things that I used to put up with as a younger programmer because part of putting up with them was the macho-ness of, like, “Yeah, not only did I write this code but the goddamn C compiler was so fucked up that it was amazing I could get it to compile at all.”
Casey:
Yes.
Jeff:
I just don’t have any tolerance… I hit that exhaustion. For example, I’ve never ever gotten the iPhone build. I just build the iPhone build. Like, never, never, never ran it on my system.
Casey:
I see.
Jeff:
I always ask Dan or someone to run it just because…
Casey:
You don’t want to feel the rage?
Jeff:
Yeah. And I know if I feel that rage not only will I not do what I’m supposed to do, that will kill me for days.
Casey:
Yes.
Jeff:
Where I’m just like, “Fucking goddamn it. What’s happening in this world?” And we have… I mean [ Bobby ] went through that period where he just…
Casey:
Yeah, that’s right. He was in a rage about the…
Jeff:
[ In this phase ] where he’s like, “I just don’t want to program any more.”
Casey:
Yeah.
Jeff:
It was one thing after another after another after another…
Casey:
Yes.
Jeff:
And part of it is the turnaround time and the cycle of which you can edit and play with but there’s also just something where it feels like everything is trying to prevent you from… It doesn’t feel like this is something that’s sewing you out. It’s like there are systems that are actively preventing you from doing stuff.
Casey:
Yeah. Well, it’s a lot like…
Jeff:
And I don’t think they think about that but it’s like you feel like you’re under attack.
Casey:
You know what I think of it as? I think of it a lot like… When I work on platforms, any of them nowadays really, I think of it a lot as, you know, “Pulp Fiction”, how they call in the wolf, right? I feel like “Pulp Fiction” kind of glamorizes what that job would be like but I feel exactly like that a lot of times when I have to do [inaudible 56:02] It’s like, “Okay, I’ve got to [ ship this app ] on iPhone,” and I show up and I’m basically the guy who shows up with the dead body in the truck. Everyone’s covered in blood, right? And the wife is going to be home in 30 minutes or whatever and it’s like… That’s what I feel. It’s like, I got here and it was like all these incompetent people shat all over this thing. And now, that’s the platform I have to work with. It’s like, this really hateful thing. And so, I feel like… You know, the first couple times you do that, maybe you feel like a bad ass like, “Yeah, I went and did this super awesome thing,” right?
Jeff:
Yeah.
Casey:
The 50th time he goes to a house with a fucking dead body and everyone’s covered in blood, he’s got to be like, “Why don’t you assholes fucking put some plastic wrap down before you fucking shoot a guy in the head? How stupid do you have to be? Why are you people incompetent?” And he doesn’t want to come anymore, right? He doesn’t want to come to clean up the bloody mess anymore. And I feel like that’s one thing and that happens to I think a lot of people after the cross platform shit because instead of just cleaning up one set of dead bodies every 2 years or whatever, they’re cleaning them up every 3 months. It’s like, “Oh, new platform, new DS built…”
Jeff:
Usually what happens…
Casey:
What did Nintendo shit all over me this week, it’s like, right?
Jeff:
Yeah.
Casey:
And each one’s updating every month. Xbox just pooped out a new [inaudible 57:26]
Jeff:
I’m using Nintendo and Apple as examples but everything’s like that.
Casey:
Oh, it’s everybody. It’s everybody.
Jeff:
The number of platforms…
Casey:
Yeah.
Jeff:
And even platforms that are fairly simple to develop for like Windows, they’re really pushing hard. When you [inaudible 57:43]
Casey:
[inaudible 57:42] crap it up more and more and more.
Jeff:
“Here’s this API. It just doesn’t work anymore until you make a manifest.” I’m like, “I don’t have a manifest. I never had a manifest. Now there’s this new thing in my build. I don’t want to do this! This used to work!”
Casey:
Yes.
Jeff:
And you feel it’s a very… It has much more of an effect on anything… Even the language, for me, my productivity is solely based on how much I feel like I’m wading in shit today and how much I’m just gonna be like, “Oh, I’m just gonna write some stuff.” So yeah, I mean, that’s…
Casey:
Most people don’t see how bad it is because they aren’t in your position. You actually ship for basically everything. I mean, most things that are out there besides server blades, you pretty much ship for.
Jeff:
Right. And also…
Casey:
And what that means is that you actually are one of the few people in the industry who actually realizes that this is a systemic problem. Every single place you can ship off for now has been crapped up beyond belief.
Jeff:
Well, and the important thing…
Casey:
Most people, we see like one or two [inaudible 58:47]
Jeff:
Well, I was gonna say the important thing there is, like, if you develop for iOS, you get used to the horse shit.
Casey:
And you forget about it.
Jeff:
And you forget about it.
Casey:
Exactly.
Jeff:
It’s like it goes away. But like, none of that… If all that horse shit was the same, no problem…
Casey:
It’s different everywhere.
Jeff:
No, everybody does this slightly differently and some sign and some don’t have to sign and some you have to emulate the disc and… This is very sad.
Casey:
It’s even language-based now. This is the thing. It used to be bad. I mean, it used to be pretty bad. But then, with Apple and android, they brought up a whole new wave of shit which is that now, we even have separate languages you have to write part of the code in. Like, you can’t even compile C to it anymore. You have to have a Java-binding layer or an objective C fucking layer. You’re like, “What are you talking about? Come on…”
Jeff:
And if that’s the only thing you do, then you say, “Well, it’s just one file and I just copy the…”
Casey:
Fuck you.
Jeff:
But I have 14 of those files and they break every goddamn time.
Casey:
Yes.
Jeff:
And then you’re like, “I have to re-remember this,” and it is the thing that, for me, has way more of an effect than anything else is the psychology of feeling like the platforms that you use are…
Casey:
Shit.
Jeff:
Hostile to you.
Casey:
Yes.
Jeff:
That they don’t want your stuff to run. They would actually… They want it to be this attrition to get there. It feels like… You just get to the point where you’re like, “Fuck this shit. This just sucks.”
Casey:
Yes, it does.
Jeff:
And it’s not programming anymore. It’s not even plumbing. It’s like supply-chain management. Get the plunger, right? And it’s nuts. And then the plunger’s not the right shape for the toilets patented. So you’re like, this plunger is for a different toilet. And so it feels… The closest thing is just feeling like it’s a hostile work environment like you have an asshole that lives in your office and you just have a guy that’s just mean. And you know how that would feel?
Casey:
Yeah.
Jeff:
It’s like, imagine all of your platforms are mad at you.
Casey:
Yeah.
Jeff:
That’s what it feels like. It’s a very depressing thing sometimes. So I can see… And I feel like Windows is going that way…
Casey:
Windows [ dumped that chart. ] If you do RT, you’re done.
Jeff:
RT is, like, one of the worst to use of all of them. And you’re like, “They have one that isn’t like that, that is nice.” And like, yes, there’s a million things wrong with Visual Studio but I don’t know how the people who actually work there don’t see that horribleness. So…
Casey:
It’s surprising to me, too, because when Win32 was the most recent platform API, you know, in 1995 or 1994… ‘Cos I guess Win32 S probably came out in, what? ’93? ’94?
Jeff:
Well, S came out technically after Win32 did because it was like the back patch to get S…
Casey:
But it was out earlier, I thought, because Win32 was only ‘95. Win32 only came out in ’95 then NT, right?
Jeff:
NT…
Casey:
But NT was earlier. NT was, like ‘92… Okay, never mind. So it was pretty early. Back then, you know, it’s a pretty bad API. I mean Win32 is pretty shitty. It’s a bad API. When I look at it now, I’m like, “This API is much, much better than anything I see today.” And to sit here and think about how perverse a world of computing we are living in when 20 years of technological progress has brought us a significantly shittier standard for platforms than what we have back then, that is terrifying. I mean, what’s it going to be like in another 20? No one’s going to be able to write anything.
Jeff:
I think even if you take out, like, “Hey, the quality of the API, the simplicity or whatever, the complexity of what [ is in all modern ] API now,” even setting that aside…
Casey:
Yeah.
Jeff:
I can get the documentation to any Win32 function on MSDN…
Casey:
Yeah.
Jeff:
Just trying to do that for Win8, half the API’s out there, they haven’t even documented a lot of the X11. It’s been out for, like, [ 4 years ].
Casey:
Seriously? I don’t ever use the X…
Jeff:
It’s just [inaudible 63:12] People are like, “Oh, it’s just happening so fast, the examples [ of the code ],” like, I did some fucking PHP to hook to a Google drive. The download… The STK that you download is brand new. So none of the examples work. They [inaudible 63:34] the examples until after…
Casey:
Awesome.
Jeff:
And then the standard thing of the web of, like, a hundred monkeys all trying to paste it together means that you just have example code that’s a mixture of both out there. And it’s like, “This is shipping end products.” This isn’t just… I’m using a [inaudible 63:54] stupid bullshit but people depend on this.
Casey:
Right, are making these games that have to run it. I don’t know…
Jeff:
It’s just very… Yeah, I. . .
Casey:
So let me talk about it clearly…
Jeff:
But I’m assuming when I say that testing is the most important thing for me, that is starting from the aspect of an imagination where I’m in the window where none of my platforms…
Casey:
Which are broken…
Jeff:
Have been fired…
Casey:
Okay.
Jeff:
Or broken…
Casey:
Yeah.
Jeff:
Or have stopped syncing…
Casey:
Authorizing…
Jeff:
Or their firmware’s too old…
Casey:
Yeah.
Jeff:
In this magic window where all my platforms are able to run…
Casey:
Yes.
Jeff:
Testing is a huge problem.
Casey:
Okay.
Jeff:
But I will say…
Casey:
That’s actually number 1.
Jeff:
And second thing which is that… And all I can… My only thought there is that it has to be temporary because I can’t imagine…
Casey:
It can’t go on forever?
Jeff:
It can’t get any worse so it has to… They have to eventually improve. Like, eventually…
Casey:
But I might not have been able… Like I said, back in ‘92 or whatever… So the first time I programmed with Win32 was in ’92 or ’93, sometime around there. That’s when I entered at Microsoft. So that’s the first time I ever saw Win32. Before that, I was in LINUX C [ Slackware ] I think, one of those [ LINUXes ]… I don’t know if it was [ Slackware ] or something else. And I was on Amiga before that which I loved. That was my favorite platform, by far. But back then, with Win32, I thought it was bad but I don’t know that I had in my head… I don’t think I could’ve predicted these… Like, right now, I look… And I would agree. It’s like, “It couldn’t get any worse.” But I between it can. And you just haven’t seen… Your poor little brain who’s only thinking about reasonable code can’t possibly conjure up a abominations that Microsoft, Apple, and Google will come up with when they have… Even people who are even less qualified to make API’s than they do now because every generation’s getting worse at making that, right? Every generation of people is further away from someone who ever programmed a microprocessor directly and has less and less of a grasp on what the code is actually doing at all and has more and more C++ crap than other things Java, PHP…
Jeff:
[ I just think like ] what does the programmer at Microsoft, when he hits F5 and there’s this whole rigmarole to get the thing running under Win8, to run the thing under the Store App is a huge pain in the ass.
Casey:
Yeah.
Jeff:
Is it just that he has IT there when the wireless doesn’t connect ‘cos it doesn’t? Is it that he has a support system so he never sees the fact of, like, “This is ridiculously bad.”
Casey:
Here’s my theory. I have only one theory for this because I don’t know. I really don’t.
Jeff:
Or do they, like… Do they have the secret where we can just run stuff and don’t have to, like, maybe…
Casey:
So here’s trying to sort of get a handle on what happens there. I think that if I looked back at my own programming over the… Okay, so I had done it for 30 years now. So if I looked back at the 30 years that I had been programming computers, there are plenty of times earlier on… I don’t do it so much anymore ‘cos I think I’d probably gotten better at this part of it but certainly in, say, the first 20 years of programming, there were times when I conceptualize something and I went down a path and the thing that I ended up with is a completely unusable pile of garbage. I have this big idea of how it’s going to do something and all these things are gonna work together. And I work for a couple months. Then the thing at the end was a disaster. And it took more lines of code to get it to do the thing it was supposed to do than if you just wrote the thing that you try to get it to do yourself.
Jeff:
It happens a lot. Yeah.
Casey:
So what I think happens… And I look back and it’s like that literally happened. That could happen at any time during literally 20 years maybe of [ my staying ]. Most programmers, I think, at Microsoft now have been programming probably less than 20 years. Probably. I think what happens is a lot of these API’s they ship are because they did exactly what I did during those times and then it came to the time when they had to release it and it fucking went out the door that way, something that I would never in my wildest dreams ever ship to anybody is what now everyone’s using. And I think all of this is that way. I think things like DirectShow, I think that’s absolutely what happened. Their people, inexperienced, don’t have the right metrics in their head, won’t have those metrics for another 20 years if ever (I mean, they might not be people who are even capable of leveling up to the point where they might just not even ever be that good of a programmer), sit there and go, “Oh, it’s going to be this thing. They have this great idea. It’s going to be this thing. They plug them together and then you can make this… It’s just like using Outboard MIDI Gear and it’s going to be cool.” And they may even sort of realize when they finally have to ship it, they’re like, “Man, this does not work…”
Jeff:
When we have to write the example programs… Usually, when they write the examples, then they go, “Holy shit.”
Casey:
They may not have learned that. One of the primary things you learn is always write the [inaudible 69:31] code first. They may never learn that.
Jeff:
I’m saying it does…
Casey:
There’s people [inaudible 69:34] who do sample code. They may never really have done…
Jeff:
Oh, I see.
Casey:
Sample code which is a huge problem, right? You know, it’s a huge problem. They may not realize that’s a huge problem. So I think that’s sort of what happens. And then the problem is it’s a latching mechanism. Once that goes out into the wild. It’s there.
Jeff:
Yeah, that’s true.
Casey:
I mean, [ that’s where it’s at ]. So I think a lot of times what sort of happens is manifests, they probably sat down and someone who’s very inexperienced, you know, doesn’t… And again, may never be a great programmer… They sit down and they’re like, “We’re trying to fix this problem…” And there’s a bunch of them in the room…
Jeff:
Or it could be a good programmer and they just got stuck.
Casey:
Like I said… But I don’t know. [inaudible 70:12] programmer but even if they were, like me… Like I said, I’ve made these mistakes before. They sit down and they go, “Okay, here’s what we’re going to do. We’re going to have a file that lists the things that it needs so we’ll always know from now blablabla…” And they just don’t see down the road what that’s actually gonna lead to. And by the time it actually gets out there, they either can’t fix it or it’s like, you know, they don’t see the problem with it because they’re not actually doing active deployment with that thing. And it’s just everyone else who suffers. And so, I think that I can see how either not good programmers or good programmers who just haven’t learned enough yet can get into those situations. And the problem is just in my situation, I can just throw that away. But in their situation, that’s not what happens to that thing. And so, at some level, if you want to fix this at a systemic scale, you have to start embracing the fact that projects actually fail and can’t go out the door. Like, API’s have to not ship sometimes and you have to stop doing that. And that’s a very difficult thing to manage around and structure and I think it’s just not happening. And so as a result, you get things like the Android STK, you get things like WinRT, that are just… These are inexperienced programmers with bad ideas who haven’t learned enough and who, worse yet, may never be good programmers, they might not be people who have that talent…
Jeff:
Or they may be really good and they’re like, “This is what I cobbled together on my machine ‘cos I had to [ segue ] and I got it working and I happened to have make and… Run the PHP and the Pearl thing and I just had this.” And then somebody says, “Well, now we gotta ship that to everybody else.”
Casey:
And you’re like, “What?”
Jeff:
And then you burn the VM and send the VM out…
Casey:
Exactly…
Jeff:
Because you couldn’t figure out how to make that [inaudible 71:56]
Casey:
And I think that that is a fair bit of it. There’s obviously other times when people are actively optimizing the wrong metrics and that’s simply a case of you not being good enough to realize what is important here. But again, like I said, I think every mistake that I see made in these things are mistakes that I myself have made. And the reason that I know not to make them now is ‘cos I went through that. So if there are programmers who are all these things who have never had that educational process, then that is the problem. You need very experienced, very good programmers to design API’s. It is the hardest single job in programming that there is bar none. And it is almost never given the attention that it deserves.
Jeff:
Right.
Casey:
And I mean that literally. There is literally no programming task harder than making API’s. And a lot of that is probably that our languages are very primordial. And so, there’s a lot of [inaudible 72:53] which…
Jeff:
Well, also because the latching thing… Like, it has to be good because you’re going to end up supporting that, good or bad, for a long time unless you just toss it.
Casey:
Yes. Well, there’s so many reasons why API’s are important. A is that they do tend to stick around for longer than you expect, right? And so basically, you have to respect that part. B, it is a one-to-many problem. You’re going to design this API design once but then tens, hundreds, thousands, tens of thousands, sometimes millions of people have to deal with it.
Jeff:
Right.
Casey:
So the leverage is incredible. One mistake that cost an extra hour of programming’s time in your API means a million lost hours if a million people write programs in that language, right?
Jeff:
Or worse, an easy… If you write an API that’s easy to write a bug…
Casey:
That’s a million bugs.
Jeff:
That’s a million bugs.
Casey:
Exactly. So the leverage is huge on API even if it’s just internal to your company, the leverage is usually huge because usually, you’re talking about something that lots of people use for a lot longer than you expect, right? So there’s that. And then the other thing that’s super important that is sort of central to the problem, the reason why I say that you need your best people on it, is because API’s involve making very complex decisions about trade-offs and usability that is different from everywhere else in your code. Like, figuring out at this sort of main primary interface layer the degree to which mistakes there because of that leverage come into play is way worse than it is in lower pieces of code. So if someone chooses the wrong functional decomposition for something in a lower piece of code, the impact to the code around it is much less because there’s only one little layer of crust that actually ends up forming there. But if that gets pushed out to the API level, now literally everything you write for the rest of time at that library has that crust on it.
Jeff:
Right.
Casey:
It’s really bad the way the leverage pushes out that way. And so, it really is the most important thing. It’s very poorly understood. I don’t even know… I have that talk a long time ago that’s talking about reusable components and how they need to be designed. I’m not even aware of a single other person who’s ever fucking given a lecture on actual criteria for good API’s. I literally know of… See, I’m not even talking good ones. I don’t even know of a single person who’s ever even fucking tried, besides me. That’s how much people don’t seem to care.
Jeff:
Well, I would also say the bar for which people refer to something as an API now is low.
Casey:
It’s like if I exported a function, it’s an API, yeah.
Jeff:
Here’s a protocol and the structure that comes back from the [inaudible 75:44] that’s our API [inaudible 75:45]
Casey:
Right.
Jeff:
That’s not an API. I’m sorry. That’s not an API. That’s a protocol and some fucking…
Casey:
Transfer?
Jeff:
And some struts with no goddamn example.
Casey:
So this dovetails into the fact that you’re talking about — platform fatigue. It actually leads into one other thing that I want to talk about on that sort of programmer motivation, are they doing work… There’s a thing that happens with older programmers, more experienced programmers, that doesn’t happen with younger programmers. It’s one of the reasons that sometimes older programmers aren’t as productive as younger programmers even though they’re better programmers. And that is… I don’t have a good term for this. I think there probably is a Grecian myth that would be appropriate but I think there might be… Isn’t there a myth about a person who is going to die but they get to choose how they’re killed or something like this?
Jeff:
I don’t remember.
Casey:
So if there was a myth for that, that’s the one.
Jeff:
Okay.
Casey:
So basically, at some point, because of that gap, I think… Although I am sort of talking about that gap explicitly and openly here and I feel like people probably understand it, what I just said about it. I realize that most people probably hadn’t been thinking about the gap that way necessarily. And it might be a different perspective for them. But I think they all feel it if they’re experienced programmers. They feel the gap. And what I think this translates to is when you sit down at your computer and you are an experienced programmer and you have a task to do, you know, given the tools that you have and the time that you have to do it, you know that you are going to write something shitty. You know.
Jeff:
Right.
Casey:
And it’s not your fault. There’s nothing you can do about it. You couldn’t work twice as long today and have it come out. It is simply a case of making the thing that is performance, reusable, concise… All the things that you know you could do is not possible in the language that you’ve been given, right? With the tools that you’ve been given to write it and view it in. So you know, sitting down, that what you’re task actually is today is to pick the least important one of those things of a multiple of those things to give up. So when I sit down to write this piece of code, it’s not about the excitement of figuring out how to write this page layout piece of code that I’m going to write because you know and I know that we can both sit down and write page layout code in 5 hours any day of the week, not a problem. The difference between that and the page layout code we want and know is conceptually possible is non-traversable, right? Because every step of the way, we’ve got to say something. First, “Oh, well, I’ve got to first choose which character encoding it’s gonna be in.” There’s no way to really write a piece of code that is character encoding agnostic. Even though, conceptually, it is trivial to conceive of it that way, the actual act of programming that out is almost impossible. Like, “Oh, maybe…” And then you start to think like, “Oh, I can template-ize it on the type of character… No, that’s a bad idea. We know where that goes. And here’s all these problems I’ll get into if I do that.” It’s like, “Okay, I can use [inaudible 79:14] but okay, that’s not gonna work ‘cos I’m gonna have to detect it and I can’t [inaudible 79:18] properly or I’ll put all these codes that’s hard to read ’cos it’s got all these instances…” All you’re doing in your head is sorting out what shit you will accept today. And I think that that turns programming for experienced programmers into a very sanguinary process. It is about what blood will be shed today, not about what new heights you will accomplish.
Jeff:
I see.
Casey:
Because we all know what the optimal thing is and we all know, other than you sitting down and trying to conceptualize a new language today, you ain’t getting there. You ain’t getting to the top of the mountain because the mountain is floating in mid-air and you haven’t a flying machine. And so, I think that I see that a lot with people. I know it happens with me. And it’s one of the reasons that nowadays, I spend a lot of my time meta-programming. And it’s because programming isn’t fun anymore. I know all that’s gonna happen if I crack out an existing language, no matter which one it is. And don’t fucking write in and say [ switch to get ] ‘cos fuck you. I know programming very well and I know for a fucking fact that your language blows, whichever one it is that you’re about to say, fuck you and your language. Period. Because they all suck and nobody knows what the fuck is going on, right? But once you start to sort of take things a little bit more into your own hands, it starts to become a little bit more fun again because you can start to go like, “Oh, okay. Now, I am actually back to thinking about could I make progress,” whereas in today’s languages, if you’re actually programming directly in them, it’s all about, “What do I forego?”
Jeff:
Yeah. No, I agree with that.
Casey:
And so, I wish there was a good name for that. I feel like there’s got to be a Grecian myth I could use to [inaudible 81:10] Someone who’s good with the classics… I don’t think Steve Theodore listens to the program but if he did…
Jeff:
He would point…
Casey:
He could help us out here ‘cos he’s, you know… I mean, he’s a Greek and Roman history almost PhD. I don’t think he ever bothered to finish it but he’s got skills.
Jeff:
He’d be able to pull that myth out.
Casey:
He would be able to pull that myth out or story… Maybe it’s not a myth. It could be a play or a book from that period. I’m sure it’s there.
Jeff:
Well, we didn’t… I don’t think we offered too much on Scrum and Agile except to say that if that’s your problem, you’re in a great place but it’s probably not your problem.
Casey:
Yeah. I mean, I think it’s a very uninteresting part of the problem. And I guess what I would say is like any other system, it’s more important to understand what you’re doing and whether it’s having an effect than thinking about the system. So it’s like, if you know, if you can see that your programmers are doing more work under the Scrum system than not under the Scrum system and that was a win. And maybe Scrum still sucks compared to the other stuff that you could be doing. But until you go try those other things, you wouldn’t know. So you might as well start to use it if that’s what helps you. So I don’t tend to criticize those 2 things much but I do laugh at people who overstate the value. They’re like, “Oh, my God. We’re working so efficiently.” It’s like, “No, you ain’t working efficiently for shit. You apparently don’t see these massive gaps in where you could be.” So if you want to say Scrum gave us a little tiny boost, I might be with you on that one. But don’t try to tell me that you’re getting up to close to how you should be working ‘cos you ain’t.
Jeff:
Alright, we’ve gone… This is another long one, huh?
Casey:
We only do epic podcasts here.
Jeff:
What are we looking at? Can you see it?
Casey:
22…
Jeff:
Oh alright, that’s not too bad.
Casey:
So thank you very much, Anders for writing in with that topic. If you have a topic out there, if you are a person right now Scrum-ing away at your desk and you have a topic…
Jeff:
Then you send it to Podcast…
Casey:
That you would like an hour and a half of discussion on that does not yield anything fruitful or answer your question, you know where to send it — Podcast@JeffAndCaseyShow.com. We will receive it and we will read it and then we will do something ridiculous like this with it on the air.
Jeff:
And join us next week as we talk about McGruff the Crime Dog.
Casey:
Yeah, we didn’t get to McGruff the Crime Dog.
Jeff:
We’ll get back to him but join us next week. And thanks, everybody.
Casey:
To help us take a bite out of crime.
Site design and technology © Copyright 2005-2014 by Molly Rocket, Inc., All Rights Reserved.
Contents are assumed to be copyright by their individual authors.
Do not duplicate without their express permission.
casey muratori
the jeff and casey show - season 4 - episode 8
prev
next
mollyrocket.com