Algorithms are just one of the variables in the equation.
I read a very interesting article about the importance of algorithms , the conclusion of which seemed very controversial to me.
For starters - thesis. I argue that knowing the algorithms and even having a systems education does not make you a good developer. You can say it harder - for most of the tasks you will be unsuitable for you, even if you are proficient in graph theory, knowing the computational complexity of algorithms and reading the whole Knut.
')
The fact is that software development is not just algorithms or languages.
1. First, to reduce everything to the knowledge of only some algorithms is a dead idea. If the programmer does not understand, for example, in network technologies, does not understand how the operating system works, and so on - knowledge of quicksort and of all data structures will not help it.
So, if a programmer does not have an understanding of the ready-made tools available to him in * nix and writes his own (inventively to invent his cron, to start the jobs, conditionally) - then this is a pipe. Or a person does not understand the device of networks, and cannot even assume that a certain part of the data is not loaded in his web application due to incorrectly written routes or a lagging DNS server.
2. Secondly, without the experience of using real technology stacks (both software and axes / hardware), a programmer with steep theoretical knowledge can shine on topcoder, but fixes the most primitive task of creating a scalable application.
About the nuances of how Java / various compilers / interpreters behave, you can read tens of thousands of articles.
3. Without global thinking, understanding of the application as a whole at all levels (not only in its sandbox, but also within the axis / hardware / network infrastructure), the programmer cannot call himself a programmer. Relatively speaking, if a web programmer is thinking only about how to put a new lib on the server, but not at all puzzled by how admins will then update it on 200+ servers (and what will happen if it becomes critical for the application, and after the next OSI updates will turn out that it does not compile at all).
4. Security. Only with experience comes, on laboratory or olympiads this will not be trained.
5. Architecture.
I happily watch how another language / framework comes out, and then the crowd rushes to screw it in itself. Or - even better - to take for their startups.
Not understanding how to support then zoos from 5+ technologies (especially when they will not be supported - hello GWT and hundreds of others), or how to scale newfangled crap on several servers, or how to solve problems in the absence of a community.
What is worth applying? Depends on each specific case, but often the tool is more run-in and more common than the fresh one that has just appeared. I can bring such an unfashionable Pure C language in which drivers, systems, Postgres, and a million other things are written that people don’t like because of the lack of glamor (and complicated pointers, with a bunch of places where you can shoot yourself in the leg, we admit honestly - that imposes additional requirements for the developer), but with a long history and accumulated experience of use.
6. Database design and query optimization. Everybody there normal forms go through everything, and the experience of choosing a DBMS and creating a scalable structure for real data with the subsequent optimization of work comes only with practice. But we will not call an inferior knowledgeable red-black trees and a decisive Olympiad programmer problem inferior simply because he does not have the experience and understanding of how the PostgreSQL query optimizer works, why it is better to put such a composite index, but not a simple one, and why fine-tune the server settings for the current read / write load.
7. Finally, we cannot simply ignore people's general intelligence and soft skills, EQ / empathy.
For example, if a person is intelligent and has common sense, then he understands that language is a tool. And he will not write in real work on Java what is well written on the pros and works without brakes and a tambourine (as well as fat servers and expensive colleagues).
At the same time, he will gladly take Dzhava and the whole stack, if he already has a ready-made framework, libraries and open-source software, which solves problems. And the skills to communicate with the manager will allow him to work out the requirements and select the entire infrastructure, develop an architecture, etc., taking into account possible changes and business requirements (and not just interests like self-development or the everlasting high from picking new Scala toys).
Therefore, dear colleagues, I would still be more cautious about others and with less pathos and emotions. Maybe someone forgot the once read basic algorithms or data structures, but his competence in the same architecture or security is so superior to yours that he can look down on you.
I wish us all greater empathy, and more often share interesting links with colleagues (including showing the benefits of owning new knowledge and skills), rather than sharing them on ours and others.
Shl. If you feel that all the same algorithms will not be superfluous - an excellent course on Coursera: one , two
Live long and prosper.
For starters - thesis. I argue that knowing the algorithms and even having a systems education does not make you a good developer. You can say it harder - for most of the tasks you will be unsuitable for you, even if you are proficient in graph theory, knowing the computational complexity of algorithms and reading the whole Knut.
')
The fact is that software development is not just algorithms or languages.
1. First, to reduce everything to the knowledge of only some algorithms is a dead idea. If the programmer does not understand, for example, in network technologies, does not understand how the operating system works, and so on - knowledge of quicksort and of all data structures will not help it.
So, if a programmer does not have an understanding of the ready-made tools available to him in * nix and writes his own (inventively to invent his cron, to start the jobs, conditionally) - then this is a pipe. Or a person does not understand the device of networks, and cannot even assume that a certain part of the data is not loaded in his web application due to incorrectly written routes or a lagging DNS server.
2. Secondly, without the experience of using real technology stacks (both software and axes / hardware), a programmer with steep theoretical knowledge can shine on topcoder, but fixes the most primitive task of creating a scalable application.
About the nuances of how Java / various compilers / interpreters behave, you can read tens of thousands of articles.
3. Without global thinking, understanding of the application as a whole at all levels (not only in its sandbox, but also within the axis / hardware / network infrastructure), the programmer cannot call himself a programmer. Relatively speaking, if a web programmer is thinking only about how to put a new lib on the server, but not at all puzzled by how admins will then update it on 200+ servers (and what will happen if it becomes critical for the application, and after the next OSI updates will turn out that it does not compile at all).
4. Security. Only with experience comes, on laboratory or olympiads this will not be trained.
5. Architecture.
I happily watch how another language / framework comes out, and then the crowd rushes to screw it in itself. Or - even better - to take for their startups.
Not understanding how to support then zoos from 5+ technologies (especially when they will not be supported - hello GWT and hundreds of others), or how to scale newfangled crap on several servers, or how to solve problems in the absence of a community.
What is worth applying? Depends on each specific case, but often the tool is more run-in and more common than the fresh one that has just appeared. I can bring such an unfashionable Pure C language in which drivers, systems, Postgres, and a million other things are written that people don’t like because of the lack of glamor (and complicated pointers, with a bunch of places where you can shoot yourself in the leg, we admit honestly - that imposes additional requirements for the developer), but with a long history and accumulated experience of use.
6. Database design and query optimization. Everybody there normal forms go through everything, and the experience of choosing a DBMS and creating a scalable structure for real data with the subsequent optimization of work comes only with practice. But we will not call an inferior knowledgeable red-black trees and a decisive Olympiad programmer problem inferior simply because he does not have the experience and understanding of how the PostgreSQL query optimizer works, why it is better to put such a composite index, but not a simple one, and why fine-tune the server settings for the current read / write load.
7. Finally, we cannot simply ignore people's general intelligence and soft skills, EQ / empathy.
For example, if a person is intelligent and has common sense, then he understands that language is a tool. And he will not write in real work on Java what is well written on the pros and works without brakes and a tambourine (as well as fat servers and expensive colleagues).
At the same time, he will gladly take Dzhava and the whole stack, if he already has a ready-made framework, libraries and open-source software, which solves problems. And the skills to communicate with the manager will allow him to work out the requirements and select the entire infrastructure, develop an architecture, etc., taking into account possible changes and business requirements (and not just interests like self-development or the everlasting high from picking new Scala toys).
Therefore, dear colleagues, I would still be more cautious about others and with less pathos and emotions. Maybe someone forgot the once read basic algorithms or data structures, but his competence in the same architecture or security is so superior to yours that he can look down on you.
I wish us all greater empathy, and more often share interesting links with colleagues (including showing the benefits of owning new knowledge and skills), rather than sharing them on ours and others.
Shl. If you feel that all the same algorithms will not be superfluous - an excellent course on Coursera: one , two
Live long and prosper.
Source: https://habr.com/ru/post/279651/
All Articles