A passion for programming. Part 1 (Choosing a market). Start
Continuing to translate Chad Fowler's book The Passion for Programming. This is the first of the sections of the first part, which is devoted to the choice of the market. Also the current version of the translation can now be downloaded in PDF .
<- Chapter 3. Introduction Supply and demand ->
You're on the verge of a big investment. Maybe it will not require a lot of money from you, but it will require the investment of time - the material that makes up life. Many of us, when building a career, go with the flow, allowing it to go anywhere. We just learn Java or Visual Basic, and then the authorities organize courses for us on some newfangled Hindu technology. And so we are sailing further for some time, until somebody pushes us somewhere else. Such a career is one big chain of coincidences.
In the book The Programmer Pragmatist, Dave Thomas and Andy Hunt talk about programming in terms of coincidence . Most programmers stick to this approach: they start working on something, add some code here, much more. You can start with an example of a program that copies from the Internet. At first, it works and you run the program a little to make it more responsive to your requirements. You do not quite clearly imagine what you are doing, but continue to kick the program here and there, until it almost completely becomes what it should be. The problem is that in this case you don’t understand how it works and, like in a card house, each new feature added increases the likelihood that the program will crash.
For any developer, it is obvious that concurrency programming is wrong. However, for many of us, the most important career decisions become, in fact, random. What technologies should we invest in? In which area to develop? Should I deepen my knowledge or get along with a brief review? These questions should arise by themselves.
Imagine that you have opened your business and decide what will be the flagship product of the company. Without such a “hit” product, the company is likely to sink. Do you need much attention to the choice of the target audience? Before proceeding directly to the production of a product, how much time should be devoted to determining what exactly it will be like? No one will trust anyone else to make such decisions. We will be super attentive to every detail when making such decisions.
So why most of us do not do this when decisions concern a career? If you think of your career as a business (which it undoubtedly is), then your “product” is the services that you provide.
What is this service? Who will buy them? Over the years, will the income from them increase or decrease? How much do you risk making this or that choice?
This part of the book will help you answer these crucial questions for yourself.
If you are going to invest money, then you have a lot of options. You can put them in a savings account, but the income from it is unlikely to save you from inflation. You can put them in government savings bonds. And again, as a result of the money will not be much, but it is - the safest way.
Or you can invest them in a small startup company. For example, invest several hundred dollars in exchange for a small share in this company. If she has a good idea and there is an effective management for its implementation, then you can get serious on this. On the other hand, you have no guarantees that you will even at least pay back the initial investment.
This is nothing new. We all learn it from children's games. If I run right between them, then maybe it will shock them and no one will slander me . The same thing happens to us in our daily life. If you are late for a meeting and choose your way to work, then you make the same choice, weighing the risks. If there are no traffic jams, then I will save 15 minutes if I go along 32nd Street. And if there is a traffic jam, then I'm over .
Weighing risks is an important part when choosing those technologies and areas in which you will invest your time. Fifteen years ago, the choice to study COBOL was virtually risk free. Therefore, COBOL programmers were very many and their average salary was not particularly impressive. It was easy to find a job, but it is unlikely that she brought a huge income. Low risk - low and reward.
On the other hand, if you decided to learn a new Java language from Sun Microsystems, you would probably have problems finding a company that does something in Java. Who knew someone would use Java at all ?
But if you look at the state of the industry at the time, as Sun did, you will see something special in Java. You may have a strong feeling that something impressive will come out of it. Investing in something promising in the early period can make you a leader in a new technological direction.
Of course, in this case, you would have done the right thing. And if you acted correctly, then an investment in Java could be very profitable. High risk - high reward.
And now a different situation. Then, 15 years ago, you saw a Be BeOS demo. At the time, it was something incredible. Multimedia capabilities are simply amazing. The platform made a lot of noise and turned the docks of their work around, making them look forward to a new player in the OS market. With the new platform, undoubtedly, new approaches to programming, new APIs and new user interface concepts should have appeared. It was an uncultivated field for study, but it seemed worth it. You might need to spend a lot of effort to create, for example, the first FTP client or contact manager for BeOS. When Be released the Intel-compatible version of the operating system, rumors began to circulate that Apple would buy the company and use BeOS developments as the basis for the next generation Mac operating system.
Apple didn't buy Be. And over time, it became clear that Be is not going to capture even any niche market. The product just did not cling. Many developers who have practiced programming for BeOS have slowly and painfully realized that their investments will not pay off in the long run. As a result, Be was bought by Palm and the development of the operating system was stopped. BeOS was a risky, but very attractive technological investment that did not bring long-term benefits to those developers who invested in it. High risk and nothing in return.
Anyway, I'm talking about the difference between the newest technologies and the already established ones. Choosing a stable technology that is firmly wedged into manufacturing business systems around the world is safer, but potentially less profitable than choosing the latest technology that no one else works with. What about technology, obsolete? Those who are just waiting for the last nails to score on the lids of their coffins?
Who is driving these nails? Take, for example, RPG programmers — already gray-haired and counting hours until retirement, while young people have not even heard of this language. They all learned Java and .NET. It is clear that the career of these last remaining devotees of the dying technology describes the same spiral of death as the technology itself.
But old systems do not die. They are being replaced. Moreover, in most cases, systems are replaced in stages. And during these stages the old systems must communicate with the new ones. Someone should know how to establish such interaction in both directions. Usually, young people do not know (and do not really want to know) how to work with old systems. At the same time, grumpy old people do not know how to make new-fangled systems talk to their favorite creatures.
Combining knowledge of these two technologies can be beneficial.
Therefore, the task of a calculating programmer is to occupy this niche and thus organize a technological hospice. Helping outdated technologies to leave with dignity is a task that is difficult to overestimate. And, of course, people usually leave the ship before it sinks, either retiring or simply switching to another technology. If you are the last to be able to accompany still critical systems, you will very likely be in value. This is risky, because when the technology really disappears, you will be an expert in something that no longer exists. However, if you can switch quickly, you can take another dying technology and start over.
The technology development curve has two edges. How far from these edges would you prefer to be?
Make a list of existing technologies at the beginning, middle and end of your path. Place them from left to right. On the left will be the latest, and on the right - the outgoing technology. Force yourself to find as many technologies as possible in every part of the spectrum. Be as attentive as possible to the order in which to place them on this line relative to each other.
When you write all the technologies that you can only remember, tag those in which you are strong. Then, maybe in another color, mark the ones you dealt with, but not so much about them. Which end you have the most marks? Are they grouped? Or scattered relative to each other? Are there any technologies that are located on the very edges that you are particularly interested in?
<- Chapter 3. Introduction Supply and demand ->
You're on the verge of a big investment. Maybe it will not require a lot of money from you, but it will require the investment of time - the material that makes up life. Many of us, when building a career, go with the flow, allowing it to go anywhere. We just learn Java or Visual Basic, and then the authorities organize courses for us on some newfangled Hindu technology. And so we are sailing further for some time, until somebody pushes us somewhere else. Such a career is one big chain of coincidences.
In the book The Programmer Pragmatist, Dave Thomas and Andy Hunt talk about programming in terms of coincidence . Most programmers stick to this approach: they start working on something, add some code here, much more. You can start with an example of a program that copies from the Internet. At first, it works and you run the program a little to make it more responsive to your requirements. You do not quite clearly imagine what you are doing, but continue to kick the program here and there, until it almost completely becomes what it should be. The problem is that in this case you don’t understand how it works and, like in a card house, each new feature added increases the likelihood that the program will crash.
For any developer, it is obvious that concurrency programming is wrong. However, for many of us, the most important career decisions become, in fact, random. What technologies should we invest in? In which area to develop? Should I deepen my knowledge or get along with a brief review? These questions should arise by themselves.
Imagine that you have opened your business and decide what will be the flagship product of the company. Without such a “hit” product, the company is likely to sink. Do you need much attention to the choice of the target audience? Before proceeding directly to the production of a product, how much time should be devoted to determining what exactly it will be like? No one will trust anyone else to make such decisions. We will be super attentive to every detail when making such decisions.
So why most of us do not do this when decisions concern a career? If you think of your career as a business (which it undoubtedly is), then your “product” is the services that you provide.
What is this service? Who will buy them? Over the years, will the income from them increase or decrease? How much do you risk making this or that choice?
This part of the book will help you answer these crucial questions for yourself.
Lead or die
If you are going to invest money, then you have a lot of options. You can put them in a savings account, but the income from it is unlikely to save you from inflation. You can put them in government savings bonds. And again, as a result of the money will not be much, but it is - the safest way.
Or you can invest them in a small startup company. For example, invest several hundred dollars in exchange for a small share in this company. If she has a good idea and there is an effective management for its implementation, then you can get serious on this. On the other hand, you have no guarantees that you will even at least pay back the initial investment.
This is nothing new. We all learn it from children's games. If I run right between them, then maybe it will shock them and no one will slander me . The same thing happens to us in our daily life. If you are late for a meeting and choose your way to work, then you make the same choice, weighing the risks. If there are no traffic jams, then I will save 15 minutes if I go along 32nd Street. And if there is a traffic jam, then I'm over .
Weighing risks is an important part when choosing those technologies and areas in which you will invest your time. Fifteen years ago, the choice to study COBOL was virtually risk free. Therefore, COBOL programmers were very many and their average salary was not particularly impressive. It was easy to find a job, but it is unlikely that she brought a huge income. Low risk - low and reward.
On the other hand, if you decided to learn a new Java language from Sun Microsystems, you would probably have problems finding a company that does something in Java. Who knew someone would use Java at all ?
But if you look at the state of the industry at the time, as Sun did, you will see something special in Java. You may have a strong feeling that something impressive will come out of it. Investing in something promising in the early period can make you a leader in a new technological direction.
Of course, in this case, you would have done the right thing. And if you acted correctly, then an investment in Java could be very profitable. High risk - high reward.
And now a different situation. Then, 15 years ago, you saw a Be BeOS demo. At the time, it was something incredible. Multimedia capabilities are simply amazing. The platform made a lot of noise and turned the docks of their work around, making them look forward to a new player in the OS market. With the new platform, undoubtedly, new approaches to programming, new APIs and new user interface concepts should have appeared. It was an uncultivated field for study, but it seemed worth it. You might need to spend a lot of effort to create, for example, the first FTP client or contact manager for BeOS. When Be released the Intel-compatible version of the operating system, rumors began to circulate that Apple would buy the company and use BeOS developments as the basis for the next generation Mac operating system.
Apple didn't buy Be. And over time, it became clear that Be is not going to capture even any niche market. The product just did not cling. Many developers who have practiced programming for BeOS have slowly and painfully realized that their investments will not pay off in the long run. As a result, Be was bought by Palm and the development of the operating system was stopped. BeOS was a risky, but very attractive technological investment that did not bring long-term benefits to those developers who invested in it. High risk and nothing in return.
Anyway, I'm talking about the difference between the newest technologies and the already established ones. Choosing a stable technology that is firmly wedged into manufacturing business systems around the world is safer, but potentially less profitable than choosing the latest technology that no one else works with. What about technology, obsolete? Those who are just waiting for the last nails to score on the lids of their coffins?
Who is driving these nails? Take, for example, RPG programmers — already gray-haired and counting hours until retirement, while young people have not even heard of this language. They all learned Java and .NET. It is clear that the career of these last remaining devotees of the dying technology describes the same spiral of death as the technology itself.
But old systems do not die. They are being replaced. Moreover, in most cases, systems are replaced in stages. And during these stages the old systems must communicate with the new ones. Someone should know how to establish such interaction in both directions. Usually, young people do not know (and do not really want to know) how to work with old systems. At the same time, grumpy old people do not know how to make new-fangled systems talk to their favorite creatures.
Combining knowledge of these two technologies can be beneficial.
Therefore, the task of a calculating programmer is to occupy this niche and thus organize a technological hospice. Helping outdated technologies to leave with dignity is a task that is difficult to overestimate. And, of course, people usually leave the ship before it sinks, either retiring or simply switching to another technology. If you are the last to be able to accompany still critical systems, you will very likely be in value. This is risky, because when the technology really disappears, you will be an expert in something that no longer exists. However, if you can switch quickly, you can take another dying technology and start over.
The technology development curve has two edges. How far from these edges would you prefer to be?
Act!
Make a list of existing technologies at the beginning, middle and end of your path. Place them from left to right. On the left will be the latest, and on the right - the outgoing technology. Force yourself to find as many technologies as possible in every part of the spectrum. Be as attentive as possible to the order in which to place them on this line relative to each other.
When you write all the technologies that you can only remember, tag those in which you are strong. Then, maybe in another color, mark the ones you dealt with, but not so much about them. Which end you have the most marks? Are they grouped? Or scattered relative to each other? Are there any technologies that are located on the very edges that you are particularly interested in?
')
Source: https://habr.com/ru/post/80282/
All Articles