This post is not so much for developers as it is for the managers and bosses from those developers. As you probably know by now, managing software engineers (or programmers) is not an easy task. They just don’t like to play by the rules you always took for granted. Why is that? Why are those pesky programmers too hard to handle? Why is it so hard to sit down, write code and shut up??
The software managers “joel test”
Ok, so I don’t like to call it a “joel-test”, since I’m nowhere near Spolky’s capabilities or experience. However, the purpose of this test is the same as the original joel-test. Every question must be answered either by a yes or a no (no but’s…). At the end of the test, you get 1 point for each yes.
1. Do you work with lenient working hours?
Enforcing a 9 to 5 working day is fine when you are running a factory. But at 5 o’clock, a programmer doesn’t stop thinking about the problems and tasks at hand. It doesn’t start at 9 o’clock in the morning either. Their minds keeps spinning and thinks about better solutions to the problems they face every day at a rate of 24 hours a day.. And just like anybody who are in the writing-business they do get writer’s block. I sometimes cannot do anything useful for a whole day, while the next day I keep on going and going. My finest hours are most definitely not during business hours but more likely in the evening. First of all, I have a very long wake-up-routine in the morning, which makes me unconcentrated during the first few hours of the day. It is a fact.. I don’t do important migrations at 7 o’clock in the morning right after a night sleep, but I do not mind them at 2 o’clock after a whole day of work.. My mind is clearer, there are less errors that I make and problems are resolved quicker.
Now, I do not say that developers should be able to walk in the door whenever they feel like, but merely that if a programmer wants to continue until late that evening, they should be able to do it and be compensated for it, most probably by time off. They don’t work like that because they want to, they work like that because their mind is filling up and they need to type it down before it’s gone. It’s important to stimulate this way of working.
Teleworking is also a great way for programmers to manage their time. When things are getting slow, I tend to walk to the supermarktet and get the groceries I normally pick up after work. This means that I can continue until 6 o’clock when I’m actually getting something done. Of course, not all programmers are able to cope with such freedoms, but most are..
2. Do you give enough time for unit testing?
You have to choose: Do you like to spend an extra 8 hours on unit testing before deployment, or do you like to spend 12 hours fixing bugs afterwards, while your customer is complaining about the bad website and you are in a constant fight about who picks up the bill for the extra hours? Unit testing will reduce the number of bugs massively and it is part of the programming cycle just as compiling/interpreting, deploying and writing specifications are. Off course, deadlines are always lurking around, but they should not affect QA time. Do not fall for thinking it will save you time.. It really doesn’t..
3. Do you give enough time for planning?
After a project is sold, it has to be created, and created quickly. The more time you spend on it, less profit you will get. I can understand that. Everybody probably can. But it is important to think about what you will build before you actually start building. More often than not I had to start on a project without knowing what’s going on just because there weren’t any specifications. Merely some vague idea’s and some screenshots or wire frames. Try to think of it this way: You need to build a house, but you don’t know if it’s going to be a small-sized apartment or a sky-scraper… Now, your task is to start building the concrete foundations.. Are YOU able to do that?
Spending a few extra hours or days, thinking about the project, splitting it up into small tasks of maximum a few hours will achieve at least 2 things: first, you have a good discussion about the project and have figured out a lot of bottlenecks even before typing on letter on your computer, and secondly, you get a pretty accurate hour planning. You know which tasks will become a risk, and which won’t and make planning the project a lot easier…
4. Do you give your programmers the tools they need?
This is NOT about giving everybody a license for Zend Studio or a copy of the latests “ultimate PHP IDE Deluxe enterprise edition limited 2011″. It’s about getting a programmer the tools he or she wants to use. For instance, you are using SVN for your central code repository (you ARE using version control, right?). What about the programmers who like to use GIT and use a GIT2SVN bridge to commit to SVN. In effect, it does the same thing for you, but your programmers can work while they are on the train, on the plane or any other place where they don’t have access to the central repository. And it gets easier for them to share code with others without doing intermediate meaningless check-ins in your repository. Point being: if the end result is the thing you want, don’t deny programmers the tools that make their live easier and more efficient. This example off course, is just one out of many. If programmers use tools (and they cost money), check them out and be willing to pay for them.. programmers know their tools best..
5. Do you let your programmers choose their own IDE?
The great thing about having an IDE that everybody uses is that you probably get a discount on the license costs. I cannot really think of any other reason. First of all, forcing using an IDE will restrict programmers who are used to other IDE’s. Sure, when I work in Zend Studio for a week, I can fly through it, but I’d rather use a PHPStorm or even vim for my daily work. I sincerely do not mind coding large fragments in textmate or notepad. I think most managers will think “Oh, after 2 weeks they are used to it”, which might be true, but then again: most programmers do some programming OUTSIDE your company. Open source projects, things for fun, you name it. And those projects are done in the IDE that I like. I probably are more effective and quicker in my VIM environment than any other user on their zend studio. If your programmers think an IDE is good, they will use it.
Off course, this doesn’t stop you for advising a certain IDE to (junior) programmers. If they lack the experience, this is a great way to learn using an IDE since a lot of other users in your company can answer the questions they have and set everything up and running for them. But for the more experienced (senior) programmers, enforcing is a great way to get rid of programmers..
6. Are you and others respecting “The Zone”?
We used to have a unwritten rule in a company I used to work for: if the headset is on, do not disturb unless there is a fire. “The zone” is when programmers are so mentally focused that they run on 110% efficiency. Getting into the zone is difficult, getting pulled out of one is way too easy. As soon as I’m in the zone and somebody comes up to me to ask if in_array() is haystack/needle or needle/haystack I’m out of the zone instantly. First of all, I don’t know the answer myself so I have to look it up on php.net, just like they would need to do. So a 10 second interruption, means that getting back in the zone will take hours, if it’s possible at all.
At my current job, the zone is something that is not respected. Off course, it’s hard to tell wether or not somebody is in the zone. Neither we nor managers are mindreaders but you can spot them quite easily if you are willing to… Do not send emails and expect them to be answered immediately, or worse: walk straight to the programmer after sending the email and ask if they can read the email.. You kill productivity more than you think. Most programmers (not me though) will restrain themselve for yelling right back in your face, but they hate you at that moment.. they really do..
7. Are your programmers in the loop?
This is somewhat similar to the “planning” question. Do your programmers know what’s going on and are they consulted before closing a deal on a big project? True story: at one time we deployed a final version of a website to production when we found out that website was part of a national campaign. Of course, this “small” detail was not known by the development team. The server we deployed our website to was a single-server shared-hosting environment with a lot of other sites running on it already. If a programmer, or systemadmin for that matter had been brought into the loop earlier, they would have detected those problems right from the start. Not you nor the customer wants to have a inaccesable server at the same time there are commercials airing on national televion. They make you look bad and you blame your programmers, while in fairness, YOU were the problem all along.
Programmers can give a much better estimate on wether or not something is possible or how long it will take. Don’t promise anything to customers when you have no clue on what it will take to actually deliver.
8. Do you minimize meetings?
Meetings are a great way of getting programmers out of the zone. First of all, most meetings are NOT interesting for programmers. Meetings tend to drift away into area’s that most programmers do not care about anyway. Discussions about planning, customer troubles, feature requests or removals which programmers need to defend over and over again… it’s frustrating because programmers loose that battle 9 out of 10 times and by the time the meeting is over, our minds are completely blank again which means the zone cannot be further away.. Don’t plan meetings in the middle of the day (although, some will disagree with this), so it gives your programmers large enough blocks of “time” to actually do some work (and get into the zone).
9. Do you have enough distraction for programmers?
At my first software company I worked for, we used to have a big couch in the middle of the hallway. That was A-MA-ZING.. You could relax, actually take a nap and nobody would bother you. We used to roam through the hallways or staring outside the windows looking like we did do nothing while in fact, quite the opposite was true. Your mind gets fragmented and you need to clear things up, pull your mind back and see the bigger picture again after spending hours on the details. I need those periods a few times a day and most of the time a few minutes is more than enough. Don’t think programmers are doing nothing just because you don’t hear clickety-click all the time.
Buy a Wii, buy a fussball set, beter yet, buy both. Or a dartboard. Or anything that can get the mind of a programmer to relax. Just make sure you place everything away from other programmers so you don’t disturb the ones that are in the zone.
10. Do you give back to the opensource community?
Now, this question does not matter if you are using for a full 100% closed source software. In that case, you bought it, you don’t owe anybody anything. But my guess is that you aren’t 100% closed source. Do you have a serverpark with Linux? Do you use Firefox, or thunderbird? Those software is publically available and you are using it without any charge. I think it is only polite to say “thank you” when you get something for free. Let your programmers work on an opensource project once in a while. Do some bugfixing for Zend framework or PHP, work on a opensource project on github, or even deploy tools you have developped internaly to the outside world as open source and let others help you improving the code.
First off all, that is the biggest thankyou you can give to the opensource community. Secondly, you get a lot of respect as a company. Third: your programmers will see other people code, learn from it, and see how it is to work in large projects, which will benefit them, you and the company they work in. And finally: it will attract better programmers to your company as well.. how can this not be a great deal?
11. Do you let your programmers do research?
Managers tend to forget that an R&D department consists not only of development, but also of research. Suppose you use a framework and don’t let your programmers look around for other (maybe better) frameworks? How about the fact that you can’t implement new techniques just because you don’t have the knowledge or you are not even able to see their potential just because nobody around in your company can spend even 5 minutes to take a look at it? Research is important. Programmers will gain knowledge which they can pass through to the products your company develops.
12. Do you let your programmers speak or go to conferences?
Nohting give a programmer more insight into new techniques and developments than attending conferences. They aren’t that expensive and you don’t have to send your complete development-division to a conference for a whole week. But let your developers attend them and let them pick the ones that are interessting. On those conferences they will hear a lot of other talk about the things they work with every day, discuss with other developers and bring back new idea’s and insights. Let your programmers submit papers and let them speak on those conferences. It will be a great way to attract (good) programmers to your company while giving a lot back at the same time..
The score
- 0-4 points )
Oh dear. Developers will flee away from you as soon as they get the chance. Don’t expect any loyality, because you aren’t giving them either. - 4-7 points )
At least you have given your programmers some slack. But are you getting the kind of developers you need or just the ones that don’t argue with you and take everything for granted? - 7-10 points )
You are on the right track. Fix the missing flaws and programmers all over the country are willing to work for you. You Sir, are on the edge of becoming a good manager.. - 11 points )
You are Chuck Norris. - 12 points )
You are Cal Evans.
Caution: do not take this test too seriously. But on the other hand, please do..
PHPStorm. thumbs up! :D
Extra8 hours on unit testingbefore deploymentbefore writing. thumbs down! :DGreat points! I agree heartily.
Suggestion: Reword the questions for #5 and #8, because if your preferred answer is “yes” for all the questions, then you can score the test more simply. Examples:
#5: Do you allow developers to choose their IDE?
#8: Do you run good meetings?
@Bill Karwin
Good catch. I’ve rephased the questions, but I assume everybody knew already what kind of point I was making hopefully :)
I really would like to know whether Cal Evans actually does get 12 points in this one :D
@Jani Hartikainen
Probably not. It would mean (Cal Evans > Chuck Norris) and that’s a debatable equasion anyway :) Even though I never had the pleasure to work with Cal during my iBuildings time I’ve seen enough talks on conferences from him to think he would agree with (at least) most of my points..
I think the “Are you and others respecting “The Zone”?” is a good question that I need to respect more.
I think you are missing one very important question for smaller development teams though; “Do you allow each programmer to have a sense of ownership or responsibility? (at a level they can handle of course)” I think giving programmers the feeling that they have contributed is one of the most important things. For me, a sense of ownership or responsibility creates passion and pride in my work. This can be created by anything from the type of work each programmer gets to verbally praising good work in meetings.
@Programmer
Good point. I think it depends though on how your development team is setup though. When there is a strong hiearchy with a “senior” developer doing all the hard work and only delegating the “easy and boring” stuff to the juniors, the dedication will suffer greatly. Everybody in the team must indeed have the feeling that their contributions are important part of the project. And I admit: that IS hard for both seniors and managers. Another way besides the ones you recommended could be a scoring system in your Continuous Intergration like Hudson. It can stimulate programmers to try their best (and even more) to create (and fix) code not because the CI will yell at them, but because they will get points for it (which can turn into a game itself).
The zone item made me chuckle. In other industries I have worked in, like the pharmaceutical industry, this concept isn’t even recognized, even though scientists and engineers get in the zone the same same as programmers do.
Joshua,
I am flattered and more than a bit amused. :) However, you are right, I would never put myself above Chuck Norris on any scoring system.
While I would like to think that in most management positions, I’ve nailed 12 out of 12, I know there are many times when I didn’t. The best I can strive for is to get as many points as possible at any given time.
Thanks for the mention and the chuckle. You made me smile. :)
=C=
Reads like a list of complaints from a programmer, not this is what works from a manager. I’m speaking as another programmer, so I have a similar list as well.
@Alan Jackson
To be honest, most of these items on the list (except for maybe one or two) aren’t actually a problem in my current job. In fact, I think the managers in my current job will score high enough. It’s merely a list of issues I’ve collected of the years of working in several organisations, all different in sizes and branches.
As a non-engineer, this article is pretty much the sum of what drives me crazy working for start ups. The company that supports these dozen statements isn’t considering the needs of their other, non-engineering employees. Allow me to address these points from a non-engineering point of view:
1. Do you work with lenient working hours?
Lenient hours are great for developers, but often mean there isn’t reliable help available during hours when customers are reporting bugs or downtime. Late hours for pushes or product changes forces the rest of the company to work hours outside their comfort zone (while they still must respond to normal business hours for customer contact).
2. Do you give enough time for unit testing?
I agree with this one – Unit testing is critical before pushing out code – neglecting to do so often causes a bad release, which stresses marketing, sales, and support departments. The problem is, I don’t see enough startups taking the time for unit testing.
3. Do you give enough time for planning?
Who is involved in planning? Other departments will have requirements for a project that should be considered in the very early stages of a project – not at the last minute where they might be overlooked for lack of time or complexity.
4. Do you give your programmers the tools they need?
Nothing drives me more crazy than seeing engineers with two 32-inch monitors, top of the line computers, and comfy chairs, while other departments are cobbling along with the engineering department leftovers. All departments have equally important work to accomplish, and these tools and perks should be provided to all.
5. Do you let your programmers choose their own IDE?
Choosing tools used by all departments, like a bug tracker, should not just be an engineering decision. Are other departments brought into the discussion and are their needs for a tool considered?
6. Are you and others respecting “The Zone”?
Every employee has their own “Zone”. Mine is sleeping – and I sure hate being woken up at 2am because a late-night deploy broke something and customers are pissed. As an introvert, I need time to recharge and these interruptions throw me off my game. No department should have employees that are considered “off-hands” when other employees are required to be on call and available 24/7.
7. Are your programmers in the loop?
Not only programmers, but how about the rest of the company? Is support able to push new documentation, marketing able to prepare new copy, and sales able to train their teams before a feature is rolled out, or is the feature rolled out first, and everyone else scrambles to catch up?
8. Do you minimize meetings?
Meet smarter, not less often (but both is even better). Does your company send out an agenda before the meeting? Does the meeting start on time? Are people ready to discuss the action items of the meeting? If someone cannot attend, are they responsible for learning what was decided? Preparing properly for meetings is key to making the most of non-meeting time.
9. Do you have enough distraction for programmers?
Make sure this consideration is in place for all employees – Employees should be given a space and an opportunity to unwind and recharge. Additionally, don’t blow the drinks budget on Redbull for the engineers when other departments really just want some fizzy water.
10. Do you give back to the opensource community?
Engineering holds the keys to the kingdom, in that they have the tools they need to do what they’d like – do your other departments have the resources to “give back” – or are they limited by what engineering may not care about (and thus receives low priority)?
11. Do you let your programmers do research?
An important consideration is *where* research is done – are engineers reading other engineers blogs and spending tons of time just talking about theory – or are they getting their hands dirty talking to customers, building wireframes, and running usability testing? One of the biggest mistakes I’ve seen in startups is too much book learnin’.
12. Do you let your programmers speak or go to conferences?
Does the entire team have the opportunity to present or attend conferences? Are those experiences shared with the rest of the team?
As a non-engineer, it’s tough to see this one department handled with kid gloves, when there are many other departments responsible for keeping things running smoothly and keeping customers happy. Make sure your start up culture respects the contributions of all its employees!
Sorry dude, but I gotta ding you for “110%”.
@Rachel
Thanks for your (lengthy) reply. Since this is a blog focused on techincal issues and made by a technical engineer, it’s only logical that I’ve focused on managing of developers/software engineers. Of course, these points can be made also for others inside organisations but somehow my experience is that managers in sales-departments, or managers in the healthcare branch have an easier time and have their “people” more in line with their own expectations. It might be just me seeing it wrong here, and we like to see ourselves special, just like everyone else in the rest of the world but these problems are the problems I’m facing.. If there are other departments which have the same problems, great.. let’s throw them all together and come up with a “global managers joel test” which can be used for all managers outhere..
Some remarks about your comments:
1. I think I’ve not stated clearly that this is NOT about every programmer starting at 5PM and ending something around 2AM. I agree that this won’t work. But this question is about the fact that programmers efficiency isn’t distributed evenly during a working day. You cannot FORCE coming up with solutions to problems. It might be that you do as much work in the 2 last business hours as you did in the first 6. Can you image what hours you save if you let them work even 2 hours longer.
Now, knowing programmers as I do, those 2 extra hours are no problem for them, BUT, you as a company HAVE to compensate this.. Not all companies like to pay overtime (since it might be deemed unnessesary hours), so starting the next day at 11AM instead of 9AM is an interessting reward for most programmers.
5. Interdepartmental (is that even a word) tools should be decided on a higher level with the correct input from all departments. I’m merely stating that we can be much more efficient in program X while returning the same result as with program Y. It’s like not giving a carpenter a screwdriver because you can just as easily hammer down screws in wood.. Sure.. it MIGHT work, but efficient it is not..
>As a non-engineer, it’s tough to see this one department handled with kid
>gloves, when there are many other departments responsible for keeping
>things running smoothly and keeping customers happy. Make sure your
>start up culture respects the contributions of all its employees!
It’s funny, because from that one department, I almost always see us as being the underdog. It is NOT the first time i’ve been called in the middle of the night to fix servers, deploy code and even some bugs that could easily be fixed the next day.
Just because what we produce looks magical, doesn’t make us magicians. It’s time others stop treating us as such and start seeing us as a “normal” department. That would probably save a lot of agony between all departments in the end
Hi Rachel,
I don’t disagree with most of your points but I’d like to address one and then say something about your entire post.
“4. Do you give your programmers the tools they need?
Nothing drives me more crazy than seeing engineers with two 32-inch monitors, top of the line computers, and comfy chairs, while other departments are cobbling along with the engineering department leftovers. All departments have equally important work to accomplish, and these tools and perks should be provided to all.”
I’m all for that if your sales department is running a complete stack, development environment and tool chain. The truth of the matter is the average developer will push a machine 5x-10x more than a sales person or accountant. You give developer screaming machines with 2-3 monitors because that’s what it takes to get the job done; just like you give outside sales people company cars, or delivery personnel trucks instead of bicycles.
Now I’ll say this to you but please understand, I say it with humility even though it won’t sound it.
If your company makes it’s income off of the talents of developers, yes, you treat them special.
I told my COO once “I can teach my developers to sell, can you teach your sales force to program?” because he gave me the same arguments.
No, you can’t treat everyone the same; if we could, everyone would make the same salary as the CEO. If it is the talent and imagination of your development staff that drives your company’s revenue then you need to respect that. If you don’t, you’ll find that soon, you have trouble attracting the talent it takes to get the job done. If you accounting department doesn’t appreciate that then let them go learn to program and they can enjoy the few privileges that come along with the expected “work till the job is done” attitude that most developers have to deal with. Honestly, I rarely hear sales people use the term “death march” with regards to their job but it’s a common term inside development teams that refers to 16-18 hour days and 6 day weeks.
Sincerely,
=C=
@Rachel
I have to agree that the “distractions” should take all employees into consideration.
One thing I’ve found to work well in regard to “lenient working hours” is to offer different 8 hour blocks starting 6am – 10am. This way the early birds can work at their optimal time and night owls can get that needed sleep. I think just having “expected hours” helps the teams accomodate accordingly.
In regard to “Tools”, I think you should provide any employee with the tools to get their job done in the most efficient manner. I personally use a MBP Pro with 24″ apple monitor, this allows me to easily test in multiple browsers/OSs. An account/project manager will most likely be in meetings often and needs a good laptop with no external monitor.
Conclusion:
All developers are different and have different needs (hardware and appreciation). Some developers perform best if they are applauded and told how great they are doing, but if that helps them perform well then why not. Some developers would prefer you to just let them sit in their cave and code. Everyone is different, so you can’t have one management tactic to rule them all.