The key skill of a successful career in IT or 8 mistakes on projects
Greeting! If your veins are full of Olivier, but you don’t feel like working full-time yet, or you just want light, useful reading with cats, then this article perfectly fits this description. In it, I will try to use real examples to talk about one skill that I consider key to working in IT, and which is not given as much attention as it deserves. Techies like to talk about architectures, patterns, programming languages, but sometimes it’s not the same.
This core skill will come in handy for everyone in the industry—programmers, leads, product developers, testers, management, and everyone else.
This skill is called common sense.
Yes, it’s that simple, but it’s actually not that simple at all, and I’ll explain it now.
- 1 How to do good immediately
- 2 1 – An idea that will have to be dealt with
- 3 2 – It must be done urgently
- 4 3 – We have to work under high load
- 5 4 — Everything must be burned and rewritten here
- 6 5 — Inability/unwillingness to understand someone else’s code
- 7 6 – Localization of the problem during slow operation
- 8 7 — Cover the entire project with tests/documentation
- 9 8 – Technology for everyone
- 10 Conclusions about common sense
How to do good immediately
Let’s get straight to the career: for 16 years in the industry, I have seen from the inside several hundred different projects and teams — successful and not so successful, large and small, with a lot of integrations and different architectures and approaches. And all these projects had one thing in common – what was in them nothing in common at all was not among themselves.
Unfortunately, people believe a lot in different stereotypes, and there is often a big stereotype in IT that there is one proven way to do everything at once as it should be.
But there is a big problem in that as it should be everyone has own and there is simply no single recipe here. And this goal-setting, and at the micro and macro levels, together with the ability to ask the right questions to the right people, is the most important skill. Because the ability to stop, assess the situation and repeatedly ask yourself and others the question “why?” – it is often strongly modifies our plan that we will follow.
For myself, I call it “technical management”, that is, this is a person who is able to speak equally well in different languages - designer, programmer, marketing, business, and so on. Most often, people love their circle of communication, but do not understand the nuances and specifics of the work of their neighboring colleagues (I would even say, with your permission, that often everyone mutually considers each other stupid pi%oras) and without a “translator” the same thing can be interpreted very differently by different people.
“They invented something there again, and we have to evaporate” – does it sound familiar? The ability to understand other people’s specifics, listen to people and get to the bottom of the problem, offer different solutions and find balance interests — all this helps a lot to find a common language with people and avoid career problems.
IT professionals are usually fanatics exact sciences, therefore, any given task is immediately perceived as is although in reality it may not be like that at all, it was simply put there as they could. That’s how they managed to set it up.
If you make a series of tags from primary questions with common sense, then something like this will come out: for whom are we doing this? Should work quickly or accurately? What is the cost of error? Why? Who is the customer of the feature? Who is the user? What load? What are the labor costs? What is the profit? Why so?
You can ask a lot of such questions, but let’s move on to examples of mistakes.
1 – An idea that will have to be dealt with
The greatest number of conflicts occur when people speak at different levels of understanding and when a task goes through the broken phone of other employees. Let’s say someone big let X task down through other employees, then many options are possible.
By X, exactly X was meant and it must be done strictly in this way
X meant exactly X, but in the process it was transformed by someone into Y, where Y can be both simpler and more complex
X is just a sample designation, it’s up to you
X is notation, it’s up to you, but someone cleverly rephrased it to Y, which is very complicated
There can be many options, but if you are tasked with doing something big (or critical) that may touch the core of technology or require major redesigns, common sense is exactly where you should start. Perhaps the task did not sound like that at first, the scale of the disaster is exaggerated, the urgency is overestimated, and instead of a week of work, a one-time compromise of an hour will be agreed.
It is always important to intelligently assess the real needs and deadlines of the tasks that come to you. And sometimes you have to climb on several levels “why“, because only there the real problem is revealed, and then they formulated it as best they could, distorting the entire meaning.
Most people though ready to listenif you are ready to talk to them calmly and reasonedly. Not everything and not always, of course, but before evaporating, it is worth trying.
2 – It must be done urgently
“Urgent” is very capacious a word in which different intervals can fit in the corporate world. For some, it is an hour, for others it is several days, so if they come to you urgent task – it is worth finding out exactly what is meant by urgency and by whom exactly.
My favorite case was when the manager had given a deadline in the form of “drop everything, it has to be done”, but after calling the customer directly, it turned out that their conference was in a month, and the first result was needed only in three weeks.
3 – We have to work under high load
The management is very ambitious, and the programmers are very enthusiastic, so doing big complex projects together is much more interesting than simple ones. Programmers are often given mythical expectations from management about millions of users and billions of revenue just around the corner, so it is necessary to immediately lay a very serious architecture under a serious load. And in six months, the budget for the development of the project burns up without a single living user.
How many good architectures and programming guides in projects have been burned by preparing for a load that never happened? Here it is important to understand that if you are a large company that is ready to endlessly pour money – no problem, but if such an architecture with a bunch of upstreams with geobalancers and sharding is trying to be made by a bare-bones startup (for which such an architecture is not an end in itself), then there may be something here not so in common sense and task setting.
4 — Everything must be burned and rewritten here
With such a cool idea, as a rule, new employees come to the project. Seeing the imperfect code, with a bunch of crutches inside, the winged employee offers to burn it all and rewrite it immediately normally. Ideally, rewrite immediately in another language, because dast/brainfuck/perl is especially popular this season. Unfortunately, such rushes without proper insurance and experience are almost guaranteed to lead to big problems, because at first everything is beautiful and good, and then life’s “urgently add”, “harden for the preza” begin, forgotten exceptions pop up and everything is all over again.
It is necessary to rewrite and refine the code, but large chunks/modules need to be rewritten very carefully, balanced and intelligently, because most often imperfect working code is written with someone’s “blood” and looks so bad for a reason.
A live case in a neighboring team: a person came, said that it was necessary to rework, under his charisma they began to rewrite in a new language, and the employee left after 4 months, leaving everything, directed by Robert B. Weide.
5 — Inability/unwillingness to understand someone else’s code
Understanding someone else’s code for a new project (especially without documentation and help from another employee) is a very boring thing. This is something that they do not like at all, so often small problems are solved by the aircraft carrier group.
For example, instead of trying to find a solution and fix it (for example, in the current script/framework), a new framework/library is pulled into the project and everything is redone on it. Moreover, labor costs can be the same and higher, but not to dig, but to create! All this is ok if it is a personal project, but when there are several people on the project or custom development, then you should think about it again.
New things often bring new problems. This is not bad, you just always need to understand whether it is worth it if everything can be solved with current means.
6 – Localization of the problem during slow operation
When something works slowly, most often the team immediately puts forward a working version of why – well, there is a fat request, or many connections, or a crooked module – it’s still obvious, let’s redo it.
When something works slowly – you can’t rush to rework without an accurate diagnosis, you need to delve into the layout of WHAT exactly with what timing works inside and, having collected some data, draw conclusions. Because a bold request can be larger in appearance, but fast-working, a crooked module can work perfectly, and the problem can be where you simply cannot climb without a microscope.
7 — Cover the entire project with tests/documentation
Tests are an important and good thing, but there is no reason to maniacally test everything in the world. More precisely, everyone has a meaning your. For tasks with a high cost of error, critical functionality and everything related to live money – yes, multi-step tests are necessary, but covering every function in the landing page with tests is superfluous. Tests require updating, so a balance is always important here.
The same is true for documentation – an open api should be well documented, but a text (not automatic) dock for each function in a project where the code is often rewritten – it is worth thinking about the feasibility of this once again.
8 – Technology for everyone
Since the field of my current work is ML and AI, I often come across the fact that there is an expectation from them that the technology will solve ALL problems in ALL cases. For example, by attaching a recognition system to a camera, you can solve everything that systems of this class can solve.
A simple motion sensor and a system for detecting a deviant meeting in a cafe are completely different (in everything) systems, the first is simply a change of the picture, the second should delve deeply into the analysis of what is happening. Therefore, it is necessary to immediately understand for which tasks and for whom on which equipment we are going to do something. If the software will work on a not the most powerful black-and-white camera in real time, it requires a completely different approach, so you need to approach the task accordingly.
Conclusions about common sense
Of course, the examples are very conditional and their list can be continued ad infinitum, but listing all possible connections of interests with problems was not an end in itself. I wanted to use examples to show that human interaction on complex projects in IT is always difficult and with a lot of broken phones, so common sense in all work matters is vital.
Unfortunately, projects rarely have technical management capable of understanding all the nuances of what is happening and correctly distributing tasks from all parts of the business. We are often given the wrong tasks and given the wrong tasks for various reasons and we just have to live with it. Ideally, to live well, happily and without new-fangled burnouts.
You always need to clarify why we are going to do something exactly Yes and what we want to get, because it often leads to a more accurate understanding of the task at all levels, and often to its complete reformatting, with further cost reduction, time reduction and saving the nerves of all participants in the discussion.
I want to wish everyone a productive year, less office battles and more interesting tasks that really make the world a little better.