blinkymach12

"Attention is all you need" is a famous ML paper. Though given the content of the article I don't think the author was intentionally referencing that.

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 had the same thought as I read this example. Everything in the AGENTS.md file should just be in a good README.md file.

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

Thanks! Publication was February 2024.

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.

I also had that impression.

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.

[1]: https://www.youtube.com/watch?v=0NRL7YsXjSg

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]

[1] https://www.joelonsoftware.com/2020/06/18/hash-a-free-online... [2] https://blockprotocol.org/ [3] https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...

- HyperWeb [ Internal project name for first ~year ]

- HyperDev [ First public branding / early launch ]

- GoMix [ First major relaunch, now with Anil as CEO ]

- Glitch [ After acquiring the sweet glitch.com domain from the kind folks at Slack ]

Source: I helped work on it

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 :-)

Hey Patrick! Thanks for the article.

"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.

Same.

Ah, good find of the github link! I imported it into glitch so I could see it run: https://honey-climb.glitch.me/

Fog Creek Software | Site Reliability Engineer | New York, NY | ONSITE, VISA, https://www.fogcreek.com/jobs/SiteReliabilityEngineerNYC

Hi! We're looking for some SREs and Network Engineers to work with us in our New York City office. We have a colo nearby, so we require your physical presence for this position.

We're an established small company with big ambitions. We created Fogbugz, co-created Stack Overflow, created Trello, and are now in beta for HyperDev. Come visit us at https://www.fogcreek.com/about/

Kind regards,

- Jude

Thanks Blake! :-)

Fog Creek Software | NYC or Remote | System Administrator

Fog Creek Software is looking for an experienced, unstoppable System Administrator. On our team, you'll work with top-notch developers and support engineers on the infrastructure behind our SaaS applications, FogBugz and Kiln On Demand. You'll build tools and automation that will run the environment while you sip lattes. You'll help tune the infrastructure and help plan for future growth.

http://www.fogcreek.com/careers/ http://www.fogcreek.com/Jobs/SystemAdministrator/

Fog Creek Software | HQ in New York City | Full-Time | Onsite, Remote, and Ad-Hoc Remote friendly.

Fog Creek Software is a small, friendly software company in New York City that was designed from the ground up to be a great place to work. We work on interesting projects with smart people, treat everyone like royalty, and eat lunch together every day. Over the course of our adventures we created FogBugz, Kiln, Trello, and co-created Stack Overflow.

https://www.fogcreek.com/careers/

Currently seeking Support Engineers (https://www.fogcreek.com/Jobs/SupportEngineer/) and Account Executives (https://www.fogcreek.com/Jobs/AccountExecutive/)

I hope you'll check us out.

Fog Creek Software, New York City - REMOTE and in-office

Hiring Developers, Designers, Support Engineers, and a Product Marketing Manager.

Fog Creek Software is a small, friendly software company in New York City that was designed from the ground up to be a great place to work. We work on interesting projects with smart people, treat everyone like royalty, and eat lunch together every day.

http://www.fogcreek.com/careers/

These are excellent, well done! Thanks for both documenting your progress and taking the time to inject character into your games.

Hi dlp211,

My name is Jude and I'm one of the developers at Fog Creek Software. I'm obviously a bit biased, but I'd be happy to talk to you if you have any questions about Fog Creek. Feel free to ping me at jude@fogcreek.com if you're interested.

I was an intern at Fog Creek 5 years ago, and at the time I was also choosing between Microsoft, Google, and FC. At my final interview at each of Microsoft and FC, I asked each person (at Microsoft, the head of the Windows Live team; at FC, Joel) to tell me about why I should work with them instead of my other options.

I came away deciding that they'd both be great places to work. I ended up choosing Fog Creek because of a few aspects which were more appealing to me. The biggest lure to me was that Fog Creek was (at ~15 people) and still is (at ~50 people) a small company. It meant that I'd get to see more of how a software company functions. It meant that I could get involved with more of the steps of shipping a software product, and I could have my feedback and actions directly impact the products I worked on.

Those were some of my draws. Plus, it's an internship... it felt to me like a great opportunity to explore NYC without committing myself to it for years. I felt confident that Google and Microsoft would be largely unchanged if I waited a year, but I felt like Fog Creek was a little different. I still think it is.

Whoever you choose, it sounds like you've got some great options. I'm sorry you've got an exploding offer to deal with. If you're still undecided, keep in mind that the recruiter will likely extend the window if you ask them to -- the deadline is forced so that you'll be more likely to choose them, not because they're actually trying to cut you off ;-)

Best of luck, - Jude

Fog Creek Software - New York City - Trello Mobile Designer

http://www.fogcreek.com/Jobs/TrelloMobileDesigner.html

Fog Creek Software is a small, friendly software company in New York City that was designed from the ground up to be a great place to work. We work on interesting projects with smart people, treat everyone like royalty, and eat lunch together every day.

http://trellograph.com/ comes to mind