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.

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.

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.