A lot of this resonates with me. I don't work near especially large cities. So most of the apps I wrote were for smaller businesses who tend to make investments in app dev last a very long time. Last I heard, my very first professional PHP/MySQL app is still in use. Although I haven't touched that particular code in over a decade, I still have to maintain code I wrote in my formative years as a programmer. Code that makes me shudder. Code that led me to get interested in app and system architecture, because what I wrote was nearly always hard to maintain. I didn't feel I could stay a programmer if I continued to add more unmaintainable code, which I would subsequently fight again and again. Sticking around to reap the whirlwind has definitely affected how I go about development.
It also makes me cynical of the promises of new tech. Most new techs are just rehashes of the old tech with a slightly different emphasis and more conveniences. This shifts trade-offs but doesn't significantly improve maintainability in the long term. This was brought to mind recently by the post How components won the "framework wars".
That doesn't mean I have figured out the One True Stack, of course. These are just observations that tools and techs are not to be trusted as the answer to maintainability. People who think it through are, and especially when they have lived it before. Of course, I didn't have any such person available to teach me, so I did what research I could but learned a lot of it the hard way.
This reminds me of a code base. I used to work on an API that is widely used in my company. It's quite old, maybe 15-20 years old.
Once I had to look into a quite hairy part of it and I found it awful. Variables named ps and qs all over the place in lengthy functions.
I also found some copyright notes mentioning a guy who I already knew in the company but I had no idea that he had done development before. I had my own opinion that I obviously didn't share.
A bit later I read a relatively old book about C++ compilers. And while I was reading it, I realised that this guy didn't do anything bad. When he wrote the code, the length of variable names and the number of (virtual) function calls did matter.
The point is that if we read some old code and we find it unreadable, we shouldn't judge. Maybe that time it was the state-of-the-art, just times changed.
By the way that was far from being the oldest code... We decommissioned code coming from 70s just last year... Huge fun :D
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A lot of this resonates with me. I don't work near especially large cities. So most of the apps I wrote were for smaller businesses who tend to make investments in app dev last a very long time. Last I heard, my very first professional PHP/MySQL app is still in use. Although I haven't touched that particular code in over a decade, I still have to maintain code I wrote in my formative years as a programmer. Code that makes me shudder. Code that led me to get interested in app and system architecture, because what I wrote was nearly always hard to maintain. I didn't feel I could stay a programmer if I continued to add more unmaintainable code, which I would subsequently fight again and again. Sticking around to reap the whirlwind has definitely affected how I go about development.
It also makes me cynical of the promises of new tech. Most new techs are just rehashes of the old tech with a slightly different emphasis and more conveniences. This shifts trade-offs but doesn't significantly improve maintainability in the long term. This was brought to mind recently by the post How components won the "framework wars".
That doesn't mean I have figured out the One True Stack, of course. These are just observations that tools and techs are not to be trusted as the answer to maintainability. People who think it through are, and especially when they have lived it before. Of course, I didn't have any such person available to teach me, so I did what research I could but learned a lot of it the hard way.
This reminds me of a code base. I used to work on an API that is widely used in my company. It's quite old, maybe 15-20 years old.
Once I had to look into a quite hairy part of it and I found it awful. Variables named
ps andqs all over the place in lengthy functions.I also found some copyright notes mentioning a guy who I already knew in the company but I had no idea that he had done development before. I had my own opinion that I obviously didn't share.
A bit later I read a relatively old book about C++ compilers. And while I was reading it, I realised that this guy didn't do anything bad. When he wrote the code, the length of variable names and the number of (virtual) function calls did matter.
The point is that if we read some old code and we find it unreadable, we shouldn't judge. Maybe that time it was the state-of-the-art, just times changed.
By the way that was far from being the oldest code... We decommissioned code coming from 70s just last year... Huge fun :D