Speaking from a government contracting point of view: Nobody is going to pay you to rewrite existing code that's already working. Nobody. The customer doesn't give a flying shit about the implementation. He'd be happy with a box of diodes as an implementation, as long as it worked and came in on time and on budget.

When you're writing up your proposal for a contract or a grant, the theme should always be that you're "adding capabilities" (which should be well-defined and constrained) to the existing codebase. If you get the money, then you've got carte blanche to rewrite to your heart's content - just don't tell the customer that this is what you're doing. Just make sure that those new capabilities indeed make it into the re-write and that you introduce no regressions in the new code.

People don't tend to write tests for their Fortran code so the assumption that its already working and the numbers coming out are correct is a matter of faith.

But yes, no one sees it this way.

Writing tests for the the kind of numerical code that FORTRAN is usually used for is hard. Sometimes there is no direct way of testing it because if you knew any of the results already you wouldn't need to run the simulation in the first place. Quite often, the best that you can do is proper sanity checks like conservation of energy and momentum or things like that.

Yes, it's hard. But without an automated test suite checking the numbers coming out then any change to the code could introduce numerical instability.

As with any sort of big transition (changing e-mail, using a new password manager, changing programming language), the solution is always to do it incrementally.

For e-mail, I generally create a new one, and over a year or two, I create new accounts with the new e-mail and gradually move accounts until the old one is seldom used. Similarly here, it may be a bit tricky, and it really depends on how intertwined it all is, but gradually writing new pieces that you're adding in a new language, or using C++ for pieces that you're rewriting. eventually you'll be much closer than trying to do it all at once.

This gradual approach is what Mozilla is doing with transitioning Firefox to Rust. Parts of Firefox are already written in Rust.

The one thing that helps I think is writing of codes that are open source. Yes, it's a sticky point regarding getting funding, but in that imaginary world where you are funded well, transitioning to open codes (save the things that are...export controlled) would be beneficial for all of us.

I hate how I can't publish easily on modifications I make to our PIC code because it isn't open source; eventually I'm planning to switch to another code (and might implement a needed solver for it) just for the sake of my publications.

Depends on how similar the domains are. Stacks are vastly different in companies working in disparate domains -- I've worked as a software engineer in C4ISR, gaming, EDA, oil & gas, HFT, remote sensing, consumer electronics, and more. The stacks couldn't be more different & foreign from each other. Like living in different universes. Six months to learn all the moving parts is about right.

(I can't imagine a career in only one domain; how boring would that be? Hopefully will be getting a new job in HPC soon.)

Gerrymandering is an issue. Please see https://www.govtrack.us/congress/members/map, and zoom in on Austin.

Austin is a part of the following Congressional districts: TX-21, TX-25, TX-31, TX-17, TX-10, & TX-35. Of these districts, only one (TX-35) is Democratic.

On the other hand, Lamar Smith (TX-21) is one of the Representatives for the Bluest city in the state.

> > I'm not saying that gerrymandering isn't an issue

At least two of the districts you mention represent suburbs and not the city proper, which is what I was talking about.

No surprise there. Does anyone think of the Bay Area as anything more than a way station in life?

Yeah, well... we all make our choices. We, as Americans, have made the choice to live in a market economy, replete with all its pros and cons.

I see no problem here.

Maybe you'd have more interest if you wrote up a proper RFC.

This is collaborative effort. I act from my capabilities, but people with certain skillset are welcome to contribute with proper RFC.

> That's something like $10-20k per year, at most.

You are obviously not married.

> Which means you really only need to work 2ish days a week.

And where do you find these unicorn jobs where you work only two days per week?

> Surely the most direct way of buying time is by taking a pay cut in exchange for more time off, or even taking unpaid time off.

We don't get those choices. I tried for YEARS to engineer a long-term part-time career in the software industry, and I couldn't get it to happen. I'm perfectly happy to trade more free time for less money, but there are just no takers out there. The industry isn't interested.

As far as taking unpaid time off -- usually, that happens after you've quit your previous job and before you've started the next one.

I can think of two ways you can trade money for time as a SWE: 1) Amazon has started to offer part-time jobs for SWE's (https://www.flexjobs.com/jobs/telecommuting-jobs-at-amazon) 2) relocating from the US to UK / EU gives you 25-100% more PTO and shorter hours in exchange for lower salaries

1. Interesting, except the part where Flexjobs wants you to pay to look at job listings. Primary indication of a scam.

2. Yes, it is super-easy to get a visa to work in the UK or EU.

SkipTheDrive lists remote software jobs, and doesn't charge a fee for job seekers.

> You will work a lot more than you would if you just did things for yourself.

Nonsense. I would work no more nor no fewer hours in a given year regardless of whether I hired a plumber or mechanic. In fact, given that I won't adjust my work hours either way, then hiring people gives me more free time.

I may (or not) have a smaller bank balance, but that appears to be beside the point you're trying to make.