How Your Job May Be Crippling Your Tech Skills

How Your Job May Be Crippling Your Tech Skills

hackernoon.com hackernoon.com3 years ago in#Dev Love25

Originally published by Eric Girouard on March 28th 2019 A desire for simplistic on-boarding and fail-safe environments ease developers into a self-destructive comfort. Modern software applications are monstrous. Even small corporate products can be composed of layers upon layers of abstractions. Depending on which layer you work most closely with, there’s a lot you could potentially be missing out on. Photo by Markus Spiske on Unsplash This post isn’t about learning a new language or framework in your company’s tech stack, nor is it about suggesting they use new, more modern, ones. This post is about ensuring mastery in whatever fraction of a stack you specialize in — and knowing what to avoid specializing in. Below are several situations in which your job may be holding your career back, and how to escape them. Proprietary Programming Languages Some companies invest a lot of time and resources to produce their own internal languages. These languages are proprietary — meaning no information about them can leave the company’s walls. The risks of this should be obvious: You’re unable to transfer these skills to another job, since no other company can use the technology. You may even be prohibited from discussing details about it during interviews and phone screens There is an implicit “sunk cost” associated with mastering these languages. Any time you spend learning, developing, and potentially mastering, a proprietary language is time you could have spent learning something much more marketable, and more widely-used. You could have delved deeper into algorithms, open-source technologies, or the hottest new JavaScript framework. The only real way to escape this trap is to leave and find another job. However, keep in mind that you can still progress your soft-skills and coding best practices while working in such an environment. Internal Implementations and Abstractions This situation is much more obscure, so allow me to draw upon two personal anecdotes. At my first job, I was entrenched in SQL development designed to feed data into the company’s main application. I was never exposed to said application, its APIs, documentation, or even its tech stack. It was the epitome of a ‘black box’ so much so that we even referred to it as such. I left that job with a strong understanding of SQL, but lacked any front-end knowledge of the product, including how it interacted with my work. All of this was because I was comfortable being coddled by the company’s attempts to segregate developer’s tasks from each other. More recently, I worked within the Apache MapReduce framework every day for over a year. For those who don’t know: A MapReduce Job has 3 main components: a Mapper, a Reducer, and a Runner. These components make up the core of any MapReduce Job, and I knew absolutely nothing about how to configure them directly. My team had written their own wrapping framework around MapReduce, and I was very familiar with this…but not the underlying implementations. This is your real danger. From the side of your employer — this is a huge positive. More abstractions on top of convoluted frameworks means new developers can be on-boarded quicker, write code faster, and produce fewer bugs than if developing on top of the pure implementation. Teams should be encourage to reduce complexity and implement safeguards, wrappers, and ease of use scripts into their daily development lives. Here’s the key though: Its your duty to understand the underlying implementation,  » Read More

Like to keep reading?

This article first appeared on hackernoon.com. If you'd like to keep reading, follow the white rabbit.

View Full Article

Leave a Reply