4 ms·
Tbf, it only really makes sense for the individual programmer to properly document code if there’s a decent chance they’ll forget (eg some obscure part of the c
by setr 8y ago
Tbf, it only really makes sense for the individual programmer to properly document code if there’s a decent chance they’ll forget (eg some obscure part of the codebase), or if you expect a reasonable chance that someone will have to read the code without you. Otherwise, its useful, but not necessary: you just go to the guru (perhaps yourself); his living body is the documentation.
If you’re thinking that only you’ll ever read it, or you’ll be working on this codebase for the next 30 years, it doesn’t really matter. Peoper Documentation is a cultural activity required for teams, especially those with shifting workers, as is common now. And should really be enforced by the managers, not the programmers thenselves.
Its significantly less necessary when you can expect to spend most of your career on a single codebase, a workstyle these cobol programmers presumably came from.
- TomMarius 8y agoWhat happens when a bus hits the guru?
- zoggenhoff 8y agoGuru meditation error.
- sekh60 8y agoYour DR planning better include a necromancer.
- llcoolv 8y agoyeah. this is how it had been done before the invention of writing. time has proven it not to be a very efficient method.
- tcbawo 8y agoI try to design and name interfaces clearly and comment code for myself. If it's been a few weeks since I've looked at something it helps me snap back. Also, I would never approach a codebase as if I will be working on it for 30 years. Job security comes from marketability, not obscurity.
- lovich 8y agoWas that true when these systems were first made? Many of them are decades old, and the culture of large institutions is usually resistant to change, and that comes from management on down. If the system didn't start with those values in mind, what would have prompted them to change?
- tcbawo 8y agoIt's not that I don't expect the codebase to age or design it with long-term thinking, I just don't expect to be working on it for that long. Someone will replace me, and I'd like to leave them with well-designed, readable code that they will be able to understand.
- lovich 8y agoI'm talking about that as well. The modern era of jumping ship every 2-3 years on average in software is not how its always been. Jobs used to be very long term
- tcbawo 8y agoIt's not always about jumping ship either. In many companies, you will move between areas/needs or get promoted to other work after a couple years. Also, companies will outsource maintenance to lower-cost teams. It seems there is better project lifecycle management, less waterfall development, and fewer cushy open-ended government contracts. But, you're right. The expectation that you'll be able to do the same thing indefinitely for you career is gone.
- magduf 8y agoThis is a terrible way to maintain a system. You never know when the guru is going to die or quit; you have to have a way of getting other people to maintain the system. This is why humans invented written language: to transmit information to each other and to subsequent generations. However, writing useful documentation isn't trivial, and is best done with a technical writer, and takes time away from development. If management isn't willing to invest the time and resources necessary to produce useful documentation, then they're going to have problems in the future as the gurus leave.