I get this a bit at my job, and I think there's a difference between making changes (which I do a lot of) and being confident in the changes that you're making. The environment I'm in is completely fault-intolerant, and we're currently hamstrung by our hardware (e.g. no backups/no secondaries/etc.) so changes that we're making have to be well-reasoned and argued before they're put in.
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."
Agreed. So long as the code hits performance and business goals, there doesn't need to be an emphasis put on "newness" or any other sort of vanity metric - make the code obvious, searchable, and understandable so that in a time crunch or during an outage it's easy to search and find the culprit.
despite the questionable politics of the author, I use mutt-wizard, and using its configs, a simple "v" instead of "o" will open the mail in the open web-browser. I've found this more than acceptable for reading html mail.
I don't use it for work, only personal use, though, so ymmv.
Do you feel like you shouldn't use it because of the author's politics? It's not like he gains anything from you using it. Even if he gained money from it I don't think there's any reason to believe he'd use that money to further those political opinions.
Noticeably it doesn't export Wayland to applications running underneath unless you enable an experimental flag, and half the reason for its existence is that it can be entirely bypassed by related Vulkan layer extension.
For me, the year of Linux on the Desktop was '94. It's been my main desktop at home ever since, and for wor as well the majority of time - but with some obnoxious detours.
Not advocating for 2024 (or 2025) but I still think someday it will, having seen multiple usability and feature improvements. (Not only talking about wayland here)
I go a step further on "dumb code". Write code that is easy to reason about, understand, and grok the implications of.
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.
For writing simple code, I often remind people that the first working code is not the one to commit.
Just like a text draft is edited, once the code works, now is time to trim it and simplify it.
> The truth is that most companies won't pay for the extra productivity that you create for yourself, but they will happily take it for free.
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.
I think that things like Agile are not an accurate model of problem solving and that making good software requires 'extending yourself outside', especially w agile or other modern management systems like many of us are working within. That is my experience. The actual effort is much more to make decent software that works and 'ticketing' makes it easy for devs to disown their own bad or incomplete work when it's convenient and can be disguised as working within scope. This bad work is then passed onto other devs (and the users) and/or converted to technical debt (oh look at all these bug tickets!)... When arguably the real and complete problem at hand was ignored because it was 'out of scope'. There is a 'shadow world' of work that exists outside of ticketing but is required to actually build the software. If you're not involved in that shadow work, then you may be a part of the problem. Problem solving is fluid and technical requirements and matters of approach aren't always readily available at 'groom time'. Work as a group, get uncomfortable if required, and don't go disappear with your ticket for two weeks and half solve a problem and bake the e2e tests. Most development work truly comes to a conclusion in a war room after the ticket is closed and with none of the original devs -- too much of the time these days. Reward devs for taking on more and owning parts of the codebase. AI threatens dev jobs because devs and scrum masters water down work and the system encourages shoddy, transactional work. Not really a criticism of the above comment ... But something I see a lot in enterprise software development. And I also do realize going outside of scope is risky and doesn't pay in the current management zeitgeist.
Another thing to mention is that if you find a way to do 8 hours of work in 4, almost no company will just let you take the other 4 for yourself, unless you do so quietly, so you have just created more work for yourself by becoming more productive.
Sure, but if you really did find a way to double your productivity, you can probably find a way to translate that into significantly higher income although probably not right away.
This is probably true, but if we are talking about climbing the corporate ladder here...that is primarily done through peacocking to management and networking well enough to get to the next rung, not through being very productive. If you are a 10x employee, why would a company want to elevate you out of that and into management?
But if you're going a different, more self-starter focused path, income opportunities should be increased, yes.
yep, companies thrive when they can steal as much surplus labor value as possible. you don't have to give them anything more that what you agreed to give them
Agreed with the sibling posts. Ubuntu isn't a great experience - it feels seamless until it breaks, and then it's just a world of pain.
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.
There's some of these that I think are overkill, sure, but I like the simplicity of some of them - sidenotes, progress bar, etc. Just little things that give you that much more information about what's going on. Gwern's page, to me, is too much.
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.
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."
reply