You only need these 2 practices to progress as an embedded software developer
Since I’ve started my software engineer’s journey, I’ve come across lots of practical tips to enhance your code habilities or some daily habits that will improve your routine or boost your career.
I’ve tried a bunch of them, and don’t get me wrong, all of them can make you evolve somehow. However, from my experience, I’ll share the two tips, that I’m still implementing and perfecting, which revolutionized my software engineer skills. They might seem obvious at first sight, but the obvious also needs to be said, right?
Code architecture
I remember when I first started coding, my only goal/priority was to make this code work, no matter how disorganized it was, and I didn’t care if someone else could read it or not. Since I only used it in college to get graduated, I was not encouraged to care about that part. I also wasn’t sharing my work on other platforms where people could see, so for me everything was fine.
Until my first internship, where I needed to validate what I coded with my company tutor, who had to read and understand the code I wrote. That’s when I first saw the need of organized, readable and well-structured software.
You never code for yourself
I used to believe I wrote code only for me, even when working for companies. But I started read about software development topics and after some reflections I realized I was very wrong.
First, if you are working with others software engineers in a team, which is the case very often, your teamates need to understand a bare minimum of what you’ve wrote, it can be very useful. For example, you could have a bug an you use some help with correcting it.
Another case where making your code understandable is useful, is you’ve worked in a spcecific project and you changed projects, then someone else will take what you’ve done and will continue. If your code is well conceived (strutured) and organized, chances are that the person will understand what you’ve done and will be able to pick up where you left it.
It can even apply to yourself. If you started some software and for some years you needed to stop for some time and then you get back to it after a while. your future self would be grateful to see something clean and understandable so he/she will be able to continue and move it forward.
Modularity
One thing that can improve your code architecture is modularity, which is the capacity of building consistent separates parts that combined make a whole. What does that mean? It means building different smaller layers of software that can make a whole system work.
And what is the advantage of such strategy? That you can build, test and debug smaller parts, making your life easier when spotting bugs and consequently solving them.
Making software can have the same analogy as constructing a building or a bridge. You build them putting one brick at a time, so when something goes wrong you can analyse it “brick by brick”.
Building something
Once you learn how to structure and organize software, you need to see if you really learned. And you only find out if you learned by active learning. What does that mean? It means one out of two ways (or you can even do both, why not) : doing/building something or teaching someone something.
It is scientifically proven that you can effectively learn something when you put yourself in a danger zone : the discomfort zone, where you need to push your boundaries. Why?
. When you are teaching someone something, you’ll see if the new concepts you learned can be put in a logical thinking for transmitting them to someone else. If you didn’t learn the concepts, two scenarios can be produced : the other person won’t understand your explanation, or you’re going to pass a false information.
. When you are building something (aka in a project) it’s simple to see if you’ve learned or not : it will work (well, sometimes you can count on luck to make it work, but it is large exeptions).
Are online courses a good idea?
There are really good teachers out there in the internet. I can even generalize : in the internet, in college, every where. There are real masters in transmitting knowledge that make you feel you know everything about the topic. And that’s amazing.
There is only one problem with classes in general : it doesn’t matter how good the teachers are, you’re still in the passive learning. I’m not saying that you shouldn’t take classes, I’m their biggest advocate. My point is that they’re not enough to prove to yourself that you’ve learned something. To see if you’ve learned you need to practice active learning.
The power of long term work
A while ago, I read something that I found really interesting : people overestimate what they can do in 10 days and underestimate what they can do in 10 years. This applies not only to learning, as far as I can tell. Learning takes patience, and patience takes time. It’s not a comfortable process, it takes pain and frustration, in order to give place to grow.
Bonus : documentation
There’s something even better than building something and making beautiful and organized code, it is to document all that you do and learn. Videos, text, websites, photos, it doesn’t matter.
I think when we help someone else by sharing what we know and learn, we tend to grow up somehow. That’s why I started writing. I don’t know why yet, but I started to believe that! And there’s only way to find out if I’m right or not : documenting the progress.
Final thoughts
I don’t like to reduce a whole complex and individual topic which is how to make progress in something, since there is no exact science on the evaluation of the progress of someone, that’s why I’m making it clear that this is my personal experience.
I hope you find this lecture somehow useful. Thank you for taking the time! Happy reading/coding!
