They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engineering team for not delivering to their estimate.

It's good (maybe even indispensable) for some things. Please don't go "ketchup native" on my ice cream.

I take my first cup of coffee with a little tea-leaf reading based on the activity of the CEO and my former coworkers. If you ever see more than 5 connections reacting/liking the same thing you know that HR or marketing sent out an email about it.

It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.

What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.

I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).

The most positive metaphor I have heard about why LLM coding assistance is so great is that it's like having a hard-working junior dev that does whatever you want and doesn't waste time reading HN. You still have to check the work, there will be some bad decisions in there, the code maybe isn't that great, but you can tell it to generate tests so you know it is functional.

OK, let's say I accept that 100% (I personally haven't seen evidence that LLM assistance is really even up to that level, but for the sake of argument). My experience as a senior dev is that adding juniors to a team slows down progress and makes the outcome worse. You only do it because that's how you train and mentor juniors to be able to work independently. You are investing in the team every time you review a junior's code, give them advice, answer their questions about what is going on.

With an LLM coding assistant, all the instruction and review you give it is just wasted effort. It makes you slower overall and you spend a lot of time explaining code and managing/directing something that not only doesn't care but doesn't even have the ability to remember what you said for the next project. And the code you get out, in my experience at least, is pretty crap.

I get that it's a different and, to some, interesting way of programming-by-specification, but as far as I can tell the hype about how much faster and better you can code with an AI sidekick is just that -- hype. Maybe that will be wrong next year, maybe it's wrong now with state-of-the-art tools, but I still can't help thinking that the fundamental problem, that all the effort you spend on "mentoring" an LLM is just flushed down the toilet, means that your long term team health will suffer.'

Any code that's old enough to have its first birthday party is "legacy", which means that "legacy" is a completely useless category. Anyone calling anything "legacy" is generally just showing their own lack of experience.

When everyone can sit around one big table, you don't have to consciously polish your "brand" all the time -- most people have direct experience with you and base their opinions on that. You do good work and you will have a good reputation. If you have a conflict with someone who is a jackass or have a project that fails to launch, people know enough about the context to judge pretty fairly.

When there are hundreds of people on the engineering team, especially in a remote-heavy workforce, most people don't have direct experience with you and can only base their opinion of you on what they hear from others, i.e. your reputation. This goes for peers as much as leadership.

You have to be aware of how an org changes over time, and how things that were once not important are now essential skills for success.. and decide if any new essentials are skills that you are interested in developing.

I bought a Rivendell about 10 years ago and it's probably my last bike. Is a steel frame heavier than carbon? Yes, a bit, but I don't have to throw it away after a crash, it rides like a dream, and the weight difference is less than the extra "water bottles" I carry around my midsection. Most of the weight of the bike+rider (which is what you have to haul around) is the rider, not the bike, and the frame is just a fraction of the weight of the bike!

Even though new bikes are getting more and more proprietary, I don't foresee a time when I can't buy a new Shimano cassette or other replaceable parts.

As the tale went, he was sent out to this doomed-from-birth spinoff as a "sunset cruise" to basically force him into retirement (for this bad decision) without the bad publicity of a public head-chopping.

And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.

He came back a week later with something that was about 20k lines of Node.js, all just abstraction piled on abstraction piled on indirection, hundreds of files with like one line of code in each one plus a bunch of imports. "Separation of concerns" taken to the far extreme. 100% statement coverage by the horrible kinds of unit tests that you have to write to get 100% coverage.

TBH I feel lucky I came out of that episode with my job, and it wasn't even my code!

"Are you CERTAIN that the X-ray we are looking it is of the plaintiff? How would you know if someone else showed up and claimed to be them? Is your memory completely infallible?" etc... It might not be of any real significance but poor process can make one side look like they don't have their sh*t together.

I don't know much about this project and I have never used it. But in my experience as a developer and user of software I couldn't disagree more.

The longer something can stay a one-person project, the better! Nothing kills creativity, innovation, and velocity faster than having to make every decision by committee.

Big communities are great when a project is in its maturity and mostly needs tending and slow evolution. They mitigate the risk of a single developer getting bored and walking away, or turning into a murderous wacko, or attempting to monetize the project to death. Not naming any names.

But when something is being built from scratch? Give me a single developer with a fat internet connection, alone in a cabin in the woods with a shed out back full of Red Bull :)

Listen to the live recording "12 Nights In Hollywood" and you can hear that not only is she a beautiful singer, she's an amazing entertainer who came up in a very tough school.

I have never (yet!) gotten myself into any trouble, by following a very simple principle: if aptitude (dselect back in the day) wants to remove or hold more than a handful of packages, STOP. Undo what you just did, and instead of a bulk upgrade go through marking one package at a time for upgrade. When you hit one that needs major changes, if you can't find an upgrade alternative that is sensible, leave it un-upgraded and try again in a few days.

This time upgrade has been one of the more challenging ones to track in unstable, but patience and actually reading the reasons that dpkg reports for why it wants to do something has gotten me through it.

That said, as a developer I have basically had enough of GNOME, and I'm porting my personal projects to ImGUI. Does it integrate in the desktop? Not really. Is it pretty? No. It just is what it is (a library for GUI app development) and it doesn't try to be everything else that GNOME does.

If you take the money out of the company, that money can never be impacted by anything that happens to the company in the future, so the total amount "at risk" in the company is decreased.

This is, IMO, an overly simplistic take and I'm not endorsing it by explaining!