Nexialist

It was a little tongue in cheek, but yes. I had large grievances with the software culture there, but after I got sign off on the project to modernise our build process, I couldn't bring myself to abandon ship in the middle of trying to fix it.

After everything was finished up, I was feeling burnt out and realised that I'd held on for too long at a company with a fundamentally bad culture that wasn't going to change just because the tech did, so I moved on.

My worst codebase story:

In my first real job, I worked for a company that maintained a large legacy product programmed in a combination of COBOL and Java.

In order to work on the Java side of the product, you checked out individual files from source control to work on, which 'locked' the files and prevented other developers from checking out the same files. This functionality was not part of our actual source control system, but was instead accomplished with a series of csh shell scripts you could run after ssh'ing into our development server.

Each of our customers had a 'master' jar file that represented the actual final compiled product (a jar file is really a zip file archive, which bundles together the resulting compiled java class files).

Once you had finished implementing your code changes, you ran another set of scripts which found the master jar file for each customer, unzips it, copies the compiled files from your local machine into it, and zips it back up again. Finally the source control lock is released.

This means, effectively, that the codebase was never compiled as a whole at any point in the process, instead, we just manually patched the jar file over time with individually compiled class files.

Over the years, small errors in the process allowed a huge amount of inconsistencies to creep into the codebase. Race conditions would allow two developers to lock the same file at once, or a developer would change a class that was a dependency of some other code that somebody else was changing. Sometimes code changes would make it into some of the customer jar files, but not others. Nobody knew why.

It took a small team two years to migrate the entire codebase to git with proper CI, and a huge chunk of that time was reproducing a version of the codebase that actually compiled properly as a whole. After the project was finished, I resigned.

The closest I have seen are the Oxide computer company RFD documents, many of which are public.

Example: https://rfd.shared.oxide.computer/rfd/0177

Main index: https://rfd.shared.oxide.computer

The crux of Atkinson's argument seems to be that the upfront emissions from the manufacturing process, and shorter lifespan of electric vehicles, does not make up for the reduction in tailpipe emissions.

Is this true? I know that the Tesla Impact report [0] refutes this, stating

> "While EVs today still emit more greenhouse gases during the manufacturing phase, including emissions from the supply chain, it takes less than two years' worth of driving before the total emissions from an EV fall below that of a comparable ICE vehicle."

but it's hardly an unbiased source.

[0] https://www.tesla.com/ns_videos/2022-tesla-impact-report-hig...

EDIT:

Since posting, found some of the sources that were linked by the guardian follow-up refuting Atkinson's claim:

- The IPCC Mitigation of Climate Change report [1]

- The ECIU "Energy price shock and the transition to electric vehicles" Report [2]

- Ricardo Energy & Environment report to the UK Dept of Transport [3]

- Carbonbrief factcheck article [4]

[1] https://www.ipcc.ch/report/ar6/wg3/

[2] https://eciu.net/analysis/reports/2022/global-momentum-the-e...

[3] https://assets.publishing.service.gov.uk/government/uploads/...

[4] https://www.carbonbrief.org/factcheck-how-electric-vehicles-...

If you'd like to read more about the roots of Effective Altruism, ranging from old mailing lists, LessWrong, bitcoin, cults, AI and the surprising connections to many well known figures in tech, I highly recommend the 7-part Extropia's Childen series from Jon Evans [1]

1. https://aiascendant.substack.com/p/extropias-children-chapte...

I'm generally bearish on AI, but I do feel that there are going to be a surprising number of applications where 'good enough' results are actually perfectly fine.

In particular, a couple of industries that I think are likely to get disrupted in the next few years are stock art, and the art-by-commission scene. The ability to use a Stable Diffusion + Dreambooth style setup to easily generate new artwork in the style of your favourite artist that's "good enough" is incredibly powerful.

Doctors and Programmers? Not so much, for now.

Slightly tangential but I've worked for several companies now that use `make` as a simple command runner, and I have to say it's been a boon.

Being able to drop into any repo at work and expect that `make init`, `make test` and `make start` will by convention always work no matter what the underlying language or technology is, has saved me a lot of time.

A paper I read recently (Harper 2016 - 10.1089/space.2015.0029) has numbers based on the supplies needed to the ISS.

The gist was, "Without some sort of recycling and/or use of in situ resources, meeting the lunar settlement goal of 100 people would require delivery of over 1 million kilograms of life-support consumables per year."

And then assuming a PLSS life support system you get to to needing about 5500kg of consumables delivered per person per year.

[1] https://www.liebertpub.com/doi/abs/10.1089/space.2015.0029

Netflix also seems to take into account the language your profile is set to as well, so you may get more/different subtitle choices if you change your profile language. See https://help.netflix.com/en/node/101798

For myself, I would think that the best way to compel kids (and adults) to be more interested in learning and personal development is to relate it to their sense of identity.

People want to emulate their heroes and live into who they feel they are. The 'school nerd' phenomenon is one we're probably most familiar with; if you start seeing your identity as being a 'nerd' of the school, you tend to live into it even more. If you can somehow leverage that effect, it can be fairly powerful.

And then of course, just making learning fun, entertaining and a normal part of life and not just for school would certainly help. I read recreationally very early on because that was just normal in my home environment.

Overall, I'd worry less about making students feel good or bad over individual tasks, and pay more attention to fostering their desire to be the kind of person that needs to learn.

Earlier this year I spent roughly three months job hunting exclusively through cold-emails based on Who's Hiring posts (I'm in the London area). I applied for 10 positions (and got my 10th - at a fairly large media company)

Some numbers of reasons that I felt I didn't get through the hiring process at the positions I applied for:

* Company changed their mind hiring for the position - 3 cases

* Didn't get through due to insufficient experience - 2 cases

* Didn't get through due to for poor performance on the hiring test - 3 cases

* No response received - 1 case

These numbers are a bit flaky since in the end it's a combination of factors that results in a yes/no decision. But I tried to roughly divide them into what I felt was the main "deciding factor" of the interview process.

For background, I'm a backend / "full stack" developer with 5 years experience (Most of the places that I got filtered out for experience reasons were because I didn't have enough of Brand X, etc)

Although a lot of people are pointing out (correctly) that it's trivially easy to ignore a checked exception, it does at least do two things:

1. Signal to the calling programmer that some error condition can occur. For example having to catch SomethingNotFound tells them that it's possible that Something might not be found.

2. You just put in your coding standards that you must do something sensible inside of a catch block, and get a code checker to break the build.

I don't think anybody is trying to say that checked exceptions have "solved" the problem of people ignoring error conditions. It does at least give you an easily visible thing to point at and say "that's wrong" though.

You can already produce fuel on Mars itself using the Sabatier Reaction with technology available today, you have to bring along a little hydrogen but that's not too big of a deal.

Refueling on the moon requires an (almost pointless) web of infrastructure that balloons the cost of a mission, and more importantly, increases the time to carry out the mission.

Each US administration has a habit of cancelling the more ambitious NASA/JPL projects of the previous one, so if we really want to go to mars, it has to be a mission doable in as short a time span as possible, such as proposed by Zubrin's Mars Direct plan.

This can be a major pain for larger software projects. At work we have to contend with:

* A database so large that even a minimally empty one cannot be created from scratch in less than 10-15 minutes. This creates problems for CI, integration testing, etc.

* The developers spent a good chunk of the late 90s/2000s writing Oracle PL/SQL code; hundreds of packages and thousands of stored procedures with oodles of business logic.

* We store reports, pdf attachments and other documents etc all in the DB as well.

* Since we put so much stuff on the database, small problems and schema fudges tend to creep in over the years, which makes every customer database a little bit different.

* Oracle licensing can be very unkind and the upper management mandate that we can't use the oracle XE version even in development/testing.

We ended up using a combination of Flyway for schema changes, hand-rolled scripts to apply stored procedures and packages, and we had to roll a database provisioning pool as-a-service for developers, and it's still a massively janky and fragile setup. We really need better tooling for this.

The "12 Factor App" manifesto http://12factor.net/ is in the same vein as this, perhaps a bit more in-depth.

I like the idea of these guides generally. I think it'd be more valuable if they linked to example production code that followed the principles however, since there's no substitute for the real thing.

Come to think of it, I've never seen anybody write up any kind of index of (for example) Github projects that exemplify good design patterns for people to look at. Or some kind of recommended code reference list.

The actual on-board software of an aircraft is definitely given a lot of attention as far as testing is concerned, but unfortunately more indirect systems, such as maintenance tracking software, is treated pretty much the same as any other piece of software; which puts it down to the company that made it to judge how much testing they perform.

In my company, the management puts a higher priority on putting all available hands on rolling out new functionality than fixing bugs, in order to try and win new contracts from potential customers. Or at least that's their excuse, in my opinion there is no such thing as a low priority bug, no matter what industry you're in.

That's probably true, but the potential for a severe, un-recoverable issue is about as high. An aircraft is composed of hundreds of individually tracked components with associated information about how old the component is, how much it has flown, etc. Most of these parts have a mandatory expiration date at which point it is swapped out or sent for repair. A failure in the system which tracks all this data (which is what I work on) isn't quite as directly dangerous as, say, a bug in the on-board navigational software. But you can still end up flying around with an engine way past its intended expiration date far too easily.

This is nothing. I work for an aircraft maintenance software company. Last week I fixed a bug where the system would silently delete a maintenance task if you clicked the X button on a confirmation dialog instead of "no". This had not been fixed for three years.