Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

71–80 of 788 posts

Re: Software development topics I've changed my mind on

#71
post #68
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…

> the school of thought that says that the code is the design

There's such a school?? Seriously??

Re: Software development topics I've changed my mind on

#72
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

I think the line between minutiae and craft is drawn by the effect it has on the product you're creating. Method length makes your code more manageable, for example. Placement of line breaks, not so much.

At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.

Re: Software development topics I've changed my mind on

#73
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

Is it ironic that this comment has evoked a discussion on minutiae?

Re: Software development topics I've changed my mind on

#74

> REPLs are not useful design tools (though, they are useful exploratory tools) I disagree with this. I’m a Clojure dev, and most of the time, I use the REPL to iterate on features, fix bugs, and refactor, thanks to the fast feedback loop. I used to be a Java dev—oh god, restarting the whole app after every change made me want to shoot myself in the head. Now, I use the REPL to build what I want and then move on. Thi…

I'm a heavy REPL/interactive shell user so when I do Java I abuse the testing framework, basically I put my sketches in unit tests and run those. The feedback loop is pretty tight, close to what I get in some other languages, whatever happens behind the scenes in IntelliJ it's much shorter than a full recompile and boot.

Supposedly there are some Java shells around but I haven't tried them out.

Re: Software development topics I've changed my mind on

#75
post #2

> Java is a great language because it's boring [...] Types are assertions we make about the world This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. In brief for non-Java folks: Checked Excepti…

> adding it to your own function signature

This is precisely why they are so bad: checked exceptions must not be allowed to be used outside the package (or jar, or whatever, just limit it) otherwise they cause non-local build failures in all dependencies. They're fine if you are developing the artifact that's going to be deployed.

Re: Software development topics I've changed my mind on

#76
post #68
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…

architecture over implementation (for details).

Re: Software development topics I've changed my mind on

#77
post #68
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…

> the formatting and conventions of the blueprint

Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information.

I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenated together, how far beyond that you take things runs into diminishing returns. However at a minimum formatting changes shouldn’t regularly complicate doing a diff.

Re: Software development topics I've changed my mind on

#78
post #39
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy an…

Reporting as an Eclipse user of 20+ years, and a person who cares about the craft:

The choice for me is simple:

If I'm going to view the code I'm writing in a 80x24 terminal later on, I'll break that lines, and will try really hard to not get closer to 80 chars per line.

If that code is only going to be seen in Eclipse and only by me, I won't break that lines.

I omitted your other examples for brevity.

Having bigger screens doesn't make longer lines legit or valid. I may have anything between 4-9 terminals open on my 28" 2K screen anytime, and no, I don't want to see lines going from one side to another like spikes, even if I have written them.

Re: Software development topics I've changed my mind on

#80
> Objects are extremely good at what they're good at. Blind devotion to functional is dumb.

Maybe "mutable objects"? Maybe these were intended to be isolated statements? Personally I believe functional programming is great with objects too...

It is however true that many OOP-embracing languages tend to favor an imperative style. Scala is an example of a language that embraces both.

Post reply on HN