Hacker News Reader

Comment by spicyusername | Hacker News Reader

I'm not knocking the article, but endless aesthetic discussions like this are one of the reasons why I can't wait to leave the industry. The very definition of bike-shedding.

    compare acquire and take_ownership

Who cares!? Those are both great names for a function...

If you put 10 software engineers in a room, you'll get 10 different answers to any question. Every company you work for will be filled with endless "smart guys", ready to spring in to action and nitpick you to death about arbitrary things.

It's exhausting.

We need more languages that come with rigid rules for things like style, so we can stop wasting time and get on with solving problems.

View on HN

Naming things sensibly and doing so consistently is pretty important in designing software because names are relied on to convey meaning. Sensible naming helps people. Bad and inconsistent naming confuses people.

Naming matters more for interface types and APIs than for local variables.

"acquire" and "take_ownership" might be equally good names for an operation, but you should pick one and stick to it throughout the codebase. And it would make sense to poll other people about what they think is a good name. Especially if you don't really care one way or another. Other people may have valid perspectives or they may just be better at expressing meaning through names.

You can't really nail everything down in the official style guide for a language without it becoming baroque and oppressive. If you want to avoid bikeshedding, have a process in place for choosing naming conventions. Name someone as the arbiter. If consensus cannot be reached within a reasonable amount of time, the arbiter decides. It might help to keep a record of naming choices so people understand the reasoning behind why certain practices are chosen.

Most programming is a social activity in that multiple people will have to deal with the code. Not caring about something as essential as naming, and wanting to avoid effort because you don't care, can be seen as a kind of anti-social behavior.

On well functioning teams I've worked on, naming tends to not be a big issue because over time a team develops a common vocabulary. When in doubt, ask someone else on the team how they interpret a name.

I agree that consistency is what’s important. If almost everything in the codebase roughly follows the same API then it takes less effort for people to use the various parts

>nitpick you to death about arbitrary things

Yep, it gets tedious. It really grates on me when reviewers are willing to die on a hill over some minutia while the codebase is in tatters. Arguing over extremely minor duplication while there exists two, active, physical copies of an application in separate repos (a real example) is the most pennywise poundfoolish waste of time and it drives me crazy.

I once spent 8 months merging a codebase with almost every single function duplicated three times, and all that was required for each (most of the time) was another parameter, one conditional in function, and all 3 could be merged.

So I did that! And at the same time cleaned up the code, fixed bugs, and adding required new functionality, and all while merging in constant change from the main codebase.

After reducing a 1M line codebase to 280k lines, when almost done, after that 8 months, I was asked "how much longer".

My response of "a month for testing" was apparently too long for the new manager, who turfed all those fixes, including the new functionality.

And I wasn't even behind schedule, I was ahead.

Once abandoned, everyone just copy and pasted my changes... in triplicate, into the old codebase.

Which took 3 months, instead of 1.

Bah. A year of my life wasted.

Spending 8 months when the business value at the end was mostly improved velocity doesn't sound likely to be a good tradeoff, especially if this is done as a big bang effort which either succeeds holistically or fails. You might have better success in the future by finding ways to integrate maintenance improvements incrementally.

> finding ways to integrate maintenance improvements incrementally

To be fair, it's possible bureaucratic process got in the way. If their commit / deployment process didn't allow for any changes to hit the production branch until it was "finished" then there wasn't really an opportunity for them to increment.

That seems likely considering "the new manager, who turfed all those fixes, including the new functionality" suggests other organizational problems. If one month is too long for the new manager, the new manager's goal seems to be to "do things" rather than to "solve problems".

This kind of refactoring also greatly improves robustness and stability, very worthy if the company values those qualities in their product.

This illustrates the problem with this 'business value at all costs' perspective. Improved velocity is not the only or even primary takeaway from consolidating 3 mostly identical codebases into 1. There are so many benefits that I struggle to think of a decent justification for leaving triplicated codebases in play, based on what GP has described.

This is a great cautionary tale about what happens if you don’t continuously integrate changes in an incremental fashion.

It's a great cautionary tale of management dumbassery. (yes I am still bitter)

Did you maintain a separate branch for 8 months?

Yes, and merged in all edits.

Others are discussing incremental changes, that doesn't work well when underlying frameworks have significant breaking changes.

No everyone, I didn't choose the framework. No, I couldn't change it. No, I didn't choose the path.

While I know people are trying to help, suggestions starting with "you should have" aren't very helpful here.

> suggestions starting with "you should have" aren't very helpful here

But they might be helpful to others.

There are ways to do these large refactorings that allow for incremental changes, never checking in a commit that breaks the build and where tests are passing at each stage. Your experience doesn't sound great and I'm sorry that happened to you, but I just wanted to add this to say that it's not necessarily personal.

I appreciate what you're saying here, and that your comment is more tactful than others, but I also see why the the op would be frustrated with the responses.

The responses to far, to my subjective reading, imply that the OP did something stupid and that's why they were in that situation. Again, it's just a personal interpretation, but I don't think it's a far-fetched one, and I don't think we have the context to make that assumption.

I agree that it can be useful to highlight the possible pitfalls to readers, but it's my opinion that it could be done in a more empathetic and tactful way that highlights our collective lack of context while still providing general advice to readers. I also think it would tend to lead to a more nuanced and useful conversation for the same readers.

Yeah, I agree completely. Thanks for taking the time to share your thoughts and to contribute to this community, that we all hold so dear, with a soft touch.

Just another time where prepending your words with 'IMO' would help much.

My condolences. Looking on the bright side, your manager laid their cards on the table and revealed their competence pretty quickly.

As someone who gets mired in details, I can understand how it happens. It's so much easier to focus on something you can control and fix.

Not excusing or defending it, just trying to serve up a reason why it happens.

While I share your frustration, I think leaving the industry because of it is an overreaction. It's fairly easy to just ignore the aesthetic discussions and focus on solving problems. Whenever someone brings up renaming a function from perfectly_good_name_1 to perfectly_good_name_2 in code review, I immediately agree without discussion and move on with my life.

>It's fairly easy to just ignore the aesthetic discussions and focus on solving problems.

You probably know this but for discussion's sake: in many modern forges, your pull request can't be merged unless the comments have been resolved/closed. So you basically cannot ignore these "feedback" items; you have to engage the comment whether that means actioning it or refuting it.

I currently work with the worst pedant I've encountered in my career to date, and I can empathise with wanting to leave the industry.

> I currently work with the worst pedant I've encountered in my career to date, and I can empathise with wanting to leave the industry.

I have one of these too, one of my PRs received a comment on the third round of review about correcting a minor typo in a comment that was made years ago by someone else.

FWIW, we started using https://conventionalcomments.org a while back and found it to be a useful tool for making it easy to communicate what is an issue that needs to be fixed, a suggestion to consider, or a nitpick to optionally ignore.

It is still just a tool and does require the team to buy-in and utilize it, but we've found it helpful.

If the comment was in code you touched, this seems right. Typos affect searchabilty. If the typo was outside (but close to) the block you modified you shouldn't be required, and the team ought to have rules of engagement to state this.

It would be better for all if the pedant left the industry, but they typically have too much self-worth invested in an inflated perception of their expertise within it.

What is a forge in this context? Is that a name for a code repository website? I'm unfamiliar.

Regardless, I think that's just a function of your team and your dynamics that you've built up.

On the current team I'm on we for example don't require this (at least on GitHub its configurable), there is an understanding of nits, how to declare them and what that means, as well as an understanding of using request changes vs approve and so on. We've built this up by having discussions about what the purpose of reviews are (eg making sure your code is understandable by someone other than you), having a common understanding that perfect should never get in the way of good, etc.

We regularly have retrospectives where, if we were having issues with really bad pedantry, I would hope it could be brought up.

You're 100% right regarding the team and its dynamics. I came from (and led) a team that had strict PR, but the difference is that we had well-established 'rules of engagement' so to speak, and just being decent people meant tone was never a factor. Unfortunately the product was given the 'tools down' order.

It's.. quite different where I am now. Change requests for untouched/irrelevant code, tone problems, etc. I'd be inclined to try and 'raise the tide' but I'm just trying to leave instead for many other reasons.

Yep you got it. Forge, aka GitHub, GitLab, Bitbucket, etc

SourceForge being the prime example.

I'd like to work for a team where if you have ab aesthetic suggestion like this, you're only allowed to leave a comment if you also submit a commit.

So the "actioning" part becomes their work.

I advise asking him to stop, and when he doesn't leave 75+ comments on any PR he has.

These kinds of silly games become tedious when you're trying to get something done, not to mention potentially damaging to your reputation given that the audience is your colleagues.

Wikipedia editing methodology transfered to code edits, hilarious.

Indeed, indeed.

Maybe a more accurate phrasing would be, "Can't wait to retire and do literally anything else with my time, including writing programs with which I answer to no one about coding style.", Hah.

I agree that "Who cares!" should be the default response here, as long as it's clear, but I think some folks (especially in engineering) think that "more rules = more clear," or "if we encode all of this information in the variable name, the variable name will always be clear," which is an error in thinking this particular article seeks to correct.

I have actually been in the throes of battle with co-workers over relaxing our variable naming standards because they are too damn prescriptive, which (in my opinion) reduces code clarity, while also setting up conflicts between those who think code should be as clear as possible in the file versus those who think that we should follow the standard even though we know it to be flawed and produce overly-verbose code.

My core argument is very much "who cares as long as it's clear" but having a specific piece of ammo where I can say "here are several arguments specifically against our current style" may convince some of these folks to loosen up a little bit. The bike-shedding is indeed ridiculous; going back and forth in Swarm for days over names for code that has fundamental algorithmic flaws. Awful stuff.

Yeah it is unfortunate.

Ever dealt with a rotating code review that passes through multiple hands? It's funny watching the principal architect and technical fellow ask me to refactor my code again to remove the changes that the other one asked me to make!

I spent a month in one such code review.

No wonder management hates listening to engineers. If we have a good point to make, they ignore it because of the last 3 engineers who wasted time with stylistic, pedantic arguments.

What we used to do is announce in our team chat: "anyone around for a round of bikeshedding? I need to name a thing". The thing being named is usually not user facing, so it was more of a team building exercise than anything related to compliance or style. We would get it done in a few minutes and never discuss this name again, because we already had this discussion.

The actual names that came out of these exercises are generally pretty good, and often a shorter name would win over a longer one.

> "anyone around for a round of bikeshedding? I need to name a thing"

I have to come up with many names for things in code every day. I can't imagine the slowdown having to workshop every name would incur...

This is the kind of exercise can be done in the background while waiting for stuff to compile. It's also not for trivial things like private or local variables and such, so not really a frequently occurring speed bump.

An example would be a set of enum names that I need to share with my teammates, where it might be a lot of hassle to replace them all if we don't decide on proper names now, but any set of names would work.

I'm sure the names have different importance, though. A local variable name in a small method probably barely matters, whereas the name of a variable in a widely used external API matters quite a lot.

> We need more languages that come with rigid rules for things like style, so we can stop wasting time and get on with solving problems.

This is where I'm at now.

Decades ago, I was an "only spaces, no tabs" guy. Still am to an extent. But what made me more open was realizing it wasn't spaces or tabs specifically that mattered, only that code is readable, and consistently formatted code is more readable. Seeing things like `gofmt`, which mix tabs and spaces, and comes with the language? Your debate about spaces versus tabs is over, now we can get back to tackling real problems, and your code will be rejected at CI if it isn't run through the standard formatter. Same thing with `black` for Python.

Above all else, be consistent. I can understand hate for "standard" language libraries that have functions with wildly different naming schemes or input and output arguments that aren't consistent - those should DIAF (looking at you, PHP "standard" library). But as to the names themselves? Doesn't particularly matter much. Unless you're the Bruce Tognazzini of API design, you probably don't have anything of substance to back up why it should be "make_" versus "create_".

Consistency is table stakes. It doesn't override the need for good decisions, it's just the baseline. A consistently applied bad decision is still a bad decision.

Tabs vs spaces is a great example, since tabs are just better ( :) ). The attempts to control how others view the code are frankly bizarre. Why not go all the way and control the typeface, font size, and syntax highlighting by sharing code via screenshots?

Let everyone choose their preferred indentation size, it's not only polite, but also an accessibility concern.

> Above all else, be consistent.

Aren't you still doing the same thing though? You have your arbitrary rules and they're absolutely truths... until you change your mind about them. Except before the rule was "only space no tabs" and now it's "be consistent"?

Given how many people here are disagreeing except on "be consistent", I feel I'm in good company in having that as my rule. I'm not being inconsistent, I'm learning, growing and adapting. "Strong opinions, weakly held."

But yes, "A foolish consistency is the hobgoblin of little minds." The question is, what is "foolish"? I'm arguing against things like `strpos` and `str_rot13`. I'm arguing against having similar functions where argument order is inconsistent. These are the sorts of things that slow developers down and force them to check the documentation every time just to make sure they aren't introducing bugs by default.

> I feel I'm in good company in having that as my rule

I'm sure you also felt in good company about tabs or not tabs or whatever it was you liked.

Kindly cite a problem with admitting mistakes and growing and learning from them.

Then explain how consistency is a bad thing.

> Kindly cite a problem with admitting mistakes and growing and learning from them.

Nothing against this.

> Then explain how consistency is a bad thing.

This is a really boring conversation, because if I give a good example you'll just define consistency for that example not to apply. For example, picking the token case of naming functions in such and such way, it occurs to me that I don't really care if you break rules are long it's done in a way that doesn't affect the interface. If something can be considered an implementation detail, I don't care that it doesn't follow the same rules, as long as the interface doesn't allow you to see it. But then you'll just say something like "oh but 'consistency' doesn't mean a rule applies under any and all circumstances, there's always caveats" bla bla bla.

It's a boring conversation, my point is that you had a dogma, and now you have a different dogma. You think you're evolving, I think you're changing but not evolving in a bigger way.

>>Who cares!?

Serious devs care.

I was once at a software conference where Bjarne Stroustrup was givnig some presentations, and in the after-session questions, I thought I'd ask about something that had been bugging me about software design in general — I'd found myself spending what I thought might be excessive time to designing naming systems for the projects I worked on, and I wondered what he thought about spending time on naming conventions.

With no hesitation, he said "Not at all, naming is very important", and very useful to get right up front, even for solo projects, as good clear naming helps speed the entire building and maintenance.

So, yes, both "acquire" and "take_ownership" are relatively synonymous, but one will clearly be better and more consistent with the other in the context of your naming system. And this will matter to at least some serious devs.

(But YMMV; if you have tried it a couple times and found it doesn't help you a bit, then you probably shouldn't spend more time on it)

Automatic style formatters solve a lot of this discussion. Not all, such as the naming example here, but at least things like whitespace and line wrapping never have to be a discussion point again if you have the rule that whatever the style formatter outputs is what you use

A particular gripe of mine is the tendency for some code reviewers to nitpick code golf solutions that don’t really improve clarity, maintainability, or quality (and might arguably reduce them). Going from 40 characters to 30 characters for a functionally equivalent statement isn’t a win worth mentioning in my book.

Bikeshedding is prevalent in every popular area of human study, because it's easy to talk and write about. It's not representative of what matters to those who get the job done.

Bike shedding is not the problem here.

Attitude is, if I can argue with someone and have it in a fun productive way - even if we don’t tackle most important thing we should work on at the moment - it still might be valuable.

If I have to deal with smartass that nitpicks on variable names, he wastes my energy and any will to do further work for the day or if it is more heated and goes over some “Astro architecture” might even burn my willpower to do any work till the end of the week.

I don't mean to bikeshed, but you seem to be describing bikeshedding. Bikeshedding in practice is often accompanied with aggressive arguments because some (or both) sides just really want to be right about something, as a way to offset their real worry, despite neither choice solves their real problem. Although I guess it could also be a pleasant chat, why not.

Consider for example the bikeshedding society did on whether to distance 1.5m or 2m during COVID, and how precisely and how long to wash their hands. We had a ton of those. When people feel out of control they want to own a decision that makes them feel like they're back in control.

Programming is complex at scale. But bikeshedding about how many characters our lines, how many lines our functions, and how to name things is always there for us to argue about.

Oh and whether a class is truly single responsibility, that's an evergreen.

That's not bikeshedding. Bikeshedding is focusing on an unimportant but familiar aspect of a complex project specifically because one lacks the technical knowledge to discuss the important parts. Bikeshedding might involve nitpicking, but it doesn't have to, and one can nitpick without bikeshedding. Maybe a code reviewer is genuinely so inept they can't understand anything more complex than naming standards, but far more likely they're just a bit neurotic with regards to following standards.

The definition of bikeshedding is nitpicking unimportant details because the important details are difficult to figure out, discuss, or acknowledge. It doesn't specifically point out "ignorance" as the sole reason why bikeshedding occurs:

"The term was coined as a metaphor to illuminate Parkinson's Law of Triviality. Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively."

Source: https://en.wiktionary.org/wiki/bikeshedding

A form of "one-man-bikeshedding" is when you keep postponing important work, by constantly checking email, cleaning the house, or doing other unimportant busywork. You are not ignorant about what is important. But you procrastinate as it's much more difficult and painful to face it.

The same dynamic is present also in groups, where groups naturally tend towards endlessly debating nonsense, as it's easy-to-do busywork.

Weird that you put ignorance in quotes when I didn't use the word.

Again the point that I'm trying to make is that someone making a big deal out of standards is generally not a result of other things being "difficult to figure out, discuss, or acknowledge" but instead because some people genuinely care a good bit about sticking to standards.

Not surprisingly (as the OP), I disagree. Good names help people understand concepts; bad names confuse. Choosing good names is not merely aesthetics, it's bringing clarity, meaning, and culture.

That said, in this particular case, I think Russ could have chosen a better example. Neither "acquire" nor "take_ownership" are terrible. But when you're a language designer (like Russ), the names you choose shape people's code and their thinking for the next 10, 20, even 50 years. When you're a library designer (many of us are), it might only be a few years, but still.

I think as code reviewers we should take this as seriously as the context demands: for internal names and local variables, it's not too important. For public API names, very important. For language changes, extremely important.

Some good quotes from Bob Nystrom, author of "Crafting Interpreters":

"Names are the structure we impose on the formless sea of bits that is computing." http://journal.stuffwithstuff.com/2016/06/16/long-names-are-...

"For me, thinking about names is inseparable from the process of design. To name something is to define it." http://journal.stuffwithstuff.com/2009/06/05/naming-things-i...

I don't disagree that things like function naming are important.

I understand that it's important to think critically about the philosophical North stars of your work. This is precisely what it means to be an "expert".

I appreciate the work you're doing adding your voice to the discussion.

That being said, it doesn't change the fact that, for me, it's tiring working in a profession where nothing is "real". There is never going to be an end to these kinds of discussions, because everything is abstract, relative, and ever-changing.

Unlike many other professions grounded in the limitations of physical reality: carpentry, civil engineering, hair cutting, etc, Software Engineering is a house of cards of artificial abstractions. The tools and architectural patterns are mostly free from physical constraint, so they can change at will, and they do.

What is "good" is highly dependent on context, and in our case that context is fluid, changing along every dimension all the time, making it very hard to establish a shared understanding of any given problem.

This translates into a work culture where there is always room for debate about what to do, since there is almost never an objective best next step. And debate we do.

> Unlike many other professions grounded in the limitations of physical reality: carpentry, civil engineering, hair cutting, etc, Software Engineering is a house of cards of artificial abstractions. The tools and architectural patterns are mostly free from physical constraint, so they can change at will, and they do.

Interesting comment, thanks. It certainly puts your original comment in perspective, and I respect that position. I suppose this is related to the position that "computer science is more art than science".

I don't consider myself a great programmer, but I do think I do two things well. One is solve problems. Like a dog with a bone I become obsessive about figuring something out. The other is I don't care about style, and will happily fit the existing style. For me, it's consistency above all else. I agree completely with you that arguments around style are exhausting.

> For me, it's consistency above all else.

Entirely this. I have a preferred style when I'm writing my own code. When I'm writing code for someone else, though, I will roll with whatever the house style is[1].

I just want consistency and predictability. Once I know the naming scheme, I should be able to take a really good guess as to what any given function or variable name is by knowing what they do, and vice versa.

[1] I consider it a red flag if a company doesn't have an established house style. It matters not what the style consists of, only that it exists and is mostly adhered to.

The latter is probably a better name if there are other functions involving "ownership" (give_ownership, split_ownership, etc.), but otherwise you're right.

Yep, I've seen situations where the programmer goes for brevity, and then runs into problems in the future when they want to "be consistent"

take_ownership -> acquire (fine at first)

give_ownership -> unacquire (not even a word)

split_ownership -> halfacquire (complete nonsense)

then there needs to be a way to split ownership other than an equal 2-way split and you're fucked.

I haven't seen this exact situation, but I've seen stuff like this. And sometimes, I was the programmer.

Names should be as short as possible while still being meaningful AND keeping in mind future work requirements.

On a tangent, I'm always frustrated when as a developer, I don't learn much about the actual business. There's always a situation down the road where if you had known what the company was planning on doing in the next quarter, or couple years, you could have saved everyone some work by doing things differently.

unacquire

This reminds me of when some code was lightly edited to remove references to "master" and "slave", only to end up with a function "enminion".

"We need more languages that come with rigid rules for things like style, so we can stop wasting time and get on with solving problems."

I have the complete opposite opinion. Most software engineers are obsessed with style, and I don't think accommodating it is the right solution. I think the right idea is just not enforcing any stylistic rules at all (while obviously keeping the readability and maintainability-related rules) and just let everyone write code how they want, while forcing them to tolerate other people's coding, naming, brace placement, etc. styles.

> Who cares!? Those are both great names for a function...

The source code has two purposes - to be processed (compiled/interpreted) by software, and to be read by humans. While it is relatively clear what is considered good code for the first purpose, it is harder to say what it is for the second one.

An essay could be written in an elegant style or be full of clumsy wordings and hard to understand sentences, despite having the same meaning. The same is true for source code.

It is more of software self-actualization. Just like human would need food, water, shelter, before they move on to top of pyramid.

I agree software need to be basic error free, compilable, buildable and deployable before naming and structuring aesthetics becomes important.

> Who cares!? Those are both great names for a function...

Now the author has written many good quality working software systems, it is natural that they want to talk about next level things.

> If you put 10 software engineers in a room, you'll get 10 different answers to any question.

Again with the hypothetical dichotomies!

In my experience, getting N software engineers in a room produces exactly N different answers only if you don't allow them to debate further. If you do, the upper bound on the number of different answers seems to be is at least 3N.

I wonder if there are linters that can check if a method/function name starts with a spell-checked English verb.

Hmmm...no mention of business domain language. The main reason I want to leave the industry.

I mean we have AI that generates both the function and an appropriate name for it. If you lean into that paradigm, all of this is a waste of time.

Reply on news.ycombinator.com