Last I heard he was battling cancer. We've got plenty of new blood fuelling the public discourse. He's done enough. I'm inclined to give him a break and instead put the pressure on the rest of the community to get themselves organised and do something about it.
I agree, but I do need to keep a chromium browser around for the odd times that: my webcam decides to flicker uncontrollably during a meeting, a website just happens to put JS that runs terribly on Firefox in the hot path and it slows to a crawl, or a new feature is being demonstrated with Chrome only support.
Beats ads, as far as I'm concerned, but I can't help but feel like your average user wouldn't agree.
If you use the built in keyboard I imagine you have to continuously deal with the page resizing to avoid the keyboard, and potentially people not having easy access to an English keyboard.
The custom keyboard makes all the tools you need a first class component of the game.
That's very easy to say until it's your partner, mother/father, or child on the other side of that assertion.
If you're curious and have time, I'd suggest the following excellent exploration of the idea of extinguishing natural death by CGP Grey. He uses an interesting analogy to help challenge the ingrained belief that natural death is just
https://youtu.be/cZYNADOHhVY?si=oCqVGD5RX9Q0Cnrk
Thank you – I think of "model" as meaning the way I think about, reason, and communicate an idea. But I completely see how that usage is not idiomatic. I appreciate the feedback.
Great question! I'll try my best to explain, though it's late and I may ramble – apologies in advance.
(You said you understand this bit but I'll put it here too just incase someone else could benefit). By modelling "the architecture", I'm referring to the architecture or the design of the system where work is happening. Think, for example, whether it's a system composed of many small components (modules, micro-services, micro-frontends, mono-repo), or a single large application (more traditional monolith).
By modelling "work" I mean: how do you distribute the work and the ownership of that work to teams. You can't easily have teams that share ownership, because if everyone is responsible then no one is. And you need to ensure responsibility for work is clear. For example, what are the outcomes you need from the other team building out that new API? Does your team also integrate code into those services that the other team are building? Probably not, but for some it isn't always clear. And if it's fundamentally required, how can you have many teams effectively contributing code to a single service without stepping on each other's toes and dilluting the concept of ownership?
By "communications of the team(s)" I mean to say that you need to influence how teams communicate. In a perfect world, all teams would be perfectly autonomous and never need to have the overhead of talking to or depending on another team to deliver work. In reality, teams need to communicate but there are different models to facilitate this (self service systems, service oriented software design, documentation, etc.). Organic collaboration can be harmful as companies grow beyond certain limits if not kept in check. The book Team Topologies by Matthew Skelton is a deep dive on this topic if you find that interesting.
This is one reason why I go all in on practices that are backed by data to correlate with business success (CI/CD, DevOps, etc.). Think the Accelerate book. Software development has the added difficulty of being quite a young industry (relatively speaking), but (with tongue in cheek) how can you be expected to do better than practices espoused by industry leading research and companies?
I couldn't agree more. This is written from the perspective of a manager so I am likely asking a bit too much from the reader to make the connection. Thank you for the feedback!
My experience tends to be that managers will rarely get help to manage the teams WIP and it's often left to that same manager to provide that mechanism of back-pressure. But if they then don't, for whatever reason, then it can be bad news for the team.
I'm weeks away from going on a significant period of leave and I sincerely hope that the precedents I have set carry forward during my absence.
I would certainly be lying if I said the Phoenix Project hadn't helped me form some of my ideas around capacity and limits on WIP. Agreed, a great read.