How to Really Pay Programmers Less
By: Larry Eisenstein
About a week ago, I was perusing my Google news feed on my phone and it was an article that was titled, “How to Pay Programmers Less”. Naturally, I was intrigued, so I clicked the link and began reading. As it turned out, it was a satirical piece that took some of the most popular ‘gimmicks’ companies are using today to pretend like they are modern, hip and cool and saying they could use these cheap ‘perks’ to get developers to accept less pay. Ha….ha…. It’s funny because there is some truth to it. The article was by Yegor Bugayenko (http://www.yegor256.com/2016/12/06/how-to-pay-programmers-less.html).
So, I thought I would write a counter article describing how you can REALLY pay developers less. This won’t work with all developers because some are only concerned with the bottom line, but a surprisingly high number of others will take less. My theory, counter intuitively says it’s some of the more experienced developers that this will work with.
Some developers really love what they do. So much so that they actually spend their own time (and money) cultivating their skills. Training is so inexpensive these days, there is very little reason NOT to pay for this. Have a couple open memberships to sites like PluralSight, Udemy, Lynda.com, and offer time off if there is a local conference. This will only cost a few hundred dollars and will pay off in loyalty and increased productivity.
Also, promote learning by encouraging Meetups, pair programming, lunch & learns, and mentoring. Don’t allow overzealous employees to step new programmers. Base senior developer appraisals on how well they mentor junior programmers. If a developer improves their productivity an amazing 10% every year, this would pale in comparison to a developer that could improve all his colleague’s performance by 2-3% per year. This would be like the magic of compound interest, but for work productivity.
Working from home is becoming a huge deal. It’s getting so big, many developers are skipping companies that do not have at least some sort of regular WFH policy in place. Employees spend countless hours in traffic and are then expected to produce great code, in high stress, frantic, loud environments. This is so insane and some developers have realized they are less stressed and produce more and better code when they are in the comforts of their home office.
This is a no brainer. You get happier, more productive employees and you can save money on office space too. The draw back? It does take a certain level of trust and good management to handle this. You must be willing to punish or terminate any employee that takes advantage of the policy and resist the easy, knee-jerk reaction to take it away from everyone.
This is a big one and it’s not something you can find out about an employer during an interview. Show appreciation to your employees for good work. Go overboard in your praise and look for things to praise people about. Don’t play favorites, just dole praise out to everyone that does a good job. Don’t hold out to the end of the year; praise early, praise specifically, and praise often. This is really where Dale Carnegie got it right in his book, “How to Win Friends and Influence People”.
Listen to and implement suggestions. You are paying smart people a lot of money. Why are you not taking and implementing their advice? Because it will take a little time or money or you found one drawback after seeing 10 benefits? Everyone understands not all ideas can be implemented, but if you continuously hold back (or even worse, take credit for) ideas, good people will leave. Don’t get stuck in this trap.
This is probably one of the cheapest ways to increase employee morale and productivity at the same time. Why are you frustrating your developers by giving them slow, outdated machines and not providing them with software that will make their jobs easier and more enjoyable? There are tools out there that cost less than $100 and can literally save days of manual labor. Why are you paying developers $100k or more and then having them spend 3 days writing some software that has already been created and can be purchased for $49?
Also, buy your developers good machines. There is nothing more frustrating than writing some great code, and then having to wait 2-3 minutes for the test tools to start or for the website to come up. For an extra few hundred dollars, you can have happier more productive developers. Considering this machine will last 3 years, this is a inexpensive investment.
Joel’s Rule #8: Provide your developers with quiet, distraction free environment. Joel describes the issue, so I won’t rehash it (https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/). This problem is getting more serious with these idiotic “open space” office designs and unfortunately managers are eating this crap up. They see they can fit more employees in a smaller space and then they allow some dumb consultant to convince them that this is a collaborative environment. This might work for some types of work, but I’ve met very, very few developers that are OK with this setup. We are though workers and we need quiet time to think.
Ok, now that I have gotten that off my chest, let’s take a slight detour back into reality. I’ve been around long enough there is no magic “employee satisfaction” pill and some of these things are harder to implement than others. I doubt there is a workplace out there that does a great job at all of these things, all the time. But, if you can do 2 or 3 items from this article, you are WAY ahead of the game. The great thing about these suggestions is they are not expensive (some even free) and it will make employees happier and more productive.