Sorry, but since every new language or lesson requires you to run “Hello World” first, and this is my first post on medium, I figured it was only fair (if perhaps not terribly clever). Welcome to my blog, I have never been much of a writer (more on that in future posts) and I am certainly not the introspective type. Still, I plan on sharing my journey from where I currently am to where I hope to be and hopefully share some tidbits I pick up or curiosities that piqued my interest.
Before that, lets me share some things about myself. The title probably gave it away, but I am a fledgling software engineer. Or is it a full-stack engineer? Software developer? Needless to say, it's confusing. I do have an engineering degree, though it's in mechanical engineering and there is a bit of a difference there. I have taken some college programming courses, but that was over 15 years ago and I learned C, then never touched it again. But back to the topic at hand, why software? The short answer is I like making things and solving problems, the long answer is well, long, and requires knowing a little more about me.
My background shouts plant maintenance engineering (though I strongly prefer reliability engineer) or process engineer, which at first glance is about as far from cutting edge web applications as you can get. Truth be told, there is a lot of knowledge that just does not translate, it is unlikely that a detailed knowledge of bearing failure mechanisms and inspection techniques is going to be wildly applicable (except for the occasional moment when a pc or server cooling fan dies and I get to sound smart).
The dirty secret is, identifying how equipment works and how it could fail to work was really not what I did on a day to day basis. My previous jobs in reliability engineering were really about data collection, management, and analysis. While the output of the analysis was the end goal and where the value was delivered, the data systems I used were were not user friendly (thanks SAP) and were populated by maintenance technicians who on more than one occasion told me straight up that they chose this job specifically to be as far away from a computer as they could get. This meant that the vast majority of my time spent on cleaning and organizing data so that it was in a condition that could be used. So, I spent my days thinking about how users interact with the system, how data models should be structured, how to efficiently check for inconsistencies and errors, and generally understanding the backend of the CMMS (computerized maintenance management systems) my clients and employers were using. I even had to teach myself some SQL and VBA to efficiently do this (not at all because I was lazy and really really hated do the same checks or data conversions over and over). That sounds a lot more like backend software development than you would have guessed from my background in industrial maintenance.
So, back to the topic at hand, why software and why now? Now is easy, the pandemic “gave” me the unique opportunity to evaluate what I was doing and if I wanted to continue. See, through a combination of location, skills, and market pressures, I worked in Oil & Gas, and the is fact that people are not driving and while great for the environment (and yes, I do care and am thankful for that) it is not great for the price of oil, so now I have a second to breathe and evaluate my life. Why software, well it started by getting frustrated searching job boards and discovering that every Reliability Engineer in the entire country was focused on SITE reliability. It continued after a lot of self-reflection (and gentle nudging from some good friends) and realizing that throughout my carrier there have been two things that I really enjoyed, working with other people and making something new to solve a problem.
I have worked on software development projects before. One where I was one of the subject matter experts and front line user for an entirely new enterprise program. Another where I was a sponsor (well sponsor’s representative, but still exercising direction over stories and project acceptance) for an agile data system migration. Finally, I am currently an observer and advisor for a very small software startup and am getting an up-close view of the entire process from a chat at a bar to alpha, beta and full release. Side note, the only project that failed to produce anything was the only one using a project management philosophy (Agile), it's not a fault of the methodology, or that the others would not have been better with a framework, but it's an interesting observation. This experience helped confirm that yes, I would work with people (and would have to) and that there are really exciting problems to solve and they are everywhere. Put everything together, and it seems like a no brainer to me, and to be honest, that is all that really matters at the end of the day.
So, to recap (also TLDR) I’m a mechanical engineer who has done a lot of data work and has worked with development teams before. I have now decided to stop sitting on the sideline and jump in to help solve the problem myself and do something I will truly enjoy. Wish me luck and feel free to drop me a message on LinkedIn.