Extremes and excesses
A great number of paradoxes and contradictions are born in businesses when trying to answer this question. Decisions become extremes: professional criteria are lowered and, primarily business tasks are solved. Another extreme is increased requirements taking no account of the market and often appearing because of paranoia and narrowmindedness. This leads to the destruction of the basic idea of a company and many of the decisions become excessive. Concepts become vague: product quality and value, practicability to use technologies and developer’s level. For example, the product was being produced but the main client had a lot of own needs, which led to a technological and functional adjustment. Many big players dream of doing their products but business hampers them.
But let excuses be excuses. There are good projects as well as excellent professionals! Softmotions are unknown but we try to open to people a new oasis amid the huge and motionless Enterprise-juggernauts. It’s a matter for us to be flexible and able to change.
Staying aside of “hype-rays” and rarely being in the recruitment market, our team have always thought that IT environment has already educated engineers. Certainly, a great number of Java projects and endless PR-companies of different businesses make us think that all the developers are already educated and they should not be explained simple things.
But IT world largely develops by the laws of playwriting and that’s when the problems not connected with development appear:
- The number of non-core and unprepared specialists, who evolved to developers, has achieved the tipping point. People are now not embarrassed to send CVs with “a machine gunner” as their experience.
- The specialists who labelled themselves as “Senior” appear to be “juniors”. And there are many reasons for that: “my company said I am a senior”, “I can solve any problem on Java”, “Yandex is waiting for me”. Some are more honest: “Of course I am a junior but I am paid as a senior — what can I do?”
Let’s come to the roots and we might understand something:
It is all simple: not to live in the realm of illusion, a person must create something, no matter if they are a writer or an engineer. It means:
- Engineers think projects not businesses, missions, etc., so they can define the entry point of their effort.
- An engineer must know what context is and must not suffer from “vacuum syndrome”, which is often manifested in obsessive urge to use concrete technologies. The solution quality is measured by its congruence to the context, which can be changed.
- Between the routine and interesting tasks, an engineer sees the right connection. If there is none, he expands the context and finds the contradiction. Interesting tasks are not a whim but the meaning of activity. Without them an engineer turns into a coder or a framework user and the business starts to parasite on the market body.
- An engineer has the correct understanding of fundamental knowledge as of an instrument enabling to create. To confirm this opinion a “Yandex” developer, who often holds job interviews, commented on the problem: “The point is that people often consider a very limited number of solutions and don’t have a clue about some real facilities of the language.”
An engineer needs to move in these directions — if they are a Junior or a Senior. Unfortunately, hype-rays create radio noise among people and make it difficult to assemble an engineer team. But this is a great chance to launch new companies and projects for the people who are tired of paradoxes and contradictions.