Jeremy Grifski – Page 83 – The Renegade Coder

When you start an engineering degree, chances are you'll get a good mix of experience with the latest technology as well as legacy equipment. That's because professors are researchers, and their research is typically a nice blend of old and new. As a result, you'll have tons of opportunities to see your discipline grow and develop. However, that experience is both a gift and a curse. The Gift The gift of an engineering degree really boils down to one thing: progress. Higher Education Academia is one of the few places where engineers can continue growing without being stunted by Corporate America. Because of this, progress is the norm. There are so many benefits to earning a degree in engineering. For instance, you get to practice your engineering fundamentals which further ground you in STEM. Likewise, you get to tackle a lot of new and exciting problems with some truly interesting people. As a bonus, there are hardly any negatives. In fact, even with the difficult assignments and hard deadlines, you still get to decide how you allocate your time. It's a pretty liberating experience, and you undergo self-improvement in real-time. I enjoyed my undergrad so much that I often long to return. I suppose that's why I got interested in a PhD. The mix of autonomy and challenge was truly fulfilling, and that's something you'll never be able to take away from me. Social Entrepreneurship Beyond college, progress can be found in the form of social entrepreneurship. If you're unfamiliar with this term, social entrepreneurship basically describes the act of using engineering and business skills to address social, cultural, and environmental issues. How's that for progress? This is just about the only facet of Corporate America I can get behind at this point. It blatantly challenges the status quo by using engineering for good and progress. That's something I can't say for a lot of these large engineering firms. Here's a great example of what I mean by social entrepreneurship: Believe it or not, I went to college with the creator of Parihug, Xyla. However, I never met them (#IntrovertProbs). Regardless, I recommend you show them some support. Advanced Technology On the theme of progress, let's talk advanced tech. An engineering degree opens up an infinite number of opportunities to develop the latest in technology. In my field, that includes topics like big data and artificial intelligence. Theoretically, the skills gained in undergrad should be enough to explore any technology you want. In fact, you could even go about inventing something new. The horizons are pretty much endless. Want to help build the next greatest rocket at NASA? Do it. Looking to create the first stable quantum computer? Go ahead. Never let your passion and creativity be stunted. The Curse On the flip side, the excitement of engineering pretty much dies as soon as you graduate. Of course, if you've read this far in the series, you already know that. That said, I really want to focus on the curse of an engineering degree which is a commitment to legacy. Legacy is any piece of tech that resists obsolescence. Of course, the objects themselves can't refuse to become obsolete. Rather, it's the industry that can't seem to move on. As a result, you will likely find yourself stumbling over these old systems for a long time. So, how does that affect progress? Well, let's talk about it. A Caveat As an engineer, you'll never work with anything cutting edge. In fact, you likely won't even work with technology that you learned about in school. As a software engineer, I know this all too well. Unit tests... what are those? Readability... what's that? Maintainability? Continuous Integration? Version Control? The list never ends. I should have no reason to complain. After all, my job is to share what I know to make the company better. Ideally, that would mean sharing my knowledge of everything I've learned. Resistance to Progress Unfortunately, the industry isn't too receptive to change. Implementing version control in a team that currently share files via zip folders is a challenge at a minimum. I've seen these sort of things already in my short time as an engineer. For instance, I was on a team which assigned projects specifically so that they didn't have to deal with merge conflicts. As a result, if merge conflicts ever did arise, no one knew how to solve them. To make matters worse, that team also didn't do any sort of code reviews until the product was ready to ship. Talk about horrifying. Meanwhile, I worked on a another team which refused to automate anything on the developer end. Our priority was always to automate our systems to improve user experience. However, automation tends to add quite a bit of complexity which could benefit from some developer end automation. Unfortunately, my manager was the type of person who doesn't trust self-driving cars. They believed that manual intervention was always better when in fact humans are significantly more prone to error. As a result, whenever we went to deploy software, I had to manually update software versions in a database. I would have much rather automated this through Jenkins, but my manager felt that we would somehow lose traceability that way. I never really understood the reasoning, but welcome to Corporate. Legacy Systems Of course, resistance to change goes much deeper than simple project-level improvements. In fact, I've been on teams where we had to interface with software systems that were 20-30 years old. This wouldn't seem so bad until you acknowledge the fact that there are hundreds of these systems floating around. In many cases, documentation was in the form of tribal knowledge. For example, I spent some time working on a software tool that interfaced with locomotive control systems. Since almost none of our control systems had gone through obsolescence, there were probably close to 20 different interfaces and thousands of configurations we had to accommodate. Let's just put it this way: I think I implemented the same algorithm at least five times to compensate for the various types of engines and engine configurations we had in the field. I can tell you with confidence that this was not a sustainable software environment. I can't say I've missed fighting with the union just to test some software on one of these. To add insult to injury, the company was also working on a new generation of control software that was supposed to be cutting edge. For me, that would have meant adjusting all our algorithms to support the new interface. It's not like we were going to phase out the oldest control systems as a result. Why would we do that? A Lack of Knowledge I think the legacy struggle struck me hardest when I was finally on my way out the door. With just six weeks left to spare in my job, I began visiting universities. At one of the universities, I was quizzed about my day-to-day job. As usual, I gave a generic answer about what I typically did: "I develop predictive algorithms to detect locomotive failures." Naturally, I was immediately quizzed about the machine learning techniques I was using. Plot twist: I wan't using any. I was essentially determining failures based on some perfect scenario mathematical model. It only took a few moments before the entire group—prospective students included—were sharing all kinds of stories about neural networks and deep learning activities they've tried in their free time. Needless to say, they roasted me. Apparently, all of my algorithms could have been reduced to 100 lines of code if I just used a deep learning algorithm on some test data. That moment proved to me that I wasn't growing as an individual. I was stuck sharing what little knowledge I had with people who weren't receptive to any of it. The Takeaway A couple of articles back, I complained about the tech industry moving too fast. I think I said something like "don't worry about fixing anything; there will be a brand new product released next year." That comment was a criticism on materialism in America, and the speed necessary to satisfy American consumption. In this article, my criticism is more from the inside of engineering. While we may be releasing new products every year, we continue to support old products up to 30 years old. That's insane to me, and it creates an environment where new team members can't be productive. They're stuck chasing down legacy schematics for the first two years in the job. Regardless, the takeaway is this: After college, you're basically done playing with the latest technology. Instead, you'll likely spend several hours a day devoted to maintaining legacy systems. In fact, it's possible you'll never touch anything new because the legacy system will never become obsolete. If it does, you're probably out of a job. That's sort of the sick reality of engineering. It's a business after all.