I am Andrei Liungrin – a passionate programmer, a wannabe-writer, and an amateur photographer. Most of my work is around embedded development for STM32 in C, but I also spent some time porting Linux drivers. A bigger chunk of my career was in startups, so specialization is a kind of an alien concept for me: today I write a bootloader, tomorrow I patch scripts for a proprietary robotic arm.
I have been programming for as long as I can remember. I got my first job at a local robotics food-tech startup at 14 – which is, ugh, controversial, but I managed to fit in their amazing team and it was a great time.
If you think that my very particular set of skills will be useful for your company, please do contact me at liungrin@proton.me.
My first job gave me so much experience that it completely transformed my views on engineering multiple times. But above all that, it taught me how to work in a team, to manage my own work, to coordinate with others, to resolve disagreements constructively, and to do things someone else’s way when it is better for the team.
For that I am eternally grateful to my first boss and to all of my colleagues, many of whom are still among my closest friends.
My second job was at an R&D department in a large corporation that shall not be named. There I worked on a Board Support Package for their homemade secure mobile OS. This was the real deal: completely custom kernel, drivers, libc, and userland. To make that work, my team created drivers for different SoCs, displays, modems, and whatever else you may find in a modern smartphone. Sometimes we had to resort to porting drivers from Android because some manufacturers do not publish documentation for their hardware.
I also helped with automated testing on real hardware in our CI. We are talking automated flashing, log collection, per-function power profiling, and even robotic arms for touchscreens.
Here I also was lucky to be surrounded by some amazing colleagues. My teammates were some kinds of wizards who used to work for CPU manufacturers and hack modern consoles for fun. This was my first time working with programmers far smarter than me and I feel like I learned a ton just by casually chatting with them. These people are probably responsible for at least half of my desire to dig into low-level stuff.
I should also not forget about my managers. They were some of the most pleasant people to work around, who would always come to my rescue when I got stuck navigating the corporate bureaucracy. I found out a lot about the organization of large teams, although I’m still drawn to smaller startups.
I have a great aversion towards hand-wavy magical explanations and want to understand everything I touch down to the deepest, most basic levels. It goes so far that I often look up syscall implementations when working in user-space just to be sure it does what I expect.
I value simplicity both in code and my tools. I use C89, but not because it is a great language. No, I hate it. The only good thing about it is that it does not get in the way and has just enough power to create any level of abstraction. And when you abstract just enough, I feel like it does not really matter which language it is.
As far as simplicity goes, I am also very pedantic about my dependencies. I
believe that any respectable program must have just two external dependencies:
a compiler and a kernel. Everything else must go in the source tree. Heck, I’m
no longer feeling comfortable using system make after I had a build fail for
a simple project, because my colleague had a different minor version of it.
With that said, I am not trying to be a fanboy of any technology. I occasionally wander around exploring different interesting languages. Recently, I studied Haskell, which was fun and revealing, although tough without a proper math background. Some day I will get around to OCaml for a more grounded Haskell-like experience.
All that sounds like ranting, because it is. But it is always important to remember that technical views, however strong and unconventional, should be akin to a guiding star – perhaps unreachable, but providing a sense of direction. Over time I learned that the best decisions are made when colleagues with polar views challenge each other’s beliefs and combine their strongest points. Never argue with people, argue with views.