This post originated from an article here on Habr. Quite an ordinary comment, except that several people immediately suggested that it would be great to format it as a separate post, and MoyKrug, not waiting for that, shared this very comment separately in their VK group with a nice preface.
Our recent publication featuring a report on IT salaries for the first half of this year gathered an incredible number of user comments on Habr. They shared opinions, observations, and personal stories, but one comment stood out to us so much that we decided to publish it here.
So I finally mustered the strength and wrote a separate article, elaborating and justifying the thoughts in more detail.
Sometimes, in articles and comments discussing the incomes of IT professionals, you can encounter statements like, 'Where do you get those figures? I have been working in X for many years, and neither I nor my colleagues have ever seen such moneyâŠ'.
To be honest, I could have written a similar comment N years ago. I can't now đ
Having gone through various workplaces, organizations, and life situations, I personally formulated a simple set of rules on the topic of 'what to do to earn decent money and work in comfortable conditions in IT'. This article is not solely about money. In some points, I touch on the possibility of improving one's professional level and learning new in-demand skills, and by 'good conditions', I mean not only a cozy office, technical equipment, and good social packages, but primarily the absence of nonsense, mental peace, and overall nerves.
These tips are primarily relevant for software developers, but many points will also be suitable for other professions. And, of course, what I've outlined primarily pertains to Russia and other ex-USSR countries, although some points will be relevant everywhere.
So, let's get started.
Avoid government and quasi-government institutions and similar establishments from a mile away.
First of all, when funding an institution from the budget, the upper limit on salaries is naturally restricted â "there's no money, but keep holding on." Moreover, in government institutions and similar organizations, salaries are often tied to staffing schedules. It may turn out that the document states that a programmer earns the same as a clerk, and there's no way to change this. Some managers, understanding the absurdity of the situation, semi-legally hire IT specialists at one and a half to two full-time positions, but this is more of an exception than a rule.
Secondly, if the institution does not operate in a free competitive market, its leaders are unlikely to have the goal of improving the quality and competitiveness of products and services (the goal may be to at least not let this quality drop below a certain level to avoid reprimands from supervisory authorities), and consequently, they will not strive to hire the best employees and motivate them financially or otherwise.
Due to the lack of focus and motivation of the leadership on quality and results, and the fact that they are essentially spending not their own, but others' money, you often see such a phenomenon as placing children/relatives/friends, etc., in "comfortable positions" within the organization. However, work still needs to be done somehow. Therefore, it may happen that a person who comes in from the street will have to do the work for both themselves and their colleague. Additionally, it is unlikely that they will be surrounded by high-class specialists from whom they can learn a lot.
In the case of employment in a private company working on government contracts, unfortunately, one can encounter a similar situation. If the company wins orders and tenders because "everything is already arranged," we effectively return to the scenario of "no competitors" with the corresponding consequences. Even if tenders are awarded fairly, it should not be forgotten that the winner is often the one who offers the lowest price, which may mean that the first cuts will be made on developers and their salaries, as the goal will not be to "create a very good product" but rather to "make a product that at least somewhat meets the formal requirements."
And even when a company enters the free market and faces competitors, the mindset of management and their attitude towards employees do not always change accordingly, often with unfortunate consequences. The concept of "Soviet management" sadly comes from real life.
Sometimes, it happens that in a state-owned company, even ordinary employees can earn quite good money by local standards (for example, in the oil and gas sector). But unfortunately, "Soviet management" remains pervasive, and one can often encounter administrative absurdity, such as 'working hours strictly from 8 AM, a one-minute lateness results in a bonus forfeiture', endless writing of memos and shifting of responsibilities, and attitudes like 'we pay a lot, so you should work even more, overtime will not be compensated' and 'if you donât like it, no one is holding you here.'
If you are a programmer, do not consider positions in companies where software development is not the main source of income.
⊠including various research institutes, design bureaus, engineering firms, factories, trading companies, shops, etc.
There is even a joke circulating in one community.
«If your position is not called "Senior Developer" or "Team Lead", but "Engineer of the 1st category" or "Leading Specialist in the Information Technology Department", then you have taken a wrong turn somewhere.«
Yes, itâs a joke, but there is a grain of truth in every joke.
I define the criterion of "main source of income" quite simply:
it is either
- the company genuinely earns most of its revenue from selling its IT products or services, or it is involved in developing all of that on a contract basis.
or
- the developed software is one of the important or even crucial elements determining the consumer properties of the product or service.
Why such advice?
First, read the excellent publication , it really captures many differences of non-IT companies well. If you have worked in IT companies but have always seen the points listed from 5 to 13 described in that article, then that is already a reason to think twice and study the surrounding world and the labor market more closely.
In pure IT companies, people directly involved in software development (developers, testers, analysts, UI/UX designers, DevOps, etc.) are the primary driving force. Their work generates revenue for the business. Now, let's look at a non-IT company. They primarily earn money through reselling something, providing non-IT services, or producing non-IT products. In this company, IT specialists are seen as support staff; yes, they are needed to enhance efficiency (for example, through automation, automated accounting, online order taking, etc.), but they do not directly generate income. As a result, the short-sighted managementâs attitude towards them is likely to be just that â as something to spend money on. account for spend money.
This is very well articulated in the aforementioned article:
The conceptual difference between an IT firm and a non-IT firm lies, of course, in the fact that in an IT firm, as a programmer, tester, analyst, IT manager, or whatever, you are part of the revenue-generating budget (at least for the most part), while in a non-IT company, you are merely a cost item, often one of the most noticeable. Consequently, there is a corresponding attitude towards internal IT workers â they are seen as some kind of freeloaders whom we, the business, are forced to pay out of our own pockets, and they even dare to want things for themselves.
Often, the management of such a company has no understanding of IT and software development, which makes it difficult to convince them of the necessity of anything. Furthermore, the mere creation of an IT department may not go the best way: a person is hired as the head of this department, whose skills the management cannot properly assess. If they're fortunate, they will assemble a good team and set the right direction for development. But if they're not, it may happen that the team appears to be developing something, and the product seems to work, but in reality, it's marinating in its own juices, isolated from the outside world, not really evolving, and truly knowledgeable and talented people do not stick around. Unfortunately, I have witnessed such situations firsthand.
How can this be identified in advance, at the interview stage? There is a so-called , but it must be acknowledged that it is very superficial, and in reality, there may be many more factors to check and warning signs, but that is a topic for a separate article.
I would like to say a few words about various engineering companies, manufacturing associations, research organizations, design bureaus, project institutes, and everything of the sort. In my experience, there are several reasons for 'why one might not want to go there, or at least think very carefully before doing so.'
Firstly, once again, there is often a sense of ignorance and technological backwardness. Whyâthis is a separate question and deserves a good article, but people regularly express their opinions on this topic even here, on Habr:
"I will reveal a horrifying secretâthe embedded software is tested at least an order of magnitude less and worse than any shabby web server. And often it is written by dinosaurs, who think that debugging is for the weak, and 'if the code compiles, it means everything works.'
... I'm not joking, unfortunately." []
"Nothing surprising. In my observations, many 'hardware engineers' believe that producing a device is an art, accessible only to the chosen few, while writing code for it can be done by them, just like that, off the cuff. It's just a trifle. The result is a quietly terrifying mess. They get very offended when it's explained to them why their code stinks, because... well... they made the hardware, so what, just some program." []
"From my experience in academic work, I can say that when one to several people work on a task, there's no talk of code reuse. They write as it comes, using the minimal capabilities of the language, and most are unaware of version control systems." []
Secondly, everything often boils down to management and established traditions:
The development of equipment related to statistics is often a self-sustaining, self-financing Russian enterprise with Russian clients, a Russian market, and a Russian managerâtypically a former engineer aged 50 or older, who previously worked for little pay. Therefore, his thought process is: 'I've worked hard all my life; why should I pay some young person? Theyâll get by!' Thus, such enterprises generally lack substantial funds, and if they have any, they will certainly not invest it in your salary.]
Moreover, in such places, programmers and other engineers are often not differentiated. Yes, certainly a programmer can also be considered an engineer, and even the term 'software engineering' implies that. In both cases, individuals are engaged in intellectual work and the development of new entities, requiring certain knowledge, skills, and mindset.
However, the nuance is that in the current job market, these categories are compensated very differently. Iâm not saying it should be like this; I personally believe it is wrong. Unfortunately, at this moment, it is a fact: salaries for 'programmers' and other 'engineers' can differ by one and a half to two times, or sometimes even more.
In many engineering and quasi-engineering enterprises, management similarly does not understand, 'why should we pay them twice as much?' Sometimes itâs even 'whatâs the big deal, our Vasya, the electronics engineer, can write code just as well' (and Vasya wouldnât mind, even though heâs not a software developer). ).
Jef239 engineer in St. Petersburg,' when in reality, if a company values and respects its employees, it should pay '... above the average salary for a programmer in St. Petersburg.' A very telling image that circulated a few years ago in various process control social media groups speaks for itself.
Do not work with military clients.
This conclusion I made for myself back when I was a student on the military department at the university đ.
In fact, personally, I have never worked with military-related contractors or private firms in that field, but my friends have, and from their stories,
In fact, I personally have not worked in military-related agencies or private firms with clients in this field, but my friends have, and from their accounts, like "There are three ways to do anything â correctly, incorrectly, and the Army way" and "I'm going to gather a select group of limited individuals to figure things out and punish whoever I need to!" did not arise from a vacuum.
In my case, interviews with such companies usually ended with the necessity of falling under secrecy forms. Moreover, the interviewers solemnly assured that "the third form is purely a formality, it means nothing, you won't even be asked about it, and you can travel abroad without any problems," but when asked, "If it means nothing, then why does it even exist and why sign it?" and "What guarantees are there that considering the madness happening around, at some point the legislation wonât change and everything wonât be different?" no answers were given.
Do not work as a "jack of all trades".
⊠this is when you are simultaneously a programmer, an admin, a network engineer, a hardware buyer, a cartridge refiller, a DBA, tech support, and a telephonist. If you find yourself doing "everything at once" in your role, you are likely not an expert in any of these areas, meaning you can potentially be replaced by several students or juniors, which isn't hard to find even for a small amount of money. What to do? Choose a narrow specialization and develop in that direction.
Start learning a more relevant tech stack.
⊠if you are working with legacy tools. For instance, it happens that a person is coding in some version of Delphi 7 or ancient PHP versions with equally outdated frameworks. Iâm not saying that this is inherently bad; after all, the principle of "if it works, don't touch it" still applies, but when an ancient stack is used not only for maintaining old systems but also for developing new modules and components, it raises questions about the qualification and motivation of the development team, and whether the company even needs good talent at all.
Sometimes there is a reverse situation: you are maintaining some legacy project on legacy technology, and you are doing quite well (perhaps because no one else wants to step into that quagmire), but when for some reason the project or the company dies, there is a significant risk of finding yourself in a tough spot, and returning to harsh reality can be very uncomfortable.
Do not work in small and medium companies operating in the domestic (Russian) market.
Here itâs quite simple. Companies operating in the international market have an influx of money in foreign currency, and considering the current exchange rates, they can afford to pay their developers well. Companies operating in the domestic market have to catch up, and while large and wealthy companies can afford to pay competitive salaries to retain good specialists, smaller and medium-sized ones unfortunately do not always have that capability.
Learn English. Even if you donât particularly need it right now.
English is very useful for a modern IT specialist: the vast majority of documentation, manpages, release notes, project descriptions, and everything else is written in English. Top books and scientific papers are published in English (and they are not always translated into Russian, let alone being translated correctly), world-class conferences are held in English, the audience of international internet communities of developers is hundreds of times larger than the Russian-speaking community, etc.
I would like to draw your attention to another fact: there are numerous companies with exciting challenges and attractive salaries that will not even consider you without knowledge of English. These include outsourcing companies, integrators, branches of international firms, and simply businesses operating in the international market. In many of them, you often have to solve tasks in a team with colleagues from other countries and frequently interact directly with clients and their specialists. Therefore, lacking a good command of English, you immediately exclude yourself from a significant portion of the job market, particularly in areas where you can often find very interesting projects for very good pay.
Moreover, language proficiency opens opportunities to work on international freelance platforms and remotely for foreign companies. And it also gives you the chance to pack your bags and relocate to another country, especially considering that even those who previously would never have thought of such a move are doing it nowadays.
Don't be afraid of 'galleys'
Sometimes, there are opinions that so-called 'galleys' (companies engaged in consulting, outsourcing development, or selling their specialists' expertise as outstaffing) are lousy, while product companies are great.
I disagree with this opinion. At least two places where I worked for quite some time were indeed these 'galleys', and I can say that the working conditions, salary levels, and attitude towards employees were very good there (and I have plenty to compare with), and around me were very pleasant and qualified people.
Don't think that if things are not great at your current job, it's the same everywhere.
Perhaps psychologists will someday study this phenomenon and give it a name, but for now, we need to acknowledge that this phenomenon indeed exists: sometimes people work in a place they are not very satisfied with but believe that 'it's probably the same everywhere' and 'what's the point in switching'. I'll say it simply: no, it's not the same everywhere. To confirm this, let's move on to the next points.
Go for interviews
⊠just to gain experience in interviewing, learn about requirements and salary levels in different places. No one will throw stones at you if, in the end, you receive an offer and politely decline it. However, you will gain valuable interview experience (which is important, yes) that may come in handy at some point, you will hear about what other companies in your city are doing, find out what knowledge and skills employers expect from candidates, and most importantly â what money they are willing to pay for it. Donât hesitate to ask questions about how processes are organized within the team and the company as a whole, inquire about working conditions, and request to see the office and workspaces.
Research the market and know your worth
Look into Headhunter, My Circle, and similar resources to get an approximate idea of how much what you know and do is really worth.
Do not be intimidated by large numbers in the salary offers section, even if it turns out that some company promises to pay you much more for the same work you are currently doing. Keep in mind that IT is one of the few industries here where it has become a norm that if a job description states the company is willing to pay a specialist 100-150-200 thousand, they are likely actually ready to do so.
Do not undervalue yourself
See. , which has already been covered in articles on Habr. Don't think that you are somehow inferior, less qualified, or lacking compared to other candidates. And especially donât base your salary requests on these facts; instead, _always_ aim for an amount slightly above the market average, while clearly indicating that you are open to discussion.
Donât hesitate to negotiate with management for a raise
Don't just sit quietly and wait for someone above to have a revelation and raise your salary on their own. A revelation may come, or it may not.
Itâs quite simple: if you believe youâre underpaid, tell your management. The reasons for "why I think I should earn more" donât even need to be invented; they can range from "over these N years, I have grown as a specialist and can now handle more complex tasks and work more efficiently" to "other companies offer this amount for the same job."
In my case, this always worked. Sometimes immediately, sometimes after a while. However, when one of my colleagues, tired of being broke, found a new job and laid his resignation on the table, they were very surprised and asked, "Why didnât you come to us about a raise?" They persuaded him to stay for quite a while, even offering a higher salary than the new offer.
Consider relocating or switching to remote work.
If the scarcity of job openings in your city is the issue (in other words, if there arenât many "other places" where people with your qualifications are needed or it's hard to get in there)⊠then improve your skills and consider moving to another city if possible. I personally know people who moved from million-plus cities to St. Petersburg and Moscow with a twofold increase in income, even when taking a lower position.
Again, donât fall for myths like "in capitals, salaries are higher, but costs are also much higher, so itâs not beneficial at all"; read the comments to , as there are many opinions and stories on this topic.
Study the job market in major cities, and look for companies offering relocation packages.
Or, if you are already an established and experienced professional, try remote work. This option requires certain skills and good self-discipline, but it could be quite suitable and beneficial for you.
Thatâs all for now. I want to reiterate â this is just my opinion and my experience, which, of course, is not the ultimate truth and may not align with yours.
Related materials:
â
â
â
Source: habr.com
