4 ms·
Yeah, to me there's a natural progression in understanding of system design. When you start out, you just write code and don't think about how things interact
by allenu 6y ago
Yeah, to me there's a natural progression in understanding of system design.
When you start out, you just write code and don't think about how things interact with each other too much.
Then you learn that you're rewriting a lot of code, you overcompensate and start to over-engineer to avoid duplication and often to handle more scenarios than you need. You abstract out possibly too much.
Finally, you get to a phase where you realize a lot of abstractions that you've created aren't actually used and you're writing more "meta code" than you need. In this phase you learn to engineer just enough for what you need at the time and design things to be easily changed in the future. You trust that even if you're system design can't handle everything right now, you've designed options for yourself to expand as needed.
- Nimitz14 6y agoNowadays every CS student reads HN and blogposts like this one so by the time you end up having to work with them they're so indoctrinated into the "must write Enterprise(tm) ready code" mindset trying to teach them to be more relaxed is a real pain.
- deleted 6y ago[deleted]
- dstick 6y agoYup, adopt to the business you’re in. As in, the company. Make suggestions if you think it’s worthwhile but in the end accept that there’s a “that is the way” in any company and you’re getting paid to learn and work with that “way”, and build it out :)
- nickbauman 6y agoTDD helps keep this "abstraction abstraction" thing in check.
- mjcohen 6y agoI prefer TDD. More entertaining.
- adkaplan 6y agothis last phase in your coder evolution reminds me of a very rough translation of the wabi sabi view on manufacturing. "Nothing lasts, nothing is perfect, nothing is finished."