Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

201–210 of 788 posts

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

#201

Earlier quoted context omitted.

Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.

IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style. Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt. I'd say that if you're manually formatting stuff with line breaks…

Be careful what you wish for. Sometimes leaving a line stupidly long is better for readability than awkwardly trying to break it up.

If you have five similar statements somewhere with only one exceeding the linter's line length, breaking up that one can lead to code that is harder to parse than just leaving it jutting out by way of an exception to the general rule; especially if it contains some predictable bit of code.

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

#202
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…

Let's talk about in the way you seem to interpret it.

Imagine if Blueprint A used imperial units while others used metric units.

That's what inconsistent code style does to you.

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

#203
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…

When people stress over the details I care, it's craftmanship. When they stress over the ones I don't care, it's nitpicking.

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

#205
post #163

Earlier quoted context omitted.

If you want to compare to artisans - they were stressing about details that customers see, details that customers don’t see were to cut corners on. Making fuss about indentation in code file is not artisanal. It is insane weirdo if we are charitable and if not clueless and childish.

Everyone wants a particular style. Except when they have to use someone elses style. Pick a style stick with it. Review it every 6 months to year to see if anything needs to be tweaked. If you hear 'we are professionals' you are about to see code that has 20 different styles and design patterns. I worked with one guy who could not make up his mind and changed the whole style guide about every 2-3 weeks. It royal made…

Ideally pick a style from a different large organization that you have no input in. Because the organization is large they will have put a lot of effort into it, but since you have no input you can just follow it without thinking. Sometimes an organization will make some really weird choices and you will be forced to change styles (google as rejected a lot of the latest C++ standard and thus their C++ style guide is not to be used elsewhere, but there are plenty of other good options).

Second best is to start a large cross company standards organization and only allow one representative per organization. Make sure there is a lot of process standing in the way of changes so that changes are only made when really justified (because most are not justified)

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

#206

> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions th…

Most programming is actually figuring out what already exists and what (and more importantly: why) the requirements are. This is best done long before a single line of code is written. I think the author is taking a wider view of "programming" than the actual writing of code as the end product. Some of the most important work I've done is spend the time to argue that something doesn't need to be done at all.

> what (and more importantly: why) the requirements are

Maybe in a startup? My experience as an IC in larger, more established companies is the requirements are dictated to you. Someone else has already thought carefully about the customer ask, your job is just to implement, maybe push back a little if the requirements they came up with are particularly unreasonable.

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

#207
post #79

> Typed languages are essential on teams with mixed experience levels I'm 30 years in now, and on balance, whilst they have clear advantages, I'm still not convinced that typed languages are essential, particularly for low level or module programming.

I think the sentiment was they help significantly when you have inexperienced programmers. (That has also been my experience)

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

#208
post #181

Earlier quoted context omitted.

remind me why they don’t work? because “throws Exception” propagates virally to every method in the codebase?

Because you can't capture the evaluation of a function as a value, or write the type of it. E.g. try to write a generic function that takes a list and a callback, and applies the callback to every element of the list. Now what happens if your callback throws a checked exception? It doesn't work and there's no way to make it work, you just have to write another overload of your function and copy/paste your code. Now w…

what is "it doesn't work" ? The exception is part of the type, so it doesn't typecheck unless all callbacks are of type "... throws Exception"? What's the problem with that? It's not generic enough, i.e. the problem is Java generics are too weak to write something like "throws "? (Forgive me, it's been 13 years since I wrote java and only briefly, the questions are earnest)

edit, so like `@throws[T <: Exception] def effect[T](): Unit` or something, how is it supposed to work?

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

#209
post #186

> Most programming should be done long before a single line of code is written This is the only point I strongly disagree with. I have been doing this for twenty years now and every time we've gone into something with a STRONG plan for how it's going to be built, it's ended up an inflexible nightmare when we inevitably end up having to work around things that were not considered in the design phase. The plan always e…

I feel like exploratory and iterative development is more necessary when requirements are unclear or when there is a lack of domain knowledge. Also obviously things like game dev require an iterative style.

For backend web dev though, I can plan it all in advance. I have done it enough times that there are rarely any surprises and I know the pitfalls. I am really just limited by customers not knowing their own requirements.

I really love the iterative style but the problem is that I never worked in a company that allowed for enough time for large scale refactors. They might promise you that but it will never happen. You have to get it right the first time around or you will have to suffer until the system gets rewritten in a decade or two.

Of course plans can absolutely be too rigid but I generally found that more planning results in better products.

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

#210
Strong opinions, but only telling them doesn't say too much for me.

Constructive criticism: tell the reasoning behind those opinions. I really believe that they are based on facts and experiences, so tell them! Only telling "after 10 years in the industry" may look like the argumentum ab auctoritate fallacy (https://en.wikipedia.org/wiki/Argument_from_authority)

Post reply on HN