A few years ago, with one of the company's projects prospering, management decided to let one of the developers on said project work on a side project during less busy times in the hopes that this side project could also become something revenue-generating.
The side project would be some sort of simulation engine built in Unity, to run on mobile devices. The developer, Lenny, had been in the industry a bit under a year, but he had been doing decent work, so why not give him a chance? It would also represent a great opportunity for him to pick up some greenfield experience in a new framework, which is something a lot of juniors don't get to do.
Now, while Lenny did not report to me, he often shared anecdotes of challenges he faced and overcame in working on this project, possibly because I tend to be a very approachable person in the workplace that people consult for advice and/or rant to about their latest frustrations. Perhaps he also looked up to me. Either way, one day, he was lamenting how MonoDevelop (which is what ships with Unity) behaves differently from Visual Studio:
"One thing that's really frustrating about MonoDevelop is that the code completion doesn't fill in the parameters the same way that Visual Studio does, so I have to type a lot more. I mean, I have this method that takes 33 parameters..."
"Wait a minute," I objected. "33 parameters? Does your method handle all the possible permutations? Did you ever think, for even a moment, that 'there has to be an easier way,' when you were adding, say, the 20th parameter? Do you have any idea of how much more irritating this is going to become for you as the method grows?"
"But that's not the point," he countered. "Visual Studio does it for me when I'm using Visual Studio! I shouldn't have to do all that typing!"
Figuring that one can lead a junior to water, but cannot make them learn maintainable practices, I'd figure I'd let him learn the hard way. I wouldn't be touching his codebase, so the outcome wasn't really my problem, anyhow. Fast forward a day or two to another conversation:
"Sounds like you're making a lot of progress," I complimented. "What are you using for source control?"
"Oh, that? I've heard about it," he said, sheepishly. "The code's on my computer. Right now, I do a build maybe once a week and throw the ZIP on a share folder on the server."
"You really should put that into some form of source control," I suggested. "The benefits are enormous - your entire project is backed up, you can isolate local code differences down to individual lines, and if you mess up one file, you can download the last good copy of any file from any point in time. I'll show you how to set up SVN, Mercurial, or TFS if you'd like."
"No thanks," he said. "I'm learning a lot right now, and I don't want to try to learn too much too quickly."
Murphy's Law kicked in a few days later. Unity, being the gigantic turd that it is, occasionally corrupts your project files when it crashes for whatever reason. If you don't have your project files backed up, you will then have to go through the tedium of reassembling and reassociating your assets. This lovely feature had now graced Lenny's project. "Ugh, my project file won't open! It's gonna take me a while to get this all set up again!"
At that point, a coworker sitting in the cubicle next to mine, who had been quietly savoring the schadenfreude of the events up to this point, finally spoke up. "You know, Lenny, if you'd like, I can show you how to make a backup of your important files by copying and pasting folders in Windows Explorer."