How Your Job May Be Crippling Your Tech Skills

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.

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, and then gain appreciation for the abstractions you once held as a crutch. Its not your team’s fault they did such a good job abstracting complexity — it’s yours for succumbing to the comfort your predecessors designed for you.

The perfect illustration of this concept is high school algebra. Almost every equation and concept you studied in class is now solvable with a quick Wolfram-Alpha search, but that sure as shit wasn’t allowed. Before using a calculator, you had to learn long-division; before accepting the quadratic formula, you had to discover it by completing the square on a quadratic function.

Proof of the quadratic formula

Just like algebra class: we first need to study the underlying solutions to equations we use, only after can we truly appreciate our abstractions. Failing to do this results in an apparent lack of what I call tech-confidence. Theres a clear difference between a developer who truly knows the frameworks they utilize — and one who simply knows how to use them. Sure, you can survive, and even flourish, by only understanding whats on the surface, but you and I both know you’re capable of more than that.

Nobody wants just the tip…

Never Stop Learning

The turning point in my career was when I switched gears from:

I know enough to be effective in my current position

To:

I can be most effective in my current role, and in future roles, if I choose a specialization and master it

With this new mindset, I finally escaped a job that was locking me into a bleak future, became more connected to my daily development projects by actually understanding the technologies I utilized, and conveniently doubled my salary in the process.

Below are the steps you can (and should) take to reach engineering self-actualization:

Choose a Specialization

Specialized developers are far more marketable than those who generalize. In the past I mistakenly applied to dozens of “Software Developer” jobs by packing my resume with every language or framework I had ever touched, which to my demise included HTML/CSS. This got me nowhere, because while I was endeavoring to appear a “Jack of all Trades”, I instead presented myself as a “Master of None”.

You’ll find that even when your specialization doesn’t exactly match a position’s hiring requirements, you’ll still be considered due to your evident expertise and ability to digest complex technologies. In other words: those who specialize prove themselves more so than generalists, and said proof is much more apparent. Below are two examples of candidates skillsets I’ve seen on resumes:

Tech Skills: Java, Ruby, SQL, Apache Hadoop (HDFS, MapReduce, Spark, Cassandra), Linux (zsh), Vim, Git

Tech Skills: Java, Ruby, Python, Bash, SQL, C, C++, C#, HTML, CSS, Flask, Algorithms, Data Structures, SASS, JavaScript, CoffeeScript, Rails, PHP, AWS, S3, Redshift, Linux, Mac, Windows, Microsoft Office, Jira, Github, IntelliJ, Eclipse

As an interviewer: the latter screams “I probably know none of these, and just wrote down every technology I’ve ever touched”. They included Microsoft Office, Github (as in the website..not ‘Git’ the tool), and the dreaded “HTML/CSS”.

The former appears much stronger: they imply a core competency and the subtle inclusion of vim and their shell preference suggest they’re comfortable on the command-line. This candidate has a clear specialization, and a skillset I can more easily digest.

Surprise! Both of these candidates were me, and only one of the above approaches led to serious interviews, I’ll let you guess which one. Also, don’t put Microsoft Office on your tech resume, or any skill you can’t backup — trust me.

Never Stop Reading — Never Stop Doing

The keys to your future have already been written down just waiting for you to pick them up, it’s really that simple. Books hold all the knowledge you need to master your career, all you need is to actually read them.

Countless developers graduate and decide their job will teach them all they need to know. As we’ve already shown, this an extremely dangerous comfort! By simply being proactive and continuing your education, you’re already more prepared, more marketable, and will eventually become more knowledgable than all those who chose to lag behind. Guides, courses, books, documentation, open source projects, and APIs are all great sources of content to dive into.

Reading by itself is an amazing start, but isn’t enough on its own. The key to developing your skills is to ‘just do’. It really doesn’t matter what you decide to code, but you need to put your newfound skills to use to solidify them. Just finished a book on MapReduce? Thats great! Now get out there and write a MapReduce job on some famous sample weather data.

This industry is one that never stops improving, so neither should you — lest you find yourself stuck in a cubicle, maintaining a legacy application built on a deprecated framework. If you only takeaway one thing from this post let it be this:

The best investment in your future is to invest in yourself