Comments URL: https://news.ycombinator.com/item?id=48536419

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48524584

Points: 6

# Comments: 0

Among other things, she worked on mission control software for tracking rover-carrying spacecraft en route to Mars and related ground data systems (I'm probably getting the wording wrong, but that's my outsider understanding of it). Later she worked on software used to analyze interferometer data for exoplanet research on the Caltech side (again, wording?). I'm not aware of her ever being near robotics work.

Part of her shift to Caltech was to try to get to an environment where there was more predictable focus on the science, but a lot of the grant money there was from the same or related budgets as JPL's money, with plenty of strings attached that weren't always pulling in directions she was excited about.

I'm retired and can't justify spending too much on these things. CodeWhale over DeepSeek is helping me understand this space much better (and have some fun!), and it's quite affordable. I've spent ~30 hours using it over the last couple of weeks, and I've spent $3.89 on DeepSeek in that time. If I don't feel like writing any code for a few weeks, I pay nothing. Looking at DeepSeek's dashboard, about 60% of my requests have gone to Pro and 40% to Flash. I've used 97M Pro tokens and 19M Flash tokens (well over 90% of each have been cache hits, so the price is much lower than it would otherwise be).

I live in rural California. During the pandemic, a lot of people moved here and didn't last six months before leaving (I can relate, there's a lot I miss about living in SF!). There are so many services people expect, and they expect them to be prompt. We have the opposite of economies of scale in our small town. We have zero options for meal delivery. The nearest full size grocery is a 20-30 minute drive. Costco and Trader Joe's are a 90 minute drive. There are so few auto mechanics around that many of us drive 90 minutes for car service if we don't do it ourselves. Power outages often last 3-10 days. Large snow storms (4+ feet) typically make our roads impassable for 3-7 days. When the power goes out, internet follows 90 minutes later. There's no cell coverage inside or out, even when the power is on.

All of that is worse in almost all of Alaska. My brother worked on Alaska's North Slope for a few years - if you've ever seen the TV show Ice Road Truckers, that was his job. They'd fly him up north for a 1-2 week long shift, then fly him back to the little town he lived in for a week-long break. You have to worry about crazy things like hoping the summer doesn't get too warm, because roads will melt and collapse into what was previously permafrost. Uh oh, someone left a loading bay door in the warehouse open and now there's a polar bear in there breaking expensive stuff. Then you go home and can't go inside because a moose decided to go to sleep right in front of your door - better drive 50 miles and fuel up because you might be sleeping in your vehicle tonight and you don't want to freeze to death if your fuel runs out. These are all things my brother experienced. The pay was great, but he finally gave up and moved to Anchorage to drive a truck locally there.

The first big task was to find the common bits and abstract them out. It did a great job of creating a plan, summarized in a table, that gave a name to shared chunks, the line numbers in various files where they appeared, line counts of new functions vs. removed bits, and some pros/cons about splitting out each chunk. It was very well "thought out", so I told it to go ahead. It did a nice job other than straying from my coding conventions. That gave me a chance to build out my AGENTS.md file (it helped with that, too).

Once that was done, I had it create automated tests for the newly abstracted parts. I think this is probably a bad practice... I believe humans should at least define what the tests are testing so that there is a deeper understanding of what oversight is in place. But I was just trying things. It surprised me how well it did. The biggest surprise was that the tests seemed quite inspired by vision. It would try different parameters and then have comments about making sure the shape protruded in a certain way, then code that did that. I expected it to refactor a bunch of the code to make it more testable. It found a way to not touch the code while testing everything I asked it to with just two simple mocks - I hadn't foreseen that, but it felt quite practical. It was passing around several opaque tuples in the tests and accessing items in them by index. I prompted it to replace the first one with a frozen, kw-only dataclass. Then a second. On the second request, it saw the pattern and did the rest without me asking. It created 44 tests across a handful of files.

The next part is where I was the least happy. I use ruff and ty to check my code with almost all checks enabled. It was mostly good about the ruff issues. But for the type checking, it just wanted to disable 6-8 rules for the entire repo in pyproject.toml, or at least for all the tests. I had to repeatedly tell it not to and it kept telling me it wasn't recommended. When it finally gave in, it fixed most of the type issues (build123d has lots of types specified, but many operations result in type conflicts because things are so deeply overloaded). The things it didn't fix, it just left a comment to ignore type checking altogether on that line. After I did a little more brow beating, it finally changed the comments to only disable specific rules. To be fair, and unlike most of my other repos, I've had to spend way too much time getting types right in this repo myself.

My last task involved a small library management system for our little town library (tracking library cards, books, DVDs, check-outs/check-ins, etc.). I inherited it from someone who had built the entire web app out of bash/awk/troff scripts with the data in text files burdened by a lot of schema changes that he didn't really know how to deal with. I'm halfway through moving it to Python/FastAPI/SQLite. I asked it to do a security audit of the entire code base, both the newer parts and the old parts that are still in bash/awk/troff. It found everything I knew about and a few things I didn't know about. It made a decent assessment of the risks/impact of each issue. It also called out design decisions that were good security practices. One of the next big tasks will be to see how it does at continuing the migration - it has enough examples of how I've done it that I suspect it can do something fairly consistent with my thinking. I'll probably have it do one or two web pages. When I feel like it understands what I'm after, I'll tell it to use sub-agents to do the rest. I'll be very happy if I don't have to tease apart any more troff scripts that are generating PDF files!

So I just started trying CodeWhale (https://github.com/Hmbown/CodeWhale) with DeepSeek V4. I expected to be impressed by the abilities (which still require plenty of oversight). I didn't expect to be completely shocked by how cheep it is. After most of a week of using it 4-8 hours a day, which would amount to a full week of coding in many jobs after you account for non-coding activities, I'm about to hit $3 in total usage. So we're talking $10-20 per month for single-agent use by a full time software developer? And I'm sure some of my usage is waste as I'm still getting my head around things like compaction. If I take a break for a few weeks, I pay nothing because there is no subscription.

If DeepSeek and Xiaomi MiMo stay within a few months of the US-based models in terms of capabilities and US companies don't figure out how to drastically cut prices, I can't see how China hasn't already won. Protectionism would be one reason, but that might be ceding 50-90% of the total addressable market, and bring us closer to moving knowledge work out of the US the same way we did with manufacturing because it's too expensive in the US.

INDX no longer needs a tower. They say there is 13 milligrams of waste (which they call less than a grain of rice) on each filament change. So a print with 1,000 changes wastes 13 grams of filament. Details:

https://blog.prusa3d.com/prusa-core-one-indx-orders-now-open...

Comments URL: https://news.ycombinator.com/item?id=48283410

Points: 224

# Comments: 76

In the early to mid 90s, I worked at a Silicon Valley based software startup. We had something called "The Century Club". You made the club if you'd done 3 consecutive months in the last year without working less than 100 hours in any week of those months (averaging 100 hours was not good enough). More engineers were in the club than not. We were told that making the club was not mandatory, but nobody in the club was ever fired and most not in the club were eventually fired.

The next startup I was at had a similar culture without the cute name. I remember my most exhausting stretch there was coming in on a Saturday morning, for a database migration that had to happen outside business hours, and working straight through without sleep (other than nodding off at the keyboard) until Monday afternoon. Our CEO was kind enough to bring us food. Even in regular times there, I would go exercise from 10-11 PM, and more often than not I'd go back to the office after.

A decade later I was at Amazon. Our entire group of ~100 engineers was required by our VP to work weekends, in the office, for months at a time when approaching ship dates. The VP would send an email every Friday during this period to remind us to be there. Of course he wasn't there.

Those were all pretty counterproductive, but didn't seem that unusual. The difference in the US back then was that even asking about such things during an interview would often result in no offer because the candidate didn't have a "good" work ethic. Things have gotten a lot better in the US in the last 10-15 years, but a lot of that came from competition for talent. The more that competition eases, the more likely it is that we'll go backwards on this.

Relating back to the article... For the last 3 years of my career (I retired a few years ago), I worked 4-day weeks, and it was all remote. This is just as anecdotal as the article, but I felt I got far more done, with higher quality, than at any point in my career. It was such a revelation.

You're right that it has trade-offs, like challenges with linting. But many practitioners in these domains are experts in the area of science or engineering involved, not in software development. The ease of adapting an existing script is a big deal for many of them. Many don't even know what a linter is, and numexpr predates (by several years) the high quality linters like ruff that so many of us rely on today.

numexpr speeds up different kinds of usage than numba does. numba is best at speeding up non-vectorizable usage of numpy like repeated operations on arrays inside of for-loops. numexpr speeds up regular numpy expressions, like `5 * x + 7` where x is an array, by avoiding intermediate allocations. It calculates the entire expression for each cell, rather than doing each individual operation into intermediate arrays. It uses strings for expressing calculation so that Python will not break down the expression and hand it off to numexpr one operator at a time like it does with numpy.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

A decade ago, I was sitting in on a meeting about a rewrite and, before I could say anything, someone in the first year of her career asked why anyone thought a rewrite would be any cleaner once all the edge cases were handled. Afterwards, I asked her where she learned this. She said "I don't know, it just seems kind of obvious." She went on to be a great engineer and is now a great manager.