> "And no, I don't consider upgrades every 18 months a waste of money if your business depends on the productivity of engineers, but many companies do. I just don't understand it."
I'm currently using an almost 4 year old Macbook Pro for work. One the one hand I seem to be able to do my job 99% of the time just fine, but it can be slow. On the other hand it is an almost 4 year old computer. I haven't complained about it because it's a Macbook Pro and just about everyone else has Dells with Windows XP and I don't think I'd get another Macbook Pro.
My bosses just significantly upgraded our hardware, mainly because they couldn't afford raises at that time. We knew that's why they were doing it, but it was still nice to get new machines with big monitors.
That's what I think the article is getting at. Hardware is a cheap way to make your employees a little bit happier, and the employees at least know that you're trying.
There's a simple reason why machines don't get upgraded every 18 months; employees do not become more measurably more productive. Management caught on to this literally a decade ago - 5 year cycles are fine.
That's not the point he is trying to make. Computers are the tools of your job. Not providing the best tools is a false economy because the cost is easily offset by the increased productivity of the programmer.
The slow part is the death-knell. It's not just that it takes longer for you to complete your task, it's also that you get distracted while waiting for your slow machine. What's your first response if you hit the compile key and it takes longer than a few seconds? You flip over to browsing the web. That interrupted flow cost you way more than $5000. If you could spend $5000 to make that go away for every engineer in the company, the increased productivity will more than pay for itself over time.
Sometimes, that means more than just paying for the machine on the engineer's desk, it could mean spending money on a cluster of machines just to do distributed compiles. That's also money well spent. Basically, any time you can keep an engineer from interrupting flow by spending money, it's a decision worth careful consideration.
As an extreme example, Google spent millions on SSDs for its source control systems to speed up submits. Money well spent.
flipping over to browse the web the moment you have a couple of minutes free is probably why some companies block access. Employers expect their employees to focus on their job and not flip over at every chance. But what the blocking means for us is something that they ll never understand..
What do you expect engineers to do while code compiles? And flipping to a browser could also mean checking e-mail, filling out expense reports, or scheduling a design meeting. The problem is: even if those things are a productive use of an employee's time, they still interrupt your flow.
I think you got me wrong. I'm one of those engineers who flip over :) What I meant was that the employers do not understand this behavior and all they could do to prevent this is to block access to the Internet which actually harms our work more.
I'm glad this article was written. I've found out some of these things the hard way as an introverted geek. Due to my personality and general disdain of meetings, I will probably never go down the management path, so becoming a tech lead is one of the viable options I've taken at a couple places. Let me say that going out to lunch (and beer Fridays if your company allows that) with your team is one of the best things you can do. It helps the team to jell and fosters open communication which is essential IMO.
As a former tech lead, if you are really mentoring and helping people, bet on allocating 20% of your time per person. Of course this leaves you with a LOT less time to do your own job, but with luck, your team's goal should be to do a better job than you yourself could have done.
Which was always my target. The team did it, and did it better than I could have expected.
This 20% ties in great with many modest management types who are out of their comfort zone above about 3 people. There a quote somewhere in Programmers at Work that the best team is one that will still fit in a VW Bug.
If you have people working off-site, make damn sure they have a separate dev box, set up their way, locked up in a server room, preferably with a way to reset it when needed.
Laptops do not cut it for development for big corporate C++/C# batch type apps.
I managed to snaffle a decent desktop box and sweet-talk IT into burying it in a corner of the server room. And yes, good devs are 'special'!
It was worth a lot to me to have a fast dev machine on the other end of a VPN, the crucial thing being that numskulls and nincompoops couldn't reassign it so some bozo could check his email and surf facebook on it.
Peopleware is out of print? That's a real shame. I wish as many managers had read Peopleware as have read The Mythical Man Month. If your local library has a copy, check it out.
Great article, and as indicated in his blog's comments, very similar to Rands in Repose (http://www.randsinrepose.com) whose writings in this space are similar.
I can't stress enough how useful 1:1s are for my own team (I believe Google follows the Andy Grove model mentioned in "High Output Management", another great book). It's easy for engineers to under-communicate those somewhat-important-but-not-really issues with their tech lead / manager, and getting it out on the table during 1:1s is crucial to keeping said issues from getting out of hand.
The best way to be a team lead is not to be one. Companies impose a title "team lead" when its not necessary at all. If you are skillful, helpful and bring good energy to the team, other people will respect you, trust you and learn from you and thats what a team lead should be.
An imposed Lead is someone who is a point of beaurocracy, someone who can selectively hide/filter information to have a better control, a step in the approval process and many other unwanted things.
"I am Team Lead, I will schedule 1:1 and frequently schedule lunch ...." sounds like trying too hard. It is sure good to have team lunches, having 1:1 with everyone in team etc, but for some other reasons
16 comments
[ 2.8 ms ] story [ 45.4 ms ] threadI'm currently using an almost 4 year old Macbook Pro for work. One the one hand I seem to be able to do my job 99% of the time just fine, but it can be slow. On the other hand it is an almost 4 year old computer. I haven't complained about it because it's a Macbook Pro and just about everyone else has Dells with Windows XP and I don't think I'd get another Macbook Pro.
That's what I think the article is getting at. Hardware is a cheap way to make your employees a little bit happier, and the employees at least know that you're trying.
Sometimes, that means more than just paying for the machine on the engineer's desk, it could mean spending money on a cluster of machines just to do distributed compiles. That's also money well spent. Basically, any time you can keep an engineer from interrupting flow by spending money, it's a decision worth careful consideration.
As an extreme example, Google spent millions on SSDs for its source control systems to speed up submits. Money well spent.
Which was always my target. The team did it, and did it better than I could have expected.
This 20% ties in great with many modest management types who are out of their comfort zone above about 3 people. There a quote somewhere in Programmers at Work that the best team is one that will still fit in a VW Bug.
Laptops do not cut it for development for big corporate C++/C# batch type apps.
I managed to snaffle a decent desktop box and sweet-talk IT into burying it in a corner of the server room. And yes, good devs are 'special'!
It was worth a lot to me to have a fast dev machine on the other end of a VPN, the crucial thing being that numskulls and nincompoops couldn't reassign it so some bozo could check his email and surf facebook on it.
Here are some small excerpts:
http://www.mattblodgett.com/2008/06/select-quotes-from-peopl...
http://www.kk.org/cooltools/archives/001248.php
I can't stress enough how useful 1:1s are for my own team (I believe Google follows the Andy Grove model mentioned in "High Output Management", another great book). It's easy for engineers to under-communicate those somewhat-important-but-not-really issues with their tech lead / manager, and getting it out on the table during 1:1s is crucial to keeping said issues from getting out of hand.
An imposed Lead is someone who is a point of beaurocracy, someone who can selectively hide/filter information to have a better control, a step in the approval process and many other unwanted things.
"I am Team Lead, I will schedule 1:1 and frequently schedule lunch ...." sounds like trying too hard. It is sure good to have team lunches, having 1:1 with everyone in team etc, but for some other reasons