How boring should your team's codebases be • Hacker News Board

Re: How boring should your team's codebases be

#191

Post by danieljacksonno » Sat, Oct 15, 2022, 6:56 PM UTC

dub wrote: post #159

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…

Figuring out how to reward simplicity, reliability, and maintainability feels like one of the most important unsolved social/human/economic issues in the software industry. Seems there's only incentive to simplify at small companies where the employees feel they can save their own time or increase the value of their equity by delivering value to customers more efficiently. At large companies employees work 40-hour we…

Stop billing hourly. Instead bill for the value you provide. How you provide it should be immaterial, and so you can do it as cheaply and efficiently as possible while still reaping heaps of money as long as it creates value.

That's how all other markets work. Billing hourly is the death of progress.

Re: How boring should your team's codebases be

#192

Post by [deleted] » Sat, Oct 15, 2022, 6:58 PM UTC

losvedir wrote: post #181

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…

Ah, I think this is actually a very interesting example. My understanding is that TigerBeetle started its development under the company Coil, and was eventually spun out to its own company. I think this post my almost be directly speaking to Coil's decision to fund an in-house, specialized, database project written in Zig. More power to you guys for actually getting to work on such a fun project, but I wonder if that…

[deleted]

Re: How boring should your team's codebases be

#193

Post by tchaffee » Sat, Oct 15, 2022, 7:14 PM UTC

thow232329 wrote: post #182

tchaffee wrote: post #132

Earlier quoted context omitted.

> Why do people think they can "play with new technologies" at work The same reason software developer salaries are so high. Supply and demand. Companies will do back flips to attract and keep software engineering talent. > which is wasting not only company money Some of the best cost saving solutions I've come up with in my career have been thanks to "playing" with new technology. It's the opposite of wasting compan…

> There is nothing childish about loving your work, having fun while doing it Expecting to love your work and have fun doing it, is incredibly naive, yes. > bringing that attitude to work. It's infectious and great for company morale. Exactly the opposite, relationships become incredibly strained with the rest of the company and there is a lot of frustration when dealing with the software department. Developers are d…

> Expecting to love your work and have fun doing it, is incredibly naive, yes.

Then I guess I've been naive for over three decades. And getting paid great for it too. I suppose I'll never learn this important lesson considering I'm close to retirement.

> Exactly the opposite, relationships become incredibly strained with the rest of the company and there is a lot of frustration when dealing with the software department. Developers are disliked in the company because they are selfish unprofessional time wasters.

I could imagine that happening with you. There are always a few envious types in any company who think the entire company feels the same way they do. These same folks are envious that the sales people get huge bonuses for "spending all their time on the golf course". Considering I have work relationships going back decades it's safe to say there are plenty of people in most companies who aren't like you.

> The users are just dumbfounded when they present their 8 month rewrite of perfectly working system, in trendy react framework, now with only 80% of the features and in a slower web page.

Of course they would be. That doesn't sound like fun at all. That sounds like a project that didn't take user requirements into consideration. Fun and poor requirements definition sometimes come together, but you are confusing correlation with causation. Loads of overly serious software engineers get the requirements wrong too.

I hope things get better for you and you learn to have fun while still being highly professional. It's a great club to belong to.

Re: How boring should your team's codebases be

#194

Post by hbrn » Sat, Oct 15, 2022, 7:22 PM UTC

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…

> If they think there's an oppurtunity to improve the developer experience at the cost of complexity, they'll try it and see what it looks like

IME this fails most of the time. Perception of complexity varies across the team. A proactive developer pushing for a new shiny thing is unable to properly recognize complexity of his solution because he is the most familiar with his solution. Familiarity changes perception of complexity.

A lot of developers have a catastrophic combination of being non-confrontational and having impostor syndrome, so when then new shiny thing gets enforced upon them they are unable to push back. They don't like it, but they think it's their fault, so they keep silent.

> "Good" boring code bases in my experience are flexible but tedious

It is true, but I taught myself to love that tediousness and I absolutely love it. I treat it as enlightenment. I write way less code, but ship way more value.

It's really sad that most engineers are excited by solving their own problems, not by solving customer problems. Talk about misaligned incentives.

We even rank companies based on how much fun they allow us to have, not by how much impact they are allowing us to have. I've heard numerous stories about folks at Google not being able to ship to production for months, but still praising their tech stack. To me that's just insane.

> Getting buy-in for refactoring is a huge effort because everyone argues "complexity is evil"

That's strange. In my world most of the refactorings are aimed to reduce complexity, not increase it.

Re: How boring should your team's codebases be

#195

Post by hnthrway » Sat, Oct 15, 2022, 7:25 PM UTC

paulryanrogers wrote: post #141

andrewstuart wrote: post #96

Here’s a question for you: “To what extent should developers use advanced programming language features?” I worked on a project once that had lots of sophisticated code in it. One of the senior developers objected however when I suggested we use typescript decorators. He said other developers might not understand it. Consider what happens when the question is phrased differently: “To what extent should developers use…

Some features are more naturally intuitive than others. Consider an 'if' statement and a monad. How much talent is available that's capable of understanding and using the latter effectively? How much time would be needed by a new hire to come up to speed? If you need intermittent help from contractors then will they be able to hit the ground running? Over time the bar does rise, and I hope that trend continues. Yet i…

Most companies are willing to invest just about nothing into education

Re: How boring should your team's codebases be

#196

Post by osigurdson » Sat, Oct 15, 2022, 7:42 PM UTC

hedora wrote: post #171

skeeter2020 wrote: post #115

Earlier quoted context omitted.

Which is actually kinda funny, because some of the "complex" technology the OP is railing against allows us today to manage thousands of databases both easily and efficiently... IF the systems are built with a more current approach. This is why I try to understand ALL of the motivations for disruptive change and not immediately assume incompetence and self-interest bordering on criminal.

Option one: Write a cloud formation / terraform template that involves O(1) machines and deploy 2000 identical copies. Option two: Write a template that deploys O(N = 2000) interdependent services across roughly 3-10x as many machines, and deploy one copy. From what I can tell, you are arguing for option 2. It is strictly worse than option one. In addition to being more complex, it has a few nines less reliability, a…

I'd argue for Option 3, which is to try to understand the workloads placed on the original system and then design the new system based on this. I think having 2K independent database servers would not normally be optimal for 2M users, but it is possible.

Re: How boring should your team's codebases be

#197

Post by baby » Sat, Oct 15, 2022, 7:58 PM UTC

gavinray wrote: post #162

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. This. I don't want to work with niche languages anymore, and artisan…

I agree, but would use Rust instead of Java. Imo Java is a horrendous language that’s basically legacy at this point.

Re: How boring should your team's codebases be

#198

Post by baby » Sat, Oct 15, 2022, 8:01 PM UTC

andrewstuart wrote: post #55

I disagree with the fundamental premise put forward here. Software should be written to meet specific needs. And those needs should be defined. And it’s likely a software project will have many tens of needs defined. And amongst all those needs it will become clear what technologies fit the needs. A blanket statement like “choose boring technology” only fits projects where the project needs result in that outcome. Sa…

Couldn’t disagree more. I think you’re missing the point. You can use boring technology (Golang) and simple patterns (no generics) and build something that works, and is readable, and maintainable, and secure as a consequence of this. I’ve seen this again and again. Then you can expand your code as business needs change, but making your code flexible from the start is in the same basket as over engineering and premature optimization.

Re: How boring should your team's codebases be

#199

Post by baby » Sat, Oct 15, 2022, 8:04 PM UTC

meadsteve wrote: post #74

bdg wrote: post #18

Earlier quoted context omitted.

> I would prefer to work on a codebase that solves problems effectively than a codebase that is novel. I have a design for a very very boring code base that involves no frameworks or external libs. It works fantastic and has been used by some of the most productive teams I've managed. Those teams can manage "more services than we have people on the team by a scale of 2-4x" (quote from one of the engineers on one of t…

I still consider "no framework" as a novel choice (most of the time): https://blog.meadsteve.dev/team-work/2022/10/13/how-boring-s...

I like this argument because using a framework, or a library, implies that it might be established and that there’s already a lot of resources, docs, and stackoverflow question on it. Not using a framework most often means no doc.

Re: How boring should your team's codebases be

#200

Post by baby » Sat, Oct 15, 2022, 8:05 PM UTC

pharmakom wrote: post #82

Perhaps a controversial take: it’s difficult to write boring code in the common boring languages because they are not powerful enough to express the problem domain without accidental complexity.

It depends what you are trying to write. But I’ve seen people complain about the lack of generics in Golang, and I’ve also seen really great cryptography code in Golang (TLS implementations, etc.)

I wouldn’t write a compiler in Golang though.