My name is Glen Cote. I was an Embedded Firmware Research and Design Co-op at Schneider Electric in North Andover, Massachusetts for six months from January to June of 2019. Embedded firmware is programmable computer code, or software, embedded in electronic hardware devices such as network routers or remote controls. It was my job to debug or fix the embedded firmware that our engineering team was putting on different network devices so that the devices could communicate with each other. It was often challenging and all-encompassing work. Thankfully I had a great team of fellow engineers I could always go to for help and guidance.
My main roles in the position were porting software libraries from one environment over into another and getting the software that relied on those libraries to work. A software library is just a collection of code, similar in concept to books on a bookshelf. Each book on this metaphorical bookshelf contains different functions or instructions that can tell a computer what to do and how to do it. If you include one software library in the program you are writing, you then have access to all of the instructions that are in that library right in your program. This is enormously useful in software development as a whole, because it means software developers do not have to keep on rewriting the same code over and over again.
Sometimes when you include a software library in the program you are writing, the functions that contain the instructions you try and use in your program by calling them do not work. This can happen for a lot of different reasons. Sometimes the environment you are writing your program in, such as what machine you are writing the software program on, is not configured properly. Sometimes the computer program an engineer is writing will fail to execute, compile or build because some or all of the libraries that the engineer was trying to include in their program are not compatible with the other libraries already included in the program.
A lack of compatibility between software libraries can cause a lot of weird things to happen in computer programs, such as the program outputting data that makes no sense, outputting no data at all, or the program refusing to run or execute. If you are fortunate, you will get an error message that can give you a clue as to what is going on or what the root cause of the problem is. Often you do not. It is often very difficult, sometimes even frustrating to figure out what broke, why it broke, and how to fix it to get software programs working properly.
I was tasked with porting libraries over from one Operating System (OS) environment, Linux, over into another OS environment, VxWorks. This was so that our team could write code to demonstrate that it was possible to have network devices we were building communicate more quickly and efficiently with each other. One of these libraries was called libnetconf2. That library is a collection of software that can allow network devices to communicate with each other in a secure and efficient manner that conforms to a network protocol called NETCONF. It was and is not trivial to port over a network configuration library from one OS to another.
My porting task was part of a larger project with the purpose of optimizing network devices for more efficient and secure means of communicating with other network devices. Schneider Electric is predominantly an electrical equipment company with a focus on industrial automation. High-tech factories need to have networks that function properly, efficiently, and securely, hence why it was important to have a team of embedded firmware engineers combing through software libraries to make sure the devices the code would be running on were compatible with the functions of the libraries.
I did not expect the workload to vary as much as it did. What I mean by that is that there were often times were the workload would be very intense. I am thinking of a particular two-week interval where the team I was working on had to prepare for the technical demonstration for the Vice President of our department. I was able to rise up to the occasion and be a productive member of the team during this time, but it was very stressful. In contrast, towards the end of the co-op there was very little to do. It felt odd that I was paid the same amount of money whether I worked my butt off or whether I did not.
One of the things that surprised me was how difficult the initial shift working an 8 to 5 schedule was on my energy. As an undergraduate, I am used to having a fluid schedule and working late into the night. I thoroughly enjoyed having a more consistent schedule and having nights and weekends available, although many of them were spent resting. I loved having actual spending money available for me to go out and have fun. I was able to meet a wonderful woman and travel to another hemisphere because I had time and money when I was working.
In America there is a unique social culture surrounding the work of young professionals where it is expected for people with a college education to be incredibly passionate about their jobs and career(s). We heavily identify our own personal identities with what we do for 40 plus hours a week and how we rent out our labor. Sometimes I would try and tie my identity to that of a software engineer and try and impress people by saying that, but I never really felt like that that is or was a core part of my identity. I am surprised that I am not as completely passionate or immersed in the tech industry as I thought I would be. I often viewed it just as work, and that work let me do other fun things that I cared a lot more about like having a girlfriend or traveling.
Experiencing the cultural diversity at the workplace was by far one of my favorite experiences during my time at Schneider Electric. I would often hear multiple languages a day: Hindi, French, Mandarin, sometimes Spanish as well. I had multiple friends who were immigrants from India, and I learned just how unnecessarily cruel and stupid the American immigration system is for people who are just trying to earn an honest living by moving to a wealthier country and working here. I learned this just by talking to people, and I would not have gotten the opportunity to talk to as many smart people from around the world if I had not had this co-op. For that I am very grateful.
My experience at the co-op gave me the confidence that I needed to know that if I want, I can succeed in this industry. It also gave the knowledge that I may want to spend my time in either another industry or in an environment with a different corporate structure, or no corporate structure at all. I also realized that while working full time and having actual work to work on for months on end does satisfy the innate human desire to actually produce stuff that we care about with other humans, I will need more from my life than just a full workweek schedule to be actually happy and have some degree of fulfillment. Or I will need a different industry other than electrical equipment or maybe even technology to really feel as though I could utilize myself and my skills to the absolute fullest with my career. That is a scary realization. It would be more convenient for my life if I could just be perfectly content working a corporate job that pays well and has good benefits. Trying to carve out something for myself that feels more tailored to who I am as a person is much more difficult. It might be worth it. It might not. I will have to grapple with that.
I learned that often the biggest barrier to progress in a tech company is not solely technological in nature but rather is often primarily an issue with how humans work together. For instance, sometimes there is a trivial solution to some technical problem that an engineer will grapple with for a prolonged period of time. All that would be needed to fix this problem would be to talk to a particular human. Finding the correct human to talk to at that specific point in time for that specific problem can often be excruciatingly difficult. On a similar note, I also learned that meetings vary wildly in terms of how productive they can be. Sometimes what was said in a meeting could easily have been said in an email. Sometimes a discussion that needs to happen but does not happen until a meeting occurs did not need me to be present whatsoever for the necessary information to be conveyed to the necessary individual at that given point in time.
I am extremely glad that I have had this work experience. I gained and developed valuable skills and now have a more robust mental muscle reflex in terms of how I tackle and address solving technical problems. I can also work much more cohesively on a team in a software development environment, which I am certain can be applied to other teams as well. I made and cultivated valuable professional and personal relationships with my colleagues and friends at Schneider Electric that I hope to continue to have for a very long time. However, it is important to note that with this experience in mind, researching and developing embedded firmware in a large multinational corporation may not be the best use of my career. I learned that I would much rather work in a smaller firm and would also prefer to have a higher degree of autonomy in terms of what projects I work on.
I am not sure what my next professional steps will be. It may be less of a forward sequence of steps and more of an awkward shuffle forward, backwards, and sideways every now and then. That is the reality of careers in modern America. No one really knows what they are doing. We are all just trying to figure it out as best we can. Some people can tell themselves or the world a really pleasant story about how they are developing themselves professionally and plan on being in the c-suite any day now. Many of those same people end up burning out and need months or years of cognitive behavioral therapy to deal with all of their pent-up insecurities that ended up derailing all the cute little plans they had for their life. The best course of professional development is to just keep trying out different projects and jobs that I find legitimately interesting and see how it works out. I would love to work with and help underprivileged youth while getting more involved in the community. That does not have anything to do with software or embedded firmware. That is also perfectly fine and a reasonable course of action for someone who wants to try out different things in life.
The best way I can keep in touch with my professional network is to take a legitimate interest in how my friends and colleagues are doing. If or when a recession comes and the job market violently contracts and shrinks, I am going to absolutely need not just professional connections or former colleagues from work but actual friends that care about my wellbeing and have my back. One of these friends could help me get work so I can pay the rent and feed myself. I would do the same for them if it came down to it. I will keep in touch with them.
I had an extremely rewarding time during my time at Schneider Electric. It put cash in my pocket, time in my schedule, and gave me more of the skills and valuable connections I need to succeed in the job market and in life. It is for these reasons that I am enormously grateful to those at Schneider Electric who helped me grow as a developer and as a human being.