51–60 of 94 posts
Maybe I’m just not good enough at paying attention, but for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems. Then you end up being able to mentally simulate what problems you will run into, and design is basically all about avoiding future problems of various kinds (and balancing tradeoffs about which future problems to avoid and how much effort to put in…
Maybe I’m just not good enough at paying attention, but for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems. Then you end up being able to mentally simulate what problems you will run into, and design is basically all about avoiding future problems of various kinds (and balancing tradeoffs about which future problems to avoid and how much effort to put in…
> for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems This shows how immature the field of software engineering is. Imagine bridges or houses were built like that. Or your surgeon was trained like that. Over time, we hopefully develop estblished norms, but at the moment, things are too much in flux. Put 5 sw engineers in a room, pose a problem and you wil…
Bridge building is a lot more conservative when it comes to taking risk in the construction, but that is how we build bridges and lots of bridges collapse because of similar causes:
- Design Deficiencies
- Construction Mistakes
- Maintenance Issues
- etc.
One thing to keep in mind is that what was well-designed 30, 20 or 10 years ago may not be considered such now. Hardware changes and so do the design decisions involving performance.
For example, if you are looking at C++ networking libraries, learning from ACE or even Asio may not be the best idea - better look at "thread per core, share nothing" Seastar[0].
Another thing is that it may be better to read design docs, not the code. For example, the rationale for the mold linker design[1].
[0] https://docs.seastar.io/master/tutorial.html#asynchronous-pr...
Maybe I’m just not good enough at paying attention, but for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems. Then you end up being able to mentally simulate what problems you will run into, and design is basically all about avoiding future problems of various kinds (and balancing tradeoffs about which future problems to avoid and how much effort to put in…
> for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems This shows how immature the field of software engineering is. Imagine bridges or houses were built like that. Or your surgeon was trained like that. Over time, we hopefully develop estblished norms, but at the moment, things are too much in flux. Put 5 sw engineers in a room, pose a problem and you wil…
If they could afford experimenting and have a few bridges collapse before they get it right with no significant negative consequences IMHO it wouldn’t be the worst way to learn.
Maybe even more so for surgeons, being able to experiment and fail in a risk free environment seems like a good thing.
My suggestion is to search for open-source codebases in your favorite languages, study them, and start practicing them.
I'm definitely going to do that. I asked because I wanted to start off with some that I'd knew would be well designed. However, it would probably be more interesting to see a wide variety of quality than just the good ones. Or maybe open source projects are all usually well designed. I haven't looked at many in depth. The only one I've really looked into was Clang to try to figure out why clang format ignored my styl…
Yes, all open-source projects are well designed with documentation and to-dos, otherwise open-source contribution becomes difficult.
Earlier quoted context omitted.
> for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems This shows how immature the field of software engineering is. Imagine bridges or houses were built like that. Or your surgeon was trained like that. Over time, we hopefully develop estblished norms, but at the moment, things are too much in flux. Put 5 sw engineers in a room, pose a problem and you wil…
> Imagine bridges or houses were built like that. Or your surgeon was trained like that. While I don't disagree with you in general, this does feel a bit off. By that logic you can call the field of music immature, and all of the arts. I think the difference is that its easy to experiment without high costs. I genuinely think that if building bridges was cheap and quick, the fastest way to learn was to try...
* "well designed": What was the objectives and ideas...
* "codebases": How well that was implemented
They are a lot of lofty claims saying how this or that is "fast, secure, etc" but don't end like that in the actual implementation.
But most of the time, that could be seen in the "design claims" already! Good design is not just full of adjectives and nice sounding goals, but the concrete considerations, what was the trade-offs, false-starts, and reasons behind the decisions.
You can see some examples reading about the design of Erlang, early pascal, most RDBMS, etc.
So, you first mid/long term goal is to learn to distinguish what good design actual look like.
then, in relation with codebases then to be kinda easier: It actually follow the design?
A good example is the 'std' library of Rust. It has a lot of lofty claims about security and such things that could sound alarms, but then you dive in the code of it and see is there A LOT of care about it, and a lot of docs comments discussing this stuff and then the code match.
P.D: The "std" or equivalent of the lang is one of the most important codebases you need to learn and study, and the MAJOR way to judge how truly good is it.
Earlier quoted context omitted.
> Imagine bridges or houses were built like that. Or your surgeon was trained like that. While I don't disagree with you in general, this does feel a bit off. By that logic you can call the field of music immature, and all of the arts. I think the difference is that its easy to experiment without high costs. I genuinely think that if building bridges was cheap and quick, the fastest way to learn was to try...
I generally agree with your point on ease of experimentation, but if we insist on calling it software engineering , then maybe the field needs to adhere to engineering principles, as the GP highlighted.
I think the field could get better at knowing when costs are low (eg sometimes scalability, cheaper to change a database choice than rebuild a bridge) and where the costs are sometimes very high (eg security).