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

181–190 of 235 posts

Re: How boring should your team's codebases be

#181

Post by losvedir »

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 was a poor decision on Coil's part, as reflected by their eventual decision to jettison that part of their tech?

Re: How boring should your team's codebases be

#182

Post by thow232329 »

tchaffee wrote: post #132
thow232329 wrote: post #76

Earlier quoted context omitted.

> A bored developer is an unhappy developer. Unhappy developers leave. Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development? Why do people think they can "play with new technologies" at work, which i…

> 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 disliked in the company because they are selfish unprofessional time wasters.

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. It's really embarrassing.

Re: How boring should your team's codebases be

#183

Post by throw827474737 »

mike_hock wrote: post #65
patrickthebold wrote: post #53

Earlier quoted context omitted.

It sounds like your project ended up working out well (ignoring the replacement). But one thing that would be hard for me when starting a project like this: How do you know that over time it won't grow into something terribly unmaintainable? You don't have an ORM, but then perhaps over time you re-implement most of the functionality of an ORM, and now new people need to learn that. Of course, you can start with out o…

By devoting time to code maintenance and refactoring in between features N and N+1 (or at least N+M). The code doesn't just magically go from 5-10 SQL queries to being completely unmaintainable without an ORM overnight. When and if it grows into that, you'll see it coming. That doesn't work, of course, if you're not considered to be "working" unless you're hacking on a new feature right now that'll be deployable by t…

> The code doesn't just magically go from 5-10 SQL queries to being completely unmaintainable without an ORM overnight.

I'm not sure in whih world an ORM helps with maintainability...

Re: How boring should your team's codebases be

#184

Post by x86x87 »

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…

I call this the tragedy of software development.

Well written, minimal, roubust systems are not appreciated or welcomed. Heck, most of the times people don't know they exist.

In our industry the heroes are the firefighters and the firefighters are usually the pyromaniacs.

Re: How boring should your team's codebases be

#185

Post by thow232329 »

Philip-J-Fry wrote: post #156
thow232329 wrote: post #76

Earlier quoted context omitted.

> A bored developer is an unhappy developer. Unhappy developers leave. Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development? Why do people think they can "play with new technologies" at work, which i…

>Why do people think they can "play with new technologies" at work, which is wasting not only company money, but other people's time as well? This has been a thing for as long as humans have been working. It's because through experimentation you may discover something that increases productivity. The guy who strapped a combustion engine to a field plow was probably playing with new technologies at work. And it no dou…

No post body was provided.

Re: How boring should your team's codebases be

#186

Post by lolinder »

thow232329 wrote: post #76
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. Unhappy developers leave. Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development? Why do people think they can "play with new technologies" at work, which i…

> Software development is the only profession where people expect (and demand) to have fun at work.

Humans in general demand fun at work whenever they have the leverage to do so. That so many don't have fun is not an example to be emulated, it's a problem to be solved. People are more effective when they enjoy what they do. And software is far from the only profession where people are able to pick jobs because they enjoy them.

A few examples from my own immediate experience:

* In the last year our company hired a full-time designer whose express reason for switching jobs was that our project was more fun.

* My dad is a producer for a radio show. He got that job by twice switching away from jobs that he'd stopped enjoying and he now loves what he does.

* My brother-in-law went into law because he knew he'd enjoy it, and he has a blast every day. He's always telling a story about some crazy new legal edge case he ran into at work.

* My wife is a musician and music teacher and absolutely loves it. You should see her when she has her instrument out.

Instead of trying to rob the fun from the creative professions, we should be trying to find ways to help more people be able to enjoy their work. Even aside from the obvious humanitarian benefits, this would have a huge improvement on our economic output compared to the status quo where so many people are basically cogs in a machine.

Re: How boring should your team's codebases be

#187

Post by [deleted] »

thow232329 wrote: post #180
lolinder wrote: post #179

Earlier quoted context omitted.

This is nonsense. A company that doesn't care one iota about how its employees feel about their job ends up with high turnover, which dramatically increases costs in the long run. Good companies strike a balance between the needs of the employees, the needs of customers, and the bottom line. Any company that fails to strike that balance will lose in the long term.

The definition of a company and its goals and motivations, is clear, and it does not have any consideration for employee amusement. That's what the christmas party and company picnic is for, and they happen outside of working hours. If you push your own amusement as a priority at work, at the expense of the goal of the company, you literally make the working environment dysfunctional.

[deleted]

Re: How boring should your team's codebases be

#188

Post by lolinder »

thow232329 wrote: post #180
lolinder wrote: post #179

Earlier quoted context omitted.

This is nonsense. A company that doesn't care one iota about how its employees feel about their job ends up with high turnover, which dramatically increases costs in the long run. Good companies strike a balance between the needs of the employees, the needs of customers, and the bottom line. Any company that fails to strike that balance will lose in the long term.

The definition of a company and its goals and motivations, is clear, and it does not have any consideration for employee amusement. That's what the christmas party and company picnic is for, and they happen outside of working hours. If you push your own amusement as a priority at work, at the expense of the goal of the company, you literally make the working environment dysfunctional.

This philosophy only works if you live in one of three simplified universes: either your employees are fully bought in to the company's goals, or you can always pay them enough money for them to keep working for you without any intrinsic motivation, or your employees really are interchangeable cogs and retention doesn't matter.

None of these simplified models reflect the real world. No employee is fully bought into the company's goals. Odds are you don't actually have enough money to beat all other offers. And the cost of turning employees into interchangeable cogs is that you need a lot more of them than if you're willing to let them be individuals.

The result is that while the company has its own goals, those goals are best served by making sure that the employees are at least happy enough that turnover is kept low. And a big part of keeping creatives happy (not just in software) is letting them try new things and experiment.

(This is aside from the tangible benefits that your organization gets from allowing people to be creative, which I think is not negligible.)

Re: How boring should your team's codebases be

#189

Post by carapace »

pwm wrote: post #8

It feels like there is an article like this every other week. They reflect the same generic view which is broadly true yet I think is not very useful as an advice. In a highly creative field like software competitive advantage often outweighs comparative disadvantage. In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete co…

> In a highly creative field like software

Not in 2022. Half a century ago, yeah, it was a highly creative field, but these days almost everything has been done. (Even ML is decades old, the hardware caught up.) And this is a good thing!

We have been doing this long enough that it should be "boring" now, in the same way that constructing buildings or bridges is "boring", eh?

> In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete competitors.

Sure, but that's a decision that should be made cautiously, with good reasons to think it will work. In other words, innovation should be "boring" too, at this stage in the game.

Re: How boring should your team's codebases be

#190

Post by fshbbdssbbgdd »

thow232329 wrote: post #76
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. Unhappy developers leave. Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development? Why do people think they can "play with new technologies" at work, which i…

Humans didn’t evolve to sit at a desk all day. We can adapt to it, but some sort of feeling of adventure helps motivate. Interest in the work engages more of the brain and can make one more productive.

I’ve cultivated the ability to become excited about picking apart grody system failures. That never gets old, and unlike adding a hot new framework to the stack, the cumulative effect is always to make things work better.

Post reply on HN