DevSecOps is all about process, I simplified my answer.

At a high level in software there will always be a review phase, where code needs to be built and pass tests (as a minimum). With Git being used by every organisation I have been involved in you will find the organisation/team will claim to follow a variation of ‘Feature branch Workflow’ with review happening at a specific point (Pull Request).

For the last ~10 years every organisation/team I’ve worked in/with has claimed to use a CI to verify the source code as part of that review phase.

In most dysfunctional teams that review phase will be broken, the fastest win is to bring in the CI. Static analysis tools are also impartial in how they review and useful in teaching people how to review.

I don’t say your project must build with no warnings, I say you project must build and I’ll have the CI point out where you have added warnings as part of review. When people complain I’ll point to their teams Ways of Working or an organisations Software Development Plan (or in one case a System Engineering Management Plan).

The sort of team that then chooses to disable this will do so because the leadership are undermining it (normally a team lead turns it off or tells them to just ignore it). There seem to be a few common reasons as to why team leads will do this but it isn’t something you can rationally debate with. The only solution I’ve found is to sideline the problem, change team culture and identify a leader within the team and hand it over to them.

Your talking about teams which are failing due to the environment, those normally understand what is wrong and the best approach is to be a good scrum master (e.g. run retro sessions, identify issues and work to resolve the environment problems with them).

You can’t fix a people problem with process.

For example I’ve worked in DevSecOps for 10+ years, whenever consulting my first step is to implement a CI that picks up Pull Requests, builds them and runs a code analysis tools (e.g. pep8, spotbugs, eslint, etc…) and have the CI comment the Pull Request. The idea is to get an understanding of the projects technical debt and stop things getting worse and ensure the solution ‘just works’.

Teams with huge amounts of technical debt will find a way to disable it when your not looking. They will develop all kinds of reasons and in reality the technical debt was created because of cultural issues in the team.

So I’ve learnt its important if you spot a team doing that, the solution isn’t locking it down the solution so they can’t disable it or more process. But forcing out the technical leader and sitting with the team and working out why each one is fighting the tool and not seeing them as an asset and teaching them to be better.

There will always be someone who is beating you in a metric (buying houses, having kids, promotions, pay, relationships, etc…) fixating on it will drive you mad.

Instead you should compare your current status against where you were and appreciate how you are moving forward

As for age

During university my best mate was 27 who dropped out of his final year, grabbed a random job, then went to college to get a BTEC so they could start the degree.

It was similar in my graduate intake, we had a 26 year old who had been a brickie for 5 years before getting a comp sci degree.

The first person I line managed was a junior 15 years older than me, who had a completely different career stream. They had the house, kids, had managed big teams, etc… honestly I learnt tons from them.

Can you elaborate…

I have looked after a few instances of Active Directory and basic user management involved multiple steps through GUI’s clearly written at different times (you would go from a Windows 8 to Windows 95 to Windows XP styled windows, etc…)

I much prefer FreeIPA, if I wanted to modify a user account it was two button clicks. Adding a group and bulk applying was the work of moments. You can setup replicas and for a couple hundred users it uses no resources.

The only advantage I could see related to Exchange Integration as it makes it really easy to setup Sharepoint, Skype & Email.

Sharepoint never gets setup properly and you find people switching to alternatives like Confluence, Github/Gitlab Pages or Media Wiki. So that isn’t an advantage.

Everybody loathes Skype and your asked to setup an alternative (Mattermost, Slack, Zoom, etc…). I am not sure how integrated Teams is.

Which really only leaves Email and I just can see the one off pain of setting up Dovecot as worth the ongoing usability pain of AD’s user control.

You realise Debian is the base distribution?

Ubuntu takes 6 monthly cuts from Debian Testing, adds some in house stuff puts them through QA and performs a release.

Linux Mint is produced by Cinnamon devs, similar to KDE Neon. They take the last Ubuntu LTS, remove many of the in house additions, add the latest Cinnamon desktop and release.

Cinnamon got upstreamed into Debian to make the process easier.

The person is correct in this isn’t a Linux problem, but relates to your experience.

Windows worked by giving everyone full permissions and opening every port. While Microsoft has tried to roll that back the administration effort goes into restricting access.

Linux works on the opposite principle, you have to learn how to grant access to users and expose ports.

You would have to learn this mental switch no matter what Linux task your trying to learn

Dockers guide to setting up a headless docker is copy/paste. You can install Docker Desktop on Linux and the effort is identical to windows. The only missing step is

sudo usermod -aG docker $user

To ensure your user can access the docker host as a local user.