rss feed
This really is quite a radical idea in today's business world. The conventional wisdom says that in a public company, there are at least three competing interests that an executive has to contend with: The interests of the employees, the interests of the customers, and the interests of the shareholders. And of course the executives are not without their own interests.But what if this conventional wisdom is all wrong? What if it's not a zero-sum game, and making the shareholders happy doesn't mean that you have to make the employees unhappy? These two CEOs have proposed that if a company focuses on the happiness of its employees, all else will follow: Happy customers, happy shareholders, and presumably happy executives.So is it only a matter of time until CEOs the world over begin to focus exclusively on employee happiness? John Mackey, CEO of Whole Foods, seems to think so:
I don't know if I'm quite so optimistic about that. Hopefully, people will use Coderific to rate those few employers who do adhere to this philosophy. If the word gets out that an employer is one of the few companies actually focusing on employee happiness, imagine the edge that they'll have on hiring good coders.
Also, Joel points out that:
And lastly:
Fixing bugs before writing new code is certainly a good general rule of thumb for exactly these reasons. But it is not always the best choice in any given situation. Allow me to explain why.It's often said that highly skilled programmers are an order of magnitude more productive than poor or even average programmers. That may be true. But even within the confines of an individual programmer, productivity can vary greatly over the course of several days.Whether or not you count yourself among the set of highly skilled programmers, I'm sure you've had days where you've gotten almost nothing done, and not for lack of trying. You stare at your code, looking for the cause of a bug. You get some coffee. You stare some more, adding a few prints. You check Reddit and cycle through your email. You go back to your code. You close your door or put on headphones. You try a few ideas out, but to no avail. Before you know it, it's time to go home, and you've gotten almost nothing done.Other days, you're amazingly productive. Code falls out fully-formed from your head right into your IDE. You almost intuitively know what's causing a bug, and after a few minutes, it's fixed. You're, well, on fire. Not in the overheating lithium-ion laptop battery sense, but more in the NBA Jam sense of the word (http://www.youtube.com/watch?v=X7dFMbubxr4).What accounts for this great variability in productivity within a single programmer? Well, as you can imagine, there are a number of factors. Maybe on your unproductive days you're having trouble concentrating due to constant interruptions, or perhaps you just bricked your iPhone and you're too sad to focus on your code. Still, despite these problems, the number one cause of variable productivity within a single programmer is that programmer's motivation.On your best productivity days, you're interested in the problem you're working on, you've got everything you need to get your job done, and you're invested in the outcome. On your worst days, you're feeling like your efforts will make little impact, you're fed up with management, or you're just tired of the problem at hand. So other than slight variations due to interruptions, bricked iPhones, and so on, an individual contributor's motivation is the single greatest determiner of their personal productivity level.Now, back to the original topic. When Joel asserts that you should always fix bugs first, he's leaving out a very important component from his "What should I do next?" task selection algorithm. He's making the selection of his next task based solely on the relative priorities of the available tasks. In other words, he's claiming that bugs are higher priority for the reasons stated above, and therefore they should be fixed first.But just because something is the highest priority doesn't mean it's the next thing you should work on. This sounds counterintuitive, but a programmer's productivity, their individual contribution to making a product customers want, is like a function with many inputs. One input is the priority of the task they're working on. Another input is that programmer's motivation. By just blindly working on bugs first, Joel is only looking at the priority input while completely ignoring the motivation input.There are two rather interesting properties of a programmer's motivation. One is that you can consciously manipulate your own motivation, with varying degrees of success, and the other property is that your current motivation has a fair amount of momentum. In other words, it tends to change slowly over time, at least in the absence of stimuli that cause it to spike or crash.So, if you're getting frustrated and upset when unsuccessfully tracking down a particularly difficult bug, and therefore wallowing in the depths of unproductivity, sometimes it can help tremendously to take a break to clear your head and get motivated again. You can often accomplish this simply by going and implementing some small, well-defined feature. By putting aside the bugs for a bit, you can finish an easy task and get your productive juices flowing again, thereby giving a much-needed spike to your morale. Then, once the feature is done, you can go back to tackling that annoying bug with renewed motivation and a clearer head.In general, whether or not you're working on bugs, you can often get a huge morale boost simply by stopping work on a boring high-priority feature in order to work on a more interesting lower priority feature. You may even end up getting the high-priority task done sooner, and with at a higher level of quality, than if you had just slogged through it without taking a break to code something more fun.Also, because of the tendency of motivation to stay at its current level for a while (in the absence of shocks like "Oh, by the way, this all needs to be done by tomorrow"), if you take a break to code up something that gives a boost to your motivation, that new level of morale can carry you throughout the day while you bang out less interesting tasks. One might even go so far as to say that the best programmers are experts at personal motivation management. They know how to manipulate their own morale such that they get the most done, even if that means not always working on the absolute highest priority tasks all the time.So, just to clarify, I'm not suggesting that Joel's "fix bugs first" rule is a bad idea. All I'm proposing is that like with any good rule, it pays to know when to break it.
happy employees make businesses succeed
posted by witten on June 29, 2008
There's an interesting article/interview with the founders of Whole Foods and The Container Store: http://www.time.com/time/magazine/article/0,9171,1818183,00.html
The idea is that happy, empowered employees beget happy customers. Happy suppliers help too. All this stakeholder joy eventually redounds to the benefit of shareholders--but the magic fades if shareholders become the focus.
This really is quite a radical idea in today's business world. The conventional wisdom says that in a public company, there are at least three competing interests that an executive has to contend with: The interests of the employees, the interests of the customers, and the interests of the shareholders. And of course the executives are not without their own interests.But what if this conventional wisdom is all wrong? What if it's not a zero-sum game, and making the shareholders happy doesn't mean that you have to make the employees unhappy? These two CEOs have proposed that if a company focuses on the happiness of its employees, all else will follow: Happy customers, happy shareholders, and presumably happy executives.So is it only a matter of time until CEOs the world over begin to focus exclusively on employee happiness? John Mackey, CEO of Whole Foods, seems to think so:
"Simultaneously we hit upon the philosophy that I think will be the dominant philosophy in business in the 21st century," Mackey says. "It's this principle that the purpose of business is not primarily to maximize shareholder value."
I don't know if I'm quite so optimistic about that. Hopefully, people will use Coderific to rate those few employers who do adhere to this philosophy. If the word gets out that an employer is one of the few companies actually focusing on employee happiness, imagine the edge that they'll have on hiring good coders.
rating a company on its interview process
posted by witten on March 05, 2008
Recently I had a discussion with a longtime Coderific user who brought up the question of where ratings of a company's interview process belong on this site. Someone who has merely interviewed at a company doesn't have the inside knowledge and experience that an employee would have, so giving their ratings equal weight with ratings by actual employees seems somewhat unfair.But there definitely is some value to seeing how a company treats its potential employees. Is the handoff from one interviewer to another well-orchestrated? Do the interviewers even know what position they're interviewing the candidate for? Are the interview questions a decent way of judging whether the candidate is a match for the job? Or do the questions more closely resemble "On page 219 of Design Patterns, what is the sixth word of the fourth paragraph?"So where do interview ratings belong on Coderific? After some consideration, I've come to the conclusion that they belong in the discussion forum for each company. Every employer on Coderific has its own forum, which seems like a perfect place for posting about an interview process, even if you were never a full-blown employee. This has the benefit of still allowing those who interview at a company to provide valuable feedback on it, without encroaching on the ratings of people who have actually worked there.I should point out that this is already happening. Just today, someone posted a couple of interview commentaries in the respective discussion forums for the companies in question. The only change I would make to promote this approach is to make it more explicit on Coderific that interview ratings are welcome, as long as they're posted in the forums. Right now, interview ratings are barely mentioned.If you've got any feedback on the topic, make your comments below. I'm interested to find out what people think.Coderific mentioned in Computerworld
posted by witten on February 25, 2008
Coderific was recently mentioned in a Computerworld article (http://www.computerworld.com/action/article.do?command=printArticleBasic&articleId=9057899) in which they interviewed me and several other people about the topic of rock star coders. In case you don't remember my stance on the issue, please refer to my previous blog post on the subject titled "why you don't want to hire rock star programmers" (http://coderific.com/blog/post/564). Computerworld calls it a diatribe. I'm flattered.learning and productivity in a micro-ISV
posted by witten on November 11, 2007
Several months ago, I mentioned that I was starting my own software company (http://coderific.com/blog/post/645). Well, I'm pleased to report that I'm just about ready for a 1.0 product launch, even if the software as it stands is currently rather minimalistic. The product is a WYSIWYG personal wiki called Luminotes, and you can check it out at http://luminotes.com/ if you're interested.Anyway, after several months of slaving away on my own software, I've learned several important lessons that I thought would be worth sharing with you, dear Coderific reader. When I worked in the corporate world, one of the benefits was that I was constantly surrounded by smart software developers, so it was almost guaranteed that I'd pick up new development tips from them. It was in the corporate world that I really internalized test-driven development by working with a team of people who wrote unit tests for a living. And it was working for a corporation that I really became halfway decent at C++, picking up tricks and best practices from other developers.There were just so many things I learned from other developers on a daily basis. So when I finally left the corporate world to sit in my pajamas all day working on my own micro-ISV, one of my fears was that I'd stop learning. Not being constantly steeped in a team of other developers, I worried that I would fall behind, no longer picking up the tips and tricks that kept me sharp.Well, I'm happy to report that my fears were completely unfounded. It is possible that by not being around other software developers all day, I missed out on learning some particular topics, but there's a whole slew of things to learn when you're working by yourself, things that simply aren't learnable when you're in a busy office environment.When you work for a big company, your coding productivity is almost always bounded by things beyond your direct control. Perhaps you get interrupted frequently or have to attend inane meetings all the time. Or maybe you waste time struggling with poorly documented libraries or dealing with office politics, rather actually getting code written.But when you work for yourself, your coding productivity is mostly bounded by your actual ability to pump out good, working, debugged code. There are still the occasional speed bumps, but if you structure your day properly (and you have immense control over doing so), then you can minimize interruptions and productivity drags. And if you're a one-man software shop, I'm guessing you don't spend a lot of time in meetings.When your productivity is no longer constrained by your environment, the only constraint is yourself: How well you can concentrate and keep your butt in that chair, how much discipline you can summon to write unit tests, how well you can deal with tricky coding problems. Suddenly, when working for yourself, you are the limiting factor, rather than the organization you work in.This shift opens up immense opportunities for learning, opportunities that you simply don't have in a corporate environment. Want to learn how to keep yourself coding for 8 hours at a time with only a few breaks to clear your mind? Now's your chance. When you don't have a meeting scheduled every two hours of every day, suddenly you've got to learn how to focus. Want to know how to stay motivated through all the ups and downs of a typical project? When you're on your own, you are the only person cracking the whip, not teammates and certainly not pointy-haired bosses. Ever wonder what time of the day is your most productive for doing specific tasks like debugging, design, algorithmic analysis, and so on? When you run your own micro-ISV, you can structure your day however you like, so it's a perfect opportunity to find out.Simply put, one of the best ways to improve your productivity, or at least start learning what could use improvement, is to quit your job and start working for yourself.don't blindly fix bugs before writing new code
posted by witten on October 07, 2007
One of the questions on The Joel Test (http://www.joelonsoftware.com/articles/fog0000000043.html) is "Do you fix bugs before writing new code?" Joel gives a few very reasonable justifications for why this is a good idea:
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
Also, Joel points out that:
There's another reason, which relates to the fact that it's easier to predict how long it will take to write new code than to fix an existing bug. ...if you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you've fixed all the known bugs, and all that's left is new code, then your schedule will be stunningly more accurate.
And lastly:
...if your competitor introduces a killer new feature that is stealing your customers, you can implement just that feature and ship on the spot, without having to fix a large number of accumulated bugs.
Fixing bugs before writing new code is certainly a good general rule of thumb for exactly these reasons. But it is not always the best choice in any given situation. Allow me to explain why.It's often said that highly skilled programmers are an order of magnitude more productive than poor or even average programmers. That may be true. But even within the confines of an individual programmer, productivity can vary greatly over the course of several days.Whether or not you count yourself among the set of highly skilled programmers, I'm sure you've had days where you've gotten almost nothing done, and not for lack of trying. You stare at your code, looking for the cause of a bug. You get some coffee. You stare some more, adding a few prints. You check Reddit and cycle through your email. You go back to your code. You close your door or put on headphones. You try a few ideas out, but to no avail. Before you know it, it's time to go home, and you've gotten almost nothing done.Other days, you're amazingly productive. Code falls out fully-formed from your head right into your IDE. You almost intuitively know what's causing a bug, and after a few minutes, it's fixed. You're, well, on fire. Not in the overheating lithium-ion laptop battery sense, but more in the NBA Jam sense of the word (http://www.youtube.com/watch?v=X7dFMbubxr4).What accounts for this great variability in productivity within a single programmer? Well, as you can imagine, there are a number of factors. Maybe on your unproductive days you're having trouble concentrating due to constant interruptions, or perhaps you just bricked your iPhone and you're too sad to focus on your code. Still, despite these problems, the number one cause of variable productivity within a single programmer is that programmer's motivation.On your best productivity days, you're interested in the problem you're working on, you've got everything you need to get your job done, and you're invested in the outcome. On your worst days, you're feeling like your efforts will make little impact, you're fed up with management, or you're just tired of the problem at hand. So other than slight variations due to interruptions, bricked iPhones, and so on, an individual contributor's motivation is the single greatest determiner of their personal productivity level.Now, back to the original topic. When Joel asserts that you should always fix bugs first, he's leaving out a very important component from his "What should I do next?" task selection algorithm. He's making the selection of his next task based solely on the relative priorities of the available tasks. In other words, he's claiming that bugs are higher priority for the reasons stated above, and therefore they should be fixed first.But just because something is the highest priority doesn't mean it's the next thing you should work on. This sounds counterintuitive, but a programmer's productivity, their individual contribution to making a product customers want, is like a function with many inputs. One input is the priority of the task they're working on. Another input is that programmer's motivation. By just blindly working on bugs first, Joel is only looking at the priority input while completely ignoring the motivation input.There are two rather interesting properties of a programmer's motivation. One is that you can consciously manipulate your own motivation, with varying degrees of success, and the other property is that your current motivation has a fair amount of momentum. In other words, it tends to change slowly over time, at least in the absence of stimuli that cause it to spike or crash.So, if you're getting frustrated and upset when unsuccessfully tracking down a particularly difficult bug, and therefore wallowing in the depths of unproductivity, sometimes it can help tremendously to take a break to clear your head and get motivated again. You can often accomplish this simply by going and implementing some small, well-defined feature. By putting aside the bugs for a bit, you can finish an easy task and get your productive juices flowing again, thereby giving a much-needed spike to your morale. Then, once the feature is done, you can go back to tackling that annoying bug with renewed motivation and a clearer head.In general, whether or not you're working on bugs, you can often get a huge morale boost simply by stopping work on a boring high-priority feature in order to work on a more interesting lower priority feature. You may even end up getting the high-priority task done sooner, and with at a higher level of quality, than if you had just slogged through it without taking a break to code something more fun.Also, because of the tendency of motivation to stay at its current level for a while (in the absence of shocks like "Oh, by the way, this all needs to be done by tomorrow"), if you take a break to code up something that gives a boost to your motivation, that new level of morale can carry you throughout the day while you bang out less interesting tasks. One might even go so far as to say that the best programmers are experts at personal motivation management. They know how to manipulate their own morale such that they get the most done, even if that means not always working on the absolute highest priority tasks all the time.So, just to clarify, I'm not suggesting that Joel's "fix bugs first" rule is a bad idea. All I'm proposing is that like with any good rule, it pays to know when to break it.