I would refuse a job offer for more money if the employer uses Microsoft Azure.

Shitty engineers, shitty services.

I've been in IT for . . . god, over 30 years now, and I can tell you, through and though, that Microsoft is a shit company to the core. They are just shit. Everything they do is shit. Windows 11 will be the stinking turd on the stale cake.

Oh, and Microsoft is primarily a marketing company combined with a finance company (with a kinda 'legal corruption' department) but that's another story.

ACM Software Engineering Notes, Jan 1985

The Parable of the Two Programmers Neil W. Rickert

Once upon a time, unbeknownst to each other, the "Automated Accounting Applications Association" and the "Consolidated Computerized Capital Corporation" decided that they needed the identical program to perform a certain service.

Automated hired a programmer-analyst, Alan, to solve their problem.

Meanwhile, Consolidated decided to ask a newly-hired entry-level programmer, Charles, to tackle the job, to see if he was as good as he pretended.

Alan, having had experience in difficult programming projects, decided to use the PQR structured design methodology. With this in mind he asked his department manager to assign another three programmers as a programming team. Then the team went to work, churning out preliminary reports and problem analyses.

Back at Consolidated, Charles spent some time thinking about the problem. His fellow employees noticed that Charles often sat with his feet on the desk, drinking coffee. He was occasionally seen at his computer terminal, but his office mate could tell from the rhythmic striking of keys that he was actually playing Space Invaders.

By now, the team at Automated was starting to write code. The programmers were spending about half their time writing and compiling code, and the rest of their time in conference, discussing the interfaces between the various modules.

His office mate noticed that Charles had finally given up on Space Invaders. Instead he now divided his time between drinking coffee with his feet on the table, and scribbling on little scraps of paper. His scribbling didn't seem to be Tic-Tac-Toe, but it didn't exactly make much sense, either.

Two months have gone by. The team at Automated finally releases an implementation timetable. In another two months they will have a test version of the program. Then a two month period of testing and enhancing should yield a completed version.

The manager of Charles has by now tired of seeing him goof off. He decides to confront him. But as he walks into Charles' office, he is surprised to see Charles busy entering code at his terminal. He decides to postpone the confrontation, so makes some small talk and then leaves. However, he begins to keep a closer watch on Charles, so that when the opportunity presents itself he can confront him. Not looking forward to an unpleasant conversation, he is pleased to notice that Charles seems to be busy most of the time. He has even been seen to delay his lunch, and to stay after work two or three days a week.

At the end of three months, Charles announces he has completed the project. He submits a 500-line program. The program appears to be clearly written, and when tested it does everything required in the specifications. In fact, it even has a few additional convenience features which might significantly improve the usability of the program. The program is put into test, and except for one quickly corrected oversight, performs well.

The team at Automated has by now completed two of the four major modules required for their program. These modules are now undergoing testing while the other modules are completed.

After another three weeks, Alan announces that the preliminary version is ready one week ahead of schedule. He supplies a list of the deficiencies that he expects to correct. The program is placed under test. The users find a number of bugs and deficiencies other than those listed. As Alan explains, this is no surprise. After all, this is a preliminary version in which bugs were expected.

After about two more months, the team has completed its production version of the program. It consists of about 2,500 lines of code. When tested, it seems to satisfy most of the original specifications. It has omitted one or two features, and is very fussy about the format of its input data. However, the company decides to install the program. They can always train their data-entry staff to enter data in the strict format required. The program is handed over to some maintenance programmers to eventually incorporate the missing features.

Sequel At first Charles' supervisor was impressed. But as he read through the source code, he realized that the project was really much simpler than he had originally thought. It now seemed apparent that this was not much of a challenge even for a beginning programmer.

Charles did produce about five lines of code per day. This is perhaps a little above average. However, considering the simplicity of the program, it was nothing exceptional. Also, his supervisor remembered his two months of goofing off.

At his next salary review Charles was given a raise which was about half the inflation over the period. He was not given a promotion. After about a year he became discouraged and left Consolidated.

At Automated, Alan was complimented for completing his project on schedule. His supervisor looked over the program. Within a few minutes of thumbing through he saw that the company standards about structured programming were being observed. He quickly gave up attempting to read the program; however, it seemed quite incomprehensible. He realized by now that the project was really much more complex than he had originally assumed, and he congratulated Alan again on his achievement.

The team had produced over three lines of code per programmer per day. This was about average, but considering the complexity of the problem, could be considered to be exceptional. Alan was given a hefty pay raise, and promoted to Systems Analyst as a reward for his achievement.

Probably obfuscation of snooping, side-channel monitoring of inputs and outputs.

Large companies can’t innovate because that requires risk, and they can only approve “safe” projects.

Also mega corps are basically monopolies, shit can rise to the top and it still not die.

I was a part of a mega company that had this very failing. The rest of my team worked on the main replacement for our product. I could never switch over because I was now the product owner of a different important part. The rest of my team failed because of piss poor oversight as to what they should have been focusing on ( stability, deliverability, and users‘ perspective / usability dominated design ).

The company ended up buying another company with an innovative product / replacement. Eventually they started downsizing our team (and I’m sure theirs too) because they were essentially copies now.

All the people who spent four years on the failed product (essentially doing nothing for four years) got to stay. People like me, product owners of other important things got let go.

Ironically the product they tried was based off of my work I was doing that kept me from joining over. I was building a functional JavaScript offline ui using a browser on the box, they wanted to make this official by making a js node engine for all the ui (would have encompassed my work too. Near the end they tried for the 5th time to rewrite or take over my work with their engine, higher up management told them to fuck off and decided to work with me directly on new projects to skip their ego / bullshit.)

My engine still exists on their box today, and my boss was fired shortly after I was let go.