Yup and I am getting sick of hearing this even on Arch Linux. Like, mofo, you could literally run a snapshot or backup before upgrading, don’t blame us if you’re yoloing your god damn computer. Windows have exactly the same problem too and this is why we have backups. Christ.
On my Arch Linux Install, I literally have a Pacman Hook that would forcibly run backup and verify the said backup before doing a system-wide update.
in case software have a nasty bug like deleting your data.
Laughs in isolated flatpak
… but seriously most of my userspace software cant even access my filesystem? So even if some software blows up i doubt it could do any damage.
The combination of nixos to have a practical unbreakable system and flatpaks to protect your userspace is pretty great. Highly recommend it. - But having backups is of course still advisable as a 3rd layer of protection, in case of hardware failure.
Might be true, honestly. I'm on NixOS using the proprietary drivers for my 3080 and 4090. No issues, took one line of configuration. I do have to stay on X11 unfortunately until Wayland supports the real drivers at least (though i hear that's being worked on, maybe already working?).
For all of NixOS' pain, it really does make some things awesome and simple.
Haha they’re just different ways of estimating the difficulty of a work task. Story points are a kind of estimate that are represented by a number. The larger the number the more difficult the task.
My company uses WAG (wild ass guess) time estimates where we have to actually say how long we think a task is going to take in a matter of days or weeks. It sounds fine but programming tasks are notoriously hard to estimate since you have to consider so many different factors. I’m especially bad at it so I’d much prefer just saying “this task is an 8 because it seems hard”
It’ll take 20 hours. Unless it’s harder than I thought. Or it’s easier than I thought. Or it’s exactly as hard as I thought except there’s one little thing that I get stuck on for 5 hours.
I recently estimated a task to take a couple hours but it ended up taking a week. Hadn’t considered having to update a bunch of other teams services with new proto schemas and making sure they were deployed before our own service 🙃
My team has being trying an approach where instead of story pointing, we break everything down into the smallest incremental tasks we reasonably can and use number of tasks overall as the metric instead of story points.
In theory it’s meant to be just as accurate on larger projects because the larger than normal and smaller than normal tasks all average out, and it save the whole headache of sitting around and arbitrarily setting points on everything based mostly on gut feeling.
Huh. That’s such a simple and obvious approach, I’m kinda mad I’ve never thought of it lmao. It seems like you’re essentially breaking everything down to a 1 (or as close as you can get it), which is probably a more accurate measurement anyways. Neat.
I remember reading a study done across some large organizations that showed this approach was more accurate than other estimation techniques. Makes sense to me.
When I teach story points (not in an official Agile Scrum capacity, just as part of a larger course) I emphasize that the points are for conversation and consensus more than actual estimates.
Saying this story is bigger than that one, and why, and seeing people in something like planning poker give drastically differing estimates is a great way to signal that people don’t really get the story or some major area wasn’t considered. It’s a great discussion tool. Then it also gives a really rough ballpark to help the PO reprioritize the next two sprints before planning, but I don’t think they should ever be taken too seriously (or else you probably wasted a ton of time trying to be accurate on something you’re not going to be accurate on).
Students usually start by using task-hours as their metric, and naturally get pretty granular with tasks. This is for smaller projects - in larger ones, amortizing to just number of tasks is effectively the same as long as it’s not chewing away way more time in planning.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.