Things Titus Says on Podcasts

…everyone that's currently working has grown up in an era where there was a playbook. Like we know, at least in theory, the right way to do this. And there's no playbook right now, right? So we all have to get a little comfortable of not knowing the answer. And we certainly don't know the answer on what is still the basics. The things that I think that the juniors should be focusing on. One, the resilience to avoid just copying your ticket into an AI prompt and then trying to check in that result. Like if that is all that you are doing, you can be replaced with a very small shell script. Like that is not a defensible advantage for you being on staff. I think it's really important to use AI to better yourself and to widen your inputs, but not to immediately produce all of your outputs. There's a metaphor that I really liked from about a year ago at a think tank. We called it Andrew's Axe. And it's, if I go chop down a tree with an axe, I do not say that it was the axe that chopped down the tree. It's me that chopped down the tree. The AI, as…

Right, exactly. And so I think that this is the insight that tries to bridge the gap between, I have not seen a research-based number that says productivity post-AI is up more than like 20 or 30%. But then everyone talks about like these 10x sort of experiences. I super don't think it's actually 10x, but yeah. But like, how do you bridge that gap? And I think it's exactly this thing of a lot of the value of AI is not in doing the same thing faster. It's doing a harder, more valuable thing that you wouldn't have even thought about. And if your productivity measures are the logical equivalent of counting how many widgets are coming out of the factory, and then you start producing super gold-plated deluxe widgets, there's no way to measure that or track that over time because we just don't have the tracking of what's the value of this component or feature. And that also matches with, you know, talking with senior engineers that are like, yes, we're up 70% on amount of code. We're up 30% on outages. Number of features is the same. The thing that we Can't know for sure is: are the value of those features up? Because what's how do you, how do you do…

Yeah, exactly. And at the undergraduate level, like there is some move towards more oral exams and those sort of things. But also, I think a really simple solution is stop grading just the outcome. Focus on the process. Right. Like even if you don't come up with wildly harder. Assignments for assessment. Stop grading just the code that they turned in. Grade instead, what are the prompts that you used to get here? Also, what are the tests that you provided? Like, how did you make sure that this thing is actually doing what you need it to do? And when you start focusing on the process that got you there instead of just the outcome, I think not only CS, but most disciplines, right? Like, we've been using, go write a new essay on Catcher in the Rye. Like, we don't need another essay on Catcher, right? Go write a new linked list. We don't need another linked list. We've been using the artifact that's produced from that as a proxy for you put in the time and the struggle and like faced the friction that we assume that you now have learned something. It might be more appropriate to just focus on: do we have evidence that you've struggled and learned? Turn in the whole package, right?