Live data from Hacker News

Donkey code

einarwh.wordpress.com

41–50 of 64 posts

Re: Donkey code

#41
post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

You think ‘Galois field’ is better than ‘finite field’?

Yes absolutely! As per my original comment neutral names are better. "Finite" has a meaning.

Re: Donkey code

#42
post #39
post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

I once inherited a codebase that did this, and it was a nightmare to learn. All the classes were named after types of alcohol for some reason. Naming things clearly is really hard, but this approach is just giving up completely.

I wouldn't want that for my math scripts, either.

Re: Donkey code

#43
Sometimes you want to identify things by type, and sometimes by capability. There is a time and a place for each. The article illustrates the case where capabilities were used instead of types to create complexity. It can go the other way too — web browser identification used to be based on naming the creature, but then shifted to capabilities.

Know both approaches and use the one that results in a simpler system.

Re: Donkey code

#44
There's nothing inherently wrong with `is_stubborn` or `is_short` flags in your schema, if that's the thing that actually matters.

But the `if` blocks given as examples in that post make it clear that there is business logic that cares about something that is higher than just those booleans – logic that is based on some other identity or flag.

An `is_donkey` or `is_mule` flag isn't necessarily any better – if you're determining e.g. whether or not the animal can be used in dressage competitions, a `can_compete_in_dressage` boolean would be better than looking for `is_horse`, or God forbid `!is_short && sound === 'neigh' && !is_stubborn`

Re: Donkey code

#45
post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Hard disagree.

Please everyone name it what it is, and don’t try to be coy or clever. Call it the metrics database, the example.com web service, the marketing tool, the data acquisition service, etc.

I really hate that most private code bases are named “Steve” or similar, in a sea of micro services with Stacey and Stans and then there’s Steve 2.0 projects, and the only thing they bothered to document in the readme is the origin story and maybe a cute meme picture to go with it. And all of those people are gone and I’m a new employee and it’s not funny anymore.

Everybody please just be serious, name it what it is, and document private business code like a professional. You’re getting paid so please take your job seriously.

Re: Donkey code

#46
It's not enough to have separate names, implicitly you must also treat them like separate entities and duplicate the code for horses into a separate donkey entity. While the code may be similar at first, changing business requirements means that donkey code and horse code will eventually have to be evolved separately and your future self will be thanking you for duplicating code rather than tangling everything into giant mess.

Write! That! Code! Twice! Then once you have more experience in the domain, you can refactor out the parts that are actually semantically identical. Code reuse should be proven, not a given.

Re: Donkey code

#47
post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

> This is the power of mathematics really.

In mathematics, things are never named "Steve".

Re: Donkey code

#48

Earlier quoted context omitted.

You think ‘Galois field’ is better than ‘finite field’?

Yes absolutely! As per my original comment neutral names are better. "Finite" has a meaning.

Yes — a meaning that fits. Since a finite field is, by definition, finite.

Why would having an entirely neutral name be better? A finite field isn’t a field that is in some sense finite or related to or inspired by finiteness in some mysterious way, it is quite literally finite (in the sense that all mathematicians use the word).

The danger of using existing terms like ‘category’ for new concepts is that they encourage the importation of lots of likely irrelevant associations and intuition that is likely to confuse rather than aid one’s understanding.

I definitely think your argument goes too far if you think the phrase ‘finite field’ is potentially misleading. You might as well demand that the phrase ‘multiples of 5’ be replaced with ‘fluffies’ because it has less meaning.

Re: Donkey code

#49
post #45
post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Hard disagree. Please everyone name it what it is, and don’t try to be coy or clever. Call it the metrics database, the example.com web service, the marketing tool, the data acquisition service, etc. I really hate that most private code bases are named “Steve” or similar, in a sea of micro services with Stacey and Stans and then there’s Steve 2.0 projects, and the only thing they bothered to document in the readme is…

And then the metrics database also stores the tracking timeline for physical deliveries, because the business decided that it had to cut corners and ship a feature urgently and they had just fired the CTO for standing up for quality engineering at the expense of velocity.

Re: Donkey code

#50
post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Please never do that.

Think of how you would explain things to some external or new person. Compare:

"You need to tune Steve so Lily doesn't get stuck".

to

"You need to tune the data collection service so the object storage service doesn't get stuck".

The first proposed variant is just ridiculous! Whereas the second variant gives you a glimpse of what's going on.

For the exact same reason you should not call your identifiers in code "liz" or "bobo".

Name your things what they are!

Post reply on HN