My universal IT complainer surface

ThingsMakeMeMad.MD

I just complain here

This is a complainer surface to show the world the dark side of my real-life developer experience

content

• Things software engineers say about work

  • Programming is easy
  • To be a good programmer you have to be good at maths
  • The best programmers are the laziest ones - they want to keep it short and fast
  • Bullshit about passion
  • Do not copy code
  • You have to know the basics first
  • Pretending that patterns are universal
  • Just Google it
  • Oldschool shamings

• Colleague practices

  • I help you with Your code... hey, I'd do it differently here and here and here...
  • Programming Patience Paradox

• Manager practices

  • Seeing employee as a one-trick-pony & Seeing employee as Play-Doh
  • Manager is off-ice
  • Resignation = You're dead to me
  • Friday firing
  • Management is a cult
  • Trashing employees or applicants
  • Decision versus Explanation versus Being nice
  • No hiring and team concept

• Tiring hiring

  • Know who you're talking to
  • Know who you are and what is the job you offer
  • Know what you want before persuading others to follow you
  • We won't write down what we want
  • We want your phone number
  • My camera does not work
  • I am waiting for the call which never happens
  • Company cannot control its outer communication
  • Do not hire Jobhoppers
  • Time
  • Loyalty
  • No proactivity on position fitting
  • No response, no feedback
  • No direct contact
  • Checkboxing interviews
  • Testing coding skills with puzzles - You expect applicants to be geniuses
  • Do not ask "Google brainteasers"

• Simple anti-patterns

  • Abbreviations, abbreviations everywhere!
  • Job fair cutting edge fancy pants

• Delusions and self-deceptions in development

  • Denying how much we follow trendy stacks
  • Treat every human error with a technical solution
  • TDD hallucination
  • Software engineers are smart

Things software engineers say about work

Programming is easy

Complete misunderstanding of programming. It is NOT about writing if-else cases and for loops. Yes, that is pretty simple and that is following very strict rules, just like elementary maths. But the core of programming consists of three different things:

• automate everything which is simple and common enough
• create abstractions for everything which are complicated but which are daily needs
• research, understand, learn and apply abstractions of others

So essentially you will have to learn new technologies continuously (without enough help). Applying them for simple examples will be easy but the very reason they were created is to step higher on complexity and speed. It is not easy.

To be a good programmer you have to be good at maths

As a mathematician, I can say: no. For coding you have to create abstractions and people think that Maths - as the science of abstraction - is a must for coding. Of course you need it, but what level? Do you need university-level mathematical analysis and linear algebra? No, you don't. Do you need three-dimensional geometry, the law of sines, will you solve secondary equations? I don't think so. You will only add numbers, create functions, count repeated actions. Quite basic stuff, isn't it?

The ability of abstraction can be found in many other areas. Like foreign languages. Like creating complicated chemical processes. Like examining the complex legal situation behind a lawsuit.

What you really need is determination. To dig deep into a problem, create abstractions, and mostly: pick up the knowledge for the problem. You have to be able to handle the stress caused by this process, even if nobody will really help you.

Finally: yes, sometimes there are mathematical problems in programming. For example coordinate geometry is needed for graphics. But the fact is: you may also meet many different areas you should be able to learn. All the softwares are created for someone's own, different job and you have to be familiar with those concepts to fulfil the criteria, find the appropriate library you will use and understand that one too and you can only start coding after this.

The best programmers are the laziest ones - they want to keep it short and fast

Home-made corporate oracles love to say this. But efficiency and laziness are not the same. When you are looking for a working, efficient (maybe even elegant and smart) solution, you do not do it to just get it done and go to sleep. Stamina is necessary and the very moment you are finished, you will have a new task and you will want to still optimize your solution.

Bullshit about passion

Everybody is always saying that you HAVE TO BE PASSIONATE. Which means: otherwise you are shit and you will never do this job.... what a son of a bitch. It is about praising YOUR passion, excluding others and creating an excuse. People do not go to work all the time for passion, usually we do not get up early in the morning that "Oh my God, I want to have sex today with five new npm packages!". We just get up and do our work. Which is fine. Which should be enough for anybody.

“The key is: don’t rush learning Redux just because. You should start learning Redux if you’re motivated and passionate about it.”

Valentino Gagliardi

Do not copy code

Oh yes, it is soooo much better to write everything by your own hand. Sure you won't ever type "mednium" instead of "medium" and you would find this typo in a 2000 lines project in 10 second anyway... NOT

Everybody's copying code and it is a valid argument, that code snippet libraries and autocorrect tools are also external codes you accept and paste into your work. Not to mention the package managers, which are pulling great bunch of code you've never seen inside.

Your principle should not be "do not copy code". Your principle should be "make sure that any code you use is trustworhy and it fulfils your requirements". If it is a library, then you should check its licenses and certifications. If it is an auto-created snippet, don't forget to check if it is appropriate. And yes, if it is a long piece of code you've found on Stackoverflow or other "unreliable" places, then read every line of it. Copying should help you, but it should not replace your efforts to understand the code and take the responsibility for it.

You have to know the basics first

It means: I don't want you to touch the real code, so I will shame you on your mistakes. While the fact is that everybody is just hacking and by the time, by knowing real issues you go deeper and deeper on reading documentation and principles. Pretty often won't even understand them if you don't know why we need them.

It is pretty funny anyway that people tell you things like "You Should Learn Vanilla JavaScript Before Fancy JS Frameworks". Yeah, thank you, jerk. You've just moved from a Spring backend position to a fullstack JS developer position and the tool of choice is React+Redux+Typescript. Of course you will start a 20 hours long Javascript training and Google stupid JS type situations (which never happen in 2021), not going ahead to learn the frameworks you will really work with and which is fine with your basic JS knowledge for now.

Still, it is important to have the deep knowledge about language basics. But that is not a precondition, that is a continuous effort.

Pretending that patterns are universal

There are universal patterns in programming: you have functions, variables, loops and so on. But the wise old programming masters wanted to write about architectural rules and teach programming in abstraction, without the actual language. Was it a good intention? Yes. Did they fail? YEP. Did they made junior life a hell with it? Absolutely.

When I had my algorithms course, the teacher used pseudo-code, pretending "I won't specify the language". He actually wrote code in Java syntax, just replaced the keywords. Does it make sense? Absolutely no. You can teach algorithms with Java. Students are not idiots, they will be able to use the logic in other programming languages. Because why did he use you Java syntax? Of course because there is NO universal syntax. Languages are different! Their approaches are different!

And it is just the same with things like Clean Code. Are the Design Patterns smart? Of course they are. Are they universal, without any language dependency? NOOOOO.

The problem is not that you think about universal patterns. The problem is that you do not tell people like "hey, this concept is based on C++, Java and C#, so it is for those languages. You may be able to use it for other languages but don't forget that you will have to ask yourself: does a good pattern interpretation exist in this language? How will I solve the problems of the differences?"

Final note: programming technologies cannot be easily grouped, because they are all based on different principles. There are related ones, but in general, it is a chaos. Which is okay, chaos is a ladder. They are different for a reason and this reason is to help the programmer. But then do not pretend that they are all the same! When you say such things, you make the life of your colleagues an actual hell, because you teach them a lie and they will build their learning on that.

Just Google it

Okay, it lights a very important problem. Learning to code has no methodology. Most of the complicated things are taught in school by professional teachers who trained themselves well on that specific topics - by university teachers and so on. In programming you may learn the basics in school, but the everyday work requires everyday learning and there is no one to help you. Not even a mentor, because the skilled seniors are busy with the projects. So you will learn alone, get frustrated, ask for help and then they say "It is on the internet, just Google it".

Which is a bit asshole-ish. It means that it is your problem, you should solve it, everybody does. Which, in fact is true. But the real solution would be not "get used to it or leave the profession", we lose too many good people this way. The solution would be to teach people how to learn alone or how to learn with people having the same zero knowledge you have.

So please don't be an asshole and tell people how You learn and offer them trainings on learning. Maybe you survived without it, but people survived wars too, but did not tell their children "Do you want to be a successful adult like me? Then please go to war, maybe you will die, but no problem, you have a chance to survive and be like me". Only the fact that you had a specific path does not mean that it is the good path or that everybody should go on the same path.

Oldschool shamings

I'm sure you heard and read things like that with malicious notes. Spaghetti Code. Coding Monkey. Boilerplate.

Some people don't care if a given term is out-of-date yet, like in the case of spaghetti code, which was originally used in the 1980s for overusing goto statements (which was a common and accepted language element if properly used) in superlong code files. After recalling these facts usage of this term in the 2020s sounds weird. But people still use it. Yes, some of the coders still use these languages, some of newer languages still have goto. But it isn't the reason.

It is mostly because these situations are not about fixing code. It is simple shaming. Spaghetti code is used like "this file is 60 lines long and I don't understand it! I won't read it and contribute with constructive criticism, but simply shout spaghetti as all coders know it is something shameful, so everyone can join for some nice shaming-together". It is quite like in school when someone's shouting "SEAN LOOOOVES AMYYYYYYYY". Commonly accepted and known way to embarass someone without any good intention. While it does not say anything valuable about the code. It is simply like "It's bad code", just in a more popular form.

Shaming is never acceptable. Doing it in the context of coding does not change anything about it. Using old, well-known (and not necessarily well-understood) terms does not change anything about it. Just do not do it.

Colleague practices

I help you with Your code... hey, I'd do it differently here and here and here...

First, let's make a statement: pairworking is a fundamental practice in programming. Coding is more and more a lonely genre of work. It amplifies isolation and feeling of being isolated, feeling lost at work. Even if programming communities established solid systems to communicate, these are channels with limitations. They aren't even close to traditional, live, cooperative jobs. It makes pairworking precious.

On the other hand, coding together is not per definitionem pairworking. Programmers - especially the more senior ones - should take care of not taking away the keyboard from their colleague, because then it is not pairworking anymore but watching-someone-coding. Even worse, senior colleagues tend to rewrite code instead of fixing it. The original goal was to make the senior understand the problem, understand the code (that's why you are a senior), have a discussion, make the junior understand, make the junior fix the code. The worst possible outcome is that senior deletes the code, rewrite stuff by own taste with superfast explanation, then leave behind the junior without the job done (by self) and without doing it with a good understanding.

Doing it instead of providing support is not help PERIOD

I know it is hard. It requires self control and soft skills. To be able to explain. To be able to understand people and their way of thinking. I guess we can call it like The Second Rubber Duck Crisis of a Coder. You have your first crisis as junior: understanding the problem, asking the appropriate questions, making the adequate efforts. As a senior you have your second crisis you should grow up to: understand People. I know this is something you did not expect to experience as a coder, but life is a shit. After all these years you worked on avoiding human interactions now it is your primary mission to understand other human beings.

Programming Patience Paradox

One of the most satisfying factors in programming is simplicity. You don't have to think in detailed steps for long-term plans, because after breaking down everything to tasks on the planning meeting, you can minimize the preparation time of each steps. Think what you wanna do. Write some lines of code. Run it. Repeat. Repeat. Commit.

This makes work extremely comfortable and safe. You go step by step, without doing tiring debugging. Early programming was not like this. It made work painful. That's why well-defined error messages, syntax highlight, intellisense, unit testing were rapidly growing, ending up as industry standards. Autosave on every click and hot reloading elevated it even more. Today software engineers may have the most fail-safe environment compared to other jobs - especially engineering jobs.

But the problem is: Did we forget how to do planning, how to think ahead? Can we accept that problem analysis without typing is still a thing? Are we patient enough to think by drawing, writing, talking, understanding - instead of thinking with our hands, practically implementing stuff immediately?

My experience show that several people are failing on these questions.

• they tend to believe that in any situation it is the best to write a small, simple function.
• they tend to rollback and rewrite the code when they get confused by unexpected complexity. If their implementation was bad, they may be better for the second time. But if the problem has the complexity, they end up in an endless loop of random retries.
• after some retries and fails they start to question the task itself. Denial of the reason behind the feature exonerates them from the struggles and disappointments.
• they tend to solve every problem with a tool (testing, choosing a strongly typed language, paying for a new IDE) instead of analysing it with rubber duck debugging. This mindset creates blamegames like "With Delphi we would not have this problem!" It enforces the colleagues to stay silent or to tell them "Another language or library is not a solution. You are lazy to go the extra mile", which is a straight way to a quarrel. Even worse: you will never change the programming language in the middle of a project, so the whole approach is ab ovo a dead end. It is only about letting people releasing their disappointment - by pushing it on others.
• they don't even accept basic planning steps. The best example for it is frontend engineers implementing design without having a design in Figma or at least on paper.
• they easily ignore existing code or note and starts the same thing from scratch again and again and again. Even after several retries they do not consider the option of analysing and fixing what was already there.

It is essential to be able to stop, think, explain, understand, analyse. Focusing on small steps can be useful, but insisting on it blindly can also make your thinking patterns closed.

Manager practices

Seeing employee as a one-trick-pony & Seeing employee as Play-Doh

Managers tend to see employees as someone having competency in only one professional field. I see it again and again that Human Resource Management de facto does not exist in companies. They have colleagues with decent knowledge about how that company works and they let them go, because the actual project is being terminated or the given person was not the best for that role - while they have other open roles in the company, and they pay a LOT for headhunters to find good people. Usually they do not even ask the colleague (or first: the HR person, who already knows everything) about other competencies, about other ambitions. While such questions are free.

I've seen the opposite too: managers hire someone for position A, then push the professional instantly to position B, then pull that poor guy back to position A... Fundamentally, it is the same problem we had in the one-trick-pony case. The manager did not ask what the employee wanted, what the employee was capable for, how does it fit company needs, did not have the necessary discussions. It is usually a basic mismanagement situation too: both cases make the employee leave the company - which obviously has a cost.

Management has to see employees in their inner complexities. The goal of having HR people, having regular 1:1 meetings is not only to talk through daily stuff and big problems, but also to know people in depth. What they know, what they can, what they want, what they plan. It is not enough to measure people with one dimension only, like "he is a good one, so good for management and coding and everything - while he is a bad one, so do not give him any new responsibility". In the end of the day, human resource management (by HR person & the manager) is about helping the employee to be happy and productive. It is a misconcept to believe that it should be limited by the actual project or role. It is not a loss if the employee loves the actual job, while also empowered to step ahead to a new one, which may be out of the company. Leaders and companies which make people happy will be always rewarded by good new applicants, because employees love to be honest, open, successful and happy, and because they appreciate when their employer care about it. The work itself will be also much more productive if people's motivations are well-managed.

Manager is off-ice

You are hired. You are fired. Your team is reorganized. What do you need then? Manager presence. "I am here, I know what is happening, I take the responsibility" - that's what we except. Still, I saw and participated situations like:

• some guy you never met invites you to a meeting room. He tells you that you are fired, sign this paper and it will be the best for you. Somehow the senior developer you worked with is not in the room. He did not even say it the last days that "hey, it is a problem, I want you to stop it, my advice is to go ahead this way". Your manager is on holiday, definitely not in the office
• you are hired to a new job. You go there, take a deep breath in the door and step in. You do the administration, pick up the computer and sit down. Expect something to work on. They just say "oh, we don't have to hurry, we will talk later today". Tomorrow morning. Okay, but next week. In the end of next week. Remember: it is your probation period, you have to prove that yes, you are at least as great as you seemed to be in the interview process.
• You are moved to a new project, new team in your job. Just get a mail or your manager tells you. Okay. You finish your actual tasks and go to work on your first day on the new task. You may even participate in the sprint kickout meeting. You do not get any tasks to work on. You are not onboarded. Your manager and the senior developers do not ping you. Maybe they are even on holiday.

These things are highly unrespectful. You can say "oh, we have time, don't hurry". Yes, you can. If we have the tasks yet. It gives you time to take a breath in a working hard time. But just not doing Anything is wasting time, wasting money, wasting opportunities.

And yes, your very job as a leader (even as a senior) is to Be There. You have to take care of onboarding, describe situation and answer questions in any big changes and participate in every step of letting someone go, no matter if it is a simple leaving or a firing. Real leaders even do exit interviews to have final, open discussions about experiences.

Resignation = You're dead to me

You are hired. You are not fired - but you chose to leave. From the day you've announced it many of your colleagues, including your manager stop talking to you, stop asking your opinion, you are simply ignored. Especially if you work off-site, especially if you are not in a super-senior position yet. It is not actually something would make you mad, it is rather embarrassing. You still have some weeks in the place, is your time and the money they pay for it so worthless? If yesterday your contribution was good, why isn't it today? If they liked, respected, supported you yesterday, why has it changed?

My very best experience about leaving a company was when on my last day the CEO invited me for an Exit Interview. Wow. It was pretty something. Not because we would find out something unexpected in such a talk. But because it is a chance to have a retrospective overview on the company, on yourself, on the project. It is also about showing respect for each other's work. Once a Prezi leader said that it is natural that people are coming and leaving. If someone's leaving Prezi, he wish that guy good luck. Maybe they will work again later.

Respecful leaving environment is also important because the company loses some know-how with each and every person. You should use even the last moments to have communication, to let remainers grow by the leaving person. YES, it is also true for a junior guy... and even if there is no knowledge there: it is a common joke that ten years later that young, no-clue-guy will be your manager. Treat him/her accordingly.

Friday firing

Just do not do it. No one-on-ones on Friday 16:30. Definitely not if you want to fire somebody. Many (most) employees are already traumatized, they predict dark future when they see a last-minute friday meeting, or when they hear a late "we are still waiting for a volunteer for the weekend", or when they do not receive their year-end bonus and the management is complaining 7/24 about the budget.

Any bad news, any painful actions should be addressed very early, transparently. If you leave your people alone with their fears and traumas, working environment will be based on these frustrations. Good people won't stay, they won't be productive, they won't be honest and they definitely will not respect management and see them as partners. If you want to fire somebody, it is okay, you can. But you have to be able to tell them what the problems is. Then you have to actually tell them to work on this. If they do not put the effort necessary to do it properly, you should tell them that it is a problem. If your acceptable expectations and requirements will not be fulfilled by employee actions, then you can tell them on a normal appointment that you fire them. They won't be surprised. Then you can be sure that you were fair and they won't have groundless fears.

Firing is hard, but you have to understand that it is always harder for the fired one. As a manager you should make it simple, fair, transparent and painless. It is a general rule as a manager that you can never know what effect a leaving employee may have on your business. A fired one can be your future employee, colleague or even boss. Leaving people's feedback may be the primary way for potential partners and employees to grade your company. What you should always communicate is that "now it is over, but we may meet again in the future and I hope that we will create awesome software then".

Management is a cult

In theory leadership means responsibility and competency. Of course in legal terms it is usually more than theory, managers have a strict code what they can do and what they cannot. But is it true about the everyday experience?

When you are hired or fired as an employee, they say it is all about your work. You are responsible for delivering a good work and you will be effected by problems in the business. It is something I always experienced directly. Managers may have more responsibility, but I never saw this. I saw several failing products, projects, companies. The harshest consequence I saw on mid-managment was pushing back someone to have a smaller team. The harshest consequence I saw on high management was an early goodbye with a nice goodbye bonus. I saw never ever a rapid manager firing due to shitty work.

It is strange for me, because then what does their responsibility mean which they get the big money for? I saw managers who were hanging around all day long. So-called "leaders", who had their faces in business magazines, got awards - and I knew for a fact that they did nothing for months! The company around them had serious problems, fired the working people - and two years later I see their Linkedin profile. Not fired, not punished, anything like that. Promoted to be a vice president staff whatever manager.

The interesting part is that it is hard to have a manager role. If you are a developer, you won't be hired to a manager role. "You do not have the 3+ years experience". 5+ years of experience in development, nice soft skills, relevant educational background, similar roles (like being a teacher) never matter. But if their work is not a proven skill in real life, but an ad hoc decision about choosing mid-level leaders, then why is it a big problem to hire someone who does not have the CV experience but has the skills? It can be checked by a good HR colleague, who knows what is necessary for leaders.

My only explanation is that management is not handled as a skill. It is handled as a cult. Managers decide in companies (never in a hiring process) if you can join the club. They have to like you. If you follow their habits, if you look like them, if you are attractive, if you are not against their corporate politics goals, then it works. Otherwise not. And if you are in the club, you are in the club. You have the experience in your CV, you can have a new manager role. You may be an asshole and some people in company HR and leadership may not hire you, but most companies won't measure your skills, they will check your CV and check your loyalty. The point is not to have the soft and hard skills of management. They may not even know what are these.

I have to make a note here about the consequences. Women are not hired to be managers, because they do not fit the status quo. People with great soft skills (but no wish to shine a manager's ass or to step on other people's heads) won't be hired to be people managers. Developers won't be chosen to be the managers of development companies, because they are developers. After knowing the things above it is much more easy to understand why these things are happening. I won't go to the deep rabbit hole why it is terrible that we have so few female leaders, that is a complex (still, obvious) topic. But I would like to be very outspoken about the dev-manager problem. It is ridiculous and it is financially nonsense that we have IT company managers who know nothing about code. These people are planning longterm software product goals, investments, hirings without knowing anything about what they buy and why they buy it. I heard IT startup leader saying "we don't need someone for devops. You just switch on the service on AWS and it works." Potential developer leaders are starting their own businesses or just keep on coding, but just a few of them have effect on management in the end of the day. While we have several managers who are bad about management and know nothing about code. Then I see companies, trying and failing with huge products - because during the decision process they had no professionals in the room at their level, having the ability to say it won't work, do not do it!

Trashing employees or applicants

Most of the managers are not trashing employees publicly in the company, because even if they feel like they wanna do it, they know or at least feel that it would be a problem. They depend on employees and they can be easily in trouble if the employees get publicly hurt by them - they may demand the removal of the manager together. A manager never wants to shape cohesion against him/herself.

Applicants. That is completely different. Many insecure managers feel that about an applicant they can say whatever they want. It is visible on interviews - some managers (and even future colleagues) are so confident and so hostile that they have no problem about saying really awful things to a person they would like to hire. It is even worse if we hear what they tell other managers or senior colleagues about possible applicants. I heard a manager calling some applicants "trash", talking about underperforming people. Which is obviously trashing. Literally. Not having enough expertise does not make you trash. Just not the appropriate applicant. (I would argue that you can be a perfect applicant without enough expertise but that is another topic). You may say that "the applicant won't be hired, won't work there, so who cares?!?" but you would be wrong. If a manager talks about people this way, you can be sure that he/she will handle you the same way as an employee. If you do not deliver what the manager wants, the manager will simply throw you under the bus. Doesn't really sound like leadership, does it?

Decision versus Explanation versus Being nice

Leaders should make unpopular decisions from time to time. Part of the job. So they often find themselves in uncomfortable situations. They have to tell employees they won't get bonus or not in time or less than expected. They won't get the tools for their work they want. They have a short deadline. Their colleagues got fired. They cannot have their holidays they planned. They won't get a raise.

A leader in such a case should do these things:

• Show trust and respect to make communication smoother, to avoid intense conflicts
• Describe the rules precisely, tell a no if it's a no.
• Provide at least the minimal explanation on Why this decision was made. It is not apologizing, it is simply being open about the reasoning behind.
• Be as public as possible. Decisions always have long shadows, they effect all the people.

It is a simple thing, but most leaders fail here. They don't want to hurt others, they are insecure. Typical examples:

• The leader circumscribes the answer, but never ever gives a straight answer. The employee is like "Will I get a 10% salary raise?" and the leader then talks 30 minutes about the business results of the last 5 years, current costs etc. The employee will feel embarrassed, because he/she has to ask after this 30-minutes monologue "...so it is a No?" Pretty often the employee does not dare to ask again. But it creates frustration and angry discussions among employees.
• The manager simply tells the decision, but gives no explanation, does not put the extra time into discussing the problem. Employees are full of questions but they don't wanna ask risky questions. They are starting to share theories and gossips to describe for themselves what happened, what may happen later. It is typical about HR changes and reorganizations.
• Being nice and telling what to do, but with no explanation. It is infantilizing the employees. I like you, I made a decision, just accept it. It is not the children's stuff to think about the motivations of the grownups"
• The manager only communicates with the minimal amount of people. Important and / or public informations are not transparent, they just float among people as gossips. People lack information in company life and it generates several conflicts. It is very typical among insecure managers who prefer to keep employees in dark, thinking that employees should not know too much. Pretty often it is because they are afraid of the employees.

These are all terrible antipatterns. As a manager, you should always make sure to avoid such situations. Without them you may look incompetent, insecure, unreliable and unapproachable. Even if you made a good decision, it is a poision for the team, something dangerous. And if your decision is not good, if your action was really against the company's interest, it will prevent people to let you fix it.

No hiring and team concept

There is a reason why we have agile teams of 4-6, why we have managers, why there are engineering roles defined in Agile methodology and company roles defined in management studies. Professional IT leader and HR should also have to have common sense and experience on how to apply it on the specific team. Unfortunately people tend to ignore it.

Sometimes they only hire engineers and expect them as "smart people" to solve other problems too, like daily administration, sales, marketing, project management and so on. In other cases they hire a big management, many of them producing documents never opened again, never got used. Or they hire designer too early or too late. They ignore importance of UX design in application development. It also happens that hiring happens without discussing it with future leaders of the new colleague.

These decisions should be managed by leadership. The leader should talk himself with HR, team leaders, even with employees to monitor the real needs and make decisions with HR accordingly. Bad hiring creates a huge waste of energy. For example: firing people "with no use" (damaging team moral and wasting money), making people work without expertise (bad results), making company vulnerable and incompetent.

Tiring hiring

Know who you're talking to

I've read a huge amount of job advertisements and most of them start with something like "my client is a successful tech company which just secured a $49M Series B investment". Why? The recruiter is not selling the company shares but a job. Why is the investment the first information you read?

I guess people just copy parts of company press kits - made for business partners and investors - and send them to recruiters - then the recruiter does not say "i know it better, guys, so I edit this description this way", but just post it to Linkedin.

If you are a recruiter or the company HR person, you should think about such questions and push the leadership to approve provide job advertisements which truly impress software engineers. It is not an investment, not a bean bag, it is the job. All the others should come below.

Know who you are and what is the job you offer

Every second people in job calls could not tell me what they are doing and what is the actual job. I would predict a manager is a better communicator compared to a developer. Some of them can answer well if you can follow their fast talking and if you ask well, but many of them are simply unable to tell you briefly by themselves ten sentences about the basic questions. Please imagine that you're sitting in front of Denzel Washington, saying All right, explain this to me like I’m a 4-year-old, OK, because there’s an element to this thing I just cannot get through my thick head.. And just tell Denzel what he has to know. Like:

• What is the company doing?
• What is its business model?
• What are you doing?
• What will I do from the first days?
• Who I will work with?
• What will be my major task to do?

Let's make it clear: the name of your role is not what you are doing. It is just a name for a role which may mean this or that. I met high level, well-paid people, who had answers like "I am the engineering manager" or "I have companies". I was obliged to do Story Telling training as a junior developer many years ago, but these managers want me to work for them without the ability to write down in 5 sentences what are they responsible for, what is their daily job and how I will fit into the company

And yes. I get that recruiting is pretty often like "the investors push us to grow and we have a bunch of stuff to do, let's hire 5 developers", but before the interview you should have figured out something more. How you will reorganize your teams, what are the priorities for the next quarter and so on. How it will look like from an employee perspective. Some guys will tell you that "we provide autonomy to teams to pick their tasks". Bullshit. It simply means "I did not do my home work and I do not want to practice leadership, because it is easier to avoid decisions until I really have to."

And the practical life proves my points. Most of my jobs were advertised like "haha we do not do waterfall" and "great autonomy!!", but in the end of the day the management always had expectations, deadlines, preferred people etc. in their mind. Which is good, it is their job. Just own your expectations, be transparent about it. And learn how to express them to someone you would like to hire.

Know what you want before persuading others to follow you

It is a so simple one. Make a decision about your project, your human needs, communicate it transparently, make the selection process, make a choice. Still, it seems to be a problem for many.

• Once I started an interview process and I was open about my expected salary. During the process I raised my expectation (I got other offers, also got more information from recruiters about the job market). In the end of the process I got a call from the CEO. He offered less than my first number.

• Another company hired me to be the second member of a new team, with the prespective of further growth. My manager (senior developer) worked there for a year. After six months the whole team was removed from the company, saying that in-house web development is not a need any more. There was no rapid external change, there was no financial pressure on the management to make such a change.

• A third one reorganized the teams and merged our junior mobile app team to a senior team, working on an ambitious cloud management tool. Six months later the management canceled the project. At least 5 highly skilled people left the company due to these decisions in 3 months.

• A fourth one had the whole interview process for me for a quite challenging, long-term position. They gave a great feedback for the recruiter, so he told me that he expects an offer to come soon. Some days later the company withdrew the position, informing me only through the recruiter.

It is easy to understand that these examples show a pattern of disrespect. Managers are making rapid decisions, while playing games with others' careers, interview process time investments, project commitments. I am the first one to stand out for the right and duty of managers to make painful decisions. They have to do it when they have to do it. But when they do not make their decisions in time, when they start projects with poor financial plannings, when they are like "let's hire people for this project for a lot of money, even though I may fire them soon", then it is an obvious wasting. Wasting of money and wasting of time. It is an abuse on people, an abuse on taking resposibility. Especially junior colleagues need longer time to get comfortable with a project, with the technologies, reach the point of delivery. Playing such games is the best way to ruin their lifes. In my junior years more than 40% of the software I wrote never went into producion. Average time I had for a "long-term" project was about 6 months. If I count small project, it may go under 4 months.

...and yes, the very same managers like to complain about jobhoppers, the lack of loyalty.

We won't write down what we want

In job descriptions you will usually find tech stack ("React, Node, Express, Styled Components, Postgres"), necessary bullshit ("our financial status is stable, our colleagues are great at their job, we are looking for a skilled new guy"), unnecessary bullshit ("we have a young team, we have free cleaned water at office, we provide competitive salary"). Fine. But pretty often the real point is not articulated. Guys, if do not need a guy who wrote 500 endpoints with unit tests calling MongoDB with Mongoose, but someone who also has practice on how to setup a highly scalable system, following Microservice Architecture principles, using many services of Nginx, dockerized and pushed to AWS with terraform, architectured it alone, that's okay. Just write it into the job description.

Pretty often it is just humiliating (and wasting time) when a company has expectations and it becomes clear during a second interview. I get it, you wrote it was a senior dev position, so he/she should know these things. But (1) you wrote so many unnecessary things, why is it less important than the "modern office with free water"? (2) a senior dev position may mean many different things in different business areas. A corporate inhouse web project will never face thousands of visitors in a second, a skilled developer on creating WooCommerce won't ever meet custom server systems connected to industrial internet tools. Both cases with 5+ years experience imply you are a senior dev, with completely different backgrounds.

I tend to see it as the unspoken concept of surprise interview questions. Employers' visions on candidates do not include preparation. You're expected only to prepare yourself on company background and practice if you wish, but no actual learning. "You know it or you do not know it". But it is just crazy. "We do not want the candidate to prepare and 'fake knowledge'". Even more crazy. No, they won't fake knowledge as in practice it will be clear anyway that it is not real (not to mention it is hard to fake technical knowledge). And yes, it is in your interest to hire someone who can do research & learn on the spot.

Another possibility is that companies don't know what they want. Which is okay as a starting point, but if you talk with a dev colleague, talk with the company person responsible for hirings, talk with the headhunter, spend time to write the text and you still do not know what you want.. well, then you have an elephant in the room to find.

Or maybe the headhunters want to keep job descriptions short and tidy because they know what JS is, what React is, but have no clue about Nginx, especially not about details. Of course it is hard for them to talk with candidates about a text which they do not feel comfortable about. Well, that is not your problem. The job description is not to make the headhunter comfortable. The headhunter should learn to be comfortable to tell the company and the candidate "Sorry, I do not know". It is just okay. They should not be expected to make technical interviews. They are there for making the list, checkin' in twice, to do organize hiring process, which is very tiring and very important. Respect this work, have appropriate expectations.

Clear expectations are good. Candidates read a lot of job descriptions. If they see recurring keywords, they will learn about these things and go to the interview only if they believe to have at least basic knowledge about the task. It is good for you, it is good for them. Just write it there, please.

We want your phone number

Headhunters and companies love your mobile phone. A lot. If one of them approaches you on LinkedIn, they will instantly ask for it - without even telling you the basic information about the job. If you are already in the interviewing process with a company guy, again, they would communicate everything in a call. If you do not respond for a call (it is pretty likely that you do not know them by the phone number), they won't send a mail with something like "Hey, it was us, we wanted to tell you that [information], ask that [question] and have a discusson about [topics]", but just wait and call again. Or not.

It is ridiculous. Even if we usually do not say it this way, the hiring process is business, making a contract. You give something, I give something. We talk about details in a process and agree on some basic facts and we make agreements, time limits and so on. Why can't you provide facts in a mail? It is also problematic as a communication pattern. Everybody knows the communication matrix: based on importance and urgency you can choose if a chat message, an organized meeting, a mail or a call is the best form. If someone only communicates in direct calls, they do not respect your time, they say that if they want something, it is always urgent. No, it's not, jerk.

So please, learn how to use communication tools. Provide information in a written form. Employers and headhunters never talk about company secrets, so it is not a big deal to write the non-secrets to a mail. Always start with written information, it generates respect. If some topic requires direct contact, no problem, organize a call. It is the 2020s world, so it should be a face-to-face call. Yes, dear headhunter guy, dear CEO lady, you will turn your camera on first. Nobody cares if your hair is nice, if your bookshelf in the background is full of pulp fiction, it is all about respect, openness and focus. I just had a call with a headhunter lady from an ugly Indian call center. It is a problem? Of course not. But it made everything so much easier and it felt much more honest.

Do. Not. Call. Me. Just don't. A hiring process is never that urgent. It is just putting pressure on the applicant. "Hey, we can give this salary yesorno??? Hey, when will you send us your portfolio (what needs so much fckn time how dare you think that this way we would ever hire you???)?" And if it is reeeaaaly necessary and I could not pick up the phone - because I work or have a private life (again, How dare you???)- then send me an email or a LinkedIn message in the very next moment. We met this way, I sent you my CV this way, I will know that it was you. Just use it. That's why I gave you my email, that's why I have a LinkedIn profile (and not because I love to see the shiny images of old colleagues who think that LinkedIn is just another Instagram/Twitter/Facebook for grown-up men).

My camera does not work

As I said previously: "Yes, dear headhunter guy, dear CEO lady, you will turn your camera on first." It is not something big, Teams / Zoom / Google Meet all offer background hide functionality and I really don't care even if I see your laundry behind. But talking face-to-face is definitely something generating trust and connection. It also helps to understand pronounciation. I had interviews with people from at least 30 countries, sometimes I do not understand what people say - seeing their face helps a lot.

Recently I hear more and more recruiters starting with "I'm sorry, my camera does not work for some reason. You can also switch your camera off." I believed it for the first time, but after the second, the third, the fourth I knew it was a lie. Or there was an electric storm around the world, ruining all the recruiters' webcams.

Just don't lie. Many applicants prepare their outfit, their background before the call. It is not so nice that your work is communication but you don't put the minimal energy into it. (note: Recruiters may judge applicants based on their visual preparedness, but there aren't any similar effect on you as a recruiter. It is politeness only. Which, on the other hand, is something actually important).

If you do not want to turn the camera on, don't lie. We know you lie and it is not a good start for an interview. Just be honest: "I'm at home and don't want to turn on the camera". It will be okay. It is okay to be human, to have everyday problems. It is okay to be honest. Starting with a lie which smells from ten miles away is not okay.

I am waiting for the call which never happens

Got the message on Linkedin about a job. If she can call me with details. Also want my number. I say OK, and that I am free any time today. But my phone does not work now (it was hundred percent true), please send me a videochat request to my email address. She proposed a 12:30 call, which I accepted. Videochat mail never arrives. At 12:30 I ping her on Linkedin that I got no email from her. No answer. 20 minutes later I get a message. No "sorry for being late", just that she wants my number, because it is the way she can call me. I repeat that it won't work now. I don't write her "You have internet, you have phone, you are able to call me online, just DO IT". Maybe I should. After hours, I still did not receive any kind of answer to it.

I felt ridiculous. Why she didn't? It it the very basic expectation to be on a meeting on time, especially if it was proposed by her. If late, no problem, just tell me. If forgot to tell me, no problem, just say I'm sorry and find a new timeslot. But this behaviour is just something I cannot handle. I never miss a job call, because a headhunter may judge me based on that 10 minutes long call, I would like to show that I am someone her client can trust. Maybe I can expect something similar from her. Maybe.

Company cannot control its outer communication

One of the most important rules of business communication is to hide all your laundry. Your partner is a black box for you, and you are a black box for your partner. You don't want to expose your inner problems to the public. And if you have a business meeting, you are not there to hear about inner conflicts and irrelevant details.

Hiring is no exception of this rule. As an applicant, it is quite uncomfortable (and a red flag) when company colleague A sends you to colleague B and after several days it turns out that colleague B is on holiday, is sick for weeks, is not working in the company any more. Or you get an invite from the company and you see four people invited (you, manager, HR, team lead) but only one of them shows up. In another situation I got a job description with a link to the company website. The website was under construction, with lots of placeholder content and empty menus.

Communication should be professional. Provide as much information as possible, show the best of the company and have control over the process. It is really hard to have trust in people who cannot even communicate with the colleagues they work with.

Do not hire Jobhoppers

Term 'jobhopper" was never proven to have any valid background. It was mostly created by managers irritated by employees who naturally left company when they became uncomfortable to work there. It may be bad for the employer (also not proven, there are serious pros and cons), as it generates work for the management to hire (research, interviews, maybe higher salary). Somehow series of articles appeared in management and HR magazines these times, suggesting that jobhopping is intentional in-workplace behavioural crime and/or psychological problem, so you have to stigmatize these people. The question is open if it is rather an informal, loosely coordinated crusade against employee mobility.

The amusing response to this trend was a series of articles, saying that jobhoppers are good for your company. Of course it is rather a late justification. Modern headhunting faced the reality of an endless labor shortage in IT. Traditional "working in the same place for decades" culture was replaced by rapid changes. Even if you stay in the very same company, five projects in two teams under two or three managers during only one year became expectable. Not to mention: your job may disappear pretty fast and no tech job is sustainable without continuous online learning.

But after 2020, terrible managers and recruiters still believe in this thing. Unbelievable.

Time

Time is a hard thing on hiring, especially in IT. Employers may have to handle situations when they work on a hiring process for months and after choosing the right person, the candidate will not show up on the first day, or will leave on the 5th working they or some day in the probation period. They made an offer, did not change it, so they are disappointed about this outcome. I understand.

On the other hand, it isn't less painful on the employee side. I experienced several times headhunters and employers ghosting, employer ghosting from recruiter, employer does not answering recruiter due to firing of the contact person, answering superslowly, moving interview appointment to another date without asking, terminating the hiring process randomly, firing on the last day of probation period without any real feedbacks before, pressuring with loyalty. And when they make an offer, they always want an answer immediately, preferably in 1-3 days.

I know it is hard, but we have to respect each other and avoid extra pressures. You may had a hard time with previous employers / candidates, but there is no easy way to change these situations on the spot, because a hiring / exiting between a specific person and a specific company is usually a once-in-a-life situation. The only way to properly handle it is to be respectful all the time, with everybody.

Please be transparent about the process. Please be transparent about your plans. Make your side as fast as possible. And yes, please be patient, even if you provided a very fast process on your side. It is just normal if a candidate or a company asks for two or three extra weeks to make a decision. To think about an offer is even more okay than a long process, because it is the non-predictable personal side. Just tell the other one that you need this time and accept such messages without any ❗ further comments.

It is also a good practice if all the processes which do not need any hard decisions are superfast. It happened several times that after having a discussion with a recruiter, I got an an invite for another interview - booked for two weeks later. If you are looking for a job for weeks, you won't wait another two weeks for a first company interview. You may already have offers. Other companies can do their processes much faster. Try to offer timeslots in four days maximum. Weeks work only if you offer a very high position for people who have comfortable position yet. Usually it is not like this.

Loyalty

From time to time employers tell me on interviews that if I quit the job after accepting it, I am a shit. Some tell it about withdrawals, some tell it about leaving in the first months, some even tell it about the first 1-2 years. And of course they won't actually tell you that then you are a shit, but they mean it, it is not hard to decode. It is just an unacceptable nonsense. Nobody owns you. It is one of the psychological pressuring strategies many employers use. Most of them do not even realize it, they think they are just talking honestly. But is not okay. It is NOT okay.

No proactivity on position fitting

HR is a hard, underrated field. A typical problem is that HR people usually do not have enough technical knowledge to be part of the technical selection. They just have a list to be used for preselection before the technical interview. The manager, participating in the selection usually has the very same deficiency. Technical competency becomes an isolated issue. Hence, the selection process is always about one role and nothing but that specific role. Sometimes even competent people lack the fantasy to think out of the box. I know usually it is "good enough". But sometimes it's a lost potential to find a more fitting job-employee coupling, making the company and the employee happier and more productive.

This problem is deeply connected with the oldschool subconscious misbelief that even though a new hire may mean a higher salary, it should not mean a position promotion - that only happens in-house with colleagues "we already know". It is funny, because in management roles it is not such a special thing. Somehow managers tend to think that the gap between two management roles is always smaller compared to become a manager from a professional role.

It is also a huge factor that developers are valuable properties. Companies do not want to invest to train someone to be a junior developer (they believe that the cost is too high compared to hire an already skilled developer), neither to let a developer to make a career shift to something different. (For the same salary??)

I deeply believe it is not the way to handle people. Developer knowledge could be something very useful in other roles. I do believe that some level of coding knowledge should be expected in all the roles of a software company. It will never happen if you do not encourage developers to think about seeking challenges in other fields.

No response, no feedback

It should be always a priority in every situation to answer the questions, to get and to give feedback. Especially in a profession which is highly competitive and has many requirements. Still, I see managers giving no feedback, answering no questions about why and how they made tech-heavy decisions, communicating work problems only by firing and of course, never telling an applicant why wasn't chosen.

Many applicants never get answers to their applications. It is quite funny, because nowadays hiring is highly automated, everything goes through series of applications. I am pretty sure there is an option to select all the applicants and send them a group mail like "sorry, we chose another candidate for this role, so do not wait for our call". And if you already interviewed them, you have to write them at least 3 points about what they should improve.

No direct contact

Job search websites, Saas tools and recruiter companies make a good fortune from finding people for companies. It makes sense. There is a big shortage of programmers, companies are happy to pay to make someone else to do this pretty often unsatisfying job.

The weird part is:

Sometimes I find jobs another way. I make my research on the company website, checking what they do, check the job description there and if it looks good, I send them an email or fill a simple contact form. It is also a form of impressing the company. if I have some extra motivation about what they do, writing an extra mail on the top of the Linkedin application, providing and asking early information is a good way to show it.

I would expect this is a good approach, welcomed by the company. Experience is quite the opposite: usually I never get an answer to such bypass contact attempts. Companies are so commited to have A Process with services they are paying for, that they forget to open their damn mailbox, checking if their webforms are working, or even giving a chance to contact them. It is a typical low-hanging fruit companies simply ignore. I hate it, because it bars me from giving the extra attention, extra opportunity for the companies I like.

Checkboxing interviews

You have a call with a recruiter. Fine. It is the recruiter's job to do a preselection with professional recruiting knowledge the company does not necessarily possess. Pretty often the company just want someone outside to make the dirty part of this job, so they can concentrate on the best candidates only. You, as an applicant would expect to have it as much efficient as possible with people who communicate well, as it their job and profession.

The reality sometimes is the opposite. You have a call from someone who communicates terribly and instead of inducing the applicant to talk in a relaxed way about work, professional goals etc., unintentionally providing extra information, it is all about filling a form. How much experience you have in Javascript? Three. How much experience you have in API development? Four. Do you know any design patterns? Yes, blablbla... does it make any sense? All these information could be filled in a web form oh wait you already did it, this is public data about you on Linkedin! it was in the CV you sent them, and you also told the recruiter some of them in your introduction about yourself.

Some elements, like design patterns are not necessarily mentioned in the CV, but does knowing the name MVVM or knowing the definition of it actually matter? Don't think so. If you actually worked on a project using MVVM, using Microservices, using APIs - that matters. But for that you have to talk about the project with someone knowing what these things mean. Programming principles and patterns are not something like knowing or not what happened in 1492. They are just guidelines, short wordings of how to do your job well. If you actually do your job well, you don't need them. If you don't overcomplicate your code, you do not need to learn K.I.S.S..

The most ugly part is when they try to ask some smart interviewer questions you know:

• Can you recall a situation when you contributed above expectation?
• What was the biggest performance problem you've solved?
• What are you the most proud of in your work?
• Tell me three of your weaknesses and three of your strengths!

...and you can see and hear that they are reading it from the screen. These overused, Control C Control V, supposed-to-be-smart questions. And they would like to use it to judge your personality and knowledge. Ridiculous. They see people as checkboxes. "if she does not remember an above-expectation contribution and was proud of her json processing code, then she is good to backend engineer, but not good to be a manager as she's not a teamplayer". It does not work this way. It is the poor shadow of an actual interview, finding out the reality of how does the applicant think, work, communicate. Just imagine what your partner would say if you were asking the same way on a romantic dinner. Wouldn't really work, would it?

Testing coding skills with puzzles - You expect applicants to be geniuses

It is a quite frustrating topic. Of course senior software engineers would like to measure coding skills of the applicants to be able to hire them. But measuring skills is not something software engineers know. It is something teachers know. It is the root problem behind many coding challenges and interviews.

Unskilled interviewers are looking for fun and surprising smartness - not knowledge, not experience. What they have in their mind is pretty often not finding a skilled person, but to find a genius, a talent. They don't know what shows the knowledge of the people which matters, they know what feels smart for themselves. Real-life coding practice is not about interesting puzzles. It is about recurring problems, which are usually very similar. You are a good coder if you know the patterns and you can easily apply them to the actual problems. Actually, that's what engineering is about, hence software engineer.

So what do these puzzles actually measure? Well, I made it clear that it should not be expected from an applicant to solve a problem in a live interview or in an online coding challenge (with time limit) which is puzzle-like, which needs a big idea. What they actually measure then?

• did the applicant read a lot about such puzzles. Which has nothing to do with real-life work. This very problem is already known by the applicant, so there is no need for him/her to produce the solution alone
• did the applicant cheat, googling the puzzle on the internet

I think it is clear, that neither has anything to do with job competence.

If you would like to measure the knowledge of someone, then... yeah, first ask a damn teacher on how to do it, or someone who has at least a basic understanding about people. If you would like to do it for yourself, well, then come up with something simple, boring, everyday coding problem. Like a data function which needs a filtering and a mapping.

And of course you can also write a long, public document what you expect for a given role. You can use sources for that like Freecodecamp's developer roadmaps. It is a fair and transparent way to communicate your needs, to recognize yourself what do you need, to have a cheatsheet you can use for an interview.

Do not ask "Google brainteasers"

Big tech companies got famous about asking unexpected questions like "what is the weight of New York?" or "How many golf balls would fit into a Boeing 747?". It became a trend, thousands of companies use such questions worldwide, assuming that these top companies cannot be wrong.

...well...

The HR VP of Google himself said the following in a New York Times interview: "On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart."

Simple anti-patterns

Okay, these things are not tragical. You will meet them and mostly you will have to accept them. Still, I think it's worth mentioning them to educate people, to make it visible when you make people's life harder without a good reason.

Abbreviations, abbreviations everywhere!

Let's face it: people like to speak shorter, especially about stuff which they have to deal with every day. Having complex name, abstract content. Especially if new technologies are popping up, we like simple, short names for them. So we use abbreviations and fantasy names: React, Django, EC2, EBS, FPS, ASAP, etc. But please ask these questions before creating a new name:

• is it a unique identifier?
• does it say anything about the named object? At least ringing a bell?
• does it relate to the named object and not anything else?
• do you communicate well that an abbreviation is interchangable with the term and used on a regular basis?

These are important questions. I hate AWS names with passion because Amazon made learning and understanding hard with using terms like EC2. Even Amazon Elastic Compute Cloud is highly... imperfect, but EC2 is the worst. Especially next to its friends: EBS, AMI and so on. Such things should be named a way that it gives you a guess on what it actually does. Amazon Elastic Compute Cloud / EC2 is just as helpful as Fancy Cloud Hakuna Matata / FACHAMA.

Another typical example: naming a team by their project in a big company. Then the project is done... and they still have the name which has no relation to them. Maybe even the project is took by another team.

Uniqueness: It does matter. At most companies you will meet servers called Jupiter, Saturn and so on. I don't like it but it is not a problem. BUT: do not name your project if a related technology already has that. You should not call your project nodeAPI for a java spring boot API (no, it is not good for a node project either). You should not call a javascript project as Apollo as there is Apollo Server for Node projects (and it is pretty likely that you also have a server called Apollo in the company. It is not that hard to find unique names! Investigate related technologies and put their names on a blacklist. You should try first a naming which reflects the role of the given technology, team etc. in its context. If you have multiple names in a structure, try to name the whole as something and name subelements based on their role. Subelements can have boring names too, like workingHours_nodeApi, workingHours_reactFrontend. I you need fantasy names, forget big cats, all the "glorious predators", stars and planets in this Galaxy, forget favourite movies of nerds' (nowadays they name projects after characters in Marvel movies, lately Terminator was the fancy one) and forget the biggest cities. But there are endless number of not-so-popular animals. There are many culturally interesting places. There are oldschool actors. I never met a project called Humphrey or Aretha but I would love to see them. No servers called opossum or hawfinch or seriema.

Job fair cutting edge fancy pants

Everybody loves AI. and AR. And Blockchain. And game development. Market share of these technologies? Oups...

Tech companies on job fairs are traders with products - the product is the job. They would like to tell you that what they do is super-exciting, it is the latest technology. Be clear about that: it is a lie. Most of the companies work on usual issues. Which is not a problem! It is a common misconcept that all the developers are interested only in the fancy stuff. Of course your company will come out with it best aspects, it is also not a problem. But you should make the whole picture available. Your job fair guys should talk about the everyday reality, the actual possibilities, technologies and so on.

It is terrible that you cannot have answers for the very basic questions about a company: What does it Actually do? What kind of jobs does it offer? Which technologies does it use? How you should prepare yourself for these things to fit your future career?

It is just like any other products: if it is all about the packaging, people will tend to hate it, most terrible people will love it. Not to mention: IT is Information Technology. Give us information. Please.

Delusions and self-deceptions in development

Denying how much we follow trendy solution stacks

Most job descriptions you read will say something like "Node.js, Express.js, MongoDB, React.js, Material UI" about the tech stack. We got used to it, we accept it. Some may say "we use MERN stack", or mention MEAN, LAMP. Is this sufficient information, or something else? I would argue that these descriptions have two problems.

• Knowing in time that job you're applying for

They are not about providing detailed information how the product, the development works, what you should expect in your job. That would include things like number of the APIs running, number of the Lambda functions running, CI/CD tools used, connected third party services etc. This is rather a filter to deter people from applying to the job, who reject the job because of these basic elements.

It is okay to limit stack information this way, but in the interviews you've got to say more. Companies should provide recruiters not only these basic job descriptions, but also a much more detailed information kit. Not only detailing technology information, but also saying more about the team structure, number of employees, number of developers, their seniority levels. This is something that would make interview much more useful. Especially recruiter interviews, which nowadays are quite ridiculous - they are about telling you again what you could have read in the job description; and asking questions which could have been asked in a chat message.

I also believe that companies do not create such information kits because they do not understand their development properly. Even though there are decent tools to measure usage of the services, quality of the code etc., many teams do not use them as default, do not understand how much it matters. And of course management like to handle them as secrets. Bragging with big numbers is okay, communicating clear numbers to provide transparency is not...

• decision about innovation investment

The other problem is that companies - developers - do not realize how much they follow common stacks, or at least they do not talk about it. MERN or MEAN are mostly mentioned in training titles only, while if you follow job descriptions, you'll evidently see these recurring patterns (In the middle 2010s people loved spring boot with Postgres, then changed to Node.JS / Express with Mongo, now most job descriptions mention Typescript and Nest.JS). Following such stack models is the part of your coding strategy: do you have a company which allocates resources to this kind of innovation or not.

It is not a crime if you don't do it. The problem happens when you don't have a decision how much effort you put into it. Then the developers may not know it when they join your team, and they won't know how to make development decisions. I saw innovative code in a company which did not handle web development as priority and which had a small web team only. In such cases team changes are huge risks, because the code is not self-explanatory and maintenance overhead is bigger.

Some developers are stubborn. They want to make independent decisions. It is understandable that companies wishing to hire people would like to impress them with the promise of high autonomy. But unlimited technological autonomy is an illusion. A lie. By a senior colleague (primarily CTO or architect) main technological limitations are already made. This leader and the management have also something in their mind about how much investment is acceptable in the development. Even though this is what they mean, they may not say it loud publicly.

I believe that companies and tech leaders should be conscious and transparent about such limitations from the very first company interview. These effect your daily life as a developer: what you code, how you code, when you say No to your manager. This is also essential for the company to have the code base they decided to have.

Anyway, it is also a way to help development communities to build and accept together very well-defined coding patterns. Coding monkey shaming is still a thing, but trust me: following reliable patterns is not a bad thing, it can make development safe and fast. The problem is not pattern usage, the problem is doing it blindly.

Treat every human error with a technical solution

Software engineers tend to love technology too much. I am fine that they like to solve problems, but pretty often they just wanna hammer everything as a nail.

For example:

• Overtesting | Developers tend to follow TDD as a cult. TDD is a smart method and testing is essential. But using it every time, everywhere, competing on code coverage, trying to test code elements which are actually external libraries... does not make any sense. Tests should help your development and guarantee quality. Do not test if it is not directly helpful! Don't build complicated systems into your unit tests which you cannot easily read!
• Building weird integrations | Developers tend to come up with ideas like "let's get an email, a Slack message and a homing pigeon if the build fails"... even though you only have builds once in 4 months with twelve people staring at the screen in a meeting room. These ideas come up when you miss once failed build and spend 10 minutes to find the error. Please, guys, accept that you are human. Do not build extra complexity to sleep better (spending two days with something you do not need but which will crash 3 times this year, resulting 2 weeks of extra work)
• Change to a new framework/language! This one is baaaad | I mostly see it among OOP people, starting to work in a script language after Java, C++ or others. It makes sense to consider new technologies, you should do it all the time. But if you do it because you are not aware of the actual language's behaviour, then you are just enforcing your personal taste while being lazy and ignorant. It is a really hard discussion, because OOP is still dominant in formal education and most seniors have deep OOP roots. The problem is not OOP. The problem is lack of flexibility and self-awareness. Script languages are also quite good and you should not change unless you do know that there is an objective benefit behind changing your main technologies.
• Automating things which are not to be automated | Automating is our daily job, but we should not spend time on automating stuff which does not provide benefits or which creates overhead. Pretty often the best thing you can do is to read the code again and validate the results with independent manual checks. You can even do it as a regular habit. The mantra is automate it if you do it the third time, but it is not always true. It makes sense to keep manual checks amongs steps of automated processes.
• Generative AI Fetish | In the recent moments we hear 'just ask ChatGPT'. It is a quite dangerous habit. Of course you should ask ChatGPT to answer a question or to do your job faster. The bottleneck is that you should still know how you would solve the problem. If you do not know how you would do it, you do not know how it is supposed to look like. If you don't know this, you cannot validate results - you get mesmerized by the shiny result and you ruin your work with it. I saw IT people copypasting code from ChatGPT without investing 5 seconds reading and understanding the generated code. It is even worse when these guys have to do something not-IT-related. Developers and managers tend to blindly accept the ChatGPT result and just copypaste it for everybody like ultimate truths. For traditionally undervalued professionals (HR, Marketing, Copywriting, Graphic Design) it is just another curse. Their managers believe that their value is creativity and after generative AI this function can be replaced. Ignoring the fact that their biggest value is their professional knowledge to create, evaluate, analyse and restructure existing solutions.

TDD hallucination

TDD is a tool for a developer who knows what to implement, has the clear contract and an outline in mind (or in a task description) of the feature. Writing the test first is a challenge, a self-check for the developer that the abstraction is correct, independently from the implementation.

This only work this way. If the developer doesn't have a clear plan, doesn't understand the functionality in depth or simply too junior to be able to write the test first, TDD approach is a catastrophy. This ends up by writing a test, then writing an implementation which does not fit the test, then changing the test and the implementation at the same time so they are fitting and they are correct. Which means you are spoiling the whole concept of TDD.

TDD is not magic. It does not guarantee you perfect code or less failure by definition. If you are not super confident about the task, don't do TDD. It is not a crime to implement first, then go for testing.

It is even worse if you force a junior to do TDD. That person is just learning how to implement and test. A junior should do lots of implementations, then lots of tests, also lots of work on the project to be able to read any project, know the specific project. Have some success. Only after is it possible to imagine the next feature and start with the test.

Software engineers are smart

Software engineering is a profession. It requires technical knowledge, some basic skills in maths, thinking in logical structures. It is becoming more and more important, it supposed to be part of mandatory education. There are still a lot of people having minimal knowledge about it.

It creates an environment where several people are blindly believing in engineers, not measuring their skills and capabilities properly. Hence investing in nonsens, giving power to mediocre swindlers, giving power to people gaslighting others and so on.

Software engineering is a profession. People learn it and then go to work. You should respect their expertise, but they are not smart in everything and definitely not geniuses. Pretty often they are not even very smart in their own profession. Just self-confident ones because in all their professional lives they got biased feedbacks.