Nah, nothing like that. We explored shipping Proton for macOS early on, but decided it wasn't where we wanted to spend our time, so we removed it[1] to focus on Linux. There's only so many hours in the day, and supporting two platforms is a lot more work than one.
The title of the blog post is "A Series of Vignettes From My Childhood and Early Career". The heading for the first section is "The Death of Software Engineering as a Profession". It makes sense to me to use the title of the blog post, not one of the section headings.
> I started to become interested in programming around late 90s and I don't remember anyone floating the idea that OOP, libraries or IDEs will make programming obsolete as a profession.
The version of this hype that I remember from circa 2004 was UML[1] was going to make most programming automated. You'd have an architect that would draw out your problem's architecture in a GUI[2], press a button to automate all the code to build that architecture, and have a programmer fill in a couple dozen lines of business logic. Boom, program done by two or three people in a couple weeks, let's all go home. It uh, didn't work out that way.
You can read a lot more about all this by following the various links to concepts & products from Rational's Wikipedia page, https://en.wikipedia.org/wiki/Rational_Software (the Rational Unified Process page in particular brings back some memories). It wasn't badly intentioned, but it was a bit of a phase that the industry went through that ultimately didn't work out.
It's interesting that even with the rise of transformers, UML still isn't popular. I wonder if that, or some other visual way of representing specs, might make a comeback.
Almost all of the couple-hundred employees laid off at my company in the past year have been managers.
For me, I paid off all my debts, and I'm reducing my spending to build up a big stockpile to weather a rough period or large salary decrease. TBH I'd rather find other kinds of work than lean into AI tooling. It's so boring & demoralizing.
> 81% of executives say metaverse related technologies are inspiring their organization’s vision or long-term strategy
> 90% of executives anticipate an increase in the level of resources their organizations will dedicate to metaverse related technologies in the next 3-5 years
> $1T executives expect 4.2% of their revenues coming from metaverse in the next 3 years—a value of $1 trillion
If ever there was an argument that executives would be more productive members of society if they were flipping burgers, it's this website.
The difference is "for a given message M1". In the 2nd requirement, you may choose both M1 and M2. For the 1st requirement, you are given M1 and must find M2.
> One underappreciated thing about Windows 8 is that even if the start menu was ugly and blocked the entire screen, you could press the windows key, immediately start typing, and then press enter to somewhat deterministically pick the top app. This made it feel quite fast.
Decent operating systems support this, and have for decades. macOS has the spotlight search (cmd-space), and most Linux DEs have some form of it too (eg XFCE's appfinder).
OSX's command-space spotlight search has been degrading functionally (at least on my machines) for literally years now. It peaked around ~2012, when it would reliably search the full text of all documents on my local hard drive quickly, and not do anything dumb like "search the internet by sending whatever I typed up into the search field to the cloud."
Nowadays it fails to reliably search the full text of documents on my local hard drive, tries to search the internet despite my best efforts to prevent this, and often even fails to find a file ~/Documents/foo.txt when I explicitly search for the string foo.txt. This is uniformly true on several work Macbooks and a couple personal macbooks too.
Most Linux DE's it's even the same use of the Super/Win hotkey by itself. I do wish Linux distros would add an emoji picker with the Suler+. hotkey (matching Windows')... When it's there, I always forget the hotkey, same on mac for that matter.
Yes. I wrote a little image uploader script to easily upload images from my phone for embedding in web forums etc, and it strips out all the EXIF orientation and just converts it to the correct orientation. Aside from that I'm always having to fiddle with it in my image tools and hope every software I use supports it. It's such a crap feature. Just rotate the damn image, phones!
Wouldn’t that degrade the quality for a lossy format, especially if done repeatedly? I see why people would not want their phone to do that. If you’re uploading it somewhere that might not be supported it would be worth it but I don’t want my phone to silently degrade images that are just sitting in my gallery
Rotate it at capture time, before encoding. This would get rid of like 95% of these exif orientation tags. For images that need to be manually rotated after for whatever reason, sure I guess you have a point, though I'd argue the quality loss would be unnoticeable in practice unless you're like spinning the image in circles 100 times for some reason.
Pretty sure that any software from after ~2005 that supports image rotation, isn’t doing so at decoding time, but rather is decoding the image into a GPU texture buffer and then rotating the quad that texture gets applied to. Which should always be lossless for multiple-of-90-degree rotations. (Presuming that the image doesn’t depend on sub-pixel rendering tricks.)
Even without a GPU, the JPEG format itself allows for totally lossless rotation. It is also quite fast, and doesn't require reading and writing every pixel in the image.
There's something to this, although I think the idea needs some refinement. Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!).
The way I've seen it implemented at a small company I worked at before was to explicitly endorse the "20% time" idea that Google made famous, where you may choose your own priorities for a fraction of your working time regardless of the bug tracker priority order. Even if in practice you don't actually have that spare time allocated in your schedule, it does give you some cover to tell your manager why you are prioritizing little UI papercuts over product features this week.
> Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!).
Not really. It's hard to see the difference from the outside without actually digging into it first, but in my experience while there's plenty of "easy" bugs that aren't actually easy, there's also plenty of easy bugs that are actually easy and that apparently everyone else assumed they're not, or else they would have been fixed already :P
Easy bugs might exist at small and medium size companies, but when you are a $1T+ company, there is no such thing as an easy fix. Your change could have unforeseen side effects that take down some critical revenue-generating service that causes us to lose $millions. It's got to go through multiple code reviews, have unit and integration tests written, be able to show those test passing more than once, it may need to get reviewed by legal, it may need to get reviewed by security and privacy teams. And tons of other process overhead I'm not even recalling. Just getting a one-liner from an engineer's fingertips properly deployed into production could take months.
Whether or not you fix a bug weighs on the scale against the cost of all of the above things, the cost of time, the cost of these people's attention, and the opportunity cost of them doing something else. And these costs tend to not scale with the size of the pull request. They're fixed costs that have to be paid no matter how small an issue is.
I work at a BigCo, and occasionally get comments from developer friends about "Hey, why doesn't BigCo fix this obvious bug I reported! It's simple! Why are you guys so incompetent??" I look at the bug internally, and it's either 1. got a huge internal comment chain showing it's not as simple as an outsider would think, or 2. it's indeed trivial, but the effort to fix it does not outweigh the costs I outlined above.
> or 2. it's indeed trivial, but the effort to fix it does not outweigh the costs I outlined above
And if you devote a whole team to simple fixes, those costs stop being a blocker. So I still like the idea.
And maybe those costs are justified at scale, but what comes with that is your small bugs affecting tons of users, so they shouldn't be ignored for scale-based reasons.
> the "easy" bugs usually aren't actually easy (or else they would've been fixed already!).
This is a perfect expression of something I like to call Chesterton's Inertia. It's exactly the same as Chesterton's Fence.
What happens is that there is a mess on the floor, and somebody walks around it, maybe just because they were in a hurry, or maybe they didn't even see it. Somebody else walks in, maybe doesn't even notice the mess, just notices the faint trail that the last person left, and follows it. The next person walks in, sees a mess, and sees a trod path around the mess, and follows the path.
Years later, the path has been paved, has signage posted that doesn't refer to the mess, and has walls blocking the mess from sight. The mess has fused with the ground it used to just sit on, and is partially being used to support the wall. Every once in a while, someone asks why there's a weird bend in the path that makes no sense, and a old hand who's been around since the beginning tells him that the bend is a fence, and not for you to understand.
> Anyone who's worked on a real software product knows that the "easy" bugs usually aren't actually easy (or else they would've been fixed already!).
Well, could be many reasons, "priorities" is usually the reason I see as the top reason for things like that to not be fixed immediately, rather than "we looked into it and it was hard". Second most popular reason is "workaround exists", and then after that probably something like "looks easy but isn't".
I think the solution would be to stop consider "easy-but-isn't" as easy bugs, even if they might appear so. So the "easy bugs" team would have their worklog, and if they discover one of those bugs weren't actually easy and would need large changes, reject it and push it somewhere else, and start working on something that is actually easy instead.
Thinking about it more, maybe the better approach is the 2nd team works on the oldest tickets. That's an objective measure that has no surprises and more directly addresses the problem of long-standing issues that are sometimes embarrassing because they turned out to be easy.
But in general, I do believe that teams should be split on the priority issue in some way. If all you are doing is chasing the highest priority stuff, you're going to miss important things because priority isn't an exact science either.
reply