Programmer Life
Earn the Big Bucks By Learning New Job Skills Smartly
You’re smart, you love to code. You frequently learn new skills, because it’s fun and useful. But are you learning skills that employers want? Are you sure that, if your job loses stability, you can find a new one? Your favorite language may be cool – lots of skills are also cool – but wouldn’t you like to have job security as well as write cool code?
Or maybe you’re that guy who picked-up FoxPro years ago and hasn’t learned anything new since. Now your company wants to upgrade its technology; do you have alternatives? Or are you going to live in your car while you try to learn Android? All your peers learned new skills; maybe you should do the same now!
What You Can Learn Reading this Post
You can avoid sleeping in your car by intelligently analyzing the coding skills in demand now. After reading this article, you’ll be prepared to analyze the skills market and be smart about which new skills you learn!
So here are some things you can learn from this post:
- Make sure your skills are strong enough to look for a new job, or negotiate a better salary.
- Update your resume; use the right buzzwords to reflect your hard-earned knowledge. HR departments sometimes use bots to scan resumes – they don’t understand that, if you write code in C#, then you already know .NET!
- And what about learning a new, rare skill that pays high – can you pick that skill?
- You can use my free, easy to use, open source app to analyze what skills are in demand
I Doubled My Salary By Learning Skills in Demand
Quick story… Years ago, I was a mainframe programmer, and I could tell that my mainframe skills were rapidly becoming unmarketable. I was pretty underpaid to boot. My employers didn’t really treat me very well, and I didn’t have a lot of options with my current skill set. I took matters onto my own hands; having read “What Color is Your Parachute”, I took classes in VB, Java and C++. Then I begged to write my next work project in any of those new skills. They let me write my project in VB and tada! Now I had the skill and the experience. Shortly after finishing that project, I was able to switch jobs and double my salary, on the strength of my new skill!
Years later, I’m still doing fine, but I still want to list attractive skills on my resume, so I wrote a program to scrape data from the web and actually measure what the employers are looking for. Then I looked at the results and realized that I haven’t made the best choices about picking new technologies to learn. For fun, I thought I’d share what I learned with you. Maybe you can double your salary, or else avoid getting laid-off with no current skills.
Chances are you’re pretty smart… when it comes to maximizing your employer’s profit. But are you being smart on your own behalf? We programmers like to brag we are logic experts, capable of hard work. If you ever told someone you’re good at logic, and work like a slave, why don’t you prove it by logically analyzing your skills and working just a little to choose your new skills, for your own career!
I Wrote a Screen-Scraper/Analysis Program for Careers 2.0 (StackOverflow)
StackOverflow has a nice jobs board that displays only programming jobs. That made it easier to grab their data; it was also easier because they prominently display the major skills as searchable tags. I was able to get some real-world data and accurately dissect it!
My program grabs data from their site and analyze the approximately 700 jobs they have listed there. I posted my code on CodePlex at https://visualizejobskills.codeplex.com/releases/view/122002; you can download it free and run it yourself. The results could change your life.
When I first ran my program, the first thing I checked were the skills most in demand. Holy cow, Java Script is beating everyone these days! jQquery also surprised me with a #4 ranking, I had no idea they were so popular. I sure am glad I spent the time to learn those two! In fact, I know 6 of the top 10 skills pretty strongly; that’s the good news.
Some of my Skills Aren’t too Popular
But now for the bad news: lately I’ve been writing a lot of WPF with MVVM, using Test-Driven Development (TDD), and learning Rx (Rx == “Reactive Extensions”, a cool multi-threading API from Microsoft). If you download my Tag Analysis app from CodePlex, you’ll see exactly what I’m talking about. I searched for the rankings for these skills and was disappointed: WPF is #62, MVVM is #196; Rx is not even listed. At least TDD came in at #45.
You should do the same thing: get out your resume, look at your major skills, see how they rank with employers. Then check the skills you think are cool and might learn: do employers want them too?
Bottom line: I know some cool stuff, but not all of it is demanded right now. True, Stack Overflow is only a small sample (approx 700 jobs), but that does not disqualify it. I tend to think of Stack Overflow as the avaunt guard programmers. So while the data is not conclusive, but nonetheless highly indicative.
What Skills Should You Learn?
So, what should you be learning for new skills? Based on popularity and compatibility with my current skills, plus an idea of how hard they are to learn, I’d guess I personally should start looking at CSS3, node.js or AngularJs. The upside is that they are easy to learn and piggy-back on skills I already have. You should consider the same idea, i.e. build on what you know. Also, when picking a new skill, take a peak at what related skills employers seek.
But, maybe we should try to pick a rare skill that is hard to fill, in hopes of commanding a higher rate!
Identify Rare Skills that Pay Better
According to the law of Supply and Demand, rare skills command a higher rate than common skills. Based on the data available on Stack Overflow, I picked 3 measures of rareness:
- Posting Age. The longer the job has been listed, the more desperate the employer is to fill it. Some skills may, on average, be posted longer than others, implying scarcity.
- Percent remote work allowed per skill. Employers prefer to have you on site. But if they can’t find someone local, they’ll reluctantly relax their standards and hire remote workers. The more they need it, the more likely to allow remote, thus the more pressure to pay top dollar to whomever they can find.
- Average # other skills listed. Imagine the bosses having this conversation: “Hey Bob, this project will die if we don’t get an Erlang coder, we can’t find anyone. I don’t care if they don’t know TCP/IP or Linux, Rajiv can teach them
that. Just find me an Erlang guy! Write-up the ad without any other requirements than Erlang.” As it turned-out, there doesn’t seem to be much variation in the counts, so perhaps this measure is less powerful than I anticipated, it is definitely useful, but less than I wished.
Looking at my screen shot, if I knew Ruby-On-Rails, I’d be feeling pretty good right now. It scores well for both % remote allowed and Avg. job age. The following other skills looked good to me, based on my measures of scarcity:
- GWT (presumably not the Global War on Terror, but Google Web Toolkit) – I already have some experience with the Google Maps API, and GWT scores well for % remote and average age.
- NoSql, Cassandra – I’m already pretty darn good at SQL, that means there should be less new material for me
- Amazon web services (probably not a good match for my skill set)
Are you Listing the Correct Buzzwords in Your Resume?
As I mentioned above, the HR departments (and their bots) don’t understand the skills their internal customers seek. For example, they don’t understand that, if you practice TDD, you also practice automated testing! Here are some tags I didn’t realize were in demand, but which I am adding to my own resume because I already know them:
- Performance analysis (I’ve worked with the .NET profiler)
- jQuery-UI
- Design patterns
- Automated testing, unit-testing, e-commerce, Web applications
- Model-View-Controller (Since I practice MVVM, I also practice MVC)
- OOP
- Active Directory – I thought it was too simple to list!
- http – I can’t believe this is a tag, but I’d hate to miss a job for lacking it
- Scripting – who writes these ads? It’s ranked #205
You should download my app and scrutinize the list of job tags. Make sure you list all common synonyms on your resume so HR won’t reject your resume before the IT folks see it.
What’s Your Plan for Success?
Don’t go randomly buying computer books based on hunches. Use your professional logic skills to strategically pick new skills to bolster your resume; see if you can learn something new that is not only cool, but also in demand. Why don’t you download my project and analyze the data yourself?
My Replacement for the Joel Test
A while ago I saw a job advertisement bragging about having a Joel Score of 10 out of 12. In other words, this company thought they provided a pretty good environment for programmers. That was the first I had heard of the Joel Test.
It didn’t take too long to calculate that my current position only scored 4/12. While the Joel Test is fun, useful and easy, I feel it leaves-out some important features, while emphasizing other features I think are relatively unimportant. So I decided to create my own list! Here it is:
- Can you get face-time with your boss, without scheduling well in advance?
- Do you have written specs? ( I agree with Joel on this one!)
- Are you allowed/encouraged to apply creativity and best practices to your code?
- Are there any kinds of metrics to distinguish good code from bad code?
- Do you have means to compel the users to cooperate?
- Are the users prevented from making decisions they are not qualified to make?
- Do you perform either Test-Driven-Development or else Behavior-Driven Development?
- Do you have code reviews?
- Do you work with up-to-date tools (Joel specifies the very latest, but I am not quite that picky)
- Do you have fewer than five interruptions per day?
Caveat: I’ll bet you can quickly think of that job from hell that scored pretty good on my scale; I’m sticking to my guns because I think these conditions are broadly speaking, applicable in general.
1. Can you get face-time with your boss, without scheduling well in advance?
I’ve spent more time guessing what the boss wants than you would believe. Famous quip: “Why is there always enough time to do it over, but never enough time to understand how to do it right the first time?” I have had many bosses who spend 30+ hours per week in meetings, while I sit frustrated trying do my work, only to have to redo that work when they finally have time for me.
2. Do you have written specs?
Specs provide the benefit of forcing users to think-through their project before wasting time on half-baked ideas. They give you a more realistic idea of the time frame (everything is more complicated than you think at first!) Specs help prevent feature-creep. They make some things unambiguous that users think everyone knows.
If you go even further and can achieve the level of planning provided by Agile techniques, your company will save a bundle and your coders will be able to have a personal life!
Specs reduce work but require discipline and mental effort (i.e you have to act like an adult). Unfortunately, most users lack discipline and frequently don’t care if they reduce your work. I like gigs where the opposite is true!
3. Are you allowed/encouraged to apply creativity and best practices to your code?
I take pride in keeping up with the latest tools and practices; when applied, they benefit my employer by because they make my code easier to maintain, with fewer bugs, and easier for the users. I want to provide good value for my pay! And I don’t write complicated code for the sake of using ‘cool’ technology. Yet time and again I encounter resistance to “cutting edge” practices like Agile, normalized databases or Microsoft’s latest release.
Case in point (my worst gig ever): I worked with one pointy-haired boss who demanded that everyone follow the exact same pattern for their code, regardless of whether it applied to the module at hand. We were micromanaged to the point of being forced us to use his character casing on our file names. (That is a bigger pain than you might think when working with Subversion, because once you have checked-in your code, Subversion won’t recognize case changes in file names. You have top edit the file, copy the contents somewhere else, delete the original file, check-in, recreate the file, save it, check it in again. We literally spent days changing letters to upper or lower case for our file names, the client must have paid 5 figures for that bit of nonsense.) For that particular ‘manager’, showing initiative was far from encouraged, it was was a criticism of his design and practically treason.
As a long-time consultant/contractor, I have learned many ‘best practices’ on my better gigs. Those practices save employers money because the code is better, but many sites simply aren’t interested in any ideas I offer. I generally get the excuse “it will take time to learn, so I don’t want to spend the money up-front”. Whereas, in reality, the improved techniques pay for themselves when used more than once!
Employers take note: if you want skilled programmers, let them do what they love: being creative! And if you want good code delivered at a reasonable cost, you need those skilled programmers.
4. Are there any kinds of metrics to distinguish good code from bad code?
Now, I realize there are plenty of programmers who believe that coding is such an art that there is no way to quantify any aspect of it. Generally they will employ a line of reasoning like “I found one exception to your metric, therefore it is of no use under any circumstance.” To which I reply with a quote from Galileo, “Measure what is measurable, and make measurable what is not.” By the way, Galileo was a genius (unlike the guy who found an exception!) Galileo realized that metrics are useful even when imperfect, and also that there is no metric of any kind that is absolutely reliable. Even those metrics which we use every day. Metrics are a useful predictor, not a guarantee. Generally the skeptics are happy to apply metrics anyone’s work but their own!
What I’ve seen happen is weak coders with great schmoozing skills being valued because the boss doesn’t realize how weak they really are. These guys always have an excuse, and the rest of the team has to pick up their slack. That can be bad for morale.
Even with flaws, metrics are tangible and unbiased. Very rarely are programmers rewarded for tangible aspects of their work, a fact I find hard to swallow. When intangible aspects are rewarded, I frequently see programmers recognized for how good they are at fixing bugs, which is ironic, since good programmers should avoid creating bugs in the first place!
I always try to make my code maintainable and reliable (so I think it would score well on most metrics), but I am not very good at coming up with excuses; I think my employers would benefit from recognizing the efforts I (and you too) make to save them money and hassles!
I am not advocating any particular metric (there are many which are useful) but there should be unbiased some way of finding the things your team needs to improve; metrics can do that.
- There should be some impartial way of measuring which projects have excessive maintenance costs, and of measuring the coding practices that contribute to high maintenance cost.
- There should be some independently verifiable way of measuring which consume too many resources, like user time or database space.
- There should be some means of discovering which projects fail to deliver features that actually save the company money.
5. Do you have means to compel the users to cooperate?
Don’t get me wrong, I love pleasing users. But it sure can be frustrating when there is no penalty for them wasting your time over and over again, and that never changes!
One common scenario is when you can’t get the information you need while writing the code, so you go ahead and write the code anyway. Then, users being users, they decide they don’t like what you gave them because it didn’t incorporate the information you needed. So you throw-away your code and start over!
That happened to me on my latest gig; I had a user (a manager who was a pretty nice guy) who, for whatever reason, didn’t want to work-out the details on how his users would use the app. To nail-down some sort of specs, I wrote-up what I thought the business rules were. Unfortunately, this particular user couldn’t be bothered to read a 3 page document, and I had no recourse. The upshot: I rewrote that app three times! My time didn’t come out of his budget, so he didn’t care.
Another common scenario is when the users are your testers and they will barely lift a finger to do so. Then, after you deliver the product, and after you haven’t worked on the code for a few weeks or months, when it is much harder to re-write your code, they finally use the app and discover bugs you didn’t think to test. Argh! (I love this parody of a certain TV commercial: “I don’t always test, but when I do, I do it in production”)
2 Are the users prevented from making decisions they are not qualified to make?
I’ve had users
- Demand that I denormalize the database!
- Force me to use non-standard UI practices, such as using TextBoxes instead of ComboBoxes
- Prevent me from standardizing common data entry forms
Needless to say, it is especially frustrating if you have studied UI design principles and are giving the users the benefit of your knowledge. Frequently this is a scenario where your new method is superior, but users cling to the old because they refuse to learn new UI styles.
I’m perfectly happy with users providing criteria describing the outcome (“the form should be easy to use”) but I am not happy with users who think they know UI principals better than someone who has read books on them.
7. Do you perform either Test-Driven-Development or else Behavior-Driven Development?
I realize not everyone will agree with me on this one, and that’s probably because you’ve never done TDD. Most likely you think that automated tests are only necessary for nuclear power plants, NASA or other high-risk enterprises. You probably don’t realize that simple tests, which can be re-run at the click of a button, provide a nice way to find bugs created by refactoring your code. And you probably don’t realize that, when you can refactor without fear, you can write more elegant code.
Further, many people believe that test-driven development costs too much because the project takes longer. I like this funny retort: “Sure it takes longer to use TDD – if you change the meaning of ‘done‘.”
What these folks don’t realize is that TDD does take a bit longer – just 15% – 35% according to Microsoft – but your code has 60-90% fewer bugs. The net benefit to the company is huge! Because of how much more expensive it is to fix a bug than to write it correctly the first time, plus the lost time for users due to the app not performing.
8. Do you have code reviews?
I have learned a lot from other programmers, and I think I also have a lot to share. You can do that in a code review. If you believe there is such a thing as good and bad code quality, then you need to try and evaluate your team’s code- again. You can do that with code reviews. The amount of developer time you will save, by improving code quality, will more than compensate for the time you spend in code reviews.
I should say that I only advocate code reviews if you can do it properly, for example, if you work with some prima donna who won’t let anyone else talk, or harps on some minor issues, you can skip the whole deal. But, with some planning and proper ground-rules, you can run your code review civilly and productively.
My bottom line: I like to share, and I like to be recognized for the efforts I make to write quality code; I like to see my peers improve their code quality too!
9. Do you work with up-to-date tools?
Well, let’s face it, job security is not what it once was, so we always need to keep our resumes up-to-date. For example, I wouldn’t want be stuck with a resume only listing VB3 experience! So, if I have a choice between two gigs, roughly equivalent except that one uses old technology, and the other uses the latest tools, I’ll take the new tools, thank you very much!
Employers: take note again. The kind or programmers that are good for your bottom line are the ones who want to use up-to-date tools!
10. Do you have fewer than five interruptions per day?
Famous quote: “When you interrupt a programmer for 5 seconds, you really steal 15 minutes from him. Because it takes that long for him to get back to his mental position in his complex world”.
I’ve resorted to coming to work at least an hour before the crowd, just so I can enjoy the deep, uninterrupted concentration it takes to write complex code. After I’ve chatted with people interrupters for a while, all I can think about is our conversation, not my work. Then it gets really hard, and I start to get frustrated.
How to predict this scenario? Ask yourself: is my boss a professional meeting attender? Or does he/she think the point of their job is to make their team more productive? If they are the latter, then they will intercept the users who have ‘urgent bugs’ and prioritize things (users always think their bug is top priority!)
This also is closely related to Joel’s criteria, “Do you have a quiet place to work?”. I think my version is broader, because loud-talking-neighbors are just another kind of interruption.
Wrap-Up
Well, hopefully I don’t sound too bitter about all the Dilbert-lessons I have learned on the job – I really do love to write code. Some day I will have a great gig that scores 10/10 and is located in my home town, or, just maybe, some pointy-haired-boss will read this and change something to make life better for us humble coders!
Or, better yet, some day I will get another gig that uses Agile development techniques, because that system actually addresses most of my ideas.
Randy's Rants, Ravings and Reflections 