5 ms·

When I started coding, I just hacked stuff out any which way. This code was hard to extend, because it had no structure. When I arrived at university, I tried

by ekidd 12y ago

When I started coding, I just hacked stuff out any which way. This code was hard to extend, because it had no structure. When I arrived at university, I tried to use all the "appropriate" design patterns and software engineering techniques. This code was hard to extend, because it had 60 separate extension points, all of which were in the wrong place (and none of which had ever been used). When I arrived at my first internship, I killed a project or two though grotesque over-engineering. Today, I'm just happy if the code is simple, readable, and does one thing well, and if it has enough unit tests to prevent bit rot. If I add an extra layer of abstraction, I do it because it makes the code simpler, or because it eliminates duplication.

arethuza 12y ago
"This code was hard to extend, because it had 60 separate extension points, all of which were in the wrong place (and none of which had ever been used)" I've been working with "enterprise" systems for ~20 years and I swear that most of the extension points I've seen in custom-built systems have never been used to extend anything and simply complicate the original system. Of course, a lot of products (particularly EPR and CRM) are extensible - sometimes quite elegantly, sometimes with Lovecraftian horrors, but at least they actually get used.
gedrap 12y ago
Yes, I think that this is a rather typical 'programmer growth curve'. You start with spaghetti code which just works (hopefully), after a while you are taught how to do things 'properly', resist to it a bit and suddenly you have an epiphany - design patterns should be everywhere, etc. After over-engineering some projects, with loads of UML diagrams and stuff, you step back and stick to simplicity. And I believe it's a good curve. You learn why some certain things (like overengineering) doesn't work, hopefully it happens early, and learning from trial and error is much more valuable compared to when someones teaches you how to do things 'properly'.

by ekidd 12y ago

arethuza 12y ago

"This code was hard to extend, because it had 60 separate extension points, all of which were in the wrong place (and none of which had ever been used)" I've been working with "enterprise" systems for ~20 years and I swear that most of the extension points I've seen in custom-built systems have never been used to extend anything and simply complicate the original system. Of course, a lot of products (particularly EPR and CRM) are extensible - sometimes quite elegantly, sometimes with Lovecraftian horrors, but at least they actually get used.

gedrap 12y ago

Yes, I think that this is a rather typical 'programmer growth curve'. You start with spaghetti code which just works (hopefully), after a while you are taught how to do things 'properly', resist to it a bit and suddenly you have an epiphany - design patterns should be everywhere, etc. After over-engineering some projects, with loads of UML diagrams and stuff, you step back and stick to simplicity. And I believe it's a good curve. You learn why some certain things (like overengineering) doesn't work, hopefully it happens early, and learning from trial and error is much more valuable compared to when someones teaches you how to do things 'properly'.