Three Pillars to Elevate Your Career

Whether you’re working at a start up, an enterprise, your first professional job, or celebrating your 10th year as a senior-level dev, there are always three areas to examine to take your skillset to the next level.

This time of year I always make it a point to sit down and talk with individuals on my team about career development and areas to grow into, and I always find that the recommendations fall into one of three categories. They work together to help raise your career and your skill as a developer — so I’ve dubbed them “pillars”, and are grouped as, “Conceptual Knowledge”, “Contextual Practice”, and “Autonomy”.

Though this article discusses software engineers specifically, I believe these pillars can apply to many careers outside of engineering.

These pillars will help elevate you to the next level, working together to raise your ability and value as a developer. Over invest in one, and you’ll end up lopsided – feeling stuck even though you feel really good at this one thing. Investing in even two will get you farther, but still a bit wobbly – someone who can be relied upon but who will have obvious shortcomings.

Conceptual Knowledge

This is often the easiest and most thought-about pillar in the engineering industry. The term “conceptual knowledge” here is thought of as the raw knowledge of various technologies used in your day-to-day. How well do you know [insert programming language here]? What about [insert framework here]? Do you have a solid understanding of [broad concept here]?

Conceptual knowledge is gained through study and through practice with your set of tools. It’s reinforced with certifications and college coursework. It adds up in the Skills section of your résumé and your LinkedIn profile. You know AWS, Python, C++, Docker, .NET Core, etc. Maybe you read 10 programming books in the last year. All of these things are great, it’s the foundation of any engineering job ever.

However, by itself, it’s not enough.

Contextual Practice

Also referred to as “practical experience,” this pillar is where your contribution value starts to show itself. How do you take what you learned (your conceptional knowledge) and apply it to business needs? You might know how to do back-end API performance analysis, but do you know how to optimize front-end performance?

Consider the following: How do you take a request, add your conceptual knowledge to it, and fit it into the existing business model? Why are your environments set up the way they are? What are the benefits to framework A vs framework B as it relates to your organization’s problem?

Let’s look at this pillar through a real-world example. You work at a startup that is working in a machine-learning application to help first-time authors get feedback and edits quicker on their manuscripts. You want the application to give feedback on words that don’t exist or are used improperly, which for most manuscripts would work great.

But what happens when the application encounters a fantasy or sci-fi novel? What if there is new technology invented as part of the story? There may need to be some interpretation going on there as to what a certain term means. So how, in the existing application, is genre determined? Are there any guidelines? Based on your understanding of the goal and the product, should there be any additional input parameters, or are you just feeding it text and hoping it’ll figure it out?

How do you take your machine-learning knowledge and write a function to determine a manuscripts’s genre? Or interpret words that don’t exist according to your referenced dictionary?

Contextual knowledge is tricky to grow, and is often niche-specific. IoT developers think differently than mobile app developers. The best way to improve on this column is to work on real-world problems, but if you want to go the extra mile, look at examples of common business asks in engineering companies and use your specific tools to solve them. Some examples that I can think of off the top of my head:

• How would you keep track of physical inventory in an order management system (OMS) while also protecting against over-selling?
• When developing a web application, how would you build it so that you could easily add a mobile app in the future?
• How would you go about increasing network security in your infrastructure?

Autonomy (Problem Solving)

You always see terms like, “self-starter”, “self-motivator”, and “strong problem solver” in job descriptions and recruiter messages. Can you work through this error message by yourself? Do you know the steps to breaking down a complex problem? What about analyzing complex requirements?

In the real world, this may look like an ambiguous ticket that you just got assigned, or some service that you’re not familiar with. Maybe it’s a bug whose existance defies all reason.

Let’s look at what this might look like in practice.

You work at an e-commerce company, and the operations department just came to you with a request to start collecting fulfillment analytics after a customer has placed an order. They want the following data:

• Mean time from checkout completion to leaving the warehouse
• Mean time from checkout completion to delivery
• Correlate the fulfillment times to order value (How long does an order worth $1,000+ take to fulfill vs an order valued at $100?)
• Run a comparison from the time estimated at checkout to what was reality. How off are the estimates you give to the customer?

How would you start breaking down this problem? Do you understand all the data points that are involved in these calculations? Do you have the same understanding as the requesters?

Now let’s skip ahead to the future, after you’ve used your awesome conceptual knowledge to identify what tools you’ll need and your contextual practice to place the code right where it needs to be.

You’re completed with the code, unit tests are passing, and it’s about to go to UAT. You decide to do a quick sanity check on some numbers, and find out that according to your report, the low-value orders nearest to the fulfillment center are taking the longest to be delivered. That doesn’t seem right, does it?

Well, does it?

How you tackle complex problems and analysis like our example will help determine how autonomous you can be in your role. Breaking down problems is a fundamental skill in software engineering, and how you go about navigating those problems will be a huge determination in how you operate as an engineer.

You may be asking, “but Logan, how do I get better at thinking?”

Like any technical skill, problem solving is something that is both teachable and easy to formulate. Here are some suggestions:

Write down a list of questions that are broad enough to be applied to any problem, but specific enough to get you useful answers. Some examples:

• What data points or functions are involved with this issue?
• What is the end result supposed to look like? Do I understand it the same way someone else does?
• What services does this problem involve?
• In our e-commerce example, what service generates the orders? How do those orders get from the e-comm site to your fulfillment software?
• Are there any error messages or information to take into consideration?
• If you’re debugging, my personal favorite is, “what does the error message actually SAY?”

If you’re feeling overwhelmed, break it down into steps that feel digestible.

In a classic twist, breaking down a large problem into smaller problems, especially sequential smaller problems, can often help you get traction on an issue. “How do I fix this problem?” becomes, “How do I ensure data from datastore A is getting to datastore B properly? How do I then give the reporting service access to both the datastores to run reports?” You get the point.

When in doubt, diagram it out!

Anyone who has worked with me knows that I am an absolute diagram junkie. It’s how my mind understands things, and a way that I’ve found communications a flow effectively. Create a flowchart outlining how the function operates or how data flows based on your understanding, and then read through the code to make sure it’s accurate. After that, run it by someone else as a sanity check. (Or you can talk to your handy-dandy rubber duck.)

Bringing It All Together

Using these three pillars, you can evaluate where you are and what you need to improve on. Be honest with yourself when evaluating your strengths and weaknesses — embellishments won’t help you. Think about what your job requires of you, think about how you are able to cope with the challenges thrown at you, and look for where things fall in the cracks.

Regardless of skill level, there will always be something more to dig into. Maybe it’s another programming language that is optimized for certain procedures. Maybe it’s a new tool that is just coming over the horizon. For all you senior, staff, principle, [insert big title here] engineers, keep in mind: though you’ve come a long way, there will always be more for you to dig into.

For those who are in management, or maybe among those who don’t write code, these concepts still apply. Think about leadership skills, project management, and coaching — these are all things that can be honed just as someone’s fluency with programming languages.

You are the captain of your career. Only you know how to progress.