The struggle I found in coding as a CTO was that executive team priorities would come along that would take precedence over my ability to maintain my coding contributions, and in my experience no developer team wants to inherit and maintain code from their CTO. I found myself ultimately more drawn to coding tasks that improved developer experience or validated proof-of-concept work.
I agree with the author that CTO positions are incredibly varied, so I appreciate them sharing what works for them personally and in their organization, even if it doesn't match what has worked for me.
I don't think anything requires a README.md to be monolithic. They often provide the introductory material that you mention here, then link out to other appropriate files for contribution guidelines, etc.
I like this insight. We kind of always knew that we wanted good docs, but they're demotivating to maintain if people aren't reading them. LLMs by their nature won't be onboarded to the codebase with meetings and conversations, so if we want them to have a proper onboarding then we're forced to be less lazy with our docs, and we get the validation of knowing they're being used.
I don't think the bar here is a human level coder, I think the bar is an LLM which reads and follows the README.md.
If we're otherwise assuming it reads and follows an AGENTS.md file, then following the README.md should be within reach.
I think our task is to ensure that our README.md is suitable for any developer to onboard into the codebase. We can then measure our LLMs (and perhaps our own documentation) by if that guidance is followed.
We're in a transition phase today where agents need special guidance to understand a codebase that go beyond what humans need. Before long, I don't think they will. I think we should focus on our own project documentation being comprehensive (e.g. the contents of this AGENTS.md are appropriate to live somewhere in our documentation), but we should always write for humans.
The LLM's whole shtick is that it can read and comprehend our writing, so let's architect for it at that level.
I like it! I spun up a little remixable Glitch project based on your demo so that I could play with it in a web editor. Thanks for sharing. https://glitch.com/~fullsoak
I'm very much an environmentalist and am very concerned about climate change, and I feel like this article completely put me at ease about sea level rise. I suspect this was the opposite of the intent.
I feel like in comparison to intensified weather phenomenon and especially heat waves, sea level rise sound very manageable.
The headline worked for me, and then it sort of teased me along with details that ultimately ended without a conclusion and a feeling of "why did I just read this?"
From memory and a little grepping of the Weekly Kiwi archives, I found: "Project Null Terminator", Aardvark, B??, Caribou, Dingo, E??, Flying Fox, Giganotosaurus, ??
Aardvark'd: 12 Weeks with Geeks[1] is a delightful time capsule of 2005 software development. It includes interviews with @pg, the Reddit founders, and other delights. It's available on youtube now.
When I interviewed at Fog Creek, they had a DVD copy of Aardvark'd in a care package in my hotel room. I watched it that night, and for my interview day in the morning it felt like everyone I interviewed with was a movie star. Sneaky plan, Joel. Well executed.
FogBugz's evidence-based scheduling always resonated with me too. Back in grad school I remember writing a paper arguing how it was a fundamentally better way to manage project estimates and schedules. Curiously, even at Fog Creek, something happened over time where we kind of migrated away from using it and instead favored more kanban-style project management systems.
I think a few forces came together to diminish the relative importance of EBS in project management:
- Rapid shipping got easier; rather than uploading executables (or minting CDs!) we shifted to the SaaS model and with that, continuous delivery, etc. In this world, coordinating a "big release" became more of a marketing/communication topic than an engineering one. In the FogBugz customer base, it was the game development companies that held on to EBS the longest.
- Developer tools in general got easier and faster to use, and along with that all of our tolerance for managing timers and estimates went down. Estimation and work tracking I think are still hugely valuable, but there's an ever-higher UX bar to hit to actually have people use the software, and we want the computer to be smart enough to figure it out on its own. EBS never achieved that fluency of UX and it really needs diligent users for it to perform well.
For the last ~10 years of Fog Creek, we were largely structured so that we had core groups of developers focused on our mainstay products, like FogBugz, which were happily profitable revenue sources and could fund all of our assorted bits of inventiveness. After pushing on FogBugz and Kiln in an innovative way for a few years, we came up against an adoption wall of sorts--- changing those products to increase their user base was harder than inventing entirely new products. Trello, in many ways, represented our next stab at productivity and software development tools, and making FogBugz more Trello-like was never going to be as compelling as Trello already was. This pattern kept repeating, and so we did our best to stabilize FogBugz while inventing other sorts of things that would show us a more compelling path to growth.
Glitch was the biggest next invention and its interest and adoption so greatly outpaced what growth we could achieve in FogBugz that it make sense to reorient around it. But of course FogBugz paid the bills and Glitch wasn't doing so yet, so that lead to a VC raise for Glitch and, ultimately, a sell-off of FogBugz and Kiln.
I still love FogBugz, and all of the users of FogBugz were ultimately the seed funders of inventions like Kiln, Stack Overflow, Trello, Glitch, HASH, CoPilot, and a dozen others that we never let past internal testing. Thanks, FogBugz :-)
Fog Creek renamed to Glitch as we transitioned from being a bootstrapped product-incubation lifestyle company to a single-product VC-backed startup. I think of the Fog Creek storybook closing with that rename, since Glitch always had a very different business focus, but technically (and perhaps culturally) they're of the same lineage.
In other Joel track record exploits, he's also our co-founder over at HASH.ai [1] and a driving force behind the Block Protocol [2][3]
Thanks for sharing, Chris. Honestly it sounds to me like you're living the dream-- you're secure enough in your abilities that you can pursue the projects you're excited by rather than having to play career games as an employee for someone else. I hope it keeps working out for you :-)
"Producing Artifacts" is definitely what we called that at Fog Creek, and I think our cousins at Stack may have used a different term but followed much the same spirit. I didn't realize until now that that was a term from our little software microcosm, I had assumed it was one of the terms that was known broadly in the startupverse.
I definitely came to my opinions around it through my interactions with the Business of Software conference and (later) Microconf, and I think in parallel Stack Overflow came to much the same conclusions as we did at FC. Stack also lead with something in its early days which pushed us to go further, which was that they had a "default open" policy on all their artifacts-- code, company writing, etc. This specifically was inspiring for us at FC and many of us sort of implicitly adopted it. We doubled-down on our artifact publishing, leading to a bunch of open source contributions, blog posts, conference talks, etc. Interestingly (and to your point!) I think that those public artifacts for the most part didn't impact the company very much (as much as we did try to harvest the artifacts for blogging/marketing/recruiting purposes), but they unquestionably strengthened the careers of the folks who created them.
"Make sure your work is creating artifacts; Collect and share your artifacts to multiply their impact." Remains among my top items of career advice for software folks.