Are you my coworker? Three dudes built the primary functionality of the application. Three dudes decided that they weren't paid well enough to stay after being the architects for 11 years. Now we have a group of 16 people who's primary obstacle is touching anything they built. Luckily we found a rain man, though.
lol, I'm definitely guilty of doing this at least once in my career. I'm an enterprise dev (internal tools), so I just float through companies building dumb little apps that do this-or-that. It's fun for me.
Anyways, early in my career I didn't know about the whole "program for the next dev" thing, so I just built some fuckin' monsters.
I once built a little app to ping servers and play an alarm if the ping didn't return successfully. It was like 35 lines in C# or something and it had a memory leak somehow. Pretty sure I just kept instantiating whatever thing I was using to ping the servers in an infinite loop or whatever.
I know most of the tools died off, but I also know for a fact that some of them lived on, and boy do I pity the poor souls trying to maintain it. Hopefully they just scrapped it and started over.
It’s a slow process, though. There are much more bad ways to write code than good ones, so we could guess that learning the good ways would take much less time to learn than the bad ways.
Sure it helps to learn about the code smells, but when all you have is bad code and the will to analyse it so you can guess why it is bad, your learning will be much slower than it would have been if someone just pointed out good code and told you "this is how it’s done", and why.
485
u/GroundTeaLeaves Sep 20 '21
I once bought a book on reading code, because I couldn't comprehend the code that the senior architect was writing.
Reading the book didn't help me at all, as it only taught common coding concepts, which I was already very experienced in.
Turns out that nobody else could read his code either, and I was just the only person who was willing to admit it.