Lessons Learned-2 Avoiding the Hard Way

Published on : Saturday 06-03-2021

Ninad Deshpande narrates his experience of learning on the job for the benefit of engineers entering the automation and robotics world.

The life of application, commissioning, service and software engineers might be termed as difficult with everyone enduring extreme pressure on the job and several hardships especially in the early part of their career. Pressures are usually part of any profile, but especially coming out of college, application engineers are subject to not only corporate pressure such as punctuality, bosses and colleagues but also customer pressures. While growing up our grandparents or parents have always taught us ‘Athithi Devo Bhava’ (Guest is God), and as we enter and grow in the automation world we are taught by our seniors, ‘Customer Devo Bhava’ (Customer is God).
 
In this edition of the column, I will focus on some learning during my time as an application engineer and some mistakes which I made and many learning I had by committing these errors. 
 
Hard-work and smart-work is the key
Most of us know that hard work and dedication is the key to success. As we grow in our professional careers, we see our seniors or peers and understand that the ladder to the top is built on a solid foundation of hard work. In my previous company, where I was working as an electronics engineer, I was reporting to the automation and electrical head of the organisation manufacturing special purpose machines. During this time, I learned corporate as well as life lessons from my seniors Ashtekar (automation head) and Pawar (design head). The way my previous boss had learnt and honed his programming skills was simply amazing. In his early part of his career, laptops were not common, and programming was done via desktops, which were locked away after office hours. Only specialised programmers could program machines. During the day he completed his wiring and electrical tasks and observed the specialist program. Later he stayed back after office hours, took back up of the system and tried various programming techniques. Before dawn, he downloaded the last known backup, locked away systems, returned home only to reach the office for the brand-new day. I always tried to walk on his path of hard work, which helped me in my career. I learnt hard work, dedication and focus together with smart work makes life easier, comfortable and faster. 
 
Another important aspect I learnt from Pawar and Ashtekar was brainstorming and out-of-the-box thinking. Many times, it happened that we got stuck in development and all roads seemed to be leading nowhere. Here was the spark of brilliance where Pawar and Ashtekar discussed for a couple of minutes and voila there was the solution to the pestering problem. Moreover, Pawar had a mechanical and design background, yet had that out-of-the-box innovative thinking which usually led to brilliant ideas. These were some of the many learning I had working with them. Words are too less to describe the wonderful times and learning I had in those early years of my career.
 
Programming, but with efficiency

In another instance, I was tasked to complete offline programming of 3 different machines in a matter of a few weeks and then visit the end user place for commissioning them. Post discussion with the customer and my boss I immediately got down to work. Within a week I had completed basic logic development and was 80% ready for visiting the end user site. I made a brief visit to my bosses’ cabin and informed him of the progress. I restarted my work on my desk and at this point in time a senior application engineer named Bhavin happened to pass by my desk. He is very knowledgeable, a master in motion systems and very particular about standardisation and efficient way of working. He asked me a few questions and asked to look into the logic I was working on. Within the first glance, he was displeased with the way I had written the code. The nomenclature was not as per the defined organisation standards. He told me to redo the entire code of all projects. I requested him that it’s too much effort and if it is fine to follow the nomenclature in upcoming projects. He simply smiled and told me that I might be programming the system today, but tomorrow the project modifications might be handled by another engineer owing to a change in profile or me quitting the organisation. In this scenario, a consistent nomenclature, a good commenting pattern and following the organisational set style guide will help everyone and make the life of others easier. I realised how important it was and in one day I modified my projects based on the organisational set coding and nomenclature rules. I informed him the following day and he was happy I had followed his orders. He is a very strict person and upfront to express positive as well as negative feedback. Thanks to him my programming improved and it became easier for others to understand and debug. Today, we work side by side in different departments and he is a good friend. 
 
Performing valuable checks saves trouble and money
Delegating tasks is necessary but it is equally important to review the work before you take the next necessary actions. I learnt this the hard way. In one of my first commissioning visits, I made an error in assessing the efficiency of an electrician. Connecting a 24V signal to electronics is not rocket science. It is connecting 2 wires, one to 24V and the other to ground 0V, which are coming out of an SMPS. I had checked the wiring for 24V in the cabinet on site before power on. There were some errors, which the electrician rectified. Post which he connected the HMI. As I had checked earlier, I was reluctant to do so again and told him to power on the system. However, the electrician had inverted the 24V and ground connections. Boom! The HMI was in smoke and the capacitor and power circuit shorted out. I called up my boss and informed him of the situation. On urgency, he had to send another engineer on site with a replacement device so that I could restart my work. This activity resulted in my sales head blasting me when I returned from site for the additional cost incurred and the time lost for the customer commissioning. The company had to bear the cost of an engineer traveling 700km with a hardware and then traveling back. If only I had made a final check before powering on the system would have saved time as well as costs. This was a useful lesson learned and unfortunately learnt the hard way. However, in all my future commissioning visits I took extra care on these checks and never made these mistakes again. 
 
Learning going a long way
These are only a few learning I could put together from the immense learning I had during my 5 years of application and R&D career, which I found were important for engineers entering the automation and robotics world. I am happy that these learning have helped me not only in application development but also helped me in other areas of corporate life. I hope these will be helpful for young engineers too helping them make the most of available opportunities that lie in front of them.   
 

Ninad Deshpande, Head – Marketing and Corporate Communication, B&R Industrial Automation, has made it a mission to get to know the needs of internal as well as external customers and understanding their unfulfilled desires thus, being able to provide extraordinary experience. Whether it is executing an exhibition, seminar, conference, implementing a campaign for print or social media, delivering a technology oriented presentation, implementing a branding campaign, or internal and external branding, Ninad takes pride in providing best in class service and experience in record time while always leading by example.