stevecrox

It does but for the 90's/00's a computer typically meant Windows.

The ops staff would all be 'Microsoft Certified Engineers', the project managers had heard of Microsoft FuD about open source and every graduate would have been taught programming via Visual Studio.

Then you have regulatory hurdles, for example in 2010 I was working on an 'embedded' platform on a first generation Intel Atom platform. Due to power constraints I suggested we use Linux. It worked brilliantly.

Government regulations required anti virus from an approved list and an OS that had been accredited by a specific body.

The only accredited OS's were Windows and the approved Anti Viruses only supported Windows. Which is how I got to spend 3 months learning how to cut XP embedded down to nothing.

The team/organisations knowledge is a huge factor but its easy to fall into a trap where no matter what the problem is the solution is X language.

If I have an organisation that knows C# and we need to build a Web Application. I would suggest we need to learn Node.js and Typescript and not invest in a solution that turns C# into web pages.

Technical Leads are not rational beings and lots of software is developed from an emotional stand point.

Engineering is trade offs, every technical decision you make has a pro/con.

What you should do is write out the core requirements/constraints.Then you weigh the choices to select the option that best meets it.

What actually happens is someone really likes X framework, Y programming language or Z methodology and so decides the solution and then looks for reasons to justify it.

Currently the obvious tell is if they pitch Rust. I am not saying Rust is bad, but you'll notice they will extoll the memory safety or performance and forget about the actual requirements of the project.

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.

So I know thats a joke but...

With Java 11's inclusion of 'var' I have successfully copied JavaScript code into Java without needing to change anything.

I judge the direction Java is going in

It isn't a good move.

A domain name can cost as little as £10, similarly most email services cost ~£5-£15 per person per month. Its normally pretty easy to link a domain to an email provider and doesn't cost anything other than time.

If a company can't be bothered to implement the most basic online branding people will make their assumptions and some will filter your company out because of it. With the cost to implement so low (e.g. £160 per year), even the loss/gain of a single customer would justify it.

Society is complex, visting a country is different from living there an extended period of time and even then even small geographical distances can result in huge changes in culture.

For example if you started in London and travelled the M4 to Bristol and carried on through Newport and then Cardiff. You would find dramatic differences in housing costs, religiousness, sports played (e.g. football to rugby), views on public transport, job market, jobs people work, education level, favourite drinks, marriage, etc..

You could spend 3 months basing yourself in any one of those locations and derive completely different views on what is wrong with the UK.

Which is why the OP brushed this off as nonsense. It also isn't uncommon for Americans to go somewhere and suggest it would be miles better if it was exactly like the USA, which is why you get the ad hominem.

It would be like a British Tourist suggesting they don't drink enough larger or accusing themof being savages for putting salt in tea