I’ve been a video game nut ever since I was a kid. I especially loved those Dungeons & Dragons style role playing fantasy games where you played a lone hero out to save the world from unspeakable evils.
Every role playing game, whether it’s paper based or computer based, all share the same basic gameplay mechanic.
You start out with a set of character attributes that define various aspects of your player character. Things like how strong you are, your dexterity, your intelligence level, etc.
Then you have something typically called “hit points” which represents the total amount of “life” your character has during the game. When your hit points level reaches zero, your character dies and the game ends. The key to survival is to make sure your hit point level always stays above zero, especially during battles.
When you go into battle, either the computer player or the human “dungeon master” of the game, calculates the success or failure of your character, based on your character attributes and how many current hit points your character possesses. Every time the enemy successfully lands blows to your character, your hit point level goes down.
These role playing games are all about going on quests and battles. The key to winning the game is to “level up”. When you first start the game, you start at level 1.
But you must constantly strive to make your character stronger by leveling up, because the foes you encounter continue to get stronger and more powerful as you progress through the game.
To level up, you must perform various actions and complete quests to demonstrate you have earned the right.
Much as in real life.
Maybe not so much in the form of slaying dragons and saving the world from evil wizards. But there’s definitely a path one must take.
I had a recent one on one meeting with my senior management for the purpose of knowing what I needed to demonstrate as a software developer, to progress up the technical ranks.
it was a very informative discussion and by the end of the meeting, it occurred to me that leveling up in a fantasy role playing game isn’t terribly different, in essence, than “leveling up” in a real life career.
The first thing to understand is there ain’t no freebies in real life. Any sense of entitlement or attitude that you somehow DESERVE to be promoted, just by showing up to work, is fool’s thinking. Period.
Complaining and whining about not getting promoted won’t get you anywhere either.
When I first began my professional software development career, I started out with some naive and incorrect notions about career development.
First, I thought that just showing up to work on time and doing my job was enough to show my manager I deserved to be promoted.
Second, I thought that merely continuing to learn technical things was the magic ingredient to showing I could level up to a senior level developer.
Anything else that got in the way of being hunched over in front of a keyboard, and pounding away on computer code, was a complete waste of time.
I kind of wish I had a time machine to go back in time to meet my younger version of myself and bonk him on the head with a sock puppet, and knock some sense into him.
Chalk it up to human nature, but the only way I learn most things is the HARD WAY. That is, by making truly terrible mistakes, and experiencing the negative consequences first hand.
Does your hand hurt when you place it over an open flame? Then stop putting your hand over the open flame!
It took me many years and some painful life lesson experiences to finally get it through my thick head that the world doesn’t owe me a thing.
And it took me many more years to finally figure out some things about the nature of working for a business, before I finally learned HOW to actually level up in an organization.
Probably the number one mistake that trips up many software developers about career progression, is the notion that technical skills are the ultimate key to moving up within an organization.
And at first glance, it actually SOUNDS logical, doesn’t it? After all, a software developer absolutely needs technical knowledge and skills. It’s software programming, after all.
And make no mistake, you absolutely need to know how software is constructed. Technical knowledge is the programmer’s virtual toolbox. And you absolutely must continue to keep your technical skills sharp, because technology is moving at an ever faster pace than ever before.
Nothing in technology stays still. That’s an ironclad fact. There will always be a new programming language around the corner. A new framework. Some shiny new software development methodology. Extreme programming. Pair programming. Agile programming. Scrum. Lean. Yada, yada yada…
As a developer, you don’t need to learn every new thing on the block. But it’s important to keep abreast of the latest developments in technology. The kinds of technical skills and knowledge you possess, directly affects your career prospects and job marketability in life.
The more you learn in-demand technical skills, the more marketable and valuable you are in the job market.
But the technical skills are only one piece of the equation.
It’s not just about knowing how to construct a software application for a single project.
If a junior developer wants to progress up to senior level developer and beyond, they need to start thinking at an architectural level.
When I say architectural level, I really mean thinking about software at an enterprise level. That is, the level at which a company operates to do business and make revenue.
Most, if not all companies, are structured in a way that helps the company sell a product or service in the most efficient and cost-effective way possible. Or least that’s the goal!
It usually starts at the sales channel level. There’s a salesperson or team of sales people that are responsible for finding new customers and convincing them to purchase their company’s product.
There’s usually a marketing department which figures out how to advertise your product or service to the public at large.
If the product is a physical tangible product that must be manufactured, there will be an operations department responsible for the actual creation and production of the product.
And a shipping department responsible for delivering said product to the customer.
There’s a lot of variations of these but for most companies that sell a physical and tangible product, you’re going to have at least some of these kinds of departments.
The wise software developer will know how all these departments operate. And especially how they communicate and work with each other.
But a developer may balk and say, “Why is that MY job? I’m just the technical guy!”
I used to have that same attitude. That being technical was the ONLY thing that mattered for a software developer.
It was a fast path to nowhere in my career. I didn’t get promoted. I didn’t progress up the company food chain. Yet OTHER developers who had the same level of technical knowledge I did, were getting recognized by their peers and management, and eventually landing in senior level positions.
It took me the longest time to figure out that technical skills are just one piece of the equation.
You need to understand how your organization works. If you’re a software developer for a bank or other financial institution, you better learn how banks do business. The kinds of products and services they offer to their consumers. How they actually make money.
Because in private sector employment, money is the name of the game, ladies and gentlemen.
Your worth to a company is directly proportional to how much revenue you are saving and better yet, CREATING for the company.
By figuring out ways you can help the company either save or make new revenue, you’re helping to advertise yourself to upper management as a key contributor to the company.
And if there’s one thing companies do, it’s reward key contributors.
Understanding the core business domain of your organization is absolutely key to your success as a developer.
There’s a reason why there were TWO co-founders of Apple. Steve Wozniak was the technical genius of the two. He was the one who actually designed and created their first Apple I personal computer.
But he couldn’t have made Apple successful without his co-founder and friend, Steve Jobs. Steve Jobs was the salesman. He knew how to charm others and land business deals. It’s why he commanded such respect and admiration around the world. He was the public face of the company.
Neither Steve could have made Apple the success it is today, without complementing each others skills. Steve Wozniak the technical genius, needed Steve Jobs, the business wunderkind and vice versa.
Much in the same way, a developer needs to recognize technical skills, while very important, is just one of the ingredients for success.
For instance, when a software developer understands how the sales department works, he can see ways to improve efficiencies and look for ways to help the salesperson do their job more effectively through automation and software.
Or the manufacturing department. Or shipping department. Pretty much any division of the company has opportunities to increase efficiencies and save or make new revenue, once you know how they operate as a business.
Companies will ALWAYS value these kinds of developers who know both the business AND technical domain of a company over developers who may just be hired gun consultants or offshore teams.
The last major area a developer needs to continually improve, is their “soft skills”.
It’s the equivalent of a doctor’s “bedside manner”, so to speak.
Good doctors don’t just throw medical facts and figures at you. They relate to you on a personal level, and you, the patient, tend to reciprocate more when the doctor asks you try to try to change your lifestyle to become healthier.
Much in the same way, a developer with a good “bedside manner” will get noticed much quicker than the lone wolf developer, hunched over their keyboard, and avoiding other people whenever possible.
I’ve been on both sides of the job interview table, and can say I’ve been hired over other developers who may have had much more technical skills and knowledge than myself, due to the fact I was told I seemed easier and more personable.
Time and time again, I’ve seen more experienced software developers get passed over, because they just didn’t possess the soft skills the company was looking for … the ability to work well with others and in a team environment, the willingness to share and collaborate, being communicative.
I’m sure I’m generalizing here, but I believe many developers are lacking in the soft skills department. Their introversive nature makes it hard for them to be assertive and work well with others.
When I started out in my developer career, I was much in that category. I was painfully shy and felt nervous being the center of attention. I preferred holing up in my cubicle, working on my code, and avoiding meetings and human contact whenever possible.
But I eventually learned that is a quick path to nowhere.
And it’s probably one of the hardest skills to learn, believe it or not.
Learning a new programming language is comparatively easy compared to improving your soft skills. It’s black and white, no gray area … which is what computers really are. 1s and 0s. Off and on. Yes and no.
There is no rulebook for learning soft skills. It’s a lifelong education.
My product owner recently remarked how appreciative she was that I was so communicative with her. Keeping her in the loop and asking for her business input, as we charted out a software project plan.
When employee review comes around and your peers are asked for feedback about you, these are definitely the kinds of positive things you want to make sure they remember about you, because it directly affects how you get evaluated as an employee.
Leveling up as a developer is no easy feat, period. It takes sustained and concentrated effort in improving areas about yourself that may be lacking.
But there’s just no way to avoid it. And the end goal is being rewarded for your efforts and more opportunities for challenging and interesting work thrown your way.
A fair bargain, in my opinion. Are we ready to level up then?
Good, let’s do this!