Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

691–700 of 788 posts

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

#691
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.

In my experience when working on and/or leading a team, having good and clear code style/guidelines helps the members of the team understand other people’s code much more easily. It often also serves as much easier to understand historical record when looking at previous contributions. I find it’s best to leverage tooling that enforces team conventions so that programmers don’t have to “stress” about it.

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

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

No, they are saying that code style, minting rules, and other minutia are not the essence of the craft. Which I agree with.

You have to read between the lines to pick that up though, so your criticism seems valid.

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

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

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

Completely agree on all points. I used to have a style that I preferred and really wanted to use everywhere but nowadays I just throw prettier at it and take the defaults for the most part. I’ll take consistent code over mixed styles every day.

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

#694

Earlier quoted context omitted.

The way I like to use OO (usually not real OO, but rather class-based languages) is to minimize its mutable state. Often mutability is merely a lack of using builder patterns. Some state can be useful as long as it's easy and makes sense to globally reset or control. It's like writing a process as a construction of monads before any data is passed into it. Similarly a tree of processing objects can be assembled befor…

Exactly. Automatically adding getters and (especially) setters to a class is something I see far too often.

Agree on both of your takes.

I've probably written more Java than any other programming language during my career, and I've seen both good and bad ways of writing Java.

Bad java heavily uses lots of inheritance, seems to think little about minimizing exposed state, and (unrelated to this discussion) uses lots techniques I like to call 'hidden coupling' (where there are dependencies, but you can't see them through code, as there is runtime magic hooking things up).

Good java almost never uses inheritance (instead composes shared pieces to create variation on a theme), prevents mutability wherever possible, and makes any coupling explicit for all to see.

Good java still has classes and objects, but starts to look pretty 'functional'.

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

#695
post #239

Earlier quoted context omitted.

Maybe a new paradigm for code formatting could be local-only. Your editor automatically formats files the way you like to see them, and then de-formats back to match the codebase when pushing, making your changes match the codebase style.

It's a decent idea, but it's weird reviewing code you wrote in saying GitHub, it looks totally different. Imo not a show stopper but a side effect you have to get used to.

I’d like to think that GitHub would be able to display with my editor format settings.

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

#696
post #608

> ORMs are the devil in all languages and all implementations. Just write the damn SQL What are the main issues people run into with ORMs? I've used Django ORM for years and written some relatively large applications using it without much problems. Complex queries and aggregations can result in quite hairy code though.

I've seen and poked at a lot of the ORM-hating on here, and whenever I can get people to give specific examples instead of generic theory-level stuff, it's either not a problem in Django or Django has a fix you just need to learn about and use. The fixes have sometimes even been there for over a decade. It seems be leaps and bounds ahead of every other ORM out there.

The main problem is if you are not very careful it leaks its internals (ie. the relational model) into everything it touches. That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries. By carefully writing managers and having a rule to never use querysets anywhere else you can avoid it, but it requires everyone to understand this and all the Django docs and examples everywhere will just randomly drop a queryset into a view or do a `prefetch_related` because they know that some higher-level function is going to need access to that attribute (ie. coupling code together).

Ultimately Django just doesn't fully do the object-relational mapping. It maps single rows, but that's it. So it doesn't really support objects that contain lists or sets etc. Things like SQLAlchemy can actually map data from a relational database into plain old objects. Those objects can be instantiated (e.g. in tests) completely independently of the database. Notice how in Django you can't test anything without a database being present? Why do I need to store an object in a db just to test some method on an entity?

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

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

> Revered artisans are precisely the ones who care for the details.

Abhored obstructionists and covert saboteurs are also the ones that care for the details.

You need to care about right kind of details. Any specific linting is not that kind. Linting at all is.

Artisan without a proper sense could spend weeks exquisitely decorating a spoon with gaping hole in the middle. State of nearly all software is more or less horrible. Choosing the right linting rules is most often than not putting lipstick on a pig.

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

#698
> You have to actively invest in improving your soft skills (and investments pay back immediately)

I wonder how much of this can be qualified with "after you've been hired".

Between two university graduates with equal skills in technical interviews and splicing linked lists and recursive-descent parsing and whatever, if one has better soft skills, you hire that one.

The question is what you do between one who is better at soft skills and another who is better at doubly linked lists or group-by queries or docker orchestration or whatever tech you're asking about in the interview. Empirical evidence suggests you hire the second person and support and expect them to skill up once they're in.

If you have spare time at uni, working on both soft and techy skills is great, if you have to trade off opportunity costs, the advice I hear a lot is invest on the technical side first.

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

#699
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 have a lot of sympathy for the golang auto-linter here.

I can also understand the fuss better in indentation-is-structure languages like python.

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

#700
post #214

Earlier quoted context omitted.

To reduce your argument to its essence, you're saying typesetting is part of the craft of writing. I've yet to meet an author who believes this (other than enjoying editing their own work as output from a typewriter), and I think the same broadly applies to code. It's not that everyone thinks these things are unimportant, it's that caring deeply about doing them a particular way is orthogonal to the craft. It's somet…

More than one writer refuses to use a computer, preferring typewriters. Harlan Ellison learned how to repair typewriters after he could no longer find anyone to fix his. Stephen King wrote Dreamcatcher with a fountain pen. Authors totally obsess over details that seem irrelevant to people outside that craft.

Those are tools you use to write, not typesetting. It's equivalent to wanting to code on paper or use a specific editor. Cognitive connection to tools is a real thing, and I know a number of authors who really can't form a mental connection with their writing if not using their tool of choice.

That doesn't mean it's normal for them only use a certain typewriter because of its typeface, insist a publisher use Garamond to typeset their book for publication, or refuse to write without a certain margin.

To bring it closer to programming, in collaborative writing especially (think manual writing at large corporations), nobody is insisting that everyone indents paragraphs their way because it's better. As long as there's consistency those matters are best left to the printer. When I was younger I knew a lot of technical writers who in fact really disliked the move to Word from traditional word processors, because they didn't want to be distracted by those things.

Post reply on HN