I think you’re being a little pedantic here. Even if we assume "senior" is an arbitrary title, the article is still a useful description for how to be effective as an experienced engineer. The title is the least interesting part of it.
It’s only useful if you consider a single anecdote useful. For every OP’s example I can come up with at least 2 where you follow their advice and it goes south, most likely there are thousands engineers who can do the same.
It’s a typical pat on the back/confirmation bias article so whoever identifies with this specific opinion can feel good and close the tab with “yeah, I’m a real senior”.
The problem is that the alternative is usually only sites created only to chase affiliate revenue. At least on Reddit, there’s a _chance_ I’m reading something from someone genuinely sharing their opinion.
Uh, sure, maybe in a professional setting where you’re getting paid. But this was unpaid volunteer work. If, as a community, we start enforcing professional grade standards on people who are just contributing their free time to give us neat toys and tools, I kinda worry it makes the whole thing the whole thing less fun or sustainable. And if that happens, we probably stop getting these free toys altogether.
I heart-fully disagree. Being professional crosses the bounds of paid work and unpaid work.
It doesn't take much work to not leave a gigantic pile of trash behind you.
If anything, it's an even more a self-responsible thing to do in the OSS world, as there isn't a chain of command such as in the corporate world, enforcing this.
It's selfish to engage in group relation with other people building something without the conscious decision of continuity.
A job worth doing is a job worth doing well. Maybe I'm just a gray beard with unrealistic expectations, or maybe I care about quality.
Think of it as a non-profit club. If you volunteer to be the treasurer, are you then free to ignore everything and do whatever you like, just because you aren’t paid? Of course not. It’s the same with being a software project maintainer; you have willingly taken on some obligations.
If I put some code out on the internet and some other people find it and start using it, they message me we talk and I start adding things they suggest and working with others to improve this code. Then one day I wake up and don't want to do it anymore. At what point did I become obligated? When I published the code? When I first started talking to others about it(building a community)? When I coded their suggestions? When I worked with other coders?
If I strike up a conversation with you, and suddenly I don’t want to talk to you anymore, then what, if any, obligations do I have? Can I just stop talking mid-sentence and begin to completely ignore you? After all, I did not promise you a complete conversation.
Or did I, by engaging in a civil conversation with you, implicitly promise to abide by the normal social rules of etiquette, as far as I am reasonably able?
It is similar with software. If you, say, put up a web site (or even just a README.md) containing blurbs about how useful your software is, extolling its virtues, you are implicitly promising future updates and support, to the best of your (limited) ability. If you need to step away from the project, you are expected to do so in an orderly fashion (again, to the best of your – possibly limited – ability), announce it publicly, etc.
If you have no web site, but you have given similar indications in conversations, the same principle is applicable, but you have fewer people to notify.
> Who get to decide where the line is?
If a user can reasonably feel let down by your actions, or can reasonably feel that you have misled them, then I feel that a line has been crossed.
It's not like this kind of thing doesn't happen in the professional world - in fact, quite the opposite. The incentives to cut corners in a company are if anything greater than in open source, with pressure from management to meet the next deadline.
> I just think it's ironic that this advice is useless to junior engineers but unneeded by senior engineers.
That's a good way of putting it. The advice essentially boils down to "do the right thing, don't do the wrong thing". Which is good (if common sense) advice, but doesn't practically really help with making decisions.
Well, that goes to the heart of my point. I take pictures because I value how literal they are. I enjoy the fact that they directly capture the arrangement of light in the moment I took them. That
So yeah, if I'm gonna then upscale them or "repair" them using generative AI, then it's a bit pointless to take them in the first place.
I feel, generally, with an aging population + rising unemployment due to AI, we'll reach a crunch point that puts governments under immense pressure to increase taxes (probably on megacorps & the wealthy) more in order to fund welfare. The most optimistic, utopian, solution would be UBI and an artisan economy, but I think we all know that capitalism isn't kind enough for that to play out so we'll probably end up with something much more dystopian.
> we'll reach a crunch point that puts governments under immense pressure to increase taxes (probably on megacorps & the wealthy) more in order to fund welfare.
I don't see how even that helps. What you need to fund basic welfare is a large supply of basic goods (shelter, food, medical care). The basic problem with retirement of a lager generation than subsequent generations is a lack of labor/productivity. Those basic goods don't really respond well to just throwing money from tech companies/rich people at the problem, you need people to work to provide those goods and services.
The only way taxes help is if they discourage "unproductive" economic activity (SWEs and financial planners) so much that those people start working as nurses and construction workers instead.
Planes have just as much spaghetti code as anything else, the only difference is that it's extremely well tested (functionally) and verified spaghetti code.
I agree. I don't understand how people prefer buildroot. Buildroot feels like an adhoc system of glued together Makefiles, whereas yocto actually feels like it was built for purpose.
Yocto feels like a ball of mud duct taped together, but thankfully has good documentation. It reminds me of CMake. Buildroot is nice for relatively simple situations. Nixos is arguably better than both.
Their idiosyncrasies may look similar, but CMake has a much stronger skeleton of core algorithms and data structures for a build system than Bitbake. Specifically, as I mentioned in another reply, Bitbake does not model dependencies correctly. CMake does.
Can you elaborate a bit on the dependency-handling topic? I've always thought that Bitbake's dependency handling worked pretty well. It only has package-level granularity, but is quite good within that context.
Bitbake doesn't model all changes that affect packages, so after certain changes, some packages that should be rebuilt, aren't. It is especially prone to happen when changing Bitbake variables (example: MACHINE_FEATURES), and these are a quite common way to change things about the image being built.
reply