421–430 of 788 posts
> 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…
Earlier quoted context omitted.
yes exactly, hence unchecked exceptions are the sane option.
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.
This list does resonate, but I’d make some tweaks to express things slightly better. For example: > Most programming should be done long before a single line of code is written I would say “most engineering should be done before a single line of production code is written”. Formalizing a “draft process” is something I’m really trying to sell to my team. We work in an old codebase - like, it’s now older than most of t…
The fact that you just summarized about an hour worth of argumentation from my last annual planning meeting with that one sentence has just destroyed me. I kneel.
At this precise moment in time, if anybody seriously thought the above was the way the process works or should work, they should be advocating for firing all the juniors and replacing them with LLMs.
Earlier quoted context omitted.
> Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. I started working in Java a few months ago and holy shit does this stick out like a sore thumb. Null checks cascade down from gods domain all the way to hell. But oop we missed one here and caused an outage lol add one more! So much wasted human effort around NPE, and yet, we sit around in a weekly meet…
C# half-fixes this with its nullable annotations. I say half-fixes, because the boundary between code that supports them and code that does not is leaky, so you can make a mistake that leaks a null into a non-nullable variable. If you build an entire program with nullability checking on it's pretty great, though.
Reality does indeed feel exactly like what you mentioned with C#, though. The annotation is going to be missing where it’s needed most unless something forces the whole project to use it.
I think this one keeps on being viewed as a % metric. You have 50% code coverage, 75%, 99.9%, 100%, etc. In that sense it is useless. Where I think code coverage has an enormous value is in showing what parts of your logic are/are not covered by test code. Being able to eyeball that and see where key parts of logic are not tested is extremely helpful and tends to get lost in these discussions.
After more than 25 years in the industry, and 10 years of retirement, I agree with pretty much everything on this list. A few things that struck me: - Don't get too fundamentalist about OO or functional programming. Each has its place. - "Spend time hunting for an algebra" is somewhat obscure, but truly excellent advice, and I have spend a lot of my career doing exactly that. That has never been time wasted. This con…
I’ve had the pleasure of finding a few of these over my career.
> 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
Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. - Java is a great language because it's boring That is if you write Java the boring way. A lot of Java code (looking at you…
> - There is no pride in managing or understanding complexity > Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. I interpreted that one as a suggestion to avoid welcoming needless complexity because of the false sense of pride it gives you to successfully manage that complexity. To give an example, I believe C++'s end…
There are modern languages trying to eat C++ lunch, like Zig and Rust, but you don't get decades of backward compatibility, and they are not particularly simple either. Rust in particular is one of the most complex programming language in use today, it could definitely be simplified by removing the borrow checker and lifetime things and make "unsafe" implicit, leave memory safety to the programmer. But it makes no sense because Rust was designed for memory safety and performance, which is a complex problem, and therefore Rust is complex.
> 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…
Earlier quoted context omitted.
They do caching themselves so that some of your queries via ORM won’t hit the actual db.
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.