577 karma · joined March 24, 2017
That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.
I barely have to do it, but imho, this is how software should work and what running a computer should feel like.
Mastodon and email are the closest I've felt to a distributed system that works, but for oss stuff ... I think we're getting closer, but it's still a very hard problem to solve.
I see it as part of the feedback loop, and it speeds up some of the mechanical drudgery, while not removing any of the semantic problems inherent in problem solving. In other words, there's things machines are good at, and things humans are good at - if we each stick to our strengths, we can move incredibly fast.
Once I get my footing, I can use them to generate more and more specialized code and ultimately get to a place where the code is good.
I see this a lot in the wild, though - as an honest question (not trolling!) why do people still shorten their variable names in place of having a terse descriptor ?
I'm learning rust while I'm doing this too, so it's been an experience. Fun, though.
I don't understand why so many engineers are like this.
1) Each PR (even if it's part of a larger whole) can be committed and released independently. 2) Each PR has a description of what it's doing, why it's doing what it's doing, and if it's part of a larger whole, how it fits into the broader narrative. 3) PRs are focused - meaning that QOL or minor bugfixes should not be part of a change that is tackling something else. 4) PRs are as small as possible to cover the issue at hand. 5) All PRs are tested and testing evidence is presented. 6) When a PR is committed to master, the final narrative in step 1) is the Git commit, along with the testing evidence, includes the JIRA ticket number in the headline, and the reviewer in the body of the git commit.
This way we have a clean, auditable, searchable history with meaningful commit history that can help reconstruct the narrative of a change and be used as a guide when looking at a change in, say, a year.
I suggest that a codebase should read like a newspaper. While there is room for op-eds in the paper, it's not all op-eds, everything else should read as a single voice.
Some people take that as being scared, but it's more like "you have to have made this work and tested it before putting it in."
I don't use it for work, only personal use, though, so ymmv.
I spent a ton of time doing support and engineering on a trading desk, where our SLA for an outage was somewhere in the range of 30 seconds to 5 minutes. Having super simple code that makes it easy to understand what the code problem is (if not necessarily the business problem) lets you move on with life and let the business keep moving.
Fantastic way of putting it. Know this is a low-effort comment, but that's a great way to describe why over-extending yourself outside of the context of the overall mission isn't a good thing to do.
Debian/Mint/etc. are all good distros, but if you're willing to step up the learning curve just a bit, I'd definitely suggest Gentoo. I've been using it as my daily driver for several years now and it's made me feel like I'm actually in control of my machine (compiling all your code with debug flags so you can attach gdb when it's behaving weird so you can write a patch?! And then submit it to get sucked into upstream!? Yes please!). There's definitely a little work up front, but it's without a doubt the best experience I've had with Linux and I'd recommend it if you're up for it.
My personal favorite mixture of style and implementation of these features is jefftk.com - simple, fast, but gives a ton of information in an unobtrusive way.