another reason I like doing work stuff on a vm: touching node/npm feels less gross when it is in a vm. and I don't ever need to install it on my laptop

Yeah, I run it only with podman, which I started using quite some time ago after you mentioned it. The only NPM command that runs directly on my machine just because it's way more convenient is run. But arguably I should be using something akin to a Makefile for that.

Does npm ci work?

Now it does, after I ran two npm i locally and pushed the changes. Before, it complained that package.json and package-lock.json are not in sync, even though the latter was just created with a single npm i. The second npm i rewritten package-lock.json again.

Huh, that's odd.

Not that odd if you consider that it's NPM. :) That's why I wrote "it just never ends".

For context: I'm thinking about just doing the design phase for my next side project, no implementation.

I've been looking into this a tad. I think it is used a lot a nubank https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)

My go-to book about the topic is John Ousterhout's "A Philosophy of Software Design". The important idea is to reduce the amount of information you need to keep in your head at any time in order to correctly develop the software.

be outcome focused, making trade-offs that reflect your priorities, and be human-focused until you can't be (optimize for the work to be done afterwards). be careful about invisible risks (things you only care about when they go wrong but you can't see if they go right).

also be conscious of the never-quite-enoughs: there will be many solutions where no single need will be enough to justify a new approach but many past needs and likely future needs will justify it if taken as a whole. also be conscious that which architectures make sense changes with company and system size, small groups can do things that don't scale while they figure out what users actually want and then build out more scalable architectures later

I have read about so many architectures but it feels like a lot of this stuff gets lost in the shuffle.

my philosophy

@U02N27RK69K good stuff, have you written about this? I'd be curious to learn more

Some of the people I've learned design from: Stu Halloway, Rich Hickey, Dave Farley, Geepaw Hill, Kent Beck, John Ousterhout, James Shore, Michael Feathers, Gerald Sussman, Hal Abelson

There is of course the Rich Hickey talk on the topic. Surprised it wasn’t the top comment 😂 https://youtu.be/c5QF2HjHLSE?si=MB1ARDJYStha3vfE

In the RH talk Simple Made Easy, there is a bit about asking what the who, what, when, why and how aspects are of things. It makes sense imho (without having tried it). Generally I find it pretty hard to come up with any software design principles that are universal, i.e. categorically apply in all scenarios. Like, name a principle that is true without qualification and truly matters in all of the following: when 1. developing a 10 line bash-script you're gonna throw away after its onetime usage by you, 2. implementing a change to an 18 year old 25k-line swing-gui codebase which also happens to be marked for phase-out in 12 months, 3. implementing your 21st microservice in a quickly growing startup that is needed now to deal with extra load (or whatever), 4. making a change to the space-shuttle codebase that's needed for the next launch. Different priorities and tradeoffs apply to each because most goals, aspects and general principles will contradict each other and someone has to make a decision and it better be the right one. E.g. it's easy to imagine that principles for creating code that is well suited to unit testing (as in TDD) directly contradict principles for creating REPL-friendly code. There is little point in generalizing imho, because a) it's hard to find generally true principles that are concrete enough to inform action and 2) you will always deal with specifics.

@U06F82LES I haven't written about it, but maybe I should?

@U05N15QDUHX there are principles that apply to all of those circumstances but they're meta principles, they're about deciding how and what to write not so much as particular tacts you might take, they're oriented around humans because we're the common thread to all those circumstances you described.

maybe that will seem banal but it turns out these things really matter and often matter more than more specific principles of software

• Build for the problem you have today, not the problem you think you'll have in 3 years time • Plan to re-architect significant portions every 10x of users • Just use PostgreSQL until you've proven you can't with real data and not developer feelings • StackOverflow proves vertical scaling is fine, actually • The drawbacks of abstraction in application code are hugely underrated • Security is difficult and expensive to "bolt on" later. Learn you some OWASP • As soon as you have more than 1 developer responsible for deployments, consider investing in IaC that is subject to version control • Tarsnap The outcome of the above is 90% of cloud platform services are pointless because you're not an enterprise customer with unlimited $$$, who are forced (via a perverse set of byzantine incentives) into a situation where they need SupaFaaSBaseNetes

@U02N27RK69K Totes, I had thought about extending the examples with such thing; like e.g. you gotta write a bash script but you don't know any bash (or neither you or your customer can test the swing gui because there's no proper environments to do it in etc.) Tangentially (or more meta if you want) software is basically never an end in itself but always a means for reaching some other, human, end (usually with profit as the ultimate goal) and any decision ought to be judged in terms of serving that end.

As a self-taught programmer I frequently find it just as (if not more) useful to look to other domains for knowledge as within software development - here are several such resources that have influenced my thinking on design: • https://www.hup.harvard.edu/books/9780674627512 by Christopher Alexander - A short book with a provocative idea: design is a process intrinsically linked with a problem context, not a prescriptive, defined method. • https://www.cambridge.org/core/books/representing-and-intervening/F6506B708BB5A8B6A5D884BDCF28E7B7https://www.cambridge.org/core/books/representing-and-intervening/F6506B708BB5A8B6A5D884BDCF28E7B7https://www.cambridge.org/core/books/representing-and-intervening/F6506B708BB5A8B6A5D884BDCF28E7B7 by Ian Hacking - Probably the text that informed my understanding of the scientific method more than any other; thinking about problems empirically is an essential aspect of doing design well. • https://www.paulrand.design/writing/books/a-designers-art.html by Paul Rand - a book on visual design that discusses a goal shared by both visual design and software design: how to clearly and faithfully represent the essence of an idea without unnecessary detail and ornamentation. • http://nxhx.org/maximizing/http://nxhx.org/maximizing/http://nxhx.org/maximizing/? by Joe Edelman - a talk that made me extremely skeptical of almost all attempts to claim that some method or tool is superior on the basis of narrowly defined metrics. • https://eric.ed.gov/?id=ED344734 by Howard M. Kanare - many resources and guides on taking notes are purely research-oriented; this is the first note-taking guide I've read that immediately made me more productive in getting actual work done instead of merely recording things for their own sake.

not an endorsement of the speaker in general (he has some "interesting" views) but this talk makes some great and simple points on architecture and (I think) is timeless https://www.youtube.com/watch?v=WpkDN78P884

the way I conceptualize the high-level point of it is to use 4 logical tiers in a app architecture vs the traditional 3 (one to abstract specific database/storage choices). This brings about many many benefits due to decoupling. the talk also contains this great quote: "The web is probably the worst idea that's happened to our industry in the past 40 years" - echoing Alan Kay

The same idea of decoupling the pieces of your system (in response to a similar question) was posted here too: https://clojureverse.org/t/architecture-of-big-applications/9574/30