Audit logs and Access control paper trails.

Security event logging has to be:

1. Broadly accessible
2. Write-protected
3. offering some proof of completeness.

These three requirements are tricky and often conflicting. Block-chain might be an inefficient way to achieve these, but the glove does fit quite neatly.

Logistical paperwork

• Purchase Orders/Invoices and packing slips
• Waybills/Bills of lading and CMR's

These kinds of documents require multiple stages of matching and approval by untrusted 3rd parties. There are dozens of ecosystems of interacting systems that support processing these documents, but most people still use paper. Paper is more reliable when you need to deliver a container full of diapers from Poland to North Sudan. It's more reliable but incredibly prone to fraud and forgery. Having all of these approvals and transactions tracked on a blockchain and letting different systems interact with the same chain, would make it possible without each ERP having a rest API to each other ERP.

This is a bit of a narrow view of a very vague term. Having worked with many different sizes of organisations i can say that the responsibilities of whomever is labelled CTO are completely arbitrary. The only thing you can establish is that they are the person accountable for the technology decisions.

Sometimes that's a legacy developer, sometimes that's the first sys-admin.

Sometimes it's the VP of engineering.

Sometimes that's the person that maintains the best relationships with software vendors.

Sometimes it's the person that was hired externally to explain the tech to the CEO and let's them make informed executive decisions.

Sometimes it's just a public figure used to promote the org and maybe do DevRel.

Sometimes it's the Architect that designed the ecosystem.

Sometimes it's the ancient programmer that has kidnapped the entire codebase so that no-one else can sanely work on it.

Sometimes it's a six sigma type that setup the ticketing system, PRs and the release process.

At any size, the CTO is whatever the org needs him to be at that point.

I had been struggling with severe RSI for a few years and no one thing helped. I would try something out and the pain would return in a few weeks. What eventually completely solved my problem is variation. I have several working spots using different devices (traditional mouse, vertical mouse, thumb balls, trackballs, pen tables, touchscreens). I've made sure to just change posture and devices every few weeks. Ever since doing that, my problems have completely gone away. A mobile standing desk that you can adjust for squatting to slouching to sittin to standing and walking is great adds a ton of variation.

Inheritance is a fine abstraction. Easy to understand, but can't bring you very far. It's like a necessary evolutionary niche. It has its places, but it's most important as a gateway to get us to better abstractions.

some solid software system specifications. The kind of thing you might get from a client or stakeholder

🤔

In all seriousness, sounds like a fun exercise. Have you tried to contribute to open source? That doesn't mean just bug fixing, many popular projects accept contributions in issue tracking and QA. Many are great ways to get to know a new technology and solve novel problems.

All you folks are crazy not to unit test personal projects. Unit tests don't need to be fancy and exhaustive. A sanity check and having a simple way to execute isolated code is well worth the 15 minutes of setting it up. Heck, just use them as scratch files to try out libraries and APIs. I can't imagine having the kind of time to raw-dog that f12 button and sifting through print() nonsense all night.

You either start saying no to unreasonable demands, or you hire someone that will take the heat for saying yes.

So what we do is, between the first and second interview we have new candidates recreate Twitter over the span of a week. We stress that they can put in as much time into it as you want. By no means does the site need to be functional at all by the second interview. If they spend 30 minutes thinking about it and are able to have a decent conversation, great! 30h assignment is a bit much and a programmer with that kind of time, is a bit of a red flag actually.

The point of the assignment, for me, is not to have some barrier of entry for a candidate. Instead, I use the assignment to:

1. Have something to talk about
2. See how good they are at structurally dissecting the problem

• Do they get bogged down in details
• In what order do they attack the problem

3. Are able to effectively communicate some basic concepts around web-development

• Request sequences
• Authentication
• Database Schemas

4. Asses their personality

• Do they want to try some new tech
• Do they polish

5. How broad are their technical interests

• Do they do tests, did they host the project, did they do something interesting with UI

6. How deep does their knowledge go

• did they use the right tools, do they have experience

7. Have room for some hypotheticals

• How would you do it in a team
• what would you do with a month of time

When you look at it like that, the project doesn't really need to be that complicated. A candidate may be able to fake a challenge, but they can't fake an interview.

Whenever possible, I've run projects to have zero downtime deployments. Multiple stateless instances behind a load balancer. Deploy one instance at a time, run a health check and move traffic to the fresh instances. Most cloud providers often have these out of the box. Database migrations are run well in advance. New functionality is hidden behind feature flags.

Zero downtime is nice, but the real benefit is that you force the teams to really think about deployments as migrations to accomplish this policy.

Your instrumentation and alerting need to be top-shelf you need to automate deployments fully, which means you can fully automate rollbacks.

The downside is that you have to build everything twice, deployments are slower and there is a significant descaffolding.

But that's a small price to pay not to be on call outside of business hours to deploy.

A single race condition is a tragedy. A million race conditions is eventual consistency.

If OP play their cards right they have a wonderful legacy support gig for life

Counter point. Sounds like a c-level pet project on steroids. It doesn't sound like anyone is planning a migration. So they are relying on a big bang.

Now... A question for the panel: how would you say big bangs on corporate software projects with actual customers typically go?