What is more important: to know a programming language or to be able to solve a business problem?
There are a lot of controversies about how to learn a programming language to make a career in development. But I am deeply convinced that the required set of knowledge is not limited to the language. Unfortunately, not everyone understands this.
In discussions of tasks, business and developers speak different languages.
From a business point of view, it does not matter at all what language their task will be solved in. Business does not think, and perhaps does not even know about java, go, ruby ​​and other languages ​​and technologies. It's great for developers, of course, when a large-scale and interesting project starts from scratch and the technological stack is selected by the team. But in the real world it happens much more often than this. Usually the company already has expertise in a certain stack, which the IT leadership does not want to give up. The reasons may be completely different, from the ban on the “zoo of technologies” to the personal preferences of decision makers. There are also additional factors like the need for interesting technologies for teams, for the sake of attracting and retaining qualified personnel.
')
Developers for their part often express a desire to develop in a certain technological stack. This intention is reinforced by the large difference between salaries for some languages. So there are people who live hard, for example, in the framework of Java or Python (Go, Kotlin, Scala ... the list can be continued almost infinitely) and even Delphi, not trying to see, but what else is there?
In my opinion, the desire to go deep commendable. But sometimes “the forest is lost for the trees” - in the process of this immersion the specialist simply forgets that technology is only a tool for business to solve its problems. As a result, narrow-mindedness on one technological stack, complete with innate perfectionism (“let's do refactoring for half a year to a project that does not have serious development plans, simply because it will be nice”) are not the best way reflected in the quality of decisions made.
My point is that a particular programming language is secondary. Primary are the general understanding of the principles of development and the ability to solve business problems - knowledge of approaches and patterns that help systematize the overall work, experience in the use of various techniques, including command ones. With such baggage, one more language that is needed in this particular project is easy to master. Before my eyes are full of examples of how people retrain for other stacks in a month - two intensive training. Of course, it is more difficult to switch between languages ​​with different paradigms, for example, from functional to object-oriented, but even here nothing is impossible if a person does not oppose such a switch “at the level of faith”.
Knowing several languages, for each specific business problem, you can choose your own approach to the solution - one that does not just fit, but will be optimal in this particular case. And the more the developer’s base of these approaches (languages) is in the arsenal, the broader the view on the problem and the more motivated the selected stack. Business, in fact, it is necessary - to obtain the most suitable solution for their tasks.
But with a deep knowledge of one language, but without the ability to solve business problems, the specialist will benefit not every team. Of course, in individual projects, the profound knowledge of the “tweaks” of the language helps the team as a whole to achieve greater performance. But more often, a team member who knows one language but does not know how to listen to business will only slow down colleagues. And by the way, such a “walking reference book of unobvious opportunities” is often if needed in a specific team, then only one (we draw conclusions about the relevance of such narrow specialists in the labor market).
The ability to solve business problems is in fact a part of a more global entity — comprehensive work experience. You can get it both with the employer and in home projects. However, in my opinion, only business projects (where there are customers, budgets, deadlines) can provide the feedback that is so necessary in such situations, assessing the quality of the decision. Namely, it determines the depth of the experience. With home projects, such feedback is simply not from anyone: you yourself do something and at a certain moment decide for yourself what you have done well. That’s the end of it. But when the project is implemented for business, an underdeveloped solution will be sent back for revision,
then again and again if necessary. And in the course of these iterations, you will inevitably learn several approaches to the problem - you will get an understanding of a higher level.
One of the components of the ability to solve business problems is the understanding of this very task. And since quite often Russian developers participate in foreign projects, for this understanding, knowledge of the English language is necessary. In this matter, it is not always possible to rely on a business analyst, since there are not enough good specialists in this field.
Better understand the business helps immersion in some industry. When you do not just make an abstract module that receives, processes and sends data packets to an unknown recipient, you implement, say, a part of complex billing or the banking system, where there are different types of users, standards and other features. Knowledge of these details is very valuable. Such an immersion teaches you to be interested in what is happening around your part of the task. It helps to find the best solution. I know specialists who will never go to work on a task that is not clear why. And in some areas of business development for developers, mandatory internal training is provided for, because without a dive, in principle, it will not work effectively.
As a small addition to better understanding business issues, I recommend attending industry-specific conferences. There, speakers share their experiences on how they solved a business problem with the help of IT technologies. Often, from there you can make useful information about the direction in which to move. Although, of course, no one requires in detail to repeat the experience of others.
I'm not saying that every developer should take care of business problems. June is just entering this circle, at the initial stage it takes him too much time to communicate with colleagues and learn how to solve a specific problem. It's not up to the expansion of horizons. But starting from middle, previous experience forms an understanding of which side to approach the tasks of a particular type. At this stage, there are no questions about the development ecosystem - when and what statuses to exhibit, how to respond to code review, etc. The specialist begins to cope faster even with unfamiliar tasks - here it’s time to “pull up” the business component. In fact, the senior and the middle differ by this understanding of approaches to solving common business problems. And the desire for such an understanding helps to quickly move to the next level.
Thus, I urge to set goals for development at the same time in two directions. On the one hand, to learn languages, and on the other, to gain experience in solving specific business problems. And in this development it is necessary to keep a balance, otherwise it will be rather difficult to find your place in the world of seniors. But where exactly to develop - in the direction of the architect, a very strong developer or teambuilder - depends on the ambitions and personal qualities (teamwork skills, responsibility, communication skills, etc.) of a particular specialist.
What do you think about this?
Article author: Sergey Marina
PS We publish our articles on several sites Runet. Subscribe to our pages on the VK , FB or Telegram channel to find out about all our publications and other news from Maxilect.
In discussions of tasks, business and developers speak different languages.
From a business point of view, it does not matter at all what language their task will be solved in. Business does not think, and perhaps does not even know about java, go, ruby ​​and other languages ​​and technologies. It's great for developers, of course, when a large-scale and interesting project starts from scratch and the technological stack is selected by the team. But in the real world it happens much more often than this. Usually the company already has expertise in a certain stack, which the IT leadership does not want to give up. The reasons may be completely different, from the ban on the “zoo of technologies” to the personal preferences of decision makers. There are also additional factors like the need for interesting technologies for teams, for the sake of attracting and retaining qualified personnel.
')
Developers for their part often express a desire to develop in a certain technological stack. This intention is reinforced by the large difference between salaries for some languages. So there are people who live hard, for example, in the framework of Java or Python (Go, Kotlin, Scala ... the list can be continued almost infinitely) and even Delphi, not trying to see, but what else is there?
In my opinion, the desire to go deep commendable. But sometimes “the forest is lost for the trees” - in the process of this immersion the specialist simply forgets that technology is only a tool for business to solve its problems. As a result, narrow-mindedness on one technological stack, complete with innate perfectionism (“let's do refactoring for half a year to a project that does not have serious development plans, simply because it will be nice”) are not the best way reflected in the quality of decisions made.
My point is that a particular programming language is secondary. Primary are the general understanding of the principles of development and the ability to solve business problems - knowledge of approaches and patterns that help systematize the overall work, experience in the use of various techniques, including command ones. With such baggage, one more language that is needed in this particular project is easy to master. Before my eyes are full of examples of how people retrain for other stacks in a month - two intensive training. Of course, it is more difficult to switch between languages ​​with different paradigms, for example, from functional to object-oriented, but even here nothing is impossible if a person does not oppose such a switch “at the level of faith”.
Knowing several languages, for each specific business problem, you can choose your own approach to the solution - one that does not just fit, but will be optimal in this particular case. And the more the developer’s base of these approaches (languages) is in the arsenal, the broader the view on the problem and the more motivated the selected stack. Business, in fact, it is necessary - to obtain the most suitable solution for their tasks.
But with a deep knowledge of one language, but without the ability to solve business problems, the specialist will benefit not every team. Of course, in individual projects, the profound knowledge of the “tweaks” of the language helps the team as a whole to achieve greater performance. But more often, a team member who knows one language but does not know how to listen to business will only slow down colleagues. And by the way, such a “walking reference book of unobvious opportunities” is often if needed in a specific team, then only one (we draw conclusions about the relevance of such narrow specialists in the labor market).
The ability to solve business problems is in fact a part of a more global entity — comprehensive work experience. You can get it both with the employer and in home projects. However, in my opinion, only business projects (where there are customers, budgets, deadlines) can provide the feedback that is so necessary in such situations, assessing the quality of the decision. Namely, it determines the depth of the experience. With home projects, such feedback is simply not from anyone: you yourself do something and at a certain moment decide for yourself what you have done well. That’s the end of it. But when the project is implemented for business, an underdeveloped solution will be sent back for revision,
then again and again if necessary. And in the course of these iterations, you will inevitably learn several approaches to the problem - you will get an understanding of a higher level.
One of the components of the ability to solve business problems is the understanding of this very task. And since quite often Russian developers participate in foreign projects, for this understanding, knowledge of the English language is necessary. In this matter, it is not always possible to rely on a business analyst, since there are not enough good specialists in this field.
Better understand the business helps immersion in some industry. When you do not just make an abstract module that receives, processes and sends data packets to an unknown recipient, you implement, say, a part of complex billing or the banking system, where there are different types of users, standards and other features. Knowledge of these details is very valuable. Such an immersion teaches you to be interested in what is happening around your part of the task. It helps to find the best solution. I know specialists who will never go to work on a task that is not clear why. And in some areas of business development for developers, mandatory internal training is provided for, because without a dive, in principle, it will not work effectively.
As a small addition to better understanding business issues, I recommend attending industry-specific conferences. There, speakers share their experiences on how they solved a business problem with the help of IT technologies. Often, from there you can make useful information about the direction in which to move. Although, of course, no one requires in detail to repeat the experience of others.
I'm not saying that every developer should take care of business problems. June is just entering this circle, at the initial stage it takes him too much time to communicate with colleagues and learn how to solve a specific problem. It's not up to the expansion of horizons. But starting from middle, previous experience forms an understanding of which side to approach the tasks of a particular type. At this stage, there are no questions about the development ecosystem - when and what statuses to exhibit, how to respond to code review, etc. The specialist begins to cope faster even with unfamiliar tasks - here it’s time to “pull up” the business component. In fact, the senior and the middle differ by this understanding of approaches to solving common business problems. And the desire for such an understanding helps to quickly move to the next level.
Thus, I urge to set goals for development at the same time in two directions. On the one hand, to learn languages, and on the other, to gain experience in solving specific business problems. And in this development it is necessary to keep a balance, otherwise it will be rather difficult to find your place in the world of seniors. But where exactly to develop - in the direction of the architect, a very strong developer or teambuilder - depends on the ambitions and personal qualities (teamwork skills, responsibility, communication skills, etc.) of a particular specialist.
What do you think about this?
Article author: Sergey Marina
PS We publish our articles on several sites Runet. Subscribe to our pages on the VK , FB or Telegram channel to find out about all our publications and other news from Maxilect.
Source: https://habr.com/ru/post/459294/
All Articles