I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software.
When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team.
It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option.
The trick is to work this out VERY quickly!
However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal
I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.
https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...
Lololol
Edit: I'm already down one - for people that don't read wikipedia here are the 4 dimensions of alienation of a worker as listed in the wiki:
1. From a worker's product
2. From a worker's productive activity
3. From a worker's Gattungswesen (species-being)
4. From other workers
Edit2: People [in America] will moan about their jobs, their bosses, their dwindling purchasing power, their loss of autonomy, etc etc etc but then come back as champions of capital. You see it all the time - "my job sucks but entrepreneurialism is what makes America great!!!!!!!". I've never seen a more rake->face take than this (and on such an enormous scale). It's absurd. It's delusional.
To solve this, one can be an instrument for change. Network, band people together, evangelize better ways forward, all while not angering management by operating transparently.
Sometimes, that can work... up to a point. To broadcast real change, quickly, you really need anyone managing all the stakeholders to lead the charge and/or delegate a person or people to get it done. So the behavior of directors and VPs counts a lot for both the problem and the solution. It's not impossible to manage up into that state with a lot of talking and lobbying, but it's also not easy.
I'll add that technological transformation of the workplace is so hard to do, Amazon published a guide on how to do this for AWS. As a blueprint for doing this insanely hard task, I think it holds up as a way to implement just about any level of tech change. It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow. https://docs.aws.amazon.com/prescriptive-guidance/latest/clo...
That describes so many projects that I've seen, over the years.
One of my first programming projects, was maintaining a 100KLoC+ FORTRAN IV email program, circa 1975.
No comments, no subroutines, short, inscrutable, variables, stepped on by dozens of junior programmers, and the big breadwinner for the company.
Joy.
It was probably the single biggest motivation for my uptight coding style, since. I never want to do to others, what was done to me[0].
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
* The team used a monorepo for (nearly) all its code. The upshots of this include the ability to enforce contracts between services all in one commit, the ability to make and review cross-cutting changes all in one PR, the increased flexibility in making large-scale architecture changes, and an easier time making automations and tools which work across the system.
* We used Go, which turned out to be a really excellent fit for working within a monorepo and a large-ish codebase. Also, having the Go philosophy to lean back on in a lot of code decisions, which favors a plain and clear style, worked out well (IMO). And its great for making CLI tools, especially ones which need to concurrently chew through a big data dump.
* Our team was responsible for integrations, and we took as a first principle that synchronous commands to our API would be the rare exception. Being async-first allowed us to cater for a lot of load by spreading it out over time, rather than scaling up instances (and dealing with synchronization/timing/load explosion issues).
* We converted the bulk of our microservices into a stateless monolith. Our scalability did not suffer much, because the final Go container is still just a couple MB, and we can still easily and cheaply scale instances up when we need. But being able to just make and call a function in a domain, rather than making an api and calling another service (and dealing with issues thereof), is so much easier.
* Our team was small - for most of when I was involved, it consisted of 3 developers. Its pretty easy to talk about code stuff and make decisions if you only have to discuss it with 2 other people.
* All of us developers were open to differing ideas, and generally speaking the person who cared the most about something could go and try it. If it didn't work, there would be no love lost in replacing it later.
* We had a relatively simple architecture that was enforced generally but not stringently. What I mean by that is that issues could be identified in code review, but the issue would be a suggestion and not a blocker. Either the person changes it and its fine, or they don't, in which case you could go and change it later if you still really cared about it.
* We benefited from having some early high-impact wins in terms of productivity improvements, and we used a lot of the spare sprint time to tackle ongoing tech debt, rather than accelerate feature work (but not totally, the business gets some wins too).
* Big tech debt endeavors were discussed and planned in advance with the whole team, and we made dilligent little chips at these problems for months. Once an issue was chipped away enough to not be painful anymore, then it didn't get worked on (getting microservices into the monolith, for example, died down as an issue once we refactored most of them).
* Tech debt items were prioritized by a ranked vote made by everyone, using a tool I built: https://github.com/liampulles/go-condorcet. This did well to ensure that everyone got the opportunity to have something they cared about, get tackled. Often times our votes were very similar, which means we avoided needless arguments when we actually agreed, and recognized a common understanding. I think this contributed to continued engagement from the team on the whole enterprise.
* Our tech stack was boring and reliable, which was basically Postgres, Redis, and NATS. Though NATS did present a few issues in getting the config right (and indeed, its the least boring piece). We also used Kubernetes, which is far from boring, but we benefited from having a few people who really understood it well.
* We built a release tool CLI, and built reasonably good general error alerting for our system (based on logs mostly, but with some sentry and infra alerts as well), that made releasing things become easy. This generally increased productivity, but also meant that more releases were small releases, and were easier to revert if there were issues.
* We had a fantastic PM, who really partnered with us on the enterprise and worked hard to make our project actually Agile, even though the rest of the business was not technical.
That sounds challenging, and very early for email. Would I find it in the timeline or was it internal only?
https://archive.computerhistory.org/resources/access/text/20...
Name the Eastern nations plural that built these walls please. As far as I am aware, the G in GDPR stands for Germany, a country/nation/state which is (and always has been) firmly Western. People on here have such an infantile recollection of actual history.
Anyway, leaving aside debates of where the prime meridian of West vs East falls, it should've been manifestly obvious that in 2025 I was talking about China...
Edit: DPRK counts I guess although I'm not sure how many people would call what they have over there "communism": https://en.wikipedia.org/wiki/On_the_Juche_Idea
Yes surely I'm the one concocting things (rolls eyes)
https://en.wikipedia.org/wiki/Chinese_Communist_Party
As Sartre said - it's pointless debating people like you because you're just amusing yourself and it's only my responsibility to use words responsibly.