Thanks, I'm 13m in and I haven't found anything I would consider valuable or insightful.
I haven't watched many of these videos but the two that stand out for me as being genuinely helpful is Jonathan Blow's talk about software quality [0-4] and Daniel Sockwell's "Imagining the Ideal Language for Writing Free Software" [5].
From Blow's talk, my takeaways are:
* Large organizations don't necessarily know how to make software and small teams can make quality, large scale projects
* Abstraction is its own form of optimization and should be used sparingly. Stripping away a level of abstraction is sometimes desirable.
* Design should be data centric. That is, focus on how to pass data between different domains of concern. Don't be shy about exposing data and don't hide data. This differs slightly from "API-centric" approaches as the contract is in the data, not in the function call interface.
* Keep inheritance to a maximum of 2-3 levels deep, with a preference of 1 or none. Not all language features should be used. Use language features sparingly, and this is one of them.
* Duplicate code (e.g. "cut-and-paste") for clarity. Dispensing with code-reuse isn't a sin and is sometimes desirable. DRY is fine but sometimes having a common function increases cognitive load to understand what code is doing and often portions of code that look very similar are different in substantial but subtle ways that make de-duplication overly confusing to handle all cases. When reviewing a function, having all code available locally, without having to page out to different areas of the code base to see what a common function is doing, often helps with readability and isn't as detrimental to reliability as people make it out to be.
From Sockwell's talk:
It's a weird premise (how can software be ideal for writing FOSS?) but the point is that many software architectural concerns stem from what economic environment they're being developed in. FOSS tends to be developed by a single or small team. The focus is on "master-craft" tools that allow a single contributor to be more effective at the cost of a high learning curve. Since corporate environments tend to have high turn over rate with software developers, the focus is on stable "commodity" tools and methodologies that can better take advantage of the fungible nature of their software developer labor.
The talk itself isn't focused on large software projects architecture directly, but, from my perspective, it gives some very actionable items for tackling larger projects on an individual or small teams basis:
* Focus on expressibility. That is, choose languages that allow mastery over being "safe/boring/simple". Don't worry about making code readable to the lowest common denominator, make it readable for someone who's at your skill level but is trying to find out what the code does (aka "future you"). Allow "footguns" if you trust you can avoid them. Don't worry about language popularity. Enjoy using a "dialects" if it helps empower you.
* Focus on composability. Composability is a broad term but focusing on data-centric design is one way to make things composable as the design can be made around the data being transported.
For me, the major insight is to understand the context of what software is being developed. A corporate environment will have different concerns, for both the employer and employee, than a small project with one or a few developers.
For example, a corporate environment might favor a language that encourages a type of code structure, testing suite, code review process and idiomatic way of solving problems. This makes labor more fungible but means that increased productivity of any individual developer will be met with resistance if it deviates from corporate convention. It also means employees will be motivated to recommend projects using technology that's perceived to be corporate friendly to make sure they're more marketable.
Small projects (FOSS, say) might focus on niche languages, dialects, idioms or other non-standard conventions that incorporate well with the skills of the primary developer. This means the individual developer is more productive but makes it harder for others to contribute.
Oh wow thanks for writing out that summary of Sockwell's talk. I had a sort of similar line of thought a few years ago which I haven't followed since, but this just brought me back. https://josh8.com/blog/personal_computing.html
I was musing about the point on which technologies one ought to use for writing personal (or FOSS) software vs. corporate software like in the talk, but also whether the ethos we bring to the table between the two should differ -- i.e. 'software as a soap bubble' rather than only allowing yourself to write scalable and maintainable programs that are generalized for re-use. It's as if a whole class of programs which would help us Personally Compute never come into existence because of this mindset. I think the AI vibe coding thingy majingies are not too bad of an antidote to this actually
I haven't watched many of these videos but the two that stand out for me as being genuinely helpful is Jonathan Blow's talk about software quality [0-4] and Daniel Sockwell's "Imagining the Ideal Language for Writing Free Software" [5].
From Blow's talk, my takeaways are:
* Large organizations don't necessarily know how to make software and small teams can make quality, large scale projects
* Abstraction is its own form of optimization and should be used sparingly. Stripping away a level of abstraction is sometimes desirable.
* Design should be data centric. That is, focus on how to pass data between different domains of concern. Don't be shy about exposing data and don't hide data. This differs slightly from "API-centric" approaches as the contract is in the data, not in the function call interface.
* Keep inheritance to a maximum of 2-3 levels deep, with a preference of 1 or none. Not all language features should be used. Use language features sparingly, and this is one of them.
* Duplicate code (e.g. "cut-and-paste") for clarity. Dispensing with code-reuse isn't a sin and is sometimes desirable. DRY is fine but sometimes having a common function increases cognitive load to understand what code is doing and often portions of code that look very similar are different in substantial but subtle ways that make de-duplication overly confusing to handle all cases. When reviewing a function, having all code available locally, without having to page out to different areas of the code base to see what a common function is doing, often helps with readability and isn't as detrimental to reliability as people make it out to be.
From Sockwell's talk:
It's a weird premise (how can software be ideal for writing FOSS?) but the point is that many software architectural concerns stem from what economic environment they're being developed in. FOSS tends to be developed by a single or small team. The focus is on "master-craft" tools that allow a single contributor to be more effective at the cost of a high learning curve. Since corporate environments tend to have high turn over rate with software developers, the focus is on stable "commodity" tools and methodologies that can better take advantage of the fungible nature of their software developer labor.
The talk itself isn't focused on large software projects architecture directly, but, from my perspective, it gives some very actionable items for tackling larger projects on an individual or small teams basis:
* Focus on expressibility. That is, choose languages that allow mastery over being "safe/boring/simple". Don't worry about making code readable to the lowest common denominator, make it readable for someone who's at your skill level but is trying to find out what the code does (aka "future you"). Allow "footguns" if you trust you can avoid them. Don't worry about language popularity. Enjoy using a "dialects" if it helps empower you.
* Focus on composability. Composability is a broad term but focusing on data-centric design is one way to make things composable as the design can be made around the data being transported.
For me, the major insight is to understand the context of what software is being developed. A corporate environment will have different concerns, for both the employer and employee, than a small project with one or a few developers.
For example, a corporate environment might favor a language that encourages a type of code structure, testing suite, code review process and idiomatic way of solving problems. This makes labor more fungible but means that increased productivity of any individual developer will be met with resistance if it deviates from corporate convention. It also means employees will be motivated to recommend projects using technology that's perceived to be corporate friendly to make sure they're more marketable.
Small projects (FOSS, say) might focus on niche languages, dialects, idioms or other non-standard conventions that incorporate well with the skills of the primary developer. This means the individual developer is more productive but makes it harder for others to contribute.
[0] https://www.youtube.com/watch?v=oJ4GcZs7y6g
[1] https://www.youtube.com/watch?v=FvBySbGueww
[2] https://www.youtube.com/watch?v=URSOH4F3vbU
[3] https://www.youtube.com/watch?v=MlIZ2Q3Rvc8
[4] https://www.youtube.com/watch?v=xK6YZ3NFjuE
[5] https://ftp.belnet.be/mirror/FOSDEM/video/2021/D.perl/progra...