I worked at a place where the main programmer had been there 20+ years. To this day, they are still using a language which was popular in the 90's, but you rarely see today.
The day I interviewed, he said "I know I'm not the best programmer but I believe that after enough hours on the project you will end up with something that works", and he bragged about many nights sleeping in the office on a cot he had under his desk, keeping systems running and debugging live programs.
It was some of the ugliest code I had ever seen in my life. Every couple years, they'd hire an actual programmer, but he refused to change his methods, and the programmers would eventually find another job out of frustration. It was very easy to see which code was done by the other programmers, it just made so much more sense than his code, it was documented, etc etc.
I definitely agree that his approach to code quality is bad and he should improve.
On the other hand, he still seems to be delivering value to the business by making things work, regardless of how awful the code is, and I feel like this is still an improvement over the other extreme which is chasing hype and buzzwords while delivering near-zero actual business value.
Sounds similar. So many of the hours he logged were because of trying to shoehorn features into the ratsnest of code. If he had rearchitected chunks of the code into something more logical, then it would've saved time overall.
I don't think he understands the purpose of architecture is to make future development easier, and instead thinks that if you make all variables global to be changed anywhere at any time, then that makes it easier and faster
The day I interviewed, he said "I know I'm not the best programmer but I believe that after enough hours on the project you will end up with something that works", and he bragged about many nights sleeping in the office on a cot he had under his desk, keeping systems running and debugging live programs.
It was some of the ugliest code I had ever seen in my life. Every couple years, they'd hire an actual programmer, but he refused to change his methods, and the programmers would eventually find another job out of frustration. It was very easy to see which code was done by the other programmers, it just made so much more sense than his code, it was documented, etc etc.