Cultural Fit for Code

The first month of 2026 is almost done, and what a doozy it's been. Now, as a general idea I don't want to bore people too much with the menial details of my work week, never mind the privacy issues this might cause.

So let me boil it down to a more generic message: Soon we're going to ditch a lot of our current web frontend code, because it wasn't a cultural fit.

Survival of the culturally fittest #

If you've been looking for a job in this millennium, you might encountered these dreadful words already. Or even read them in a rejection letter.

A long long time ago, when goats had feathers, erm, I mean during the late stage of the dot com era and the 00s, I often heard it used by more modern IT companies. Not all of them startups, but generally more aligned with "Silicon Valley" ways of working than with the waterfall model setup of the established companies.

For young me, that usually was a good thing. If someone was looking for people who "fit in to their culture", I felt like I – university drop out and consumate nerd – might just be one of them!

These days?

Now it's quite often people being singled out because they don't fit in to the company's grindset mentality. (It's still about the difference to "Silicon Valley culture", to be fair, but we're no longer focusing on its nerds, but it's hypercapitalist techbros. And yes, I'm aware that that always was part of it.)

But what about code? #

What culture are we looking at when we're talking about code, though?

Every programming language is Turing complete. Every frontend library can recreate current web interface standards and store it's data however it wants to.

But most of the time, you've got community standards and best practices. Sometimes this arose out of the pure language features, where some ways just provide less friction. Sometimes it was more a reflection of the user base – people writing financial applications with millions of lines of code have different needs than people writing throwaway statistical analyses.

Perl might have its TIMTOWTDI, but Python had its "Zen", and Ruby on Rails was so focused on convention that it popularized the word "Omakase".¹

Herd hither, me thither? #

Still, the programming world proudly considers itself full of iconoclasts.

Outsiders.

Disruptors.

Besides, the determined Real Programmer can write Fortran programs in any language.

––Letter to Datamation, 1983

But arguments for following the general culture of a language, framework, operating system etc. are easy enough to find:

• Your co-workers are familiar with the standard way of writing.
• New programmers (especially junior ones) are more easily onboarded, as they can leverage more experience from previous jobs or manuals/courses.
• Cultural idioms are proven to work
• There's often less friction with the language or framework, and thus fewer lines of code

Most of this boils down to code that's easier to maintain and work upon in a team. Iconoclasts are loners.

Where this hit me #

This was the main topic of most of my working month. We're doing an intranet web interface, with lots of views looking pretty much the same: Lots of tables that worked the same way, lots of other pages with common elements.²

My initial code was a bit copy-pasty, but there was a lot to focus on, as I also had to patch lots of gaps in the backend serving the data.

My co-worker wasn't familiar with the backend technology, but had more experience with thee frontend tech, so after he came on the project we quickly divided our work along those lines³.

He created a system based on past work that aimed to create some kind of specialized page description language aimed at not just creating the look & feel of those standardized pages (which you get for free in almost any component-oriented web framework these days), but also the interaction and data retrieval patterns. Ideally creating a new page like this would just be configuration, not code.

I liked the idea.

In some languages, like Lisp, this would totally be part of the language culture.

Problem: It isn't in React/Typescript.

So when the project encountered some delays, culprits were looked for.

Other parts got well along with a simpler approach – their interfaces having much simpler interaction patterns and sheer number of pages was known, but not deemed important enough.

So we're finishing this in a hurry, and will replace the whole frontend code that I worked on for the last months with something newer, "simpler", and more aligned with other parts.

After writing a bit about the importance of aligning with the zeitgeist of a programming system, I can't say I'm totally disagreeing.

I had a few objections. First of all, is it really worth the time to replace this? Rewriting is almost always a bad choice (Yes, the linked page is from 2000. War, erm, coding never changes.)

Then, they underestimated the complexity, so we're probably going to end up half way to a more complex system anyways, maybe written more in the personal style of the person making the decisions there (I still hope that's me at that point, but right now who knows?).

But it's also not that clear that we could've just met in the middle. React is very pliable, to say it in the least offensive way possible, but could replacing the Typescript-based configuration style with more JSX brackets be done or would that just end up with a system that's the worst of both worlds?

Lessons learned? #

So what to I derive for myself from this last month?

Honestly, I don't really know at the moment. "Correcting" the code while navigating the waters of project politics was strenuous enough. I hope I can provide a proper post mortem in a few months, one way or another.

But I'll try to boil my current state of mind down to a few items, most of which aren't really new to me or others, but repetition is a key to wisdom:

1. Be aware at the beginning. Letting other people program the way they want, when it's not explicitly a prototype is hard to get back from.
2. Clarify the people who participate in the maintenance phase of a project. They might have less time or be "cheaper" programmers than the ones building the first stages. Less time or money is part of the cost/benefit estimation of design.
3. Deadline-oriented project structure works better with incremental changes, not building up libraries.
4. React sucks.