> ## Content Index > Fetch the complete content index at: https://www.petercai.com/llms.txt > Use this file to discover other available public pages before exploring further. # Watch your replays to level up your programming - URL: https://www.petercai.com/watch-your-replays-to-level-up-your-programming/ - Published: 2022-08-06T12:00:00.000Z - Updated: 2022-08-06T12:00:00.000Z - Description: Improve your programming skills by reviewing your own coding, not just your own code. - Author: Peter Cai - Tags: #Import 2026-08-11 22:26 In video gaming, its standard advice to record your gameplay and review your own games to spot mistakes and areas for improvement. Reviewing recorded games is extremely important to improving because: - You can spot game-losing tactical mistakes, and practice the specific sub skills that you need to avoid those mistakes. This might be a mechanical mis-play, or a lack of coordination or awareness about where teammates are / what they were trying to accomplish, and so on. - With the aid of in-game statistics, you can see where you were wasting your time doing things that weren't effective, but that you didn't know weren't effective. - You can identify game knowledge gaps and remind yourself what you need to study - e.g., "oh I didn't know my opponent could do that at 3:45," or "I didn't know it could hit me from that distance." - In most games it's extremely common for all but the highest level players to not realize when they've lost, and to end up blaming some other event happening near the end, long after the outcome was inevitable. A replay with complete information can help you understand what your opponent was doing that you couldn't see at the time, creating a more complete strategic picture of what led to a loss or victory. Competitive gaming modeled itself after professional sports, where experience teaches us "coaching" and "reviewing your own performance" make a big difference. Not everyone can afford a coach, but self-review is free (even if not as good), so there's no excuse not to self-review. And yet "watch your own replays" is *still* common advice to people asking for tips to improve, because lots of people don't do it. If you don't do reviews of any kind - either on your own or with the help of a coach - then you just aren't that serious about improving at your game. Which is OK! But still, many people clearly want to get better...but default to grinding more games, or watching more Twitch.tv, instead of reviewing their replays. What I'm getting at is this: I think we're overlooking "reviewing performance replays" as a way for software engineers to improve. I've basically never heard this suggested in programming, even though there isn't any reason why it wouldn't work. Maybe this is based on the (completely unconvincing) arguments about how software engineering is so different from every other human endeavor that there is nothing to learn from other fields. Try it: record yourself programming for say, 2-3 hours, and then watch your own replay on fast forward. Where are you making mistakes? What are you wasting time on? How could you be more efficient? You might find that: - Your typing speed or lack of familiarity with hotkeys is making you 50% slower than you can think. - You're laboriously doing things that an IDE can automatically do for you. - You repeatedly sidestep the same small problems over and over again, instead of fixing them once, permanently. - You're writing too much code before testing that the code is working, leading to wasted time at the end trying to chase down the source of each bug. - You don't know how to use a debugger and are spending most of your time spraying debug statements everywhere. - You don't understand the organization of the codebase *and* how your IDE works, so you spend most of your time searching for things inefficiently. - You don't know how to use the official documentation for your libraries, so you're just constantly reading terrible StackOverflow answers. - You're not reading (or misreading) error messages that tell you what your exact problem is, leading you on unnecessary half-hour goose chases. - You have a bad window arrangement wasting most of your screen real estate, and you can only see a few lines of code at a time. - You're repeatedly confusing yourself about what some code does, by mixing up similarly named variables or methods. - You are constantly trying to guess-and-check your way out of problems instead of approaching it systematically with logging and a debugger. - You frequently lose track of the tab or window that you want to switch to, and have to spend time looking for it, interrupting your flow...instead of using a system that relies more on visual cues and your muscle memory. - You get distracted and go off reading reddit for 20 minutes whenever there's a 2-3 minute wait in your workflow. I've done (and noticed in others) all of these issues here! Catching and fixing mechanical mistakes like this *easily* explains "10X programmer" differences in productivity. But as an industry almost nobody focuses on any of this, *ever*, except maybe, briefly, once, during employee onboarding at a "let me show you how our internal tools work" session. And then they get punted to The Wiki. What about code review? Isn't that part of how we coach programmers to be better? Sure, but that's critiquing the output, not the actual process of the coding. And it's hard to improve the output without drilling down into the process. I think this is a failure, because my experience is that SO MUCH of a programmer's productivity comes from mastering skills, tools, and workflows...not just memorizing a bunch of syntax, APIs, and even design patterns. I suspect this is part of the appeal of pair programming - pairing lets us learn skills and shadow-coach each other in a profession that essentially never does otherwise. There are so many things that I can correct and improve on the spot if I'm pairing with a more junior developer. So in that sense it's actually more like a coaching session than a "pairing" session. But this is suboptimal, because when we are "pair programming" we are usually trying to accomplish a specific task, and "hey let me teach you to (open and save files with hotkeys |use a debugger)" feels like a sidetrack. It's almost better if we focus on coaching the "mechanics" of programming separately. On the other hand, lots of people dislike pair programming because 1) yeah it's kind of wasteful, 2) some people just don't like the pressure of coding live in front of an audience, and 3) live coding with another person can be kind of frustrating if you're not operating at the same speed \[1\], or the person at the keyboard has mechanics limiting the productivity of both engineers. The solution to all of this is to do coaching and skill transfer with replays: that way we have the ability to fast-forward and skip uninteresting parts, and no performance anxiety. Software engineering as we know it is only roughly 50-60 years old at this point - still in its infancy. Future generations will regard us as basically cavemen, programming with primitive tools and espousing superstitions like "typing speed doesn't matter:" ![Reddit, where typing speed doesn't matter for programming, apparently.](https://www.petercai.com/assets/images/typing-speed.png) In the future, I think replays and live coaching will be a key way to train software engineers. We'll look back and wonder why we didn't do it sooner. Well, whenever we start trying to train software engineers. \[1\] In my experience, true pairing works best when both programmers have roughly equal experience and familiarity with the codebase relative to the problem at hand, so they can both contribute and review the work as it's being done live. When there's a big skill imbalance it feels more like a coaching session, but if you ignore this phenomenon and try to "pair" anyway, it can get frustrating for both parties - nobody enjoys "programming at 20% speed but also no multitasking," and nobody enjoys being told what to type without understanding what is going on.