Readit NewsI 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).
Also programming needs to be redesigned from the ground up as LLM first.
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.'
As far as eye strain goes, I think there's room for argument: having virtual screens cinema-screen-distance away from you is less straining than something under a meter away, but only if the text rendering is up to the job.
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.
It's good (maybe even indispensable) for some things. Please don't go "ketchup native" on my ice cream.