3 main rules every embedded software developer should follow
I recently wrote a post on linkedin which talks about the fresh embedded software engineers errors on choice of topic to focus on the early career (if you want to check it out, link here).
But to get the best out of your early career and grow as much as possible, there is some rules, or habits, that you can adopt that will make you a better problem solver in embedded systems.
Write modular and clean code
It’s being repetitive, right? When it’s cliche it’s because it’s true.
If you do a quick research, the bigger the SaaS company is, the more robust, flexible and decoupled a software is.
And this is only possible because the code is modular and clean in the development cycle.
What it really aggregates
In simple terms, what makes a software modular is the exhaustive use of functions as abstraction layers, so you can have a high level overview of the software.
The magic happens when those little blocks of functions can be tested separately and independently. That’s where the decoupled aspect comes from.
This give you a few advantages:
- Easier to test
- Easier to spot errors and bugs
- Easier to debug
- Easier tot track on a version control system
And clean part means writing code that others can understand. Because you never code for your present self.
You either code :
- For the others
- For your future self
Test throughoutly
On the book “The pragmatic programmer” (I wrote an article about it here), the author states that people tend to think test are used to make sure their code is working.
But in reality, it goes beyond that.
Tests actually can shape the design of your code.
And we agree that it’s better to test a small piece of code than a large one where you struggle to find where it comes from, right?
Embrace failure
Although it is the last topic, I consider this the most important one, and it is where most fresh embedded engineers fall into a trap, myself included.
In my first internship I got one of the best grades of my class. We were evaluated with 3 weights :
1.Oral presentation performance
2.Internship report
3.Work done at the company
So you can have an idea, I got 4/20 in the work evaluation at the company. Ans I just had a good enough grade to move on because of the two other points.
Furthermore, after this result I was told I should try something else.
At that moment I was at a rock bottom. I wanted to give up on my exchange program and go back to Brazil.
I went to a mentor I had at time to talk about the issue. He made the best provocation I have ever had in my life.
I explained that I wanted to give up and gave him all the reasons I found in my head.
He just said to me : “If you do this, then he is right. And tomorrow, what are you going to do?”
I was so angry, that I started to study consistently as much as I could every week. I failed way more than I did. But I realized something : I getting smarter, and more tolerant to failure.
People want success without failing, but failure is a mandatory part of the success.
As always, thank you for reading! Happy learning!
Other resources
I produce daily content about embedded software on linkedin, follow me here.
Want to start your first embedded project with very few resources? Read this article here.
