I follow Eric Raymond's blog via RSS - Armed and Dangerous. He has a lot of extremely good information for programmers. He is always worth reading. One of his recent posts was about Defect Attractors.
Here at work, stupid ideas often surface. When they do, I get tingles. "Avoid this", I say. "Why?" they ask. "I can't say right now, but I know it's a bad idea." and that's as good as I can tell them on first glance. It takes a while for my memory to throw up why things are bad ideas. I recognise them as bad because of past experiences. It takes time to remember and explain why. But some things will always be bad. They attract defects. They make it easy to build in problems.
I'm in my final years here. I'm working with two young programmers who are slowly taking over all my old code. I have 2.5 years to have it all handed over to them. When I retire, they will have it all and they will be responsible for it. I will be able to walk away and not be called back in the middle of the night for emergencies. But working with young programmers can be frustrating. They have great ideas that are clearly Defect Attractors, and I can't immediately explain why they are bad ideas. They regard me as an old programmer, fearful of new technology.
At this point, I give them advice which they ignore and laugh about as soon as I leave the room. I let them. They are not interested in learning from an old programmer, who they regard as a too-safe, fearful, old ninny. Fine. Clearly, they will only learn from personal pain, just like I did. When I was learning, I was self-taught. I had very little access to other programmers, books, magazines, in the late 1960s and early 1970s in North Queensland. So I made all the common mistakes, over and over, and I learnt from my pain. But once I got access to books and magazines and had access to good programmers, I read and improved and studied and learned. I still do. I don't see that in the younguns working with me. They are static. They learned a bunch of stuff in college, and believe they have knowledge and experience enough to last their entire careers. Oh well. If they will only learn from personal pain, fine by me. And they mostly see their careers as lasting about 8 to 10 years before they retire or move into management. They hate the idea that they could still be programmers in their sixties and seventies, like some of us here. Personally, I don't think of them as programmers. They are, what? Bean-counters, number jugglers, static constants? Come in for the money, learn nothing new, find the money is not there for newbies, jump into management at first opportunity. That's not being a programmer. Ten years ago, I would have said it was being a programmer, but not being a hacker, but the media has sure fucked up the meaning of the word 'hacker'.
After I retire from here, I have a bunch of projects I am going to continue with. I will continue to program for myself, I will continue to learn, I will continue to get better, and I will have more fun. My current plan is to move into Rust. Eric Raymond says it good enough to replace C. I like C, but Python makes things very easy. Raymond has a three-part series - The long goodbye to C, The big break in computer languages, and Language engineering for great justice. I want to get into Rust and rewrite my home apps. And I have a whole bunch of Perl I use for my workflows at home, and I will rewrite them in Python. I am going to have a lot of fun in retirement. And I am not going to care if the younguns make a lot of mistakes at work, that's going to be a cause for snide laughter.