[HN Gopher] Collecting and curating material is good and we shou...
___________________________________________________________________
Collecting and curating material is good and we should do it more
Author : sdht0
Score : 101 points
Date : 2023-09-23 12:34 UTC (10 hours ago)
(HTM) web link (buttondown.email)
(TXT) w3m dump (buttondown.email)
| jl6 wrote:
| > That's a whole book on manufacturing snap fits! I said that
| there's nothing like that in software: we talk about specific
| tools, but never about specific domains. What if we had a book on
| how to do versioning, or how to make a good plugin system! That'd
| go a long way to improving the state of our field.
|
| I suspect one key difference between software engineering and
| physical engineering is that with software, you hit "it depends"
| sooner. The way you design and build a software system is
| extremely sensitive to the precise details of the problem you are
| trying to solve. There aren't a lot of domains where there is One
| True Way to do something. The job of the software engineer is
| perhaps less about building the perfect "snap fit" (although it
| is at least _a bit_ about that), and more about selecting from
| the vast array of "snap fits" that exist, and matching them to
| the specific problem.
| zaphar wrote:
| I'm not sure thats true for most of the development people work
| on. Most line of business apps are pretty much the same for the
| most part. The specific domain may differ a bit but the domain
| doesn't seem to impact the design of the system that much in
| practice. It's only when you find yourself working at a Google,
| Facebook, or Netflix that you really start hitting it depends
| style questions.
| dexwiz wrote:
| I think that is exactly what physical engineering largely
| consists of, selecting the correct material, process, or part.
| The reason they don't print these for software is because the
| numbers changes too fast. The physical properties of steel are
| relatively constant. Sure, you can invent new types, but 1080
| steel has about the same properties as when it was invented.
|
| Software numbers change too quick. The amount of CPUs in a
| system, the network speed, storage, etc. Why write guides on
| what tech to choose when the numbers changes so fast?
|
| I think it's also a sign of our professions immaturity that we
| don't write more books like that. We don't even have good
| dimensions defined on which to compare approaches.
| generalizations wrote:
| > The job of the software engineer is perhaps less about
| building the perfect "snap fit" (although it is at least a bit
| about that), and more about selecting from the vast array of
| "snap fits" that exist, and matching them to the specific
| problem.
|
| Except, that's exactly what a whole book on manufacturing snap
| fits is about. Physical engineering is nothing but tradeoffs
| and 'it-depends' and that's why you end up with reference
| manuals on things like snap fits, where the point is twofold:
| an encyclopedia of the range of possible snap fits and how they
| can each be used; and some theory to help figure out the
| appropriate tradeoff.
| Scarblac wrote:
| But isn't that exactly why a whole book on a small subject
| would make sense? It would be able to show that whole vast
| array of options, and when to use one over the other.
| jamestimmins wrote:
| I've thought about this a lot.
|
| I'd love a book on "Web Authentication Systems" that is a survey
| of approaches, real world examples, tradeoffs of different
| frameworks, core principles, etc.
| zaphar wrote:
| I wonder sometimes if this is the cause or effect of the lack of
| consensus in software engineering. There are so many topics about
| which the software engineering community is somewhat split.
| Typechecked or not typechecked, SQL or Nosql, Object Oriented or
| Functional. The pendulum swings between them over time but no
| real established consensus get's established.
|
| Is the lack of consensus why we don't have more curated
| knowledge? Or is the lack of curated knowledge the reason we
| don't have more consensus?
| gdulli wrote:
| It doesn't make sense to me that there should be consensus.
| People have diverse opinions and values, and these topics are
| highly situational and subjective rather than neatly,
| objectively, universally right or wrong.
| swayvil wrote:
| If there is nigh-unanimous agreement. Asserting the same
| narrative, arguing the same arguments.
|
| Well that's suspicious. That's a sign of something.
| fabianholzer wrote:
| I think every major split would still be a topic broad enough
| for a curated body of knowledge.
|
| Unfortunately, I think the author is spot on, with the answer
| to why we don't have such kinds of work available, as he
| writes: "the work is hard and unrewarding".
| iovrthoughtthis wrote:
| imo we've not settled on a meta as the game is relatively new,
| has been changing a lot over the decades, they take a long time
| to play and lots of the learnings are fairly hidden in
| companies.
| billfruit wrote:
| More than that I feel there is hidden/lost knowledge. For
| example real world software design documents are so hard to
| come by, I think they must be one of the closest guarded things
| in software companies. The history of major software
| development projects in the industry has simply been lost to
| us.
| qznc wrote:
| I'm pretty sure the main reasons such documents are not
| public are: Either nobody documented it or the document is
| badly written. So it is just too embarrassing.
| ta8645 wrote:
| > ...the document is badly written. So it is just too
| embarrassing.
|
| At risk of being accused of being on the A.I. hype train,
| it seems like having a writing bot that could distill the
| important points out of poorly written documents, and state
| them more clearly would be a huge boon. Hopefully it would
| allow an iterative process where someone could hone their
| offering to a point where they felt okay releasing it.
| qznc wrote:
| Yes, ChatGPT is good enough to help writing this stuff.
| It is still work though. Work which is not valued much
| and which most engineers like to avoid.
|
| Personally, I like it. For me, there is no better way to
| achieve clarity than writing about something. So I don't
| really understand why they like to avoid it. They
| apparently value clarity less than I do but that doesn't
| explain it. "Everybody is different" doesn't really
| explain anything.
| layer8 wrote:
| For software documentation, "badly written" often means
| that it's ambiguous, is missing information, and/or is
| contradictory. AI can't really help with that.
| ta8645 wrote:
| I would think that a good AI could actually point out
| missing and ambiguous information and allow an iterative
| process where a programmer could more easily fill in the
| blanks before resubmitting it for another round.
| jdougan wrote:
| An excellent idea. We could work out a standardized format and
| build wikis around them. We should come up with a name too. I
| think "patterns" would be good.
| nuancebydefault wrote:
| I find there's already too much written about 'good software',
| 'best practices', 'design patterns', 'refactoring' etc. These
| books/articles almost try to force sw engineering into an harness
| as if it was the military.
|
| A lot of sw practices and solutions are in the area of 'it
| depends'. That is where good (system!) domain knowledge,
| cooperation and argumentation comes into play.
|
| More often than not, discussions are stalled because of ego,
| stubbernness, 'i know better', 'the standard practice says...'
| etc.
|
| What's needed to arrive at good sw is good collaboration. 'I
| understood we need to implement this or that because the customer
| needs..., do you agree?' and 'the current system works like this
| so i would propose... what do you think?'
|
| For some reason, it is hard to have such fruitful fully
| interactive, open and iterative discussions, which is a pity.
| [deleted]
| ricklamers wrote:
| Great analysis on the value of collecting and curating knowledge,
| even without synthesizing it into "best practices." As an AI
| engineer I collect a lot of resources here, hoping it helps
| someone https://codingwithintelligence.com/
___________________________________________________________________
(page generated 2023-09-23 23:00 UTC)