Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

471–480 of 788 posts

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

#471
post #214
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 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…

The prose writing metaphor also falls apart the moment one admits that prose doesn't have the need (and is actually very terrible at) working collaboratively, concurrently but not perfectly synchronized and continuously on the same body of text, ensuring at the same time that combined changes don't add up to unwanted/wrong semantics, even in the long term. Are consistent indentations, variable names etc. strictly required for that? No, not logically, but the real world in which our software must be built is resource constrained, so every minute I spend parsing weird formatting inconsistencies is one minute less I can focus on the actual problem that needs solving. Just use a formatter/linter everyone. And I promise I don't care how it's configured, as long as it's consistent across the codebase

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

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

I've never understood the ORM hate because a good ORM will get out of the way and let you write raw SQL when necessary while still offering all of the benefits you get out of an ORM when working with query results:

1. Mapping result rows back to objects, especially from joins where you will get back multiple rows per "object" that need to be collated.

2. Automatic handling of many-to-many relationships so you don't have to track which ids to add/remove from the join table yourself.

3. Identity mapping so if you query for the same object in different parts of your UI you always get the same underlying instance back.

4. Unit of work tracking so if you modify two properties of one object and one property of another the correct SQL is issued to only update those three particular columns.

5. Object change events so if you fetch a list of objects to display in the UI and some other part of your UI (or a background thread) add/updates/deletes an object, your list is automatically updated.

6. And finally in cases where your SQL is dynamic having a query builder is way cleaner than concatenating strings together.

For those who are against ORMs I am curious how you deal with these problems instead.

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

#473
post #422

Earlier quoted context omitted.

Doesn’t that just introduce a silent breaking change to your downstream consumers? That sounds worse. It sounds ok from a library authors perspective but definitely not from a library consumer perspective. A sane thing to do would be to do a version bump.

consider the standard library case - e.g. there's a new kind of exception because new storage or network technology demands it. you can't add it without breaking the build of everything everywhere effectively freezing the standard library version for people who don't have the means to fix their build. that's super duper bad.

1. The standard library is special in many ways, particularly because it often isn't shipped along with your product and you can't always control what version is used. Just because something is problematic for those libraries doesn't mean it it's a bad idea everywhere else.

2. The difference between altering your un/checked exceptions is not whether consumers will have to react, but how it shows up and how badly you will ruin their day. A checked exception is unambiguously better. It will immediately break their build at the same time they ought to be expecting build-breaks, and the compiler will give them a clear and comprehensive list of cases to address. In contrast, an unchecked exception may let them compile but it will break their business in production, unpredictably.

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

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

Reminds me of the equivalent you see so often about driving where people slower than you are morons, while those faster than you are crazy.

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

#475
post #181

Earlier quoted context omitted.

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…

Make the signature of your generic callback "throws Throwable". It's generic; it should never care about the specific types that the callback can throw. (Except that then you have to decide what your generic function is going to do if the callback throws an exception...)

In that case you can use the lombok @SneakyThrows annotation that converts a checked exception to a runtime exception

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

#476
Software development should also be seen from what stage the org is in.

Software development looks super different when the org is a startup vs when the market fit is established.

When you are a pre-PMF, you have to establish trust. You deliver fast, cut corners, make sure customer needs are met, value is generated. Nothing else matters.

When PMF is established. You have to de-risk everything. All your work is at stake. Then best practices has to be in place to makes things scalable, code quality matters because it is a proxy for enforcing standards.

I don't think Software can be seen in isolation. It has to be seen from thr orgs perspective.

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

#477
post #84

Earlier quoted context omitted.

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…

Construction and civil engineering have been unable to agree on global conventions and standards, and they have a multi-millenia head start over software engineering. The US may claim to follow the "International Building Code", but it's just called that because a couple of small countries on the Americas have adopted it. For all intents and purposes it's a national standard. Globally we can't even agree on a system…

I’d say that globally we have agreed on a system of units and measurements. It’s just the US and a handful of third world countries that don’t follow that system.

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

#478

Software development should also be seen from what stage the org is in. Software development looks super different when the org is a startup vs when the market fit is established. When you are a pre-PMF, you have to establish trust. You deliver fast, cut corners, make sure customer needs are met, value is generated. Nothing else matters. When PMF is established. You have to de-risk everything. All your work is at sta…

This. Engineers are hired to solve problems. Sometimes beautiful code and clean architecture are part of the requirements to solve the problem at hand. Sometimes… they aren’t.

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

#479

Earlier quoted context omitted.

That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip. But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.

I mean why should we expect soft ware to have hard rules? Flexibility is the point, no?

The rules are what make it flexible. The rules let me understand what the heck is going on in the code you wrote so I can change it. Code that is faster to rewrite from scratch isn’t flexible.

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

#480

Earlier quoted context omitted.

So, given the main issue with ORM is the object/relational part... ( https://web.archive.org/web/20160301022121/http://www.revisi... ) Why is caching not a feature in DB connection pools? I mean, most databases have it on their side, why not have it as an option for the same query sets prior to hitting the db, with configurable invalidations? Or is it, and I've just never thought to look for it.

That would be a result set layer, not a connection pool. Could make sense if you worked with rows, but if you use ORM, why mapping cached row again and again? ORMs cache hydrated objects, which seems to be more efficient.

Yeah, it was more to see if there were any benefits to an ORM that could be used without the, well "ORM" part :)
Post reply on HN