I inherited the responsibility to create Vital Product Data (VPD) data for customers (which we called called FRU data because it resided on Field Replaceable Units). Each customer had a unique spec that needed to be understood. On top of understanding the different formats and requirements, each had their own pipeline for generating and programming the VPD. I had to become an expert on all the formats for the customers and the processes from initial ideation to final hand-off to the factory. This required also building a rapport with the program manager for each project/cutomer. It required a lot of learning and and becoming the expert for the whole division.
This eventually led to me developing software that was aware of the different specs in order to expidite the porcesses. This was done using a web-based GUI that could populate templates specific to each customer. This allowed more people to be able to make the VPD files without necessarily needing the expert knowledge.
There was an issue where SFPs in our product were defective if they were from certian batches. The manufacturer of the SFPs sent us large spreadsheets with serial numbers and their correlating batch numbers for us to look up to determine if SFPs were coming from known-bad batches or if it was a new issue. This was something the Project Managers were dealing with. I had a good relationship with many of the PMs and they were doing lookups in Excel very slowly with these large datasets. I offered to make a web tool (using JavaScript) to enable them to search for Serial Numbers from the large datasets. The tool allowed them to past in many serial numbers and get sorted informaiton on each, as well as partial matches etc. It sped up the process and all of the PMs used the tool. This was not something I was asked to do, but I saw a need and wanted to help the team.
I had developed a program for managing Inital Program Load (IPL) files. It handled files for all the products we made. The problemw as that the code I made was platform specific; that is it only worked on Linux because that was the platform I was using. When this tool proved useful and other people wanted access to it, I decided it was better to port it to JavaScript and serve it on the Intranet. This allowed anyone in the company to use it, and for me to update the code and not have to worry about distributing it on multiple platforms to all the users. It was a little bit of time investment to port the code, but saved a lot of time in the end, and allowed for wider use of the tool.
I was working on the backend of a webapp using Python, and I wanted to know more about the front-end code which was in JavaScript. I did soem experimenting and learning, and ended up writing my own suite of tools in JavaScript just to get more familiar and expand my skillset.
When I inherited code for a program called cScope, the code was a bit of a mess. It was legacy code written about 7 years before I inherited it, and during that time the hardware engineers who didn't know how to code had made modifications to it. I took the functionality that was there and salvaged it, but rewrote the bulk of the UI in order to make it more maintainable. I split the different functionaility up into modules instead of just having a single monolithic source file. I also worked to modularize the code in order to reduce duplication of ideas. By converting certain areas to classes, I was able to make it easier to maintain as well as add features such as analysing multiple adapters simulatenously which was impossible before.
There was a show-stopping issue in the factory for one of our products. Time was running out and the issue kept escalating, however we were still not able to root cause the issue, which we had to do remotely. I developed a script to work around the problem which the factory could use to get us over this time crunch. That gave us more time for root-causing the actual issue and kept the factory running. We did get the issue solved after another day or two, but bein pro-active about finding a work around for the moment relieved a bit of pressure and kept us from wasting money with a stopped production line.
When working on the Vital Product Data (VPD) Assistant, I felt that the ease of use was the paramount concern since the main users would be Program Managers who were not necessarily technical. My manager wanted additional features in it that would add additional layers of compexity to the workflow. I addresses my concerns and why I thought the features were not necessary to the core reason for the tool's existence, but went ahead with the changes. The important part is to commit to the team and be unified even though I didn't agree with that choice at the time.
The support team was under a time crunch trying to solve an issue with a very large customer. They were collecting log files from the customer of captured failures that were very large (about 1gb each). I offered my services to create som scripts that would sift through the data and extract just the parts they were interested in. This saved them a lot of time and allowed them to use their time actually debugging the issue. Offering this small bit of help garnered trust, and we continued to have a good working relationship for the remainder of my tenure.
On the less serious side of the consequences, I recently got an email from a coworker asking for some guidance on how to use the utility I was developing. I read the email, and didn't resond, and eventually forgot about it entirely. A week or so later, the person pinged me again. I had to apologize for neglecting their inquiry. There weren't any dire consequences, but it did keep them from moving forward on a task for a week, and didn't grow good will. I apologized and offered any help I could give them. Everything was fine, and they were understanding. It's important to be responsive and not let things, even little things, be forgotten.
On the more serious side of the consequences, during college I was working for a company who was developing an iPad app for medical use. There were mistakes in the app that needed to be fixed before it was shown to the customer's client. I built and installed the corrected app, and then took the iPad to a demo with the customer and his client. I did the presentaion of the App, and the client said that the errors were still present in the app. The customer was furious. This meeting was an hour away from our office, and I had no laptop, and couldn't fix or reload the app. I had to just take the blame and apologize as best I could for the mistake. When I got to the office I checked the files on the computer and the files were correct. I rebuilt the app and installed it and it was perfect. If I had taken the time to check the app before I left, I would have cought that it didn't get loaded correctly, and redbuilt it and avoided the entire scenario. I have never gone to a presentation or demo without double checking everything since.
I had a co-worker for a long time who was not super easy to work with. He was a grumpy developer. Definitely good at what he did, but didn't like being told to make changes by other people. He had a reputation, but people like my or my manager would act as a buffer between him and other to keep tensions low. At times he was disrespectful or unkind, and that can hurt, but it's also important not take those interactions personally. As time went on I distanced myself and only interacted on a professional level, and not as much on a personal level. He had dificulties in his life, and I can understand why he was grumpy at times. I try hard to remember that people have complicated lives and to not take their behaviors personally, and to strive to get the work done.
The HBA products at Emulex had a lot of moving parts. We have multiple products with independent pieces, like Initial Program Load (IPL) files and Vital Product Data (VPD), etc. Many of these files were not stored in any particular location. Some were stored by the PMs who managed the different customers, some were stored by the engineer who maintined the VPD, and the IPL was stored by whichever firmware team the product was for. I because collecting all these files into a centralized location in order to more quickly and reliably provide these files to different teams. I created a database of specifications and mapping of which files went to each product. Eventually my manaager saw the benefit of this centralized approach and we created a web-based internal tool called ACE that would maintain these relationships and make it easier for each team to edit and get the most up-to-date files.
We had an intermittant issue affecting manufacturing. I wasn't able to replicate it in my local setup. There was another team that developed the OS. The OS would load the Diagnostics I was developing, but in my setup I bypassed the OS and would boot straight into the Diagnostics for development and testing. This was done for ease of development because building a new OS with a signed version of the Diags was a time consuming process. At any rate, Manufacturing, the OS team, and I had to work together to root cause the issue. We were eventually able to recreate the issue and solve it and release a fix. It ended up being related to EFI parameters and BIOS setting combination. The only stress was the time crunch, but working with each team was a pleasure because we were all focused on solving the issue.
I hadn't previously used the formal term threat modeling, but I have done the underlying analysis in my engineering work. Previously I worked on a product that collected customer data from Kafka and stored it in a database locally to be analyzed and used to identify problems that could be addressed before it was a nuisance for the customer. We had multiple considerations regarding security including PII and access to information. We chose to strip PII from our DB storage and only retain error-specific information. To address the access, the APIs were assigned OKTA roles so only specific employees with certain rights could access the information we collected.
Some software I worked on was use for provisioning hardware that was being programmed in a DOS environment (and this was only a decade ago!) We had IPL (Initial program load) files that needed to be decrypted to be installed on the system. DOS's age was a difficulty in many respects, but to get the decryption working quickly, rather than reimplement the program in C, we worked on getting Python (the program the decryption tool was written in) to work in that environment. An older version of Python was already available that would work (version 2.08 I think) and then some minor tweaks were all that were needed to the script. Not glamorous, but got the job done quickly.
© 2007-2025 Michael Caldwell