Hello there! Rob Green here and this is my part of the web!
I’m not too sure what I’ll make of this site, but as of Fall 2023, it’s going to start off as a blog and area to share my self-taught journey into the realm of Software Engineering and Machine Learning. Maybe one day I’ll add some recipes because I love to cook and experiment, or maybe add some travel/camping because I love to adventure and explore so instead of naming the website:
which I know is a great website name that just easily rolls off the tongue, I went with GreenGuy.me which is a little more generic.
So a little about my professional life… I have a Bachelor’s and a Master’s Degree in Mechanical Engineering and have had a career in this discipline for 7 years. When I was going into post-secondary school I decided not to go into Software Engineering because I told myself “I don’t want to work sitting at a desk my whole career” even though I was quite good at programming in High School and really loved it. So since I was good with my hands and fairly creative I went into Mechanical Engineering thinking I’d one day invent and build great things to help people. Ironically however, thanks to my love of design which allowed me to pursue my creative side, I ended up behind a desk as a designer…
…a designer that constantly utilized programming to automate all those boring repetitive tasks and greatly speed up the design process. I found myself programming often in every role I was in; I just seemed to always gravitate towards it and find solutions to problems using those skills. Key examples in each of my major roles are below if you’re curious.
1st Year University Co-op
My first ever introduction to the working engineering world was a brief 4 month co-op after my first year at a university I later transferred out of. It was at a research and development automotive paint facility and there were only two real duties for the co-op student. The first was a daily duty to manually grab and log a bunch of pressure/temperature values from various user-interfaces of different equipment and then input these values into a Microsoft Access form for saving to a database. The second duty involved tediously counting and categorizing small “divots to the metal” on sample painted panels which had a bunch of pebbles fired upon it. This involved using a clear piece of plastic with 4 outlined hole-sizes on it to move over the panel and manually log all the different sizes of divots that exposed the metal. Both of these duties were the most boring things I had ever had to do in my life and I couldn’t believe I was about to spend another 4 months doing them, so naturally I found a way to automate it. The first was solved with an AutoHotkey script which was simple and just did my repetitive copy & pasting of values from one spot to another. For the second I used Python with Pygame (what we used in High School) and a colour scanner to scan the panel to automatically count all the grey spots (colour of the the exposed metal) and categorize their sizes. This program was incredibly inefficient as it scanned each and every pixel one at a time and looked at adjacent pixels to determine edges vs inner pixels in a horribly long series of if-statements, recorded it in a text file of 1’s and 2’s, then scanned with different category-sized “blocks” to count and categorize it again with a horrendously long series of if-statements. It took forever to run, but it ultimately worked faster and just as well as manually counting (except for grey panels of the same colour – had to still manually do those few) and I left it running over the weekend on the few hundred scans of panels I was supposed to do over the term of my co-op. I was proud and happy I didn’t have to do such boring and tedious work… only to end up having to manually sort/file paper documents in a bunch of filing cabinets for the next three and a half months *sigh*. Suffice to say, I was the last co-op there as I programmed myself out of a job!
3rd Year University Internship
On my 16 month internship I created our department’s intranet website which hosted the quarterly newsletter using a Windows Forms application for the author to easily submit it with where the program generated the thumbnail using Ghostscript, updated the visual bookcase on the site, and notified employees about its release. This intranet site also allowed employees to submit product ideas to our prototyping department which had to go through SharePoint to be official so I managed to connect the two because no one actually liked using SharePoint. I was very proud of all this, however in hindsight the site was a mess because I created it from scratch using HTML/CSS/PHP/ASP.net and a bunch of strange work-arounds to get it connected to SharePoint. But it worked! Newsletter readership increased ten-fold and suddenly the department had the new “problem” of too many ideas being submitted since I made everything so much easier to use.
First Real Mechanical Engineering Job
During my first “real job” in the Automotive sector (which is a sector I suggest any engineer reading this never goes into as you’ll see) I learned to program robots when I was bored one day and… trying to hide from my actual responsibilities since they were a constant flow of “emergencies” I later realized was actually just poor management, short-staffing, and being completely taken advantage of; good ol’ first introduction to the real world, eh? Any-what-how, I’m not sure who had programmed most of these originally, but I found it incredibly simple and managed to increase production by over 30% on some assembly lines by changing and fine-tuning certain movements I believe were just lazily done originally. So all in the span of two days I learned how these robots worked, applied it, and made my company a couple hundred thousand extra bucks per year. Thought I might get some appreciation for this, but I actually got in trouble! Classic! On another occasion when I was tired of designing and then fabricating the same part delivery racks for the assembly lines I was bringing in and setting up, I decided to automate it in SolidWorks naively thinking it would help me have more time for the constant flow of “emergencies” coming my way. I wrote a script where you could select the part and tell it how many per day and it would use the part volume and quantity to fully generate the cookie-cutter rack(s) that the company used for parts flowing into the assembly cells. All with Bill of Materials, how-to-build drawings, cut sizes, etc. What used to take a tedious week to CAD up, draw/BoM, and then go build could now be done in an afternoon by a first year co-op student. I was proud and thought maybe I’d finally get that appreciation, but boy was I naive. Instead the company decided not to hire another engineer…
Opto-Mechanical Design Engineer
In my most recent job, which was truly a designer role at a computer, I did a lot of programming from VBA scripts in Excel to scripts in their CAD software. What I was particularly proud of was automating the bulk of our design process. This was an opto-mechanical designer role where I took the optical requirements and then designed all the precision mechanics around it. With the power of programming I managed to fully automate the base-CAD of all the optics using the Excel data from the optical designers, including embedding the tolerances and other requirements into it. Additionally, I automated all the drawings to pull all this information and re-wrote the design process for it all. In essence, with a lot of work during the downtime of various projects, this programming effort allowed the company not to hire another two designers as my peers adopted the new process/tools. What used to take hundreds of hours setting up the design and drawings with even more hours if the designer made an initial error in applying the optical data (very common) was now a thing of the past. And I really enjoyed creating it all; it was probably my favourite piece of work I did in all my years there and it wasn’t even part of my job description.
If you did check out the above examples you may have noticed a general theme where I utilized my foundational programming skill for my company to learn their tools available and then create something that ultimately made the company no longer need to hire additional employees as they grew. I believe I was an under appreciated asset partly because my superiors didn’t understand the extra work I was doing above my job description and I never really got any appreciation for it; however, I knew I must be valuable if my efforts made hiring of new employees no longer required. Even with loving both programming and solving problems using it, there was something else I really admired about it compared to mechanical design. When attempting to design a new physical product or solution to a problem there is always the prototyping and testing phase. Many project managers didn’t seem to understand this part and for reasons I still can’t understand they expected initial designs/solutions to work first try. I was often either setup for failure by being forced into building that initial CAD design straight into production (which obviously never worked first try – well, maybe once) or I had to spend many frustrating hours trying to convince them to spend some project money on tests/prototyping. In fact, I often found myself spending more time doing this than actually doing design work and that combined with so much red-tape to actually get anything done at all made me really dislike my career choice. In programming/software this barely exists. You may have dev sever copies to test with or the only barrier between your potential solution and seeing if it worked for that juicy job fulfillment is just clicking the Run button. Therefore, I was always excited to be programming on the side and able to get solutions to problems working without spending a week making stupid presentations and calling meetings to prove why we needed to spend $100 and a couple hours testing some off the shelf parts. In fact, even when approved it took weeks to actually get the same-day shipped part as it made its way through the full purchasing system. That’s just frustrating and not enjoyable at all.
After a series of unfortunate events which I’ll refrain from sharing here, I was essentially forced to quit my opto-mechanical design job. This created an opportunity to really think about my career and if I wanted to continue to pursue it. I realized that the most enjoyable parts of my career was finding inefficiencies to automate and any of the programming I learned in order to accomplish it. And so here I am teaching myself one of the most interesting topics to be able to automate very complex tasks: Machine Learning. I believe life is too short to spend a considerable portion of it in a career you do not fully enjoy and that it’s never too late to change paths once you realize this. So join me on this new career path of mine as I put this theory to the test.