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

211–220 of 235 posts

Re: How boring should your team's codebases be

#211

Post by erik_seaberg »

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.

Boring codebases should be generated, not maintained.

Codebases become boring because bad tools require a lot of repetition and meaningless boilerplate (which also encourages mistakes). Experience with bad tools is much less valuable because they can’t amplify my time and effort. If a job did not allow me to maintain valuable and marketable skills, they would have to compensate me a lot for creating a résumé gap and making future job searches harder.

Incidentally I also found this to be sort of a drawback with Google. Experience with completely proprietary platforms also has little value outside the one company where they’re available.

Re: How boring should your team's codebases be

#212

Post by erik_seaberg »

therealdrag0 wrote: post #210
klysm wrote: post #131

Earlier quoted context omitted.

I agree with this. The biggest thing that’s missing for me is sealed sum types. We’re getting there but progress is slow.

Does Scala have that?

Scala has sealed traits, which may only be implemented in the same file, and pattern matching must be exhaustive. At a glance, Java 17 has something similar (JEP 409 sealed classes).

Re: How boring should your team's codebases be

#213

Post by jiggawatts »

jameshart wrote: post #208
osigurdson wrote: post #103

Earlier quoted context omitted.

>> deployed to over 2000 locations Were there 2000 independent systems / SQL server instances running or just one? 2K separate deployments to manage (with 1K users each), does sound a little scary. Of course, perhaps that is not what is going on at all.

2000 SQL server licenses sounds terrifying

Both the old and new systems were using licensing based on processor cores, not VMs or instances.

If I remember correctly, my version had something like 8 + 8 cores in an active/passive configuration where the passive node is free. There was also a single dev/test server also with 8 cores, but that's free too.

The replacement used a few hundred cores shared by the various instances and environments. If I remember correctly, they had something like 10-20 databases per virtual machine, and then about 5 virtual machines per physical host. The cores in the physical host were licensed, not the logical layers on top. (I can't remember the exact ratios, but the approach is the point, not the numbers.)

The "modern" cloud approach of having dedicated VMs for a single thing is actually terribly inefficient, and that approach would have bloated out the above to thousands of VMs instead of "merely" a few hundred.

The correct architecture for something like this -- these days -- might be to use Kubernetes. This provides the required high availability and instancing, while efficiently bin-packing and deduplicating the storage.

Still, you can't Helm-chart your way out of an inefficient application codebase.

Again, for comparison, my version could run on a laptop and had about half a dozen components, not thousands.

Re: How boring should your team's codebases be

#214

Post by perrygeo »

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…

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

Because that is where new ideas, new approaches, innovation and knowledge creation happen? In software, like many other knowledge-work professions, you can't just put in a few years at university and then stay on top of your game by simply showing up every day for 40 years. The daily challenges are too diverse and change too quickly. Continuing education is a significant part of staying in the game, mixed with daily application of this knowledge.

Think about it this way - if you're a high-value developer, you've already put in thousands of hours of R&D and practiced with numerous technologies. Much of it on your own time, much on a previous employer's time. This knowledge is the basis of your current skillset. It's why companies pay you a salary. It's how you adapt to novel challenges in daily work for which you, by definition, require a larger body of knowledge to draw from. You know best how to build that body of knowledge.

Some companies are apparently more than willing to reap the benefits of R&D that was done on someone else's watch. But when it comes time to allow R&D on their time, suddenly it's "wasted" and derided as "play". The only thing that's wasted here is the developer's talent. When the "adults in the workplace" behave like this, making arbitrary engineering decisions about what is legitimate work vs play time - despite lacking the engineering context or credentials to make such a bold determination - that reeks of unprofessional behavior.

It would be like me micromanaging a lawyer's document list in preparation for their case. Or me telling a doctor which medical journals they should/should not be keeping up with. I'm not qualified! So I shut up and let them work, and put my trust in their deep knowledge and hard-gained experience. That's professional.

Re: How boring should your team's codebases be

#215

Post by Winsaucerer »

ratww wrote: post #95
Winsaucerer wrote: post #58

Earlier quoted context omitted.

Horror stories like this are always fun to read. I've become a fan of avoiding ORM's and API's between front end and back end for websites. Want a page that shows a dashboard of xyz? Write the right query that fetches exactly what you want, render the HTML, and return it. Super simple, and abstractions are at a great minimum. No SQL->ORM->API->frontend, each with their own twist on how they model the world. A splash…

A few years ago I start a dashboard project that was mostly raw SQL. I then saw the team wanting to convert it to ActiveRecord, which they started. But lots of queries had to use AREL (Rails' "low level SQL AST abstraction"), since they weren't really possible or just too difficult to do in ActiveRecord. But AREL is so incredibly unreadable that every single AREL query often had its equivalent in plain SQL above it,…

Another great horror story, thanks for sharing :)

Re: How boring should your team's codebases be

#216

Post by lupire »

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…

> Your good developers are often the ones who like to tinker with frameworks, patterns and complexity.

This reminds me of Spolsky's "Smart, but doesn't get things done" anti-pattern.

Smart doesn't mean good productive team member.

Re: How boring should your team's codebases be

#217

Post by lupire »

ratww wrote: post #68
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…

> 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 they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring…

Why does tinkering on the clock matter? Why not just hire people for 30hrs/week if that's what they want?

It's not the 1970s where you can't afford a computer at home.

Re: How boring should your team's codebases be

#218

Post by baby »

therealdrag0 wrote: post #209
baby wrote: post #198

Earlier quoted context omitted.

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 premat…

Your example and conclusion aren’t a good match IMO. Choosing a restrictive language is not something you can easily pivot from later when you need more flexibility. It’s a huge commitment, so making the right choice for the future is not premature.

On the other hand using an expressive language you have to force your employees to use a subset of the language, which usually doesn’t go well

Re: How boring should your team's codebases be

#219

Post by P5fRxh5kUvp2th »

lr4444lr wrote: post #117
geokon wrote: post #70

Earlier quoted context omitted.

Isn't the moral of the story that you didn't charge for it correctly? If you charged a fixed annual maintenance fee then you would have felt very clever having made a ton of money not having to do anything Administrators would have also felt good that they had you as insurance of sorts bc the way things stand you make no money and can disappear at any moment

I think they would have still been uneasy that he was a SPOF, even if he had charged a lot more. And there's also a cognitive disconnect if a one-man deliverable costs above a certain threshold.

What does SPoF even mean?

I could probably step into this system and be effective in it w/i a single month, probably less.

Is that a SPoF, or is the multimillion dollar system that no one understands well it's own SPoF?

Re: How boring should your team's codebases be

#220

Post by P5fRxh5kUvp2th »

jiggawatts wrote: post #204
osigurdson wrote: post #103

Earlier quoted context omitted.

>> deployed to over 2000 locations Were there 2000 independent systems / SQL server instances running or just one? 2K separate deployments to manage (with 1K users each), does sound a little scary. Of course, perhaps that is not what is going on at all.

I wasn’t clear in my description, unfortunately. This was a multi-tenant centrally hosted application. There were 2000 sites served, each with kiosk PCs and some associated special-purpose hardware. The actual application code ran in just four virtual machines in two data centres. No templates, no Terraform, no microservices, etc… Just vanilla ASP.NET on IIS with SQL Server as the back end. The efficiency stemmed fro…

Both approaches are valid for multi-tenancy, with their own pros and cons.
Post reply on HN