The good ol' days of programming.
-
From the CP newsletter Somewhere along the way we forgot about software craftsmanship[^] Summary of complaining about now how programming is somehow different and worse than at some undefined point in the past. "Unfortunately, "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainability of the codebase." I used to read studies all the time targeting process control. So one or more studies that I saw before the year 2000. First a study that demonstrated that 'code reuse' which everyone thought was the thing to do wasn't actually used (you know in actual code) unless there was real measured processes put into place. So when developers got paid directly for code reuse or when their annual reviews (tied to raises) measured that then developers used it. Then it was used. Otherwise it wasn't. Second a study (or several) showed that formal processes were not followed unless a senior level executive, often 'C' level, required that it be measured and enforced. Again tied to annual reviews. "you're likely to be in an Agile™ environment in which you get overloaded with tasks." That of course must be a joke. Start date of Agile was 2001. The book from Edward Yourdon called "Death March" with a copyright date of 1997 addressed that specific issue. An entire book on it. "Regardless, we're hardly ever shipping out a physical CD where we have to be damn well sure the software works. We can afford to "move fast and break things."" Not sure what that is actually complaining about. There are a lot of systems right now where that is not acceptable. Same is true in the past as well. There are processes that one can implement to mitigate problems. Very difficult processes to set up and maintain. And suitable only to enterprises with very large infrastructure laydowns. (I agree with the O'Reilly book "Building Microservices" that states that a start up with a new paradigm is going to create nothing but maintenance problems down the road if they start up by immediately attempting microservices.) "I feel like it's been forever since I had a conversation about craftsmanship on the job." Sounds like a good thing. The discussions like that I have see
I'm glad I waited to respond, because @sanderrossel covered everything I had on my mind, probably better than I could have. I owned a copy of "Death March" back when I was dealing with those things on a regular basis - (I was doing "project rescue - being hired out to get projects back on track about 6 months after they should have done something about the morale in the place). It was soul crushing work, and a big part of the reason I left the field for a time. I confess that aside from skimming here and there I didn't really read it. It was given to me, but it struck me as depressing and I didn't need more of that in my day job.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Things were better in the past. The Clipper age was the golden age of programming, according to my father. VB6 was the pinnacle of programming according to a slightly younger coworker and friend of his (who retired last year). I've seen their VB.NET code and I'm pretty sure they sucked at Clipper and VB6 as well. I started out on WinForms and VB.NET with .NET 3.5 and soon migrated to .NET 4.0. So obviously, there hasn't been a better tool than that! (Seriously though, designing a simple WinForms app was so much easier than web with the simple drag and drop interface.) My point, old folks are going to bitch about the present and reminiscence about the past. Apparently, because our brains are wired to forget the bad stuff and elevate the good stuff. Of course it's better now, we can do everything we could and a lot more at that. Problems were fixed, new problems arose, which were also fixed, which caused new problems, which we are fixing now. That is simply the way of things. But people forget the problems of the past and only see the problems now. Or just aren't as familiar with current technology, making it seem daunting and/or unnecessary. And perhaps because we have so many options now, we also have many problems and challenges. And with that said, cheers to the good old days! :beer:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
The Clipper age
The age of [SAIL](https://en.wikipedia.org/wiki/SAIL\_(programming\_language))? :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I'm glad I waited to respond, because @sanderrossel covered everything I had on my mind, probably better than I could have. I owned a copy of "Death March" back when I was dealing with those things on a regular basis - (I was doing "project rescue - being hired out to get projects back on track about 6 months after they should have done something about the morale in the place). It was soul crushing work, and a big part of the reason I left the field for a time. I confess that aside from skimming here and there I didn't really read it. It was given to me, but it struck me as depressing and I didn't need more of that in my day job.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I'm currently dealing with Microsoft support. It's taking three weeks to reset a password, which now can't be done, so we're going at it another way needing a signed letter, my driver's license and whatnot... Could use some morale and rescue :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sander Rossel wrote:
The Clipper age
The age of [SAIL](https://en.wikipedia.org/wiki/SAIL\_(programming\_language))? :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
To be fair, it's all been downhill since Plankalkül[^] :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I'm currently dealing with Microsoft support. It's taking three weeks to reset a password, which now can't be done, so we're going at it another way needing a signed letter, my driver's license and whatnot... Could use some morale and rescue :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Oh let me tell you what my job really was, from the perspective of the people hiring me: "Well, we screwed up now. The senior half the development team quit, the project is over budget, and we've got a board meeting to prepare for. What now?" "I know an outfit we can hire. They'll fix this, and when they can't, we can just blame them and the developers" "Cool. Now who gets to fire the rest of the dev team?" "That's the best part - they'll do it. Let me give these guys a call" And then I'd be flown in.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Oh let me tell you what my job really was, from the perspective of the people hiring me: "Well, we screwed up now. The senior half the development team quit, the project is over budget, and we've got a board meeting to prepare for. What now?" "I know an outfit we can hire. They'll fix this, and when they can't, we can just blame them and the developers" "Cool. Now who gets to fire the rest of the dev team?" "That's the best part - they'll do it. Let me give these guys a call" And then I'd be flown in.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
"Cool. Now who gets to fire the rest of the dev team?" "That's the best part - they'll do it. Let me give these guys a call" And then I'd be flown in.
I need you to fly over to the Microsoft support team. NOW! :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Things were better in the past. The Clipper age was the golden age of programming, according to my father. VB6 was the pinnacle of programming according to a slightly younger coworker and friend of his (who retired last year). I've seen their VB.NET code and I'm pretty sure they sucked at Clipper and VB6 as well. I started out on WinForms and VB.NET with .NET 3.5 and soon migrated to .NET 4.0. So obviously, there hasn't been a better tool than that! (Seriously though, designing a simple WinForms app was so much easier than web with the simple drag and drop interface.) My point, old folks are going to bitch about the present and reminiscence about the past. Apparently, because our brains are wired to forget the bad stuff and elevate the good stuff. Of course it's better now, we can do everything we could and a lot more at that. Problems were fixed, new problems arose, which were also fixed, which caused new problems, which we are fixing now. That is simply the way of things. But people forget the problems of the past and only see the problems now. Or just aren't as familiar with current technology, making it seem daunting and/or unnecessary. And perhaps because we have so many options now, we also have many problems and challenges. And with that said, cheers to the good old days! :beer:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sander Rossel wrote:
My point, old folks are going to bitch about the present and reminiscence about the past ... Of course it's better now, we can do everything we could and a lot more at that.
Of course you will be old one day ...
Heck, I already am! I'm always going on about the good old days (and I'm only 36)! :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
From the CP newsletter Somewhere along the way we forgot about software craftsmanship[^] Summary of complaining about now how programming is somehow different and worse than at some undefined point in the past. "Unfortunately, "impact" is almost always measured by what features you shipped rather than considering the impact your code had on the long-term maintainability of the codebase." I used to read studies all the time targeting process control. So one or more studies that I saw before the year 2000. First a study that demonstrated that 'code reuse' which everyone thought was the thing to do wasn't actually used (you know in actual code) unless there was real measured processes put into place. So when developers got paid directly for code reuse or when their annual reviews (tied to raises) measured that then developers used it. Then it was used. Otherwise it wasn't. Second a study (or several) showed that formal processes were not followed unless a senior level executive, often 'C' level, required that it be measured and enforced. Again tied to annual reviews. "you're likely to be in an Agile™ environment in which you get overloaded with tasks." That of course must be a joke. Start date of Agile was 2001. The book from Edward Yourdon called "Death March" with a copyright date of 1997 addressed that specific issue. An entire book on it. "Regardless, we're hardly ever shipping out a physical CD where we have to be damn well sure the software works. We can afford to "move fast and break things."" Not sure what that is actually complaining about. There are a lot of systems right now where that is not acceptable. Same is true in the past as well. There are processes that one can implement to mitigate problems. Very difficult processes to set up and maintain. And suitable only to enterprises with very large infrastructure laydowns. (I agree with the O'Reilly book "Building Microservices" that states that a start up with a new paradigm is going to create nothing but maintenance problems down the road if they start up by immediately attempting microservices.) "I feel like it's been forever since I had a conversation about craftsmanship on the job." Sounds like a good thing. The discussions like that I have see
I miss the good old days of: "copy con" Big move up from the bit switches.:-D That is when coders were real coders, not whiners. We didn't even have CP!
>64 There is never enough time to do it right, but there is enough time to do it over.
-
I miss the good old days of: "copy con" Big move up from the bit switches.:-D That is when coders were real coders, not whiners. We didn't even have CP!
>64 There is never enough time to do it right, but there is enough time to do it over.
