bgribble

I have been a fairly devoted user of Gtk in my Python programs for about 20 years. Back then, it was a clean, simple, functional toolkit that just worked.

Dear ImGUI cleans Gtk's clock in the "clean", "simple", "functional", and "just works" categories these days, and I am currently porting my biggest side project from Gtk to Imgui.

If you are trying to "integrate with the (GNOME) desktop", I'm sure you should still use Gtk, but for most purposes I don't see the point. It seems from the outside like there are few core Gtk developers left, and they are basically in life support mode for an entire desktop suite, one that is stuck between two broken display engines (Xorg and Wayland) with no way to really fix things and every desktop Linux user expecting miracles.

ImGUI is just a busy dude banging away on a single toolkit, without the baggage of millions of nontechnical users to support. As a developer, I know which one is going to be producing the good stuff.

In my anecdotal experience, there is a sizable chunk of people who stayed within a couple of hours drive of the city but moved farther out to save money. Towns up the Hudson Valley, Westchester, "Greater Woodstock", Long Island, Conn/Mass/NJ.

If the only reason you are paying all that rent money for that tiny apartment is so you can take the subway to work, and you can work from Yonkers over Zoom just as well, why not?

I was lucky enough to work in a small eng team with 1 full-time dedicated QA person. One of the very few coworkers from my long career that I have really tried hard to poach away from whatever they were doing after our shared workplace went bust.

Yes, part of the job was to write and run manual test suites, and to sign off as the DRI that a certain version had had all the automated and manual tests pass before release.

But their main value was in the completely vague mandate "get in there and try to break it." Having someone who knows the system and can really dig into the weak spots to find problems that devs will try to handwave away ("just one report of the problem? probably just some flaky browser extension") is so valuable.

In my current job, I have tried for 5+ years to get leadership to agree to a FT QA function. No dice. "Developers should test their own code." Yeah and humans should stop polluting the ocean and using fossil fuels, how's that going?

So given a start state and a library of valid transitions, it's easy to create a (target, path, destination) tuple that's valid (if you don't care what the destination is). It's easy to check if a (target, path, destination) tuple is valid. It's just really hard to find the path given just the target and the destination.

This sounds like it has properties in common with "multiply two very large primes to create a very large composite number". Could any of this math be used as the basis for a cryptosystem?

I may have misunderstood, but I did not read this as saying "S3 suspend works". I read it as "'Modern suspend' works, so I don't have to keep trying to get S3 suspend working".

That is basically the opposite of what you want. 'Modern suspend' is why you burn battery with the lid closed, overheat your laptop when it's closed in a backpack, etc. It sucks. It's not sleeping in any real sense and can power up to full power if a fly farts too close to the microphone.

For better or worse (worse IMO), I think that what we knew as "suspend to RAM" or S3 is gone forever. It was apparently just too hard to get working reliably with all the peripheral hardware and they gave up.

Everything I have read says that for any recent laptop, if you want reliable suspending that won't burn battery you have to always "hibernate" or "suspend to disk". It takes longer to start back up but initializes all the peripherals from "off" so it can be more reliable.

I'm still working with my older HP laptop that has legit S3 and am dreading an upgrade to a "modern" one.

Over the past couple of years the MTA's real-time data has gotten much, much better. Most stations have screens showing when the next train(s) are arriving, including signs outside the station near entrances. (now are they always working, that's a different question).

I live in Brooklyn and my local train (C) is one of the worst for reliability. It comes every 6-15 minutes during commutes, so it's important to know exactly when the next train is coming so you can hurry (or chill, if you have already missed the train!). https://mta.info is the "horse's mouth" and, while it's not a great UX, I much prefer it to going to any third-party repackager's app or site.

Just for finding your way around the city, no need to look further than Google Maps on mobile, which gives clear and reliable subway directions, including scheduled service interruptions. The only asterisk on that is that temporary service interruptions are not always taken into account for finding directions, but mta.info will always set you straight.

The one python pattern I used to use metaclasses for (registry types that keep an index of all their subclasses, very useful for DSL type tasks) is easier with __init_subclass__ and is somewhat more readable. So I haven't used metaclass in a minute.

The worst thing about metaclass is that 95% of python programmers look at it and just go "whuzzat?" and require a seminar to catch a clue. It's actively hostile to whoever maintains the code after you.

It makes sense to me. We tax companies on the money they make in excess of what they needed to spend to operate, and deciding not to make a donation would have no impact on their income. I would not expect it to be considered an operating expense.

In personal income taxes, I have always seen the deductibility of charitable donations and (in the US) mortgage interest as being a form of social engineering -- donating to charity and home ownership are individual behaviors that the government wants to promote, so it effectively subsidizes them for most people.

Businesses are generally run to maximize profit so you could assume a deduction for charitable giving would be immediately weaponized by creating a charitable arm of the company and donating most profits to yourself, or something equally repulsive.

I have even smart managers look me in the eye and say things like "can we parallelize parts of this? let's map out the dependencies."

EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.

As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales. They indicate a management and product mindset that thinks you can pre-chew a developer's food for them and make things more predictable.

In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.

Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.

You have to be a "personal accounting hobbyist" to really make your ledger match up with reality. If you have even moderately complex finances, you will have to take input from several different sources, do a lot of preening of transactions that were imported a bit incorrectly, reconcile against external sources of truth like bank statements, and in general spend time keeping your accounts straight.

How much time you need to spend to do a good job can vary widely. It depends on your data sources, your tolerance for error, and how well your use cases match up with your software's assumptions.

Balance that cost against the benefits, which are subjective -- how much do you value easier tax preparation? How much do you value peace of mind from having your financial state clearly articulated? How much do you value understanding your in and outflows, making a budget, monitoring activity for potential fraud?

The yearning in this essay for an era of wise craftsman-philosophers building architectural monuments for the ages is just fantasy. It never was and never will be.

I remember great pieces of software from before the Internet era. The grammatical tense that applies to them is "past". They are dead and gone and only exist as "hey, remember Code Warrior?" "remember the LISP Machine?" "remember Lotus Notes?" Millions and millions of dollars, hours, lines of code all just gone. They live on as inspirations but not as artifacts.

The "cathedral" model doesn't produce cathedrals, it produces photos of cathedrals that were abandoned and eventually collapsed and were forgotten.

The bazaar has produced code that outlives its authors, its sponsors, its original communities. You can Tanenbaum Linux all day long but it will outlive the cockroaches. That's the real monument.

The hype gets pushed down from the C-suite because prospects are always asking "are you doing anything with ${latest}?" and the salesdroid has to answer "of course! we'll be showing a teaser in the next couple of months".

Then it gets pushed up from the bottom by engineers practicing Resume-Driven Development. Everybody perks up when a project using ${latest} gets mentioned in the CTO's office. Wouldn't it look cool to say I was a pioneer in ${latest}?

When it's being pushed from the top and the bottom, it's gonna happen.

Left out of the process is thoughtful/imaginative product design and innovation. Sometimes it happens but it's more of an accident in most cases.

> first read the error message clearly and try understand it,

Derail, but this right here is the key to debugging superpowers. I can't even count the number of times I have amazed juniors with my genius when all I did is read them the error message and ask them under what circumstances could that be true.

A corollary that's just as important is "believe the error messages - they are telling you the literal truth." Hard to believe how often we implicitly disbelieve what the compiler or runtime is telling us.

Just my take, but I think that if you care how you scored or what the scoring criteria are you are missing the point. This "quiz" is just a guided meditation on what LLMs are better and worse at and how that interacts with our expectations. I found it to be very thought-provoking and I learned a few things. I have no idea how I "scored".

And 1 millisecond at the speed of sound ≈ 1 foot as well

I have this dream scenario where they discover that the gentle swirling of a cotton swab in the ear canal stimulates the vagus nerve and has these tremendous health benefits, allowing the sanctimonious anti-cotton-swab-in-the-ear brigade to sit down and shut up for a minute.

I have 2 kids. Commuting took a huge fraction of the available time I could be spending with them and for them -- asleep 8, working 8, kids sleep a couple hours longer than I do, so absolute max of 6 hours on a workday I could spend doing everything I need and want to do with my kids and spouse. Taking 2 of those hours for commuting is not just 2/24 of the day, it's 1/3 of the total time I have available. Juice is not worth the squeeze.

My kid just graduated from a NYC high school that had a complete ban on phones in school. The kids checked in their phones at the front desk on the way in and got them back when leaving.

It was by no means watertight -- many (most?) kids had a "burner" phone that was dead or broken or whatever that they turned in (because nobody would believe a highschooler who said they didn't have their phone with them lol) and they kept their real phone. But at least the expectation was set that you can absolutely not ever be seen using a phone in class.

Overall I think it was a good policy. I don't think it's workable at large schools.

In NYC at least you simply can't tell families that kids have to leave phones at home -- they are an essential tool for safety and travel, especially for younger kids. My 12 year old can take the subway to school by himself, but ONLY if he has a phone in case he ends up in some wackadoodle situation where his train has gone express or is on another train line and he needs to call his lifeline (me!) to figure out how to work it out. But they do not need to have them in the classroom.

I like some aspects of it, mostly the ability to say, when someone asks for something to be done Right Now, "here are the things I'm committed to for the next two weeks. Which of them should I not do to make room for this new priority?"

I do NOT like the idea of a hard beginning/end of sprint, it's a pipeline stall.

I generally like to have something I'm planning, something I'm working on, and something I'm working through review on. If I have to be 100% delivered at the end of the sprint that means I have to budget to be finished with all work and just be sitting around herding PRs the last 2-3 working days.

We don't do sprint planning until the first day of the new sprint so I can't really start speculatively executing on next sprint. So I usually overcommit a bit just so I will have stuff in progress at the end of the sprint, and then just eat the PM stinkeye when we don't burn it all down.

> you know when you’re trying to use a decorative stud to hold up part of your house

"You" might know it in "your" creations, but in my career I am much more often working and reworking in other people's creations.

I think the point of the article is not that you should avoid using decorative studs as load-bearing elements, but that you should be aware that others may have done so before you came along.

This is an even more conservative position than the default Chesterton's Fence reading, which is itself dismissed by a lot of people as pedantically restrictive.

For me, the parent article resonates. I have definitely had ceilings come crashing down on my head when I removed a piece of "ornamental" trim (programmatically speaking)

My gen Z kids use it to mean something significantly worse than "average". If something is "mid", it's really pretty gross or unappealing.

Plug for one of the best algorithm textbooks, Skiena's "The Algorithm Design Manual". It clearly motivates algorithms with specific problems that needed them and how a good algorithm improves over a naive approach in real-worldish situations. Highly recommended.

As a developer, the "one big bulletin board" visual model that Figma promotes is one of the worst steps backwards in UX I have ever had to deal with. I am constantly zooming in and out and scrolling around trying to find anything. I hate it so much.

I find that the numbers are really helpful when trying to find related items. Things that are topically connected sort together and can be filtered by common criteria.

I use SimpleNote a lot for JD content and put the category in the title of each note. I type a piece of the JD number in the search box and it instantly filters down to relevant notes. Sort by title sorts by topic.

For me, having to produce my journals was a reminder that holding on to my notes means that I might need to give a deposition or testify about them. Engaging with the court system in any way is just not something I care to do if I can avoid it. So I re-examined the value proposition of keeping written notes.

If I was working in an environment where (for example) producing patentable inventions was part of the job, I would keep and retain solid lab notebooks in case they are needed to defend my employer's IP, and would write them every day with that purpose in mind. Likewise in a job where we have to follow ISO-style engineering processes in a regulated environment such as medical device software. That's not at all the same as keeping a journal of development for my own improvement... that's consciously creating an artifact so it can be produced on demand.

If I just keep my garbage notes in garbage files that I delete, I can use them while they are relevant and sweep up after, just as if they were post-it notes.

yw, I think I originally came across it on HN :) It's not perfect, but it's pretty solid.

The one way my personal system diverges from the original is that I have a 3-digit prefix before the 2-digit category ID. 001 is my personal recordkeeping other than creative projects and has its own category tree. Then 002-499 are creative personal projects (non-work software and music). Software and music projects each have their own category tree template. 500-999 are work-related; right now, 500 is non-software-project info related to my current employer (interview notes, admin stuff, blog posts, other writing) and 501-599 are major software projects. I am guessing 600-699 would be my next employer, 700-799 the next, etc.

I went to school as an EE and learned in college to keep written, dated lab notes in a notebook without removable pages (to be more credible as evidence).

I did this for years in my earlier career... there's something really nice about using a pen and paper to write down ideas and sketches. I've always felt it was the "linearization" of moving your pen through making a series of marks, one at a time, that helps clarify the thinking process.

Then I actually did get tangled up in a lawsuit, by shareholders against the execs of a startup I worked for, and had all my journals subpoena'ed. It was a harsh reminder that lab notes aren't really your own private sticky notes; if they are ever going to be used as evidence, they are better thought of as a continuous performance of Engineering Best Practices.

I basically stopped writing paper notes then.

I've started journaling my coding again, but electronically (mostly using plain text notes in files, with Johnny Decimal to keep them organized). It's just so helpful during the design and early implementation phase, or when working through a tricky bug hunt. But I usually delete them when I'm done with them.

The Simula One (https://simulavr.com) has been targeting similar productivity use cases for a while. I've been following it from a distance; I have to wear reading glasses for computer work now, and I would love to be able to focus on a virtual screen 2 meters or so away for coding etc. Whether I could stand wearing the headset all day is another question.

The Simula folks think that there's a lower limit of about 30 pixels per degree for something to be useful as a low-eye-fatigue virtual desktop. Their device meets that threshold but really nothing else currently on the market does. I haven't seen PPD info for the Apple device yet but I am interested to see where it falls.

The Simula is at a pretty similar price point ($2700 for the preorder, but it's not shipping yet and has a way to go before it's a reality).

Very familiar-looking to anyone who has been following the modular synthesizer renaissance. Modular synths are basically analog computers, just not well-optimized for precision in most cases. All the basic building blocks of THAT are available as modules from a number of boutique manufacturers.