Man, this place definately has the vibe of an old timey BB forum. You recognise people in your replies like you used to. I find that I'm gawking at stats way less and I'm able to just talk to people. Engagement is way less, but maybe that's a good thing.

It's so refreshing. It feels like the old internet

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?

It's difficult problem to solve. Lemmy's stack is a bit unconventional. The rust backend is not idiomatic and the ui is based off a template of an isomorphic not-quite-react framework. Its not impossible, but it will take a while for alot of programmers come onboard.

That being said, there's more to it than writing code. Better bug reports, reproduction, updating docs and triaging/managing the issues is possibly more important than writing PRs. Don't be discouraged!

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.

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

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.

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

What I love most about Krazam is that in every video they make, you see the guy move up the usual tech career ladder xD

1. You need as many environmental reminders that you are doing work as possible:

• dedicated work place where you don't game or browse or do chores and taxes on.
• dedicated work time where you are allowed to do work.
• dedicated non-work time where you won't work and don't get to feel bad about not working on the project and avoiding negative emotions associated with the work.
• I have a dedicated work shirt only worn while at work
• figure out your attention sinks: music/podcasts/YouTube w/e and apply them strategically to signal that you are or are not working

1. Plan. Identify as many tasks as possible ahead of time and figure out what is motivational an demotivational. Motivation takes a nosedive once the low hanging fruit runs out.

• make sure to front-load the boring stuff and keep motivated by anticipating the fun stuff later. Please, Start out with the tests. TDD is a hack for ADD
• Ration your creative sessions. Once you feel you are plateauing force yourself create some novelty in the project.

1. Want and grit. At some point you'll have to grit it out. You have to make it clear to your brain that you want it. Make it personal. Want it not the way you want to have a cookie after dinner, want it the way you want to breathe. Don't even want the project, but want to prove to your brain that you are a rare capable human, able to start and finish a creative endeavour independently.

2. Make work time scarce and urgent. Having a child has done wonders for my creative output. I used to splurge 6 hour sessions kinda working on something..now I get maybe 40 minutes a day. An hour if I'm creative about it. But heck, does that hour get applied like nobody's business.

Hope this helps, best of luck!

First of all, thank you for sharing all of this. If more people shared difficult management challenges like this, we would all feel a little bit less like imposters.

The situation you describe isn't uncommon. I think most of us have had a stint in a shop or at least a period where we are asked to perform miracles. We are tasked with this with such confidence that it feels like we aren't up to it. This isn't true. The reason we are asked to perform miracles is because technology is miraculous for most people and the difference between an easy and an impossible project is completely opaque.

Now let me be clear. If you are having a bad time at your job, you should leave. Life is too short to stay with places and people of torture if you can afford not to.

But, if you are willing to give it a shot here's my assessment. The story you're sketching sounds like a turbulent time where the business is growing rapidly and/or has lost Engineering leadership. Engineering leadership is needed to to have realistic projects. If your job is to perform miracles, you will fail every time. What you can do is able to communicate realistic limitations to your stakeholders and negotiate consensus on what can be achieved. You need to create a situation where the business can sacrifice a 20% chance of taking 5 steps forward this quarter for a guarantee of taking a single step. A business that can't see the value in that is dead in the water anyway.

The engineers on the other side, need to have their priorities cleared and set. You need to recognise premature optimisation, hobby projects and resume fluff and put an end to them.

This has nothing to do with Amazon lambda and everything to do with communicating arguments effectively, creating relationships of trust with stakeholders and developers.

I won't lie. This role will cause alot of friction, but it sounds like the business has no one to tap on the breaks. In the end the real miracle would be to turn the boat around and have some predictability in the workplace.

It's just transparent. It feels like alot of lessons were learned from the broken abstractions of older ecs engines. It might not be as powerful yet, but the foundation is solid and it's easy to implement the more complicated stuff.

Also, dotnet 6 implementation is a breath of fresh air.

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.

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.

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.

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

Don't teach yourself complex software dev skills. Teach yourself complex software problems and learn how others have solved them in the past.

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

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.

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.

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

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

• Request sequences
• Authentication
• Database Schemas

1. Asses their personality

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

1. How broad are their technical interests

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

1. How deep does their knowledge go

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

1. 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.