While this might be true, as far as I can tell our best or even good developers would not go to a spy agency as they are intelligent people with concience.

Greed is not the only problem. Yes it is a big factor, but I also saw researchers doing things they should have gotten be laughed about, not published, which happened just because of lack knowledge or rigor.

I also had this problem. And when I asked an PhD student about a thing that seems suspicious in his papers experiment setup he admitted that it's actually not as great as described.

Another big problem is research in development processes like Scrum, XP, Waterfall etc.. I argued quite a bit with my professor as all the experiments cited where like "take a bunch of students and let them work on a toy project, which never has changing requirements and is tiny in code size." Well this of course can't be used to make any conclusions of real software projects with real programmers, yet the results where generalized. This is just bad science. And we should call people out for it and definitely not publish this stuff. A better but still wrong approach was getting real programmers and let them work for _one_ day. This is outright ridiculous. What would be the result of this? The problems in software projects arise after _months_ not hours. Also people need time to get used to a style of working, which will at least take a couple of days.

Even worse the professor was really in awe with this experiment, as somebody actually used real developers. When I talked with him about this flaw he just waived his hands telling me, then no real experiment could be conducted. This is actually right, but what he meant was actually: this is better than nothing. I strongly disagree.

Also allow me to remark, that working overtime also is not necessarily a sign of professionalism, maybe even a sign of absence. I know how many hours I can work, before I am mentally exhausted and will introduce more errors / damage then benefit. As a professional thus I will insist staying below this threshold for the better of my employer and myself.

A contract is two-sided. If one sides wishes to divert from the agreed-on terms I am sure the other side will be open for honest renegotiation so everything stays fair.

Also working overtime is a sign of bad planning, which might be the workers or his managers fault. Either the worker agreed on deadlines he should not have accepted or the manager tried to put too much work on the worker. Yet it should have been noticed early enough and the time / work could have been renegotiated. This of course requires professionalism of both sides: Don't try to hide your errors and give a early enough notice, and listening to employers and accepting that errors _are_ happing, if you are told or not.

I don't think the companies owning the dark fiber would sell / rent it so expensive that it's easier to lay it oneself. In that way they will never sell it which is even worse then selling with loss.

I disagree: Give me a really concise documentation and if there is still time then go wild on a conversational info page / demo / tutorial / best practices

  First one should be easier and faster to do and you can always reference to it for details in the more wordy thing. Examples and explanations are important especially if one just starts using the software / API, but cumbersome if I only want to know the expected boundaries of a parameter or so.

So both are important, but for different things. Probably one should not skip any of these. ;)

Because of the high resolution.

Okay, I suppose you don't mind we also stop pretending the Five Eyes (especially the USA) and Israel at not in a low level war with any other country? Right?

The thing you linked more or less said design pattern are bad because... he doesn't like it. He says there is no scientific proof they are good and thus they must be bad (without giving any proof) and because people used them wrong and introduced unnecessary complexity. The argumentation of the GoF is as sound or unsound as his. I can always construct an argument against something if I point out how it is used incorrectly. By this argumentation Assembler, C, C++ and actually every programming language is bad, because I can write really messy code.

I wrote that design patterns are usefull to _me_, yes. I can't generalize my experience, of course. Yet I learned design patterns only quite some years after I started programming. And I really prefer it this way over everyone reinventing the wheel. The code bases I worked on were many years old and more than a million lines of code or so. It just would not have worked without design patterns and code formating rules.

The problem is, that there are almost no useful experiments in software engineering. Each one I saw until now was set up way too small, too short or used students instead of professionals or any combination of this. Really good experiments are just wayyy too expensive, as you would have to watch programming efforts with and without, on the same project, over years, with professionals. Nobody will finance that, unfortunately. And case studies are just case studies and can't be generalized. Thus it is hard to scientifical sound say what is bad or good. It would be great if we could, of course.

Forgot to note, that patterns also improve communication, as you can just say, you used the observer pattern and everybody (hopefully) knows what it means. Moreover by just harmonizing the code, so that the same problem is always solved the same way, you don't have to dig deep into the implementation to see what is going on. You see ItemsPurchasedObserver and you have a rough idea what's going on. On top you are not forced to reinvent the wheel for the millionth time.

Well, I don't want to miss at least a couple design patterns: Iterator, Observer, Adapter, Decorator, Dependency Injection, Object Pools (Threads and Connections in my case).
I also sometimes use Singleton, Builder, Proxy, Command, Circuit Braker.

Iterator: I want a simple Interface I know, to iterate over data structures if iterating is reasonable. Not 10 different interfaces for 10 data structures.

Observer: Often I want information to propagate. Yet the business logic should not depend on the UI, so I can easiely provide different UIs. And especally I don't want circular dependencies.

Adapter/Wrapper: Every so often I have to work with slightly off interfaces. Putting an Wrapper around it solves this.

Decorator: You don't have to maintain for example scroll functionality for every dsplay and input type (e.g. Text, Picture) but just do it once.

Dependency Injection: My code is so much easier testable since I use DI. Only downside, I have to admit is, that you potentially have your dependencies defined elsewhere. But then again this allows easier changes of those (for example in case of software product lines).

Object Pools: Thread and connection pooling can drastically improves performance. Noone nowaday creates 1000 new connections per second from one server to one DB.

Yet of course I don't sit there all day and try to use as many design patterns as possible. For a 100 line program I would never use DI, I use a wrapper only, if I really need to. And so on...

The goal is not to use _many_ design patterns, but those, that fit and actually improve the design by making it easier to maintain.

Yeah great, I have to use key combinations for the f-keys. Best keyboard evar!

That is somewhat along the line of "If I shoot him first, he can't shoot me."