Fear and Loathing in Development or How Not to Enter a House
Some time ago, I finally realized my little dream – I switched from bare-metal development for microcontrollers to work with Embedded Linux. The reason was that working with the MK, as it seemed to me for a long time, was becoming monotonous: you take another chip and documentation, raise another UART / SPI / I2C on it, write drivers for communicating with devices and more or less simple basic algorithm. Although from time to time interesting tasks arose when you work with an interface that was previously unfamiliar, write some kind of protocol or top-level algorithm. But this rarely happened, but I already wanted something more ambitious …
Total we have:
5+ years of working with MK and only in a few IDEs, without knowledge of CI / CD, containers, testing utilities, frameworks, etc.;
profile education, which is generally neither to the village nor to the city, although technical and occasionally helping;
a strong opinion that real knowledge is acquired in work;
the desire to finally emerge from the swamp … into another.
And finally, I ended up in a new company with new tasks and with the proviso that I have no experience in Embedded Linux, that I am far from an advanced user in Linux itself (well, run around directories in the terminal, delete / create something, no more) , but there is a great desire to develop, perseverance and endless supply of vaseline stress resistance. Here it is worth adding that this reservation was said at the interview and completely satisfied the applicants. The nightmare started small – with the bootloader.
By the will of fate, the first project was associated with U Boot just so it doesn’t hurt too much. The first 1.5 months I worked only with him, of which 1 month was making changes to the bootloader while getting used to Linux, the command line, docker, tons of spaghetti code, an existential crisis.
I still remember my first attempt to build a bootloader from source: the project is not built, the compiler swears at the syntax, you start scouring Google for answers … It turns out that you need a toolchain, you google what it is and you don’t understand. You write in search of quick advice to more experienced colleagues – the answer is: “so what toolchain do you use for assembly?”… Damn it, but who is this toolchain of yours?
Okay, I figured it out, learned how to work with the docker (well, as I thought then) and completed the task on time. As it turned out, these were flowers …
After that, they temporarily transferred me to another department (to maintain the project after the employee left), in which a full-fledged firmware was assembled through Buildroot with all sorts of submodules, patches and jade rod. Yes, yes, interaction with Chinese vendors and their creativity in the form of processors, code from crutches and incomplete documentation. Here I was already getting used to working in the buildroot, and then I returned back to my department to work with the same processor, but on a different project, to work with drivers, modules, and debugging features. And then there were the berries…
It makes no sense to retell all the events of the past days, but I think it’s worth saying one thought: despite the fact that you always need to learn, before diving into a new area, you should still study this area at least a little for a couple of months. And not just to read, but to poke – read literature or watch video guides on YouTube, then try to make a small home project or, at worst, take online courses. I say this for people who begin to study a new specialty only after entering it without prior preparation. I was such, because I believed that the best training takes place in battle – if you are given a task and even in a short time, then you will break into a cake, but you will complete the task. Alas, this does not always work. It only worked at first, because the following processes take place:
you start to systematically stay late at work, as you spend more, and sometimes much more time on the task, since more than half of the time is spent on learning tools, methods, etc.
as a result, fatigue accumulates and free time (if any) is spent not on learning something new with pleasure, but on poking into entertainment content
if you continue with processing in the same spirit, apathy accumulates, the brain seems to block learning processes, any new task turns into stress, which also affects personal life
the process of learning new things loses any systematized form – information comes in fits and starts and only that which is needed specifically for the task. There is no holistic knowledge of the subject, as such
As a result, a very strange situation arises, when you seem to have flown into that sphere that beckoned and called you so much, but … You don’t have the feeling that you have at least somewhat understood the topic. Any question on the topic puts you in a stupor, since you are in a vicious circle: you spend all your energy on performing a local task, and there are no more forces to form global knowledge.
A very simple analogy with sports: before you start a marathon, start with at least one kilometer every day. And start in advance, much in advance, so as not to suffer in training and not torturing your body unaccustomed to the distance. Otherwise, you will simply run from shop to shop (if they come across at all along the way) and you will reach your goal very, very soon. If you make it at all.
Summing up the above mentioned, I would very much like to say that all the hardships have been overcome, Atlanta straightened his shoulders and proudly endures all the hardships and deprivations of Embedded Linux development, but … it turned out that the margin of safety has a limit and burnout finished me off. For the first time in my career. As it turned out later, the reason was not so much a lack of experience, but a managerial feature of “few developers – many projects.” The description of the reasons in terms of volume draws on another article, but as Leonid Kanevsky said: “This is a completely different story.”
Some time after writing the first version of this article, I started working at another company with more employees, a developed corporate culture, and a more relaxed pace of work. It’s still the same work with Linux, but far from Embedded
If it is interesting, then you can release a sequel in the form of an assessment of the team management by the developer
