Private opinion on how to get into IT

I am a long-time reader of HABR (since 2011, it seems), although the reader is passive: I was not even registered. It seemed to me that shaking the air was a rather pointless activity, and I didn’t really have anything new to say. But over the past couple of years, more and more articles have appeared on HABR, which can roughly be characterized by the phrase “how to get into IT.” I may be biased, but I can’t shake the feeling that almost all articles on this topic are similar to each other. Not literally, of course, but the general direction of thought. It is very rare to find articles that contain specifics; more and more common hackneyed banal recipes, which, admittedly, are too universal and cannot serve as a guide. Especially for those who live in the provinces, where there are no serious developers and where, alas, there is no place to get the necessary experience. Can I tell you about myself? My experience is not universal, but it is real experience. I have no illusions that this will be useful to anyone, but if it at least cheers someone up, that’s not bad.

In order not to procrastinate or create unnecessary intrigue, I will say right away: I am 62 years old. Professional programmer experience 37 years (since 1987). Probably half of HABR's readers are under 37 years old, for which I sincerely congratulate them – you still have a lot of time. Education: higher technical (with in-depth study of mathematics). True, I didn’t work in my main specialty for long.

There were few computers in those years. Yes, there were “Sinclairs”, “BC” and a number of others. People were soldering their cars with all their might, but my hands always grew from the wrong place, so this hobby passed me by. However, I was lucky: the design bureau where I worked in distribution received the SM-4 machine (a clone of the PDP-11).

Apart from me and another guy about my age, there was no one in the KB who was interested in this. True, the guy quickly got tired of all this and I was left alone with this miracle of technology of the late Soviet Union.

The computer (then they were universally called “computers”) was completely fine. I don’t remember its exact characteristics, but what stuck in my memory was that it had as much as 256 kilobytes of memory on board. I’ll say right away that at that time it was really a lot. Some kilobytes were occupied by the operating system (by the way, it was possible to work on a “bare” machine, without an operating system), some assembler, some Pascal and C translators, and at the same time half of the memory remained at the disposal of the programmer.

I started with assembler. The documentation that came with the machine was so-so (with the exception of a small brochure entirely dedicated to I/O programming), but a number of translated books on the PDP-11 were published. This was enough, and after a couple of months I was pretty good at making all sorts of small programs of an educational nature, fortunately I was not heavily loaded in this design bureau and had enough time.

Then I mastered Pascal and a little later C (compilers for them were included in the software that came with the machine). There was also an exotic language in the form of the Focal language (a highly neutered Fortran), but it was too primitive and suitable only for simple numerical calculations. Books by N. Wirth and the famous K&R were tabletop.

Rumors about my “achievements” reached other engineers and they came to me with the question: “Is it possible to create a catalog of used regulatory documents (GOSTs, instructions, industry standards, manuals, etc.)?” No one (including me) understood how to work with such a catalog afterwards: there was only one machine for everyone and it was faster to search in paper documentation than to wait in line for access to a computer. Looking ahead, I’ll say right away: that’s how it happened. The catalog had to be replenished and corrected all the time, which in itself took a lot of time. But the task, whatever you say, was quite interesting. Moreover, I have never heard of any DBase/Paradox/Clipper and similar database management systems.
Unaware of the difficulties ahead, I, of course, got to work. We had to come up with everything: from the information storage structure to the interface (of course, a console one; there was no talk of any GUI at that time). And it worked! Crooked, glitchy, pathetic – but it worked. For three or four months I spoiled my eyes and wore out my fingers, but I solved the problem. Later, in the 1990s, Jeffrey Ullman’s book “Databases in Pascal” was published and I was pleased to discover that in general I solved the problem correctly, although I was frankly ashamed of some pieces of code and algorithms (although no one knew this except me) . Of course, this development was thrown out, but the main thing is the experience – I gained valuable experience.

In those years, the finite element method (FEM) was popular among calculators. Many books were published; mostly theoretical in nature. Here my mathematical training came in handy, because… FEM is, in fact, the solution of partial derivative systems of difurs. Counting them on calculators is a futile task due to the monstrous amount of input information, small amounts of memory and low performance. With the advent of SM-4 this became possible (of course, with a lot of restrictions, especially in terms of information presentation), but I decided to try. This was another job – much more complicated than the catalog I wrote about above. But youth overcomes everything, and after about six months I learned to count simple rod structures. The main difficulty was in representing these very final elements. The mathematics was relatively simple, although it was necessary to go deeper into the calculation methods so that accuracy was not lost from the accumulation of errors. A little later I expanded the program so that simple shells could be tested for strength.

From what I did in those years, I remember a payroll calculation program. At the end of developed socialism, a progressive calculation method was invented – the so-called. “team contracting” based on the calculated labor participation coefficient (KTU). In fact, the methodology is sound, allowing salaries to be calculated not just according to the staffing table, but also taking into account the work performed and its complexity. The algorithm was not simple, it was constantly changing, but on the whole it was understandable and, most importantly, it gave quite adequate results. The engineers liked it (the bosses, not so much) and on calculation days I was a sacred cow – they brought me tables filled out by hand, which I converted into data for the program and ran the calculation. This had its costs – I had to plan my vacation so that I could be there the last week of each month. However, this, of course, is mere nonsense.

Yes, I remembered another problem that I solved – calculating heat transfer for hydraulic systems. In general, this problem was of approximately the same nature as FEM, but it contained much more reference data and terrible nonlinearity of parameters depending on temperature and working fluids. True, special precision was not required here – it was necessary to make sure that the temperature of the working fluid did not exceed the permissible limit and that the cooling means (such as fans or radiators) would do their job effectively.

And then the Union collapsed. The design bureau became of no use to anyone. The older engineers suddenly became poorer. Young people like me began to look for another job. This is how I got into banking automation. And this was a real Eldorado. Banks were multiplying to the envy of rabbits and it was necessary to somehow keep accounting records. There were no programs (something more or less worthy began to appear around 1995). So most banks created their software themselves. Here I first encountered real databases (it was Informix) and Unix (yes, exactly Unix, because Linux was in its infancy then). The three of us wrote our program in a terrible mixture of C and Prolog (the latter was incredibly popular at that time). And damn it, she worked! And she worked decently. Of course, we didn’t leave the editor and compiler for a year and a half (we often stayed in the office until 2–3 a.m. and stayed there overnight), no days off, much less vacations, but youth overcomes everything.

Then there were other banks. Until about 2005, they had interesting work for programmers: currency transactions, plastic, consumer lending. Then these niches were gradually filled with suppliers and vendors, and the work of a programmer in a bank began to come down to support and minor additions. In a word – boredom and routine.

Thank heavens, I realized this quickly and from about that time I began to develop in breadth. By this time, I had a professional command of SQL, C, quite passable C++ and Perl, knew UNIX (and had already tried Linux) plus all sorts of little things (Delphi, JS, etc.). Of course, I heard about Java and even tried it, but I didn’t dive into it. Something told me that Java was the thing. So I started switching to Java. I won't say it was an easy experience. I quickly said goodbye to the fairy tale that “if you know C++, then Java will fly right away.” Here the frameworks went awry, the business was rapidly moving to the WEB. In a word, the scope of work was extensive and it would be extremely unwise not to jump on this train. Since then I have mainly written in Java and its derivatives (Scala, Groovy). Then I came across Python and was somehow hooked. I won’t say that I have serious projects in Python, but I don’t give it up and continue to maintain the required level: periodically I do small projects of a utilitarian nature. Due to the nature of my current work, I write a lot for BigData (Spark, Aitflow, etc.) – here, I hope, Python will be very useful to me someday and it is possible that I will finally migrate to it.

I’m ashamed to say, but Golang didn’t work for me. I can’t explain why: it doesn’t drag and that’s it. It must be some kind of DNA defect. But Rust came in. However, this is just understandable – any (okay, almost any) C student one way or another sees a “kindred soul” in Rust. So far, unfortunately, I haven’t done anything commendable with it, and, to tell the truth, I’m unlikely to do anything. I don’t have much time: I may not wait for its true blossoming (which may not happen, which is also possible). So for now I’m making money with good old Java and everything that’s around: Spring, Spark, Kafka…

Now, returning to where I started: getting into IT. There are no universal recipes. At least I don't see them. And I won’t give you any advice myself. I simply described my experience and the only, in essence, thought is one thing: if you are interested in it, take a risk. If you're not interested, don't even try. Before spending money on courses, open YouTube – it’s full of training materials. Start with Python, don't touch Java, C++ or Go. Just try to repeat some pet project. One to one, without fantasies. Make it work. If you haven't vomited at this stage, then there is a chance.
I have no formal education in IT. Alas, of course, but this is how it happened. However, this is by no means an obstacle – I am sure of that.

I am skeptical about the courses. There people want to earn money and attract naive Pinocchio, offering to bury their money under a tree. Legal, but still immoral. The tree itself will not bloom, no matter how much money you bury under it. The tree needs other things – watering, pruning, protection from pests. The root of the problem, it seems to me, is that programming, like any other creative activity (painting, literature, architecture, music) is not accessible to everyone. You need interest that is not determined by the level of pay, but by the love of what you do. If you focus only on the fact that IT pays a lot and well, then this is a delusion. Yes, they pay well, sometimes even a lot. But IT is full of routine. Experienced programmers will confirm that sometimes you have to spend days and weeks trying to figure out why a program doesn’t work as it should. You can re-read the code dozens of times, learn it by heart, but not see the error (usually elementary and stupid). All professional developers, even the very best, have encountered this. We are just people. A novice developer with a probability close to 1 will get to support the so-called. legacy code. It's a great school. Without irony or mockery. Look from the inside at how everything works, be horrified, calm down and roll up your sleeves. The old code is orders of magnitude larger than the new one and it should work. In the process, you are sure to find cleaner and more elegant solutions. Discuss them with colleagues, weigh the risks and, if there are no compelling objections, implement them. Be prepared for the fact that you will make more than one mistake. And you won't be praised for it. Maybe your mistakes will have to be corrected by others. Are you ready to blush and take the blow? Are the neophytes ready to go through this rake? Are they capable of working for a couple of years for food? That's it. I know the objections: family, small children, loans and the list goes on.

If you are not ready to take the risk, don’t go at all. Don't fool yourself. Find yourself in someone else.

I enjoy working with beginners. And I can see right away whether it will be useful or not. This is determined within one to two hours, no more. Courses or diplomas have no meaning at all. If a person is capable, then this is visible and he himself, sensing the “smell”, will tear his claws and develop. Read. A lot of. So many. Collect a library. Yes, translations of foreign books are not always done with high quality, alas. To depend less on this, read the original. English (namely, the main language of a programmer) is not as difficult as it seems. Technical texts on it are quite accessible, and you don’t need more (for now, anyway). My reading norm is from 20 to 50 pages a day (depending on the complexity of the material). The process should not be interrupted, neither on weekends nor on vacation. There is no way to read – think, decide in your head, fortunately there are countless problems. Make notes, stick stickers. Be sure to create a repository; not necessarily public, local is enough at first. Learn basic techniques for working with a version control system. Regardless of whether you work with databases or not, learn SQL. Not necessarily to the subtleties. But be sure to study it.
Master Linux. It is not difficult. Download the image of the same Ubunta and practice. Again, there is no need to be a guru (unless, of course, you plan to be a system administrator), but you need to know and be able to do the basic things.

The last piece of advice is the hardest: find a mentor. Find someone who is willing to give you 15 minutes a day, no more. If problems arise, do not run to him – spend a day/another searching for a solution on your own. If you are completely stuck, ask. I repeat – this method of training is the most difficult, but also the most effective. A good mentor will not let you get into the weeds or go in the wrong direction. With it you will save a lot of precious time, and time is an irreplaceable resource.

Good luck, colleagues!