202109061338 Software Engineering

Maybe this should be a structure note of structure notes only since this is a huge topic that I'd like to really dive deep on. There is also the 202206191300 Computer Science structure note that I’ve split out to dig in to the more technical, theoretical stuff in order to keep this one focused more on the practice of writing software and careers or organizations in this field.

Topics

Documentation

• Co-locate tech docs with the code
• C4 Modeling

Abstraction

• You aren't gonna need it (YAGNI)
• 202204031033 Abstractions and future-coding are actively harmful
• 202204262054 Prefer duplication over the wrong abstraction
• On the spectrum of abstraction¹
• Open for extension closed for modification O in SOLID. Means you can add new behavior without modifying any existing code. Always green, always confident in lack of side effects.²

Measurement

• 202304231046 List of SDLC metrics
• 202204272219 The fastest code is no code
• 202109251100 Verify behaviors and assert properties
• Thought experiment. Coding as function, what do the derivative and integral represent? Related to 202107291950 Optimizing requirements and implementations and 202110111901 Run to change ratio of a program.
• Quality is not tradable. See 202205031410 Design stamina hypothesis as well.
• 202211121253 Value of employee time
• It's almost the most important thing to have a well documented, well tested, well logged, well traced service. Observability and reliability are simple but not easy. Set it all up at the very beginning and never look back. As Hamming says, "You get what you measure."[^hamming2020]

Simplicity <-> Complexity Spectrum

• 202203221620 The golden rule of programming
• 202312091440 Eliminate effects between unrelated things
• 202204272239 Monorepos make all the wrong trade offs

Constraints

• Constraints enable behaviors and properties
• You can compute a good config by multiplying probabilities
• Knowledge and skill transfer are complex

Conventions

• 202203221610 Naming conventions should use unambiguous delimiters
• Folder by tech
• Folder by feature
• Folders as namespaces

Testing

• 202312091531 Start at square one when debugging
• 202208112226 Tests are not a substitute for types
• 202208112228 Types are not a substitute for tests
• 202205121023 Use values as the boundary
• 202304031254 Small careful samples are better than large poor ones
• 202312091534 Write a failing test for bugs
• Good tests act as documentation for the code they are testing³
• The purpose of testing is to reduce fear - Phil Borlin
• Write the tests you wish you had - Kent Beck

Lifecycle

• 202205031410 Design stamina hypothesis
• 202109251124 Golden age software
• 202109251125 Post-apocalyptic software

Roles

• 202206112236 Senior engineer
• 202206112233 Staff-plus engineer
• 202407081040 If you can't cancel the project you're not the product owner

Patterns and Principles

• 202204272256 Create internal APIs on top of dependencies
• 202312091449 Encapsulate at the boundary
• 202204281140 Model, view, controller architecture
• 202204272308 Modules should be highly cohesive
• 202204272309 Modules should be loosely coupled
• 202207061626 Optimal line length for readability
• 202204272244 SOLID design principles
• 202208131327 System design
• Pit of success
• Generate IDs at the edge

Strategy

• 202312091400 Be the exemplar of change
• 202206171206 Delivery Performance vs Value Delivery
• 202112181448 Explore, expand, extract
• 202208131431 Everybody loves an existence proof
• 202208151317 Incremental change is always better
• 202110231440 Knowledge is the backbone of a product organization
• 202312091517 MVPs should be vertical slices
• 202308282340 No broken windows
• 202107291950 Optimizing requirements and implementations
• 202108261302 Prototype, Expand, Consolidate
• 202109251102 Reclaiming software systems
• 202310301105 Rescuing a failing project
• 202206051639 RGM development
• 202110111901 Run to change ratio of a program
• Transactionally-staged job drains
• Migrations
  • 202205131318 Software only supports one order of magnitude
  • 202205111310 Migrations are the only solution to tech debt
  • 202205111303 Debugging migrations
  • 202304051001 Use a simple heuristic to guide gradual adoption
  • Rewrites #thread
• Engineering organizations grow to need specialization and ownership in the 50-100 dev range, but they don't have enough people to own everything until there's slightly more headcount. #thread talk with Chandler and his convo with Gusto guy about this.
• The value of a product owner (fallout from the death of the PO)
  • Big problem with ambiguity of who is following up on things.
  • Missing glue person who would not let things fall off the radar.
  • Someone who is deeply knowledgeable about business rules and the product, but has the explicit time and responsibility of doing the people work, the stakeholder work, the setting of meetings, the looking at the project and its progress.
  • Is this dev lead? No.
  • Is this EM? No.
  • Is this PM? No.
  • Downstream effects on groups like the working groups.
• 202204021218 Architecture Decision Records
• Platform vs Application teams
  • 202110251147 Strengths of platform teams
  • 202110251148 Weaknesses of platform teams
• Internships can provide slack/bandwidth for R&D type things. They can be partially decoupled from the normal org dynamics, tendencies, or incentives and give space to explore things that wouldn’t normally happen.
• Utility vs strategy dichotomy And tractors, nuclear power plants, and the bleeding edge
• You can figure out the core domain where requests to change happen most often and what sets the company apart.\nFor those use cases show how adaptability, ease of change, makes sailing the ship (the business) on the market easier.\nFor the rest, accept to use external tools, but put some technical requirements which makes plumbing around those tools (mocking them for instance by having an api). You'll be fine this way, because either you choose the best tool for that particular supporting domain, which will get out of your way, or if not then you can later on proove with tickets how that tool incurs costs through tickets and replace it with either another tool or replace it with your own.\nFor all this approach to tooling they need to buy into the idea that a reliable, reproducible testing system is worth its weight in gold. It's possible to convince sane business people of this, but you have to draw for them the problems and the solutions, then you get buy-in.

Philosophy

• 202205031219 Agility is not equal to speed
• 202407181026 Architecture as a form of procrastination
• 202205092134 The Art of Doing Science and Engineering
• 202204281133 Computation, storage, and representation are the basis of computing
• 202110222122 Don't stress over releases
• 202205031435 Evolutionary approach to software design
• 202205041105 Firmitas, utilitas, venustas
• 202203221620 The golden rule of programming
• 202307241042 The Pragmatic Programmer
• 202312091509 There are no final architectures
• 202312091511 There is no such thing as sacred code
• 202205031449 Optimize for change
• 202203221630 Slow is steady, steady is smooth, smooth is fast
• 202304031244 There is never time to fix things later
• 202204011028 Trust, loyalty, and advocacy over addiction
• 202208130954 The value of a great tech stack
• 202204262114 Write code that's easy to delete, not extend
• 202204272326 Write less code
• 202312161343 You don’t do Agile
• 202312091520 Your language limits your world
• 202206112125 Zen in the face of programming
• Deep ownership and expertise are a prerequisite for maintaining golden age software, reliability, quality etc.
• Sandboxing is important for experimental and experiential learning. Turn off the wi-fi and run things to see how they respond.
• Thoughts about a dev career in terms of code-bases worked on.

Miscellaneous

• 202208281253 Authorization
• 202110221638 CMS editor and developer experience alignment
• 202312091526 Get good with your tools
• Example of memory unsafe code in Go
• 202312101839 Think horses, not zebras
• 202408220851 Willful ignorance of reality in organizations

Books

• 202312091323 The Software Craftsman
• 202307241042 The Pragmatic Programmer
• 202205092134 The Art of Doing Science and Engineering
• 202308241743 The Principles of Product Development Flow

Conferences

• 202404301034 Stir Trek 2024