If patterns were programmers

They never thought, but what if OOP patterns are projected onto the work of programmers?

Singleton developer
Developer with bus-factor = 1. As a rule, one of the “old-timers” of the project who had a hand in many components and only he knows how these parts work together. Virtually "unbearable" from the project, or without it, everything starts to "work somehow wrong." For any question, "how it works," it always answers, "Yes, it's easier for me to gash myself," and gash.

Registry developer
Like singleton, this is an old-time developer, however, unlike him, he doesn’t know the implementation details, but he knows that the component exists in principle. Often, it serves as a “live reference book” and can answer any question about the code where to look at how this is done.

Factory developer
Developer in a web studio. At the entrance often receives several parameters, such as the finished layout and a couple of pictures, and at the output gives a business card site or another online store. As a rule, over time, it tends to reduce the number of parameters at the input in order to increase the speed of work, or even to automate the process.
')
Adapter Developer
A developer who understands well the language of both managers and developers. Indispensable participant in planning and evaluating tasks. Able to "digest" the phrase "Make it yours" into more or less understandable causal relationships between entities that can already be implemented by other developers.

Proxy developer
The same adapter-developer, only without introducing "additional utility". He meets with managers, starts up with their words tickets, which then stupidly reassigns to other developers. At the same time, he tries in every way to demonstrate his indispensability in this process to both parties.

Observer developer
He regularly monitors all master-branch commits and reviews them even if this is not his responsibility. If he doesn’t like something about the review, he likes to launch refactoring events and tasks for revision.

(Single-) Strategy- developer
By engaging in any new project or task, it tries to implement everything according to an algorithm developed in advance on other projects. Even if for this you need to attract dependencies from other components, as a rule, justifying it by the fact that “I did it this way so many times and everything worked”.

Facade developer
Responsible representative of the team, as a rule, team lead. He can always take care of all organizational issues regarding the work of the whole team.

LazyInitialization developer
Starts to implement the task only when someone requests its status. Strongly does not recognize the work on the issue tracker through backlog.

Null-object developer
A developer who reinsures absent team members if managers have questions about any functionality. Always ready to help understand, even if he does not know anything in the subject area.

God object object developer
The only developer on the project since its inception. The degree of god-ovost grows as there is no version control, documentation and growth of the zoo on the project.

Visitor- developer
He has a general idea of ​​how to write code correctly, and tries to convey it to other developers in their components. It can get into your code, change indents and hyphenations, add DOC comments, and even rename the “right” classes and methods, and on this will consider its mission accomplished.

ChainOfResponsibility- developer
Before writing down the task, he begins methodically to overwhelm with questions of everyone who he thinks can help him with it, starting from team lead, ending with his colleague sitting next to him. As soon as the “next in the chain” begins to say “Yes, we’ve gotten a grudge,” he switches to the next one and so on until someone signs it all down to the details, or the colleagues run out.

I wish you a lot of good colleague patterns in your work.