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.
Training
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.
WFH
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.
Appreciation
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.
Tools
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.
Environment
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.