MICROPROCESSOR AND MICROCONTROLLER: Embedded System Podcast

Listing the experiences i relate to most in the book 97 things every programmer should know.

Hope you guys enjoy.

Thanks

10 Experiences I relate to in 97 things every programmer should know

I recently read a book 97 things every programmer should know. It is collection of expereicnce of various people in software engineering from various domains.

I though it would be fun to list down or mark 10 experiences that i related to most.

Here are the 10 experiences in no particular order.

Number 10 - Read the Code - Karianne Berg

This is something connected with, as soon as i read it. For me personally i didnt learn coding in college or in school. This is something i learned by looking at other peoples code and actually reading them.

I used to browse repositories in google code and try to understand why certain things were done in a certain. Slowly and steadiliy with help of books and tons of projects on google code and source forge i was able to learn design patterns that were very much helpful in developing and maintaing large codebase. Early on in college itself because of this i learned how to read other people's code and use them as is or modifying it in a way that original author would. I never understood the importance of this excersise till i started working professionally in a corporate where i quickly realized more that it is more important to have a readable code that uses the existing design patterns than come up with some eye sore that has no place in the entire code base.

Number 9 - Reinvent the Wheel Often - Jason P Sage

Whenever i see some product or software one question i always ask is whether i could have done it better or equivalent. Then sometimes when no one is looking i give it a go and try to recreate the same stuff. There were few reasons i did this. I wanted to know whether i could have done something equivalent. I wanted to know the thought and design process behind it and really wanted to adapt it. But whenever i talked about it to someone about reinventing the wheel i was always looked upon like some crazy guy who has just lost his mind and should be put in arkham asylum. Especially in corporate where every money counts.

I just wanted to know how things work and possibly it would help me using it or creating a better version of it once i know how it worked.

So it was a very pleasant surprise that someone else also shares this view. For me it was a no brainer to put this experience here in my list.

Reinventing the wheel is not just an exercise to get the same functionality out. It is about how to get an intimate knowledge of the inner workings of various things that already exists and you are going to use.

Number 8 - Hard Work Doesn't Not Pay Off - Olive Maudal

This was kind of an interesting experience. Does it says that work should be done in a smart and precise way. Well no the experience literally talks about not working hard. The concept of this is if you are working 40 hours of a week and all 40 hours is just delivery. There is no learning for you. This means for the full 40 hours you are implementing designing and writing from the things you already know or have experienced. What about adopting something new or learning something that you don't know but could be very beneficial in your scenario how will you find that. You can only find that when you look for it. This is what this great written piece talks about. If you are not willing to learn and implement something.

The idea here is there needs to be a continuous learning experience. Reading books going to conferences things that you can adopt in your day to day work. You need to spend days evenings and weekends or even holidays updating, educating yourself. How are you going to achieve this if you are busy working 60 hours a week in your current project.

The idea behind is to contribute as much as possible by finding something (you may or may not know) in process improve your skills, reflect on what you are doing and adapt your behavior accordingly.

Number 7 - Beauty is in simplicity - Jorn Olmheim

To be honest here beauty is a subjective term and depends heavily on individual and their background. But I would like to argue that whatever the background or individual. You need to first understand what has been done to truly appreciate it. One can write the most complex of algorithms but if it is not presented in a simple or written in a simple way for people to use it and expand on it to understand it you can only appreciate things that you understand.

Writing the most complex of systems in the most simplest of forms is the essecne of beauty. One cause people understand it, second people can use it for longer period of time and third it will last long. The longer it last the more the chances more people will see it and better the chances that more people will use it or variant of it in their own project. I guess thats the dream for most of the developers. They write or develop something that can outlast them in their own field.

Number 6 - Code in the Language of the Domain - Dan North

This is common in all the domain. If i talk about the electrical domain it is very very essential to code in the language of the domain. In my experience i have seen people who can only code and not understand the domain turns out making shitty code even though they are excellent programmers. It is very essential to understand the domain and talk in the language of domain.

Most of the time the hardware and software are maintained separately and if done well it is rarely required by the software guys to see the hardware if at all. This separation of hardware and software is only possible to achieve if guys in both spectrum talks in the same language. The domain language. Any difference where there of will just result in catastrophe or time wastage in meetings to just to get to the same level. So to avoid all that it is is better to code in the language of the domain.

Number 5 - Don't be afraid to break things - Mike Lewis

Sometimes when you get the code base any change to be done in the system seems completely unnecessary or nerve racking at best. The idea that doing something or moving things around will break the things though grounded in reality is necessary devil that needs to be dealt with. This paralyzing fear of changing things prevents most developers of improving the things that they have in hand.

So how to proceed in scenarios such as this. The best way to proceed is step by step testing along the way. Move some part fix it and unit test it then integrate it then again test it. Slowly and steadily all the components you want to move or update will be done.

This is the same approach that is mostly used in developing embedded code as well. In real time systems, the code isolate the control and supervision part. when working on the control part it is made sure that the supervision is tighten so proper protection are taken so as to not damage the system while changing something in the core control functionality.

Never try to refactor of fix all the things in one go the effort will be so huge and so many problems will arise that can make anyone abandon the entire work completely.

Number 4 - Put Everything Under Version Control - Diomidis Spinellis

I cannot emphasize how bloody important this is. This is basically the history for the code base. You can see the history learn from it. Take something and bring it to the present or just refer to it whenever you don't understand why something exists. But again this has to be done properly.

There are few general rules that should be followed that i will reiterate here.

Commit small and commit logical. Each commit should have singular logical purpose. Committing many changes together makes it difficult to isolate which changes are for what. So keep it small focused and logical.
Each commit should have an explanatory message associated with it.The minimum requirement is to capture what has been changed. But it is also good to capture why the change was warranted. This can be linked to some issue id or some feature id.
Never commit incomplete code into the main working trunk. It is recommended to first work in your branch then merge with the main trunk so any conflicts are resolved.

Most developers are introverts and don't like to have conversations. Version control is something that forces developers to have the minimum required conversation to keep the code base healthy.

Number 3 - Put the Mouse Down and Step Away from the Keyboard - Burk Hufnagel

All of us have days when the problem just doesn't seem to solve. No matter what is being done. The best thing to do in that scenario is just to put down the mouse and keyboard and walk away. Sometimes all that is needed is time to formulate the problem, or formulate the solution or understand the problem or the solution at hand. Sometimes even though the problem is understood and well worded it is just not the day to solve that problem. Best thing to do in that scenario is to just walk away for bit and disengage. Do something creative to stretch out the brain and then come back to the problem.

This i find applicable even when there is a huge pressure of deadlines. Recently i had this software release for which i was under pressure for over a month. Whenever i found out that i was now making more mistakes i just call it, went for a break and walk away for few momemts to referesh and recoup. After some walking and listening to music i join back and resume with the work. This way i ensured that nothing got screwed up and the pressure didnt impact or affect my work quality.

Number 2 - Write Code As If You Had to Support It for the Rest of Your Life - Yuriy Zubarev

This is one of the better coding and work advice you can get.Everything here is generalized and includes me as well. How we work now is something that will influence how we will work in the future. Our current attitude defines Our career. If we don't care about our fellow developers, testers, managers or anybody else. We will not be driven to develop something that enables all and adds value. We have to add value to our work and how we add value is by enabling our fellow developers, testers, managers, sales guy or whoever to reduce their effort or enable them to do their work properly.

If we think like okay this is a one time job for me and dust ourselves for taking any future responsibility. That is it we wont be making any effort to better what we received or even think of leaving it a better way than we found it. It will be just like taking it forward with putting as minimum effort as possible. What fun we are going to have from that.

It is better to think like this is something we have to support it rest of the life that way we will try to add more value to the work we do.

Number 1 - You Gotta Care About the Code - Pete Goodliffe

Again this applies to everyone listening. If we want to be better at anything the only way to do that is by caring about it. This is one simple experience that i relate to the most and would advice all.

Good programming is not born out of only technical competence. It requires much more.

I will reiterate the 5 points here:

Don't hack the code take time to craft out code that is correct and has appropriate tests against it.
Write the code that is easy to understand, pickup and maintainable.
Nothing is achieved alone. Work with others. Write in a way others can pick up.
Whenever you take up anything make sure you leave it in a better way than you found it.
Always keep learning new techniques, methods and idioms. But apply only when necessary and appropriate.

Maintainable and easy to understand code just doesn't comes out of thin air out of pure luck. This needs work and top of it it needs the care.

MICROPROCESSOR AND MICROCONTROLLER

Saturday, December 21, 2019

Embedded System Podcast - Episode 8 10 Experiences I relate to