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.

Every engine is going to come with engine specific problems. You will also come against many general game development problems, for which the engines have come up with many different creative solutions.

I can't make it any simpler for you. You will waste a bunch of time learning stuff. The only way to avoid that is literally building your own engine that conforms to your expectations and assumptions, because noone else can do that.

There are so many invisible boring-ish problems. Ui, scaling, networking, instancing, level changing, loading screens, even scheduling etc. You need to learn to love the boring stuff, because it comes at a 10-1 ratio towards the fun-ish creative problems.

However it's best to start wasting that time today than next week.

Obligatory: Don't learn programming languages. Learn programming problems and which languages were developed to solve these problems.

Also, you say you've reached a reasonable level of fluency with javascript and python. What does that mean? Having a grip on the syntax is different than being comfortable with half a dozen libraries and building an application that solves real user problems.

If you're learning for the joy of learning that's great! But maybe then try something completely different than the C family of languages. Try Prolog or Assembly and try to make some applications!

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.

Using DI you can register multiple configuration providers with different priorities. What's common is to have an local.appsetting.json for development and have production setup with environment variables. But you can use any combination of providers.

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.

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.

Okay, I love these features individually. I loved it when moving from java to kotlin. However, I'm conscerned that these features create multiple ways to do things correctly in C#. Having one way to do things, has been for me one of the best features of C#. It makes it easy to read colleagues code accross generations and easy to onboard new guys.

I do hope we see these adopted quickly, but I hope the C# folks dot start shoehorning in new syntactic sugar for no good reason. The language is starting to get a bit arcane.

Man, micro-services really could mean anything...

We have used Godot for a application that labels large numbers of documents for ML training data. I've also used it to show my wife the couch she wants to put in our living will absolutely dominate the space and leave no space to have dinner comfortably.

IT operators and DevOps engineers have been a nightmare liability for security, governance and business continuity. The best-case scenario for a DevOps/IT operator is that you get a superhero that does everything and knows it all. All responsibilities and security privileges gravitate towards this role, and knowledge sharing becomes impossible. Lastly, it becomes impossible to track the thousands of out-of-band changes initiated by a DevOps team to an auditor or certifier.

Cloud engineering, feature management and IAC tools have made it way better for engineers to build and deploy self-monitoring systems. A modern software ecosystem can be deployed, updated and migrated on an automated schedule. It can be done, safely without any of the responsible engineers having direct access to environment secrets or sensitive data. All of these changes can be set under version control for auditing purposes. If given the option, any smart employer would prefer the option to invest in such a system rather than support a 24-7 response team.

There will always be a need for surgery on a production environment, but there's no reason that can't be a formalised incident. If you are having weekly incidents that require engineers to do operations work, then that's something that needs to be addressed.

We should all be working to eliminate operations work. IT operator needs to be a trusted security role, not a critical glue with all the keys that holds a system together.