Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How boring should your team's codebases be

blog.meadsteve.dev

Post reply on HN
Print view View original

161–170 of 235 posts

Re: How boring should your team's codebases be

#161

Post by dc-programmer »

skeeter2020 wrote: post #111
jiggawatts wrote: post #15

Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…

This definitely one narrative, but there are lots of reasons that could also contribute to a change. A few: 1. Your system was likely more complex than you describe here; What's generating HTML with dynamic data between the database and the client? Did you "100 lines of JS" have any dependencies? 2. Maybe your company wasn't charging for this simplicity and peace of mind correctly. Companies would pay for for SaaS-st…

I do feel like the necessary complexity of SQL maintenance and dependency patching was thrown under the rug here. But then again maybe the client completely firewalled development and operations

Re: How boring should your team's codebases be

#162

Post by gavinray »

grey-area wrote: post #119
Philip-J-Fry wrote: post #40

There's never a simple answer to this. Here's some of the things we encounter: * A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them. * Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what…

> A bored developer is an unhappy developer A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. > Your good developers are…

  > A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that.
This. I don't want to work with niche languages anymore, and artisanal, hand-crafted in-house libraries/frameworks.

I want to use boring shit like the JVM or the CLR (.NET) and the libraries with the most answers on Stackoverflow so that things "Just work", issues are debuggable, the authoring experience in my IDE is solid, and I can use what little braincells I have to focus on building features + solving problems.

Niche languages and wacky libraries are for my weekend projects + personal fun-time.

Re: How boring should your team's codebases be

#163

Post by bazoom42 »

eatonphil wrote: post #19

Just as one tiny counterpoint, the company I work for [0] builds a database written in Zig, not C. We implemented our own consensus using Viewstamped Replication [1], not Raft. And we built our own storage engine on LSM trees rather than use RocksDB [2]. A lot of this we built ourselves so we can do FoundationDB-style deterministic testing [3] of the entire system which would not be possible with off-the-shelf librar…

That is not a counterpoint. If you said your choices did not have any cost or risk compared to the “boring” choice, that would be a counterpoint.

Re: How boring should your team's codebases be

#164

Post by pkrumins »

meadsteve wrote: post #130
pkrumins wrote: post #123

Earlier quoted context omitted.

There are no challenges. The code I wrote in 2000 still works in 2020 and will work in 2030. That’s why it’s boring tech - it just works without thinking or deleting node_modules directory every day.

The excitement comes when security issues are discovered in no longer maintained code

There are no security issues.

Re: How boring should your team's codebases be

#165

Post by marcosdumay »

jiggawatts wrote: post #22
bdg wrote: post #16

Earlier quoted context omitted.

I understand the annoyance of it being replaced for a more complex more expensive system, but I would also like to know: What was the reasoning provided and what did decision makers truly believe about the whole thing?

> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…

Oh, now it makes complete sense.

Yes, government tender has rules. And if the decision makers don't follow the rules, they can suffer all kinds of consequences, including personal bankruptcy and jail time. Obviously they wouldn't bend the rules just because it would save government money and lead to a better outcome.

Re: How boring should your team's codebases be

#166

Post by pkrumins »

tchaffee wrote: post #157
pkrumins wrote: post #123

Earlier quoted context omitted.

There are no challenges. The code I wrote in 2000 still works in 2020 and will work in 2030. That’s why it’s boring tech - it just works without thinking or deleting node_modules directory every day.

> it just works without thinking or deleting node_modules directory every day That kind of hyperbole isn't useful. If you're deleting node_modules directory every day, you're doing something wrong. Perhaps due to lack of experience. You're claiming 22 years of experience in PHP. So of course that familiar workflow is going to work better for you personally.

My favorite interview question is - how often do you delete node_modules directory. I find that the most experienced candidates will answer “every day”, which is the correct answer. I can catch people lying quickly if they say they don’t delete node_modules.

Re: How boring should your team's codebases be

#167

Post by pawelwentpawel »

From a perspective of a coder on a team, I think that strategically selecting which novel things to learn is a good thing career-wise. Fun aspect aside, one gets paid to learn new stuff which can later result in better future opportunities. As an example, as a junior dev back in 2015 or so, I was told to use one of the very first versions of Swift to develop a production-ready mobile app. Was it fun? Totally! Did I learn a lot? Absolutely! Did we almost trash the project and had a massive delay because of the early bugs, problems, refactoring with new updates, and because we were still learning? Hell yeah! The final payoff was pretty good for developers, but not for the final business objective which was getting a product out ASAP. Our users didn't care about what tech we used.

Following from the above, I think it's important to distinguish two different aspects of the novelty - one is completely new tech ('global' - new to everyone) and the second is tech that's new to the team that is about to use it (let's call it 'local').

Global: That's the hole we got into using the first version of Swift. The team got stuck with problems that no one has ever had yet and we had to invest our time to solve them. The biggest risk was ending up with a completely new problem and no guarantee that anyone on your team will be able to solve it. There is no Github issue for it and no helpful stranger on Stack Overflow. It's pretty bad if it happens in a critical area. From a project perspective, I'd say it's better to wait for someone else's time and money budget to iron those problems out first if you want to increase your chances of having a production-ready product within a predictable timeframe.

Local: This comes with a different set of risks. If you're working within a larger organization, how many other developers know this newly introduced tech? If the team that has introduced it quits, will there be anyone able to pick it up? If your project is on a critical deadline, do you have enough time to let developers get up to speed? I'd think about this decision from the perspective of investment.

Ironically, I have also experienced the reverse - some companies use tech so old that developers have to learn it as something completely novel. The only dev that maintained the codebase might be retiring and the option is to rewrite or hire a person with a spark for archeology.

Re: How boring should your team's codebases be

#168

Post by flippinburgers »

Philip-J-Fry wrote: post #153
grey-area wrote: post #119

Earlier quoted context omitted.

> A bored developer is an unhappy developer A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. > Your good developers are…

>A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. That only holds true so long as the developer believes the end result…

Until you have had to work with complexity guzzling junior developers who cannot help but chase the new sparkle, consider yourself lucky to be working on a stable codebase that is readable. It sounds to me like the team has turned down some of your ideas that you feel would make the codebase "better".

Re: How boring should your team's codebases be

#169

Post by csa »

jiggawatts wrote: post #22
bdg wrote: post #16

Earlier quoted context omitted.

I understand the annoyance of it being replaced for a more complex more expensive system, but I would also like to know: What was the reasoning provided and what did decision makers truly believe about the whole thing?

> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…

In the US, especially with federal money, this would be ample justification for a congressional inquiry and a potential fraud, waste, and abuse claim.

The usual outcome of the investigation is uncovering a bunch of people just saying that they were doing what they were told to do, and no one taking the common sense approach of looking at the current vendor. It might push one or two incompetent middle managers into retirement.

That said, it may get fixed for the next round of bids. It may have long term change depending on which congresspeople were involved.

Re: How boring should your team's codebases be

#170

Post by tchaffee »

pkrumins wrote: post #166
tchaffee wrote: post #157

Earlier quoted context omitted.

> it just works without thinking or deleting node_modules directory every day That kind of hyperbole isn't useful. If you're deleting node_modules directory every day, you're doing something wrong. Perhaps due to lack of experience. You're claiming 22 years of experience in PHP. So of course that familiar workflow is going to work better for you personally.

My favorite interview question is - how often do you delete node_modules directory. I find that the most experienced candidates will answer “every day”, which is the correct answer. I can catch people lying quickly if they say they don’t delete node_modules.

That's a horrible heuristic. All you are doing is selecting for engineers who have failed to fix the problem like you have failed. Misery loves company, eh?

I have decades of experience, mostly work in JS, am often in the top 5% on StackOverflow and very rarely need to delete node_modules. Neither do most of the people on my team. Some of our junior devs reach for that sledge hammer out of frustration. Which is fine. I used a lot of sledge hammer when I was first learning PHP too.

Post reply on HN