Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

111–120 of 788 posts

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

#111

Post by maleldil »

secondcoming wrote: post #54
xnorswap wrote: post #35

Earlier quoted context omitted.

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style

This is what we did with clang-format on our code base. The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.

Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.[1]

[1] https://go-proverbs.github.io/

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

#112

Post by oytis »

latexr wrote: 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…

To me "craft" is about keeping code efficient, scalable, extensible, well-tested and documented. Code style is more about what naming convention to use, tabs vs spaces etc. - it's nice to have it consistent, but no need to spend more than 5 minutes arguing about it.

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

#113

Post by pjc50 »

v3ss0n wrote: post #86

>People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. This sticks out like sore thumb to me and I think you are coding solo for 10 years. If you manage to lead a team of developers or work with them you are screwed without linting rules and standardized code style. Even if they are applied it takes months to get to a get a team working in harm…

He's not saying you shouldn't do it, he's saying you shouldn't stress over it. The "run the language's standard formatter before commit and then get on with your life" approach.

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

#114

Post by bayindirh »

maleldil wrote: post #109
bayindirh wrote: post #61

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…

gofmt sorts imports within the block they are in.

I have a habit of putting stdlib imports, a line break, golang experimental (x) imports, a line break and external imports.

I just tested, gofmt orders imports within these blocks. If I won't use the line breaks, it'll consider it a single block and will globally sort.

golang also aligns variable spacing and inline comments to look them as unified blocks (or a table if you prefer the term) and handles indents. The only thing it doesn't do is breaking lines, which I think acceptable.

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

#115

Post by pjc50 »

fergie wrote: 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.

Unless you can happily deal with '"four" + 1' your language is typed. The question is whether you want type errors reported upfront or you have to wait to find them at runtime (necessitating high test coverage).

One of these days I'd like to see a "typed assembler". It still matters what the contents of registers mean, even if they all look the same to the instruction set.

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

#116

Post by skydhash »

cess11 wrote: post #74
ertucetin wrote: post #19

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

You either REPL or do TDD.

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

#117

Post by cies »

pjc50 wrote: post #110
cies wrote: post #90

Earlier quoted context omitted.

I think the size of the code base also matters: bigger size = having types is more important. There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.

> More advanced typing features slow down compilation even more. C++ is a bit of an outlier here. But really people should think of typechecking as shifting fault detection earlier in the process than runtime. It doesn't matter if your test suite starts slightly quicker if you have to wait for the whole thing to run to find something you could otherwise have found with types.

I agree. But the nice thing about types is that they are not an afterthought, but more a "pre thought". TDD tries to make testing a pre thought...

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

#118

Post by watt »

hliyan wrote: post #84
Retric wrote: post #77

Earlier quoted context omitted.

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

I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, th…

don't stress about it so much: look how many variations of plugs and sockets are for this one quite simple thing: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets

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

#119

Post by hitchstory »

imjonse wrote: post #56

> ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables…

Depends upon the ORM. Like all frameworks, a really good one is a significant productivity boost while a bad one is faworse than none at all.

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

#120

Post by atulatul »

vladde wrote: post #65

> Good management is invaluable. (I went most of my career before seeing it done well) I don't think I've ever seen good management. Anyone care to explain what that would look like?

A couple of indicators I have seen:

1. For a non-manager, an indication that there is good management (project, process, etc.) in place is that the management aspect sort of seems to disappear/ moves into the background.

2. Communication becomes efficient or smooth.

How is it achieved?

1. High level goals and metric. And incremental upgrades to those. I think people/ teams need to get comfortable with one set of those before you want to improve better those metrics. Jira story points and velocity are not good metrics.

2. A manager acts as a buffer. A manager absorbs some shock and filters some data/ emotions which would otherwise flow between one (ideally more) pair of layers: one above them and one below them.

3. One kind of non-sense (from many kinds) is that people- junior or senior- are 'trying to prove their value'. This is why some people speak unnecessarily in meetings, emails go back and forth, senior management chimes in on low level issues, etc. A couple of good managers I saw were able to limit that- over a period of time.

Post reply on HN