From embedded to full-stack web developer

Embedded and web development, they are like two different worlds. Two different worlds also means two distinct sets of practitioners. As the nature of requirements and constraints is different for those two, the mindset of solution designers and developers differs greatly (or at least it should). In this post I'll go through my story from embedded to web and ponder the impacts such path has had to my daily work.

My story

Let's start with the studies, my major was intelligent devices. I'd say it's a fancy name for service robotics which includes topics such as machine vision, path planning, human-robot interaction, etc. Cool stuff. Considering the technology stack, mostly C/C++, some bits of Python, Java, Matlab, and PLC languages. Part of the fellow students focused more on the hardware side while I personally put all my eggs in the software basket.  I have never been the hands dirty embedded guy who spends half of days soldering. So, when I'm discussing about embedded, I mean the software engineering part of it.

During the uni years, I also worked as a course assistant in the basics of programming course which used Python as the language. It was not an obvious choice from me as Python was only loosely related to my studies. I guess the Python and teaching seeds got planted back then.

From uni I proceeded to a Finnish health tech company in which I worked as an embedded dev in product development. This was actually quite close to my studies as I was playing with dental X-ray devices which are basically robot arms packed with a variety of sensors and actuators. Key aspects of the required development mindset were that these devices are highly safety critical and the functionalities they deliver are realtime constrained. Stack: C and C++.

I was fortunate to be part of the agile transformation of the health tech company. Traditional waterfall, rigid development practices were turned into modern, agile processes step-by-step. For me adopting agile mindset was not a big thingy as I was fresh out of school. The studies had certainly pushed agile thinking and presented waterfall approaches as ancient practices which don't really fit to modern, iterative development which usually has to tackle ever-changing requirements of end users. However, this was definitely not the case for all stakeholders in the working environment. I believe it's natural to have some level of change resistance during such huge transition in the core development processes. I feel it was a great learning experience to live through and overcome the company wide challenges faced during the transition.

As if moving to other country (Finland -> Belgium) was not exciting enough, I took a leap of faith and decided to go from embedded product development to full-stack web consulting. In terms of technology stack, this meant going from C/C++ to Python, JS, HTML, and CSS as well as from close-to-metal to servers and cloud. This blog post is inspired by that leap.

Embedded vs web

The following points are from my personal experiences, not to be generalized. The syntax: Embedded -> Web

• Realtime safety critical healthcare devices, meaning people may get hurt in case of a malfunction -> Business web applications, the worst case scenario is that somebody loses some money.
• Loads of regulation, a ton of documentation and different regulatory approvals -> Bloated documentation would be considered as a waste of time as the requirements evolve constantly and thus the implementation changes  frequently.
• Hard realtime requirements, millisecond accuracy -> "As long as it happens between 10am and noon, we're fine."
• Fixed resource constraints, bare-metal programming,  "Can't have that 1 kB array there otherwise we'll run out of memory" -> "Hold my beer, I'll scale up your application server. There you go, now you have 8GB extra RAM."
• I spent a full week in lab settings figuring out whether a defect was a heisenbug, an occasional hardware fault, or some sort of combination of the two. The feeling after discovering the root cause and understanding the full what-was-going-on chain was invaluable. However, it was certainly frustrating at times as well. -> The longest time I have been really stuck with something can be measured in hours.
• Max a couple of new software releases per year -> Deployments to production even multiple times during single day

It's not hard to recognize a pattern from the listed points: web dev life is like sipping mojitos in Hawaii while embedded devs are walking to work in Siberia. Of course that mental image is exaggerated and most of the points were selected tongue-in-cheek. My main point is that the two worlds are significantly different from development point of view.

Not directly tech related but still notable, the difference between my embedded and web experience is that embedded days were spent in in-house product development while web development has been consultancy around custom software solutions. Product development vs custom solutions and in-house vs consultancy are topics which would deserve a dedicated post on their own.  

The benefits of embedded background

I argue that software correctness is a bigger deal in the embedded world. In practice, this means taking into account some edge cases that would not be in the checklist of an average web dev.

Low level thinking and thinking outside the box while tackling problems in the web world. Low level thinking comes naturally when one has worked close to metal and, on the other hand, outside of the box ideas come from having experience in different technical domains.

In my experience, the problems faced in embedded world are generally tougher compared to the web world. Thus, I'd say that embedded devs shine in problem solving to some degree. Of course problem solving is always a combination of domain knowledge and generic problem solving skills. I argue that solving more difficult problems yields to better generic skills.

Joy of working with high level languages. This is not a self-evident point. When I struggle finding motivation of writing e.g. Python, I often find a motivation boost by just thinking back the good ol' embedded days by sketching in mind what it'd take to implement the feature in hand in C. I may think that it'd take, say, something between 50 to 100 LOCs in C, and then I'm immediately motivated to type those 4 magical lines of Python which will get the job done.

Having experienced both high level development methodologies, waterfall and agile, and especially the transition between the two, I believe I have an advantage while selecting a suitable development process for the team I'm working in. In other words, if one has only worked in e.g. strict scrum settings, he/she may not have an idea why it works well or doesn't work at all in certain environment.

Potential drawbacks

In agile business web application scene, it's all about balancing between time-to-delivery vs quality, i.e. how good is good enough. I think I might be the bottleneck in some cases. In practice, not because of being slower to deliver solutions which fulfill the requirements but rather because of taking into consideration some edge cases that are not covered in the initial requirements. This is closely related to the correctness aspect discussed above.

Automated testing is harder when the software runs on custom hardware, especially if the hardware includes sensors and actuators. During the days in the health tech company, a major part of testing was carried out by dedicated testing personnel. I have had some learning to do on writing unit and integration tests in the web world. However, nowadays I'd consider myself as a "TDD evangelist" and it's mainly thanks to awesome open source tools, such as pytest and it's whole ecosystem, which make writing tests a pleasant experience.

One drawback is obviously the fact that I don't have as many years of web experience as the fellows of same age who have been playing in the web domain their whole career. On the flip side, I'd say that I'm more eager to learn new fancy frameworks etc as I've neither locked in nor found some comfort zone in the tooling I use. Surely I already have some go-to tools but I wouldn't and cannot say "I've worked with this stack 5+ years, it has worked fine till now and it'll work well in this new use case, why would I change". TBH, I am not sure if I even ever want to be able to put it like that. Technologies and best practices evolve constantly and so should we, developers.

Final words

My software development path has been an exciting trip up to this point and I'm sure it'll continue like that. After going through the transition from embedded to web, I warmly recommend taking such step if you're wondering if the grass is greener on the other side of the fence. It requires a lot for sure but it's also rewarding.

I could easily see myself taking similar leap in the future. One of my recent interests is ML/AI (the buzzwords, I know), not least because of my passion in Python. Other interesting areas include for example robotics, automation, and teaching. However, I'm currently passionate about full-stack web development and feel that I've still loads of interesting projects to explore in that sector. Overall, it's great time to be a software developer: there are a countless number of opportunities available in the job market and new technologies pop up at a frightening pace. There's a good match available for everyone.