What Programmers Want

Most people who have been assigned the unfortunate task of managing programmers have no idea how to motivate them. They believe that the small perks (such as foosball tables) and bonuses that work in more relaxed settings will compensate for more severe hindrances like distracting work environments, low autonomy, poor tools, unreasonable deadlines, and pointless projects. They’re wrong. However, this is one of the most important things to get right, for two reasons. The first is that programmer output is multiplicative of a number of factors– fit with tools and project, skill and experience, talent, group cohesion, and motivation. Each of these can have a major effect (plus or minus a factor of 2 at least) on impact, and engineer motivation is one that a manager can actually influence. The second is that measuring individual performance among software engineers is very hard. I would say that it’s almost impossible and in practical terms, economically infeasible. Why do I call infeasible rather than merely difficult? That’s because the only people who can reliably measure individual performance in software are so good that it’s almost never worth their time to have them doing that kind of work. If the best engineers have time to spend with their juniors, it’s more worthwhile to have them mentoring the others (which means their interests will align with the employees rather than the company trying to perform such measurement) than measuring them, the latter being a task they will resent having assigned to them.

Seasoned programmers can tell very quickly which ones are smart, capable, and skilled– the all-day, technical interviews characteristic of the most selective companies achieve that– but individual performance on-site is almost impossible to assess. Software is too complex for management to reliably separate bad environmental factors and projects from bad employees, much less willful underperformance from no-fault lack-of-fit. So measurement-based HR policies add noise and piss people off but achieve very little, because the measurements on which they rely are impossible to make with any accuracy. This means that the only effective strategy is to motivate engineers, because attempting to measure and control performance after-the-fact won’t work.

Traditional, intimidation-based management backfires in technology. To see why, consider the difference between 19th-century commodity labor and 21st-century technological work. For commodity labor, there’s a level of output one can expect from a good-faith, hard-working employee of average capability: the standard. Index that to the number 100. There are some who might run at 150-200, but often they are cutting corners or working in unsafe ways, so often the best overall performers might produce 125. (If the standard were so low that people could risklessly achieve 150, the company would raise the standard.) The slackers will go all the way down to zero if they can get away with it. In this world, one slacker cancels out four good employees, and intimidation-based management– which annoys the high performers and reduces their effectiveness, but brings the slackers in line, having a performance-middling effect across the board– can often work. Intimidation can pay off, because more is gained by intimidating the slacker into mediocrity brings more benefit than is lost. Technology is different. The best software engineers are not at 125 or even 200, but at 500, 1000, and in some cases, 5000+. Also, their response to a negative environment isn’t mere performance middling. They leave. Engineers don’t object to the firing of genuine problem employees (we end up having to clean up their messes) but typical HR junk science (stack ranking, enforced firing percentages, transfer blocks against no-fault lack-of-fit employees) disgusts us. It’s mean-spirited and it’s not how we like to do things. Intimidation doesn’t work, because we’ll quit. Intrinsic motivation is the only option.

Bonuses rarely motivate engineers either, because the bonuses given to entice engineers to put up with undesirable circumstances are often, quite frankly, two or three orders of magnitude too low. We value interesting work more than a few thousand dollars, and there are economic reasons for us doing so. First, we understand that bad projects entail a wide variety of risks. Even when our work isn’t intellectually stimulating, it’s still often difficult, and unrewarding but difficult work can lead to burnout. Undesirable projects often have a 20%-per-year burnout rate between firings, health-based attrition, project failure leading to loss of status, and just plain losing all motivation to continue. A $5,000 bonus doesn’t come close to compensating for a 20% chance of losing one’s job in a year. Additionally, there are the career-related issues associated with taking low-quality work. Engineers who don’t keep current lose ground, and this becomes even more of a problem with age. Software engineers are acutely aware of the need to establish themselves as demonstrably excellent before the age of 40, at which point mediocre engineers (and a great engineer becomes mediocre after too much mediocre experience) start to see prospects fade.

The truth is that typical HR mechanisms don’t work at all in motivating software engineers. Small bonuses won’t convince them to work differently, and firing middling performers (as opposed to the few who are actively toxic) to instill fear will drive out the best, who will flee the cultural fallout of the firings. There is no way around it: the only thing that will bring peak performance out of programmers is to actually make them happy to go to work. So what do software engineers need?

The approach I’m going to take is based on timeframes. Consider, for an aside, peoples’ needs for rest and time off. People need breaks at  work– say, 10 minutes every two hours. They also need 2 to 4 hours of leisure time each day. They need 2 to 3 days per week off entirely. They need (but, sadly, don’t often get) 4 to 6 weeks of vacation per year. And ideally, they’d have sabbaticals– a year off every 7 or so to focus on something different from the assigned work. There’s a fractal, self-similar nature to peoples’ need for rest and refreshment, and these needs for breaks tap into Maslovian needs: biological ones for the short-timeframe breaks and higher, holistic needs pertaining to the longer timeframes. I’m going to assert that something similar exists with regard to motivation, and examine six timeframes: minutes, hours, days, weeks, months, and years.

1. O(minutes): Flow

This may be the most important. Flow is a state of consciousness characterized by intense focus on a challenging problem. It’s a large part of what makes, for example, games enjoyable. It impels us toward productive activities, such as writing, cooking, exercise, and programming. It’s something we need for deep-seated psychological reasons, and when people don’t get it, they tend to become bored, bitter, and neurotic. For a word of warning, while flow can be productive, it can also be destructive if directed toward the wrong purposes. Gambling and video game addictions are probably reinforced, in part, by the anxiolytic properties of the flow state. In general, however, flow is a good thing, and the only thing that keeps people able to stand the office existence is the ability to get into flow and work.

Programming is all about flow. That’s a major part of why we do it. Software engineers get their best work done in a state of flow, but unfortunately, flow isn’t common for most. I would say that the median software engineer spends 15 to 120 minutes per week in a state of flow, and some never get into it. The rest of the time is lost to meetings, interruptions, breakages caused by inappropriate tools or bad legacy code, and context switches. Even short interruptions can easily cause a 30-minute loss. I’ve seen managers harass engineers with frequent status pings (2 to 4 per day) resulting in a collapse of productivity (which leads to more aggressive management, creating a death spiral). The typical office environment, in truth, is quite hostile to flow.

To achieve flow, engineers have to trust their environment. They have to believe that (barring an issue of very high priority and emergency) they won’t be interrupted by managers or co-workers. They need to have faith that their tools won’t break and that their environment hasn’t changed in a catastrophic way due to a mistake or an ill-advised change by programmers responsible for another component. If they’re “on alert”, they won’t get into flow and won’t be very productive. Since most office cultures grew up in the early 20th century when the going philosophy was that workers had to be intimidated or they would slack off, the result is not much flow and low productivity.

What tasks encourage or break flow is a complex question. Debugging can break flow, or it can be flowful. For me, I enjoy it (and can maintain flow) when the debugging is teaching me something new about a system I care about (especially if it’s my own). It’s rare, though, that an engineer can achieve flow while maintaining badly written code, which is a major reason why they tend to prefer new development over maintenance. Trying to understand bad software (and most in-house corporate software is terrible) creates a lot of “pinging” for the unfortunate person who has to absorb several disparate contexts in order to make sense of what’s going on. Reading good code is like reading a well-written academic paper: an opportunity to see how a problem was solved, with some obvious effort put into presentation and aesthetics of the solution. It’s actually quite enjoyable. On the other hand, reading bad code is like reading 100 paragraphs, all clipped from different sources. There’s no coherency or aesthetics, and the flow-inducing “click” (or “aha” experience) when a person makes a connection between two concepts almost never occurs. The problem with reading code is that, although good code is educational, there’s very little learned in reading bad code aside from the parochial idiosyncracies of a badly-designed system, and there’s a hell of a lot of bad code out there.

Perhaps surprisingly, whether a programmer can achieve “flow”, which will influence her minute-by-minute happiness, has almost nothing to do with the macroscopic interestingness of the project or company’s mission. Programmers, left alone, can achieve flow and be happy writing the sorts of enterprise business apps that they’re “supposed” to hate. And if their environment is so broken that flow is impossible, the most interesting, challenging, or “sexy” work won’t change that. Once, I saw someone leave an otherwise ideal machine learning quant job because of “boredom”, and I’m pretty sure his boredom had nothing to do with the quality of the work (which was enviable) but with the extremely noisy environment of a trading desk.

This also explains why “snobby” elite programmers tend to hate IDEs, the Windows operating system, and anything that forces them to use the mouse when key-combinations would suffice. Using the mouse and fiddling with windows can break flow. Keyboarding doesn’t. Of course, there are times when the mouse and GUI are superior. Web surfing is one example, and writing blog posts (WordPress instead of emacs) is another. Programming, on the other hand, is done using the keyboard, not drag-and-drop menus. The latter are a major distraction.

2. O(hours): Feedback

Flow is the essence here, but what keeps the “flow” going? The environmental needs are discussed above, but some sorts of work are more conducive to flow than others. People need a quick feedback cycle. One of the reasons that “data science” and machine learning projects are so highly desired is that there’s a lot of feedback, in comparison to enterprise projects which are developed in one world over months (with no real-world feedback) and released in another. It’s objective, and it comes on a daily basis. You can run your algorithms against real data and watch your search strategies unfold in front of you while your residual sum of squares (error) decreases.

Feedback needs to be objective or positive in order to keep people enthusiastic about their work. Positive feedback is always pleasant, so long as it’s meaningful. Objective, negative feedback can be useful as well. For example, debugging can be fun, because it points out one’s own mistakes and enables a person to improve the program. The same holds for problems that turn out to be more difficult than originally expected: it’s painful, but something is learned. What never works well is subjective, negative feedback (such as bad performance reviews, or aggressive micromanagement that shows a lack of trust). That pisses people off.

I think it should go without saying that this style of “feedback” can’t be explicitly provided on an hourly basis, because it’s unreasonable to expect managers to do that much work (or an employee do put up with such a high frequency of managerial interruption). So, the feedback has to come organically from the work itself. This means there need to be genuine challenges and achievements involved. So most of this feedback is “passive”, by which I mean there is nothing the company or manager does to inject the feedback into the process. The engineer’s experience completing the work provides the feedback itself.

One source of frustration and negative feedback that I consider subjective (and therefore place in that “negative, subjective feedback that pisses people off” category) is the jarring experience of working with badly-designed software. Good software is easy to use and makes the user feel more intelligent. Bad software is hard to use, often impossible to read at the source level, and makes the user or reader feel absolutely stupid. When you have this experience, it’s hard to tell if you are rejecting the ugly code (because it is distasteful) or if it is rejecting you (because you’re not smart enough to understand it). Well, I would say that it doesn’t matter. If the code “rejects” competent developers, it’s shitty code. Fix it.

The “feedback rate” is at the heart of many language debates. High-productivity languages like Python, Scala, and Clojure, allow programmers to implement significant functionality in mere hours. On my best projects, I’ve written 500 lines of good code in a day (by the corporate standard, that’s about two months of an engineer’s time). That provides a lot of feedback very quickly and establishes a virtuous cycle: feedback leads to engagement, which leads to flow, which leads to productivity, which leads to more feedback. With lower-level languages like C and Java– which are sometimes the absolute right tools to use for one’s problem, especially when tight control of performance is needed– macroscopic progress is usually a lot slower. This isn’t an issue, if the performance metric the programmer cares about lives at a lower level (e.g. speed of execution, limited memory use) and the tools available to her are giving good indications of her success. Then there is enough feedback. There’s nothing innate that makes Clojure more “flow-ful” than C; it’s just more rewarding to use Clojure if one is focused on macroscopic development, while C is more rewarding (in fact, probably the only language that’s appropriate) when one is focused on a certain class of performance concerns that require attention to low-level details. The problem is that when people use inappropriate tools (e.g. C++ for complex, but not latency-sensitive, web applications) they are unable to get useful feedback, in a timely manner, about the performance of their solutions.

Feedback is at the heart of the “gameification” obsession that has grown up of late, but in my opinion, it should be absolutely unnecessary. “Gameifcation” feels, to me, like an after-the-fact patch if not an apology, when fundamental changes are necessary. The problem, in the workplace, is that these “game” mechanisms often evolve into high-stakes performance measurements. Then there is too much anxiety for the “gameified” workplace to be fun.

In Java culture, the feedback issue is a severe problem, because development is often slow and the tools and culture tend to sterilize the development process by eliminating that “cosmic horror” (which elite programmers prefer) known as the command line. While IDEs do a great job of reducing flow-breakage that occurs for those unfortunate enough to be maintaining others’ code, they also create a world in which the engineers are alienated from computation and problem-solving. They don’t compile, build, or run code; they tweak pieces of giant systems that run far away in production and are supported by whoever drew the short straw and became “the 3:00 am guy”.

IDEs have some major benefits but some severe drawbacks. They’re good to the extent that they allow people to read code without breaking flow; they’re bad to the extent that they tend to require use patterns that break flow. The best solution, in my opinion, to the IDE problem is to have a read-only IDE served on the web. Engineers write code using a real editor, work at the command line so they are actually using a computer instead of an app, and do almost all of their work in a keyboard-driven environment. However, when they need to navigate others’ code in volume, the surfing (and possibly debugging) capabilities offered by IDEs should be available to them.

3. O(days): Progress

Flow and feedback are nice, but in the long term, programmers need to feel like they’re accomplishing something, or they’ll get bored. The feedback should show continual improvement and mastery. The day scale is the level at which programmers want to see genuine improvements. The same task shouldn’t be repeated more than a couple times: if it’s dull, automate it away. If the work environment is so constrained and slow that a programmer can’t log, on average, one meaningful accomplishment (feature added, bug fixed) per day, something is seriously wrong.  (Of course, most corporate programmers would be thrilled to fix one bug per week.)

The day-by-day level and the need for a sense of progress is where managers and engineers start to understand each other. They both want to see progress on a daily basis. So there’s a meeting point there. Unfortunately, managers have a tendency to pursue this in a counterproductive way, often inadvertently creating a Heisenberg problem (observation corrupts the observed) in their insistence on visibility into progress. I think that the increasing prevalence of Jira, for example, is dangerous, because increasing managerial oversight at a fine-grained level creates anxiety and makes flow impossible. I also think that most “agile” practices do more harm than good, and that much of the “scrum” movement is flat-out stupid. I don’t think it’s good for managers to expect detailed progress reports (a daily standup focused on blockers is probably ok) on a daily basis– that’s too much overhead and flow breakage– but this is the cycle at which engineers tend to audit themselves, and they won’t be happy in an environment where they end the day not feeling that they worked a day.

4. O(weeks): Support.

Progress is good, but as programmers, we tend toward a trait that the rest of the world sees only in the moody and blue: “depressive realism”. It’s as strong a tendency in the mentally healthy among us as the larger-than-baseline percentage who have mental health issues. For us, it’s not depressive. Managers are told every day how awesome they are by their subordinates, regardless of the fact that more than half of the managers in the world are useless. We, on the other hand, have subordinates (computers) that frequently tell us that we fucked up by giving them nonsensical instructions. “Fix this shit because I can’t compile it.” We tend to have an uncanny (by business standards) sense of our own limitations. We also know (on the topic of progress) that we’ll have good days and bad days. We’ll have weeks where we don’t accomplish anything measurable because (a) we were “blocked”, needing someone else to complete work before we could continue, (b) we had to deal with horrendous legacy code or maintenance work– massive productivity destroyers– or (c) the problem we’re trying to solve is extremely hard, or even impossible, but it took us a long time to fairly evaluate the problem and reach that conclusion.

Programmers want an environment that removes work-stopping issues, or “blockers”, and that gives them the benefit of the doubt. Engineers want the counterproductive among them to be mentored or terminated– the really bad ones just have to be let go– but they won’t show any loyalty to a manager if they perceive that he’d give them grief over a slow month. This is why so-called “performance improvement plans” (PIPs)– a bad idea in any case– are disastrous failures with engineers. Even the language is offensive, because it suggests with certainty that an observed productivity problem (and most corporate engineers have productivity problems because most corporate software environments are utterly broken and hostile to productivity) is a performance problem, and not something else. An engineer will not give one mote of loyalty to a manager that doesn’t give her the benefit of the doubt.

I choose “weeks” as the timeframe order of magnitude for this need because that’s the approximate frequency with which an engineer can be expected to encounter blockers, and removal of these is one thing that engineers often need from their managers: resolution of work-stopping issues that may require additional resources or (in rare cases) managerial intervention. However, that frequency can vary dramatically.

5. O(months): Career Development.

This is one that gets a bit sensitive, and it becomes crucial on the order of months, which is much sooner than most employers would like to see their subordinates insisting on career advancement, but, as programmers, we know we’re worth an order of magnitude more than we’re paid, and we expect to be compensated by our employers investing in our long-term career interests. This is probably the most important of the 6 items listed here.

Programmers face a job market that’s unusually meritocratic when changing jobs. Within companies, the promotion process is just as political and bizarre as it is for any other profession, but when looking for a new job, programmers are evaluated not on their past job titles and corporate associations, but on what they actually know. This is quite a good thing overall, because it means we can get promotions and raises (often having to change corporate allegiance in order to do so, but that’s a minor cost) just by learning things, but it also makes for an environment that doesn’t allow for intellectual stagnation. Yet most of the work that software engineers have to do is not very educational and, if done for too long, that sort of work leads in the wrong direction.

When programmers say about their jobs, “I’m not learning”, what they often mean is, “The work I am getting hurts my career.” Most employees in most jobs are trained to start asking for career advancement at 18 months, and to speak softly over the first 36. Most people can afford one to three years of dues paying. Programmers can’t. Programmers, if they see a project that can help their career and that is useful to the firm, expect the right to work on it right away. That rubs a lot of managers the wrong way, but it shouldn’t, because it’s a natural reaction to a career environment that requires actual skill and knowledge. In most companies, there really isn’t a required competence for leadership positions, so seniority is the deciding factor. Engineering couldn’t be more different, and the lifetime cost of two years’ dues-paying can be several hundred thousand dollars.

In software, good projects tend to beget good projects, and bad projects beget more crap work. People are quickly typecast to a level of competence based on what they’ve done, and they have a hard time upgrading, even if their level of ability is above what they’ve been assigned. People who do well on grunt work get more of it, people who do poorly get flushed out, and those who manage their performance precisely to the median can get ahead, but only if managers don’t figure out what they’re doing. As engineers, we understand the career dynamic very well, and quickly become resentful of management that isn’t taking this to heart. We’ll do an unpleasant project now and then– we understand that grungy jobs need to be done sometimes– but we expect to be compensated (promotion, visible recognition, better projects) for doing it. Most managers think they can get an undesirable project done just by threatening to fire someone if the work isn’t done, and that results in adverse selection. Good engineers leave, while bad engineers stay, suffer, and do it– but poorly.

Career-wise, the audit frequency for the best engineers is about 2 months. In most careers, people progress by putting in time, being seen, and gradually winning others’ trust, and actual skill growth is tertiary. That’s not true for us, or at least, not in the same way. We can’t afford to spend years paying dues while not learning anything. That will put us one or two full technology stacks behind the curve with respect to the outside world.

There’s a tension employees face between internal (within a company) and external (within their industry) career optimization. Paying dues is an internal optimization– it makes the people near you like you more, and therefore more likely to offer favors in the future– but confers almost no external-oriented benefit. It was worthwhile in the era of the paternalistic corporation, lifelong employment, and a huge stigma attached to changing jobs (much less getting fired) more than two or three times in one career. It makes much less sense now, so most people focus on the external game. Engineers who focus on the external objective are said to be “optimizing for learning” (or, sometimes, “stealing an education” from the boss). There are several superiorities to a focus on the external career game. First, external career advancement is not zero-sum–while jockeying internally for scarce leadership positions is– and what we do is innately cooperative. It works better with the type of people we are. Second, our average job tenure is about 2 to 3 years. Third, people who suffer and pay dues are usually passed over anyway in favor of more skilled candidates from outside. Our industry has figured out that it needs skilled people more than it needs reliable dues-payers (and it’s probably right). So this explains, in my view, why software engineers are so aggressive and insistent when it comes to the tendency to optimize for learning.

There is a solution for this, and although it seems radical, I’m convinced that it’s the only thing that actually works: open allocation. If programmers are allowed to choose the projects best suited to their skills and aspirations, the deep conflict of interest that otherwise exists among their work, their careers, and their educational aspirations will disappear.

6. O(years): Macroscopic goals. On the timescale of years, macroscopic goals become important. Money and networking opportunities are major concerns here. So are artistic and business visions. Some engineers want to create the world’s best video game, solve hard mathematical problems, or improve the technological ecosystem. Others want to retire early or build a network that will set them up for life.

Many startups focus on “change the world” macroscopic pitches about how their product will connect people, “disrupt” a hated industry or democratize a utility, or achieve some world-changing ambition. This makes great marketing copy for recruiters, but it doesn’t motivate people on the day-to-day basis. On the year-by-year basis, none of that marketing matters, because people will actually know the character of the organization after that much time. That said, the actual macroscopic character, and the meaning of the work, of a business matters a great deal. Over years and decades, it determines whether people will stick around once they develop the credibility, connections, and resources that would give them the ability to move on to something else more lucrative, more interesting, or of higher status.

How to win

It’s conventional wisdom in software that hiring the best engineers is an arbitrage, because they’re 10 times as effective but only twice as costly. This is only true if they’re motivated, and also if they’re put to work that unlocks their talent. If you assign a great engineer to mediocre work, you’re going to lose money. Software companies put an enormous amount of effort into “collecting” talent, but do a shoddy job of using or keeping it. Often, this is justified in the context of a “tough culture”; turnover is reflective of failing employees, not a bad culture. In the long term, this is ruinous. The payoff in retaining top talent is often exponential as a function of the time and effort put into attracting, retaining, and improving it.

Now that I’ve discussed what engineers need from their work environments in order to remain motivated, the next question is what a company should do. There isn’t a one-size-fits-all managerial solution to this. In most cases, the general best move is to reduce managerial control and to empower engineers: to set up an open-allocation work environment in which technical choices and project direction are set by engineers, and to direct from leadership rather than mere authority. This may seem “radical” in contrast to the typical corporate environment, but it’s the only thing that works.

93 thoughts on “What Programmers Want

  1. > hiring the best engineers is an arbitrage, because they’re 10 times as effective but only twice as costly.
    Source please.

    • In my experience, that’s correct. In other words: a bad engineer can have almost zero productivity. In some cases, if an engineer causes more harm (distraction, bugs, etc) than good, productivity can even be negative.

      Productivity also depends on how hard the task is. Productivity is best if the difficulty of the challenge matches the engineer’s talent. That’s where good management helps: if the manager himself understands the problem well enough and listens to his engineers, he can split the workload into digestable parts that match each engineer’s capabilities, thus maximizing productivity for a given team.

      • Bad engineers can have worse than zero productivity. Bad engineers force other engineers to lose productivity cleaning up after the bad engineers. In my book, that’s negative productivity.

    • http://www.quora.com/Is-the-concept-of-a-10x-engineer-valid

      Citations: “Mythical Man Month” (Brooks), “Peopleware” (Demarco/Lister), and Rapid Development (McConnell)

      Like many things in software, the 10:1 is likely overstated most of the time, but the fact that these books (spanning more than 30 years) all mention this ratio is interesting. It could be that Brooks stated it first and since he’s often deified in software others are eager to come to the same conclusion, but that’s purely speculative.

  2. Though the post is interesting, I don’t agree that money is not a motivating factor. There are corner cases which are always cited when talking about money: when one has so much money that he doesn’t see difference between $N he already has and $(N+m) he will have; the other is when something else motivates/demotivates more, for example when a programmer is too damn tired that no matter what he doesn’t want to do this job.

    In all other cases money is a good motivating factor. Sometimes a good timed check can save a company from sinking.

    • I believe that money is not a motivating factor but can be a de-motivating factor. Example: I might be happy with my current salary….until I accidently find out that the knucklehead in the next cube, whom I’ve bailed out numerous times, is making X more than I am.

    • RE the “A few thousand dollars doesn’t make a difference” is surely a false statement when the programmers are paid less than “a few thousand dollars” to start off with ;p

    • I often see large pay as a sign of dysfunction. If someone is trying to throw a big check my way it is often because they can’t do anything else to keep their employees happy.

      That being said, there are certainly times when I have felt “locked in” by a high salary. Usually those situations end up with really bad outcomes.

    • Not sure that I agree with that at all.. Right now, I’m at the ceiling of my area in terms of what software development pays (for the technology stack I am most familiar with)… there’s near 0-percent unemployment and the field is in need of more people… That has kept salaries fairly nice. Last year I took a management role at a small company… it was a bit more money, and just wasn’t an environment that I wanted to continue in…

      I took a significant pay cut to go back to development knowing where my target salary would be, and focusing on an environment that was what I wanted at that salary level.

      I could move to Silicon Valley or the Seattle area and see another $30-50K a year, but then it costs more than an extra $30K to live there, really wouldn’t put me ahead.

      You can hit a point where the money isn’t the leading factor… I wouldn’t even consider leaving where I am for less than an extra $10-20K locally, and even then would likely stay where I am.

    • Absolutely. Despite all else, even at higher level salaries for senior engineers (which are not nearly as high as they have been having stagnated at about the same for top talent in the bay area for the last two years) money is still the main motivating factor. Other things can trump it, but usually only in combination. For example, I might take a lower paying job because the company is not VC or angel backed, is profitable, has smart projects and most importantly people, and has great health/dental insurance, etc.. Then I might consider taking such a position over a contracting job paying almost 1.5-2x as much.

  3. Pingback: Missing coding « cartesian product

  4. Valentin,

    Outside of wall street I’ve never seen truly performance based bonuses in amounts that would make someone change their job performance at all. Personally I really hate bonuses, though decent sized increases to my base salary can sometimes motivate on the margin.

    Before I took my current job I said this to my boss. Now that I’m trying to get him fired for corruption is seems apt:

    [Deleted by michaelochurch. I have no idea if this is verbatim email but if it is, you are really hurting your career by posting this here. I’ll restore it by request. -MOC]

  5. I definitely agree with most of your conclusions and the general theme of the article, however, there are a couple of assumptions that IMO, are not accurate:

    “Seasoned programmers can tell very quickly which ones are smart, capable, and skilled– the all-day, technical interviews characteristic of the most selective companies achieve that– but individual performance on-site is almost impossible to assess.”

    Actually, these long interviews of seemingly technical nature miss a lot of great programmers by asking stupid questions meant to “see how one thinks” that are irrelevant and treating the candidates like children rather than as peers.

    “Engineers write code using a real editor, work at the command line so they are actually using a computer instead of an app, and do almost all of their work in a keyboard-driven environment. However, when they need to navigate others’ code in volume, the surfing (and possibly debugging) capabilities offered by IDEs should be available to them.”

    What is a real editor? Why should one be forced to use an inferior tool when a good IDE is superior for anything but small projects? Preference for development style does not reflect the quality of one’s skills. Great engineers can use IDEs and poor engineers can use “real editor”s … whatever that means.

    • I am open to either a good editor, or an IDE.. sometimes I feel that the IDE works against me. I’ve been doing a lot of Node.js work lately, and the rest of the development is .Net based… so it’s easier to keep the Node stuff under a VS project that doesn’t actually do anything. I find it works okay, but often would rather just have the directory open in Sublime. I’m not a vi/emacs snob at all, generally preferring a gui editor, but just the same not having to use the mouse is helpful.

      Also, I think the best way to learn any language is to use a plain text editor, and a command line compiler/runtime at first… this gives you a much better leverage in understanding when you do use an IDE environment.

      • I agree. I’m all for choice. To each his/her own. However, to suggest that good programmers only use CLI and that mediocre to bad programmers are the ones using IDEs is false. Period. One counterexample is all I need to debunk that and my experience dictates otherwise with multiple counterexamples.

        Suggesting that using only the CLI is the best approach is indeed the same as saying a hammer is the best tool for all repairs. I’m a bit disappointed to find such non-factual opinions presented as fact.

  6. “Career Development” is a codeword for buying the latest in software and/or tools. This is exactly why and how crappy products such as the SAP or Oracle ERP products have achieved market dominance.

    Programmers feel they need to get on the latest bandwagon so that they are able to jump ships at a momemt’s notice. They want their employers to train them for their next job opportunity outside the company.

    I will give you one example.

    In 2003, I asked someone I knew what kind of technologies his employer was using. It turned out it was an IBM mainframe and the applications were written in COBOL and used VSAM files. There was not even the IMS databse in sight, let alone a Relational DBMS.

    How many of you would want to work in that environment?

    By the way, that company has been in the consumer loan business for ages. Their business model hasn’t changed and so programs written in the 1970s were perfectly fine for them.

    Would you work there maintaining their applications? Or, would you advise them to move to Unix, C, Oracle/SQLServer DBMS, etc.?


    • Personally, if I could get hired in that environment at my current salary to learn the systems I would… I’ve been doing far more work in modern environments. There are things to be learned from those legacy systems that could be very beneficial… Though some code would be painful to wade through I think it would be a good experience.

      I wouldn’t expect to stay there for more than a year though… then again, I’ve only had a handful of jobs I’ve stayed at for over a year.

    • Yes, sometimes it is. Thus we have all sorts of applications being built on top of inappropriate technologies. Using mongo when it and more importantly the company behind it has proven itself untrustworthy (at least for a couple more years) through early blunders. Using node.js for your entire website. Using Rails … for anything. (all IMO, the specific technologies don’t matter) etc.

      At other times it’s not. Picking up Python for example is not an example of using the “cool” new things to do “cool” new things (and then ending up with a clusterfuck on your hands and leaving it to others to fix). Python is tried and true and for many, myself included (having done mostly PHP and JS etc. the last 7++ years), is an avenue of career development because it’s not a domain specific language. It also would be useful in just about any environment (I don’t currently program in C/C++ system level/kernel level apps.

      tl;dr: I agree. Most times career development is exactly what you say Vivi, but sometimes it’s the opposite.

      • you do realize that ruby is actually a pretty old language, and that the core of node.js is pretty tried and true. Not a knock on python… Just pointing out.

        libuv which is the core io library for node has been around for a while and the v8 engine is a very broadly distributed runtime, far more than python.

        • My comment refers to the architecture of typical node.js powered web applications, not the core itself. IMO, the asynchronous model works well for certain small parts of a web application, but it’s an anti-pattern for most parts and most applications.

          Rails, not Ruby.

  7. Hi Michael,

    I found this a great article, and it (almost cannily) reflects what motivates me.

    Both the carrot and the stick do work in some situations, but IMO the carrot does seem to bring out the best in programmers.

    Like all people management, working out what particular carrot to use for an individual is part of the job.

    I sometimes liken the art of managing software developers to trying to manage a team of artists. As you say, there can be hours, days, even weeks, when they experience ‘blocks’ – not necessarily technical blocks.

    They may well lie awake at night and find a solution to a problem at 02h00 and want to code it immediately, then only turn up at work at 11h00. Fantastic! They’ve ‘achieved’.(and as a bonus they’re unlikely to get interrupted at 02h00).

    Again, like artists (IMO), they are not generally motivated by money; but in the quality of the ‘art’ they produce. As a manager, I would rather say, paint a picture of a tree, than give them, a painting by numbers request.

    As long as they are aware of how the tree fits into the forest, and are empowered to help design the forest; and are given ‘general’ time constraints they can produce great work.

    However, it is not a science.

    I will certainly take away some great ideas from your article.


  8. I have been both a programmer and later a project manager and now work in an unrelated fields. I think programmers sometimes need to be careful of thinking they are some kind of protected species and that management should bend over backwards to meet their needs.

    At the end of the day they are employees like everyone else and need to understand that companies sometimes have to do things that may make them uncomfortable. For example, deadlines are often set by customers or competitors and may be beyond the control of company management. No one is going to give you 3 day weekends or 6 weeks of leave per year unless you negotiate it and take the pay cut that comes along with working less hours.

    Programmers are smart people, and the best ones I have met are verging on genius, but don’t assume that the other jobs in your company are less worthy. Programmers don’t often have to negotiate with or sell to difficult customers or run a successful business (although plenty do), especially in the current economic environment. Those skills are just as hard to master and many never do.

    This is starting to sound like a rant, and I apologise for that, but my point is that you are as much responsible for your happiness at work as your company is. Don’t expect it all to be one way.

    • James M – I think you hit the nail on the head! (And Darin, here was no missed point! James HAS the point!)

      I too have worked for many years as programmer, project manager and also Manager, and the bottom line here is that ” the work” and “the pay” and “the environment” are the same *issue in every real career*. The *monster* point that MOST programmers fail to realize is there there is always someone stronger, faster and better just around the corner, and that yes – even they – are expendable.

      In case nobody has noticed, the rules have changed – we cannot (nor should not) be prima donna’s in programming, the REAL issue is how we fit in the team, how we communicate, how professional our product is, and how we fit as a person. (yep – said it! )

      As for motivation – personally.. I firmly believe it is personal – on an individual level, and very much has to be understood by managers etc. AND .. not to harp ONLY on programmers, most “managers” are NOT equipped to be a manager in most cases. There is so much wrong at the “programming manager” levels I could write in a book! But the #1 issue ( imo ) is that we take quality programmers and push them into exactly the WRONG location – manager . (Lets take the guy that VERY intelligent, VERY good programmer, VERY technically minded … and lessor people skilled… and put that person in a level of high end social / people awareness) .

      I have managed programmers where everything Michael said above is 100% accurate. I have also had many programmers that money was everything, or being challenged was everything, or being stimulated was everything, or having all the toys WAS everything… it is a personal thing.

      But it seriously – unless your on your own, doing your own thing (which is now how I roll btw ) … your employment is in fact just that, and you *should* be either enjoying your craft… enjoying your employer… enjoying what you do *at that place* … or move on . But please.. there are many many VERY talented programmers that craft – and are not *requiring * motivation at that level mentioned above.

      • Those who can, do. Those who can’t manage. It’s funny how really nice people treat their co-workers like dirt under their feet once they become a manager. No one wants to hear someone drone on and on about how easily they can be replaced and how they should thank the company for being in their employment. Standard middle manager elitism through the whole post.

        • Some of us have done, and then gone on to manage. We make fantastic managers because we’ve been there. We know what you need and what you want, because at one time we wanted the same thing.

          Don’t paint everyone with that brush, it’s patently false.

          • Experience in development is not enough to make one a good manager. The “been there, done that” argument does not hold as the skills needed to be a good manager have very little overlap with the skills needed to be a developer (good or not). Managers need people skills and the ability to manage people, while engineers need the ability to manage code, thoughts, designs, etc.

            In my experience and that of those I’ve talked to, good managers are beyond rare. One or two in a lifetime. Yes, there are exceptions to everything, but painting deserves _that_ brush.

        • @Jon. Amen! Couldn’t have put it better myself. This is the first time I wish there was a Like button (but not from FB of course, that’d be unusable).

      • lol. Programming unmotivated is like writing essays for a college exam. I’m sure there are thousands of programming monkeys that can eventually solve most programming problems, but I think the resentment comes from the more talented programmers.

        These guys notice the problems, know where it can be improved yet are impotent to implement change outside of quitting. In the past I’ve worked only a few hours a week and still out performed everyone in the large offices I worked. I didn’t necesarily start out working only a couple hours a week, but lack of motivation led me there.

        Either the other employees were more lazy than I was or were just more incompetent. It’s something you only notice if you are talented at programming and it’s a common experience among many talented programmers who realize they can only work a few hours a week and be among the best in most companies.

        • Have we worked together? ;-) j/k Very true. Same experience here and same conclusion. Sad but true that so much great talent is wasted by corporate bureaucracy and politics. And I’m not just talking about big companies. Small 3-10 person startups, mid size, and giant companies all suffer from this problem.

          The other, even bigger problem, is the expectation of more than 8 hours of work a day on a regular without extra compensation. That is unprofessional of any manager or company to ask and it is unprofessional to accept because one feels obliged. I totally agree with Robert Martin (Uncle Bob) about this. He writes about extensively in the book, “The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series).”

    • I agree mostly, especially w/ programmers being more humble. However, if the place you’re working at primarily produces software, the reality is, even the CEO is not contributing more. Because without the product that engineers build, there is no company. That is not to say the CEO and others are worthless. But in these times of artificial scarcity of good programmers (there are a lot, most managers and engineers don’t know how to properly interview and thus find them) it’s easy to switch jobs at the least.

      So while I’m not arguing we should feel or be entitled to things, this mere fact makes a good programmer worth a lot more than a manager. Good managers … I’ve only had one or two in this industry … are almost non-existent. So good programmers are leaps and bounds more valuable than most managers. Considering all the managers (especially product managers–have worked with one decent one my whole career) usually get paid more, this is a point of contention and one that might lead someone to feel entitled. And many times, that entitlement is not wrong.

      This is even worse when it’s not a manager. I worked at a place once that provided the worst Dell laptops to their engineers and top of the line Macbook Pros to the designers who couldn’t tell HTML from their own assholes. There is no question that the engineers were more valuable. The designs included a modal that was too big for a 1080p screen. It went in despite the objection of the whole team. I went through 3 Dells, and then I finally gave up and used my own laptop. Not providing _the_ most important tool to a programmer while providing it to designers who don’t need it is an insult. This was purely a software company.

      Considering that most engineers can do the product manager’s, project manager’s, qa’s, designer’s (especially HTML and CSS without which one should not even be hired a designer for web frontends), and their own jobs at once (which is what I have done at _more than one_ company) I’d say that, in fact, at many companies programmers are WAY more important than many other jobs and thus should be treated accordingly.

      If not, they will leave and the company is the one that is losing out not only on talent which can be painfully replaced with luck and time but a lot of money. It costs the company a lot to bring someone on only to have them leave soon after because of mistreatment. That mistreatment may go as far as assault and harassment which can’t be resolved otherwise, but it might be a myriad of other factors.

    • Well said. Programmers seem to feel they are somehow special. This blog post demonstrates the unspoken programmer elitist thinking that somehow they need to be especially catered to.

      Programmers. Get off you high horse. If you really do think you are God’s gift the maybe you should go start you own company. Then maybe you’ll appreciate the skills of management, sales, administration, accounting, creative, etc.

      Good human resource practices for programmers are the same as for everyone:

      – interesting work
      – ‘meaningful’ (in the sense that it useful) work
      – a reasonable amount of autonomy
      – a reasonable amount of ‘say’ (input, influence)
      – reasonable workload
      – an environment of cooperation (rather than competition/politics).

      P.S. I’m a very experience (+25 yrs) programmer.

      • It’s good to know that you are a “very experience” (sic!) programmer. Too bad it didn’t dawn to you that it is the software engineers that build the company. It’s much easier for an engineer to sell or “manage” than it would be for a manager to figure out how to write “hello, world!”.

  9. @JamesM
    I suspect you’ve totally missed the point of the article. It most certainly IS in the best interests of companies to make technical employees happy (or at least to motivate them by means that might actually work).

    The alternative is significant attrition, which, as anyone in the field knows, can be +extremely+ costly to a company. Far more so than a few days off, or hour for hour comp time., etc.

  10. Very nice, I agree with the vast majority of it.

    My experience with bonuses has been that they drop out of the sky without rhyme or reason. However, for a short period of time after a company changed hands, bonuses were nice rewards for getting another department moving again, saving the company money with a novel implementation, things the previous owners would have yelled at me for not doing things their way, the new owners would show up at my desk with a check. That was nice while it lasted, it demonstrated that they appreciated what I was doing.

    I seem to have an odd view about business. My definition of a company, is a group of people who come together for the common goal of making money. The problems begin when some begin treating it as a zero sum game. I can’t make more money without making you make less. That, and management thinking rewards should only go to them. Every company I have been with may have started by giving bonuses to everyone, eventually changed so only managers got bonuses, to only upper management getting bonuses.

    When it comes to software tools and languages, I don’t chase fads, but I do want to move up to better tools and development methodologies as they emerge. Usually it is a battle to convince those with the pursestrings that there is a better way and to spend the money to get there.

    I agree that performance metrics are a waste of time, a call back to what I call Industrial Age thinking instead of Information Age. I’m not grinding out identical widgets. Timing how long it took me to write one routine will not be a guide on how long it will take me to write the next. This industry is driven by cognition and we don’t all have the same mindset and information at the same time. Given the squishy thing in our skulls instead of the hard silicon of our computers, we aren’t even the same day to day. How are those metrics useful other than enabling one of those management by intimidation types to think they have justification?

    • I’m a Java Programmer and used to be a C# Programmer so you know that I use IDE in my daily work. However, there are some case where I prefer a simple CLI e.g.,
      1. searching via “grep” is faster than using IDE.
      2. Reading log using “tail -f” is more satisfying than reading it in EditPlus, Notepad++, UltraEdit.

      And, I have met snobby programmer in my life and they have cleaner code than mine because they understand the important of readable code.

      You also misunderstand the article. It is not about one programmer capability. It is about work environment.

      My previous company had a good work environment. I felt being a team there. I felt accomplished something. I code more lines than in my current company. We had a lot of data to test so we can do individual test.

      In my current company, the interruption was too much. I had to write trivial documentation, answering trivial question, spending time contacting the other company to check whether their server was ready to test our code.

    • “I’m disturbed by the level of… ignorance — I’m coming up with a polite word here — that this guy seeps from this article. I had to ask myself if this was a Markov bot with some extra formatting, and possibly a glorious troll. Markov bots can’t respond yet like humans though — Unless someone’s passed the Turing test.”

      Huh, that’s funny. That is a great description of what I thought of your article/rant. It was rather terrible. I won’t bother to debate with you point by point because it’d be a waste of my time. However, not even using proper spelling and grammar destroys your argument by itself. Maybe you should look in the mirror before talking about ignorance.

      One thing I want to say though is most of the time the engineer is incapable of changing the environment, due to corporate crap, which is why it is better to leave than to stick around.

      • His points on IDEs and tools are straight on. Too bad you didn’t read the article before leaving a reply. Spelling and grammar do not destroy an argument. Please provide the logical fallacy those would be violating in destroying the credibility of the article.

    • @Indora: You have very good points especially about IDEs and cli tools and the illusion that great programmers only use the latter and bad programmers use the former. I think Michael is right on most other points, but this one is completely wrong. I’m glad you wrote up a more detailed approach that is based on reality. I’m not trying to detract from Michael’s credibility as this is a fantastic blog and missing one or two points (even as badly as this) doesn’t invalidate the many valid and true points he does make.

      On the other hand, I will make a suggestion to Michael: expressing opinions on tools as being reflective of a programmer’s skill level is going to lead to trouble in real life not just with people but with architecture. There is only one rule: use the best tool for the job. If that is CLI so be it. In any modern web app that is not CLI only. EVER!

      As in CLI only tools are NOT the best tools for programming modern web apps. I keep hearing from people, oh well I can dump 20 plugins into vim and hack up some vim extensions and it’ll be just like your IDE. Ok, well I can spend that time doing something else after spending 20 minutes customizing my IDE the way I want it to work. It’s a classic example of using the wrong tool for the job.

      Here’s another one: grep. Yeah it’s great, but my IDE maintains an index making grep 10-1000x faster depending on the project. It’s a no brainer what the best tool for the job is.

      And one final one: Magento. I need not say anymore.

      • Mmm, curious to hear about grep. In my experience (programming Python, mostly; Ruby sometimes), I found faster to use “ack” (which is a glorified grep) than to search using an IDE (I’ve tried several).

        Of course, that could be related to the dynamic element of the language. I use Vim plus a couple plugins to write code. It fits me, I’m not saying that’s what everybody should use. If I had to program again in C++, maybe I choose a different tool…

        • I’ve never used ack for searching. grep is quite fast, however, as project size increases, PHPStorm (my IDE of choice for PHP) searches faster as it is able to use indexes to search. This is contrary to most IDEs I’ve tried before (Eclipse, Netbeans), but on midsize to huge projects it makes a huge difference. The tradeoff is about a minute or two when first creating the project and a little longer startup time, both minor inconveniences that happen once a project and once a day or less respectively.

          Searching/navigating for classes, symbols, and filenames is, of course, instantaneous because of the indexing / code insight which makes full project searches for random strings much more rare as well.

          • Give it a try to ‘ack’, is one of those “OMG how could I lived without it” programs… http://betterthangrep.com/
            It is quite fast, though some times you have to limit a little the search to one directory. Used properly, is almost instantaneous for moderate sized projects. Anyway, I use a lot CLI, so it integrates good with that, but there are also plugins for some editors (I know at least Vim and TextMate)

            • Nice. I will definitely check it out. It’s one of those tools I’ve known about from many people but never put in the time to explore it.

    • Wow, you really should take some remedial English classes before you post something online. Rarely have I seen an article that was written so poorly, both in terms of its argumentation as well as its presentation.

  11. Michael, very, very good, honest article. I have been doing software development for over 25 years and have experienced much of what you very accurately put into words. I sit here, working as a contractor, in a cube, sandwiched between very noisy finance and customer service departments, wearing my ear plugs, trying to block out the noise completely.

    My career goals (sadly) are now to just have work until I retire. If I am lucky maybe a few of the projects that I develop over the next several years will use technology that is only 5 – 10 years old. Those days where I really felt I learned something, or I created something valuable are fewer and fewer.

  12. I left software development because high quality sound canceling earphones had become a mandatory bit of equipment. In all of my contracts, I owned better computer equipment than I was supplied on site, and had better software as well.

    If I ever get asked to do programming in the future, I will insist on viewing the work environment first.

    Programmers have to maintain ‘zones’ where multidimensional, complex relationship concepts have to be retained in ‘core memory’ for considerable lengths of time. Irritations like noise, bad performing equipment, uncomfortable work furniture and the like are just unacceptable.

    Would the CEO pour sand in the oil of his SAAB ? His software team are costing his company more than the car repayments are.

    • For my part, I can deal with the noise, but what I can’t stand is open-back visibility– the fact that someone can look at my screen or ambush me. It’s ridiculous.

      You can’t really get into the zone in a corporate environment, and you’re not supposed to. Companies would rather have people responsive but at a mediocre level of productivity than in a high-productivity state. Once you fully accept this, and realize that no one is expecting the level of performance you’d have on a green field, it gets easier.

  13. Pride before a fall and humility before honors. I had a construction job summers after high school, then landed a job programming at Ticketmaster while going to school. Later I took a deli job and landed a job as chief hardware software engineer. God’s world is perfectly just and pride goes before a fall and humility before honors. If you suffer in a depressing position that hurts your future potential, God will be just. In general, if you get paid more, the job will suck more. Jobs are like marriages — the side that feels they are getting a raw deal will dominate. If you’re too good for your wife, she will rule you. If you lie and get a job in over your head or take affirmative action, you will fail. Cheaters never win and God’s world is perfectly just.

  14. Pingback: What programmers want. | Stoneburners Blog

  15. I must say I agree with most of what you say. I’d say 90% of programiming businesses are so stuck in the ‘rigid office employee” of other sectors that they don’t understand what makes real programmers motivated.

  16. Enjoyed the analogy between motivation and time off, as well as the time increments for successful feedback iterations. Have you considered Disqus to aid in comment organization? Bonus karma for editing out that commenters email to their boss.

  17. Pingback: What Programmers Want | Open Source Code | Scoop.it

  18. You stated that an employee’s output level will go all the way to 0 if they can get away with it. Actually, it can definitely go negative – and especially where software is concerned. A really bad programmer can churn out bug-ridden spaghetti code that consumes vast amounts of time from other members of the team trying to work with it, debug it, fix it, and clean it up – even to the point where good programmers get fed up and quit. There’s really no limit to just how big a negative number can be reached – even the entire company can be put out of business by one terrible programmer.

  19. Pingback: Callback Coders | Coder Radio 22 | Jupiter Broadcasting

  20. Pingback: Dont Waste Your Time at a Crappy Startup » ofazomi.org

  21. Pingback: Ciekawostki « Wiadomości o technologiach IT

  22. I have a couple of independent comments…

    I’m not sure the author intended this, but in the Career growth section the author seems to imply that Trust is not important. It sort of culminates with “…and gradually winning others’ trust, and actual skill growth is tertiary.” I’d assert that actual career growth is highly trust related; skill growth in development (or any other form of knowledge work) is necessary for building that trust. As long as it is a mutually established item (i.e. you are building skills I as the employer can see useful whether now or in the future) and that the programmer is interested in pursuing, then it moves it to helping build trust between “us”, you know I care about you and I know you care about what we are trying to accomplish. Sadly the author is right in that most employers don’t see this relationship very well… This is not the ONLY thing that goes into building trust, but it is crucial in technical/knowledge work.

    I’d assert that the author’s focus on programming could be moved to any knowledge-based or creative work.

    Lastly, it sounds like the author had a manager or managers that used the information radiators of Agile inappropriately. These information radiators or for the team of developers to assess, understand, and coordinate progress, not for a manager to understand status. Managers need feedback as well; it’s unreasonable to think a manager should not know what is going on. (The author does not assert this, but I’m just being explicit so folks realize this is a necessity of life.) What management usually fails at is asking for feedback/status in an unobtrusive and useful way.

    Overall I really enjoyed your post and am forwarding it to some former colleagues.


  23. I remember when I started my programming career in a small company I was really, really happy! In fact, it was the happiest days in my life.

    My salary was low, very low – but I was really happy. My manager, although younger than me at the time, was one of the best managers/leaders I had. He was serious but not too serious – he was intelligent, and he knew what he wanted. He always used to give me challenging tasks and he always used to praise my work. He never questioned me and always trusted my technical decisions – he never micromanaged me and he never tried to scapegoat me.

    That was back in 2001-2002 (10 years ago) and since then I have worked for several companies but no manager has even come close to what this manager was.

    Now that I run my own company, I can say with confidence that programmers want 1 thing: a leader!

  24. Pingback: What we (programmers) want « Stuff From Hsoi

  25. I don’t accept the statement “Software is too complex for management to reliably separate bad environmental factors and projects from bad employees, much less willful underperformance from no-fault lack-of-fit.” I’ve been able to repeatedly identify and separate complex causational factors in my organisation. The question could be rephrased to ask why managers don’t do it, and the answer I suspect lies in understanding the psychology and motivational factors of a manager.

  26. Pingback: Issue 26 – Startup Anthropology – What’s Your Tribe? — TLN

  27. Pingback: M-A-O-L » What Programmers Want

  28. Pingback: What Programmers Want (a good read)

  29. Pingback: How to motivate me | Sorted Bits

  30. Pingback: Flow, ownership, and insubordination (plus D.F.A.) « Michael O.Church

  31. Pingback: Flow, ownership, and insubordination (plus D.F.A.) « Random Ramblings of Rude Reality

  32. Pingback: No, idiot. Discomfort Is Bad. « Michael O.Church

  33. Pingback: What Programmers Want | Devops Consulting

  34. Pingback: What Programmers Really Want

  35. Pingback: InnerWorkings Blogs » Working Conditions: What Programmers Really Want

  36. ” I also think that most “agile” practices do more harm than good, and that much of the “scrum” movement is flat-out stupid. I don’t think it’s good for managers to expect detailed progress reports (a daily standup focused on blockers is probably ok) on a daily basis– that’s too much overhead and flow breakage– but this is the cycle at which engineers tend to audit themselves, and they won’t be happy in an environment where they end the day not feeling that they worked a day.”

    Michael, I would really appreciate if you can elaborate on the above statement you make about Scrum. Why do you think it creates more harm. Some very famous companies around the world are using it successfully. Thanks!

    • The reporting, IMO, is too frequent and adds additional overhead to the programmer. Also, the problems with measuring productivity and possibly being judged for it.

      Scrum belongs in rugby, but such a meeting would be quite beneficial say, once a week, IMO.

      • @lucian303, the daily stand-ups are supposed to be no longer than 15 minutes, so the overhead is not that big. Measuring productivity and judgement are usually applied by a management, who does not understand scrum correctly. Also scrum is not only about daily stand-ups. There are other elements that could be beneficial for the development team – such as grooming and planning meetings, programmer pairing, knowledge transfer, etc. In general, in scrum, the team (not an individual team member) is responsible for delivering a working feature for a given time frame.

        I would like to hear more opinions…

        • @krassib I think the intent of scrum and in an idea setting, practiced well, it is closer to what you say. My observations are not so much of scrum but of bastardized scrum as misunderstood by managers. However, the set strict time, is just silly.

        • Scrum, practiced properly, protects the team from management. It requires priorities to be set and documented, and provides mechanisms (such as standups, which generate common knowledge of accomplishment) to certify that a team member worked in good faith.

          Managers, consequently, tend not to like Scrum if it’s practiced properly. That’s why Scrum Masters often get fired. The job is to protect the team. That’s dangerous. Eventually, you end up with a bastardized Scrum that has no teeth against management, and it just becomes another vehicle for managerial priapism.

          My issue with Scrum is that it seems to assume closed allocation, which is wrong both morally (it steals peoples’ career opportunities from them) and industrially (it doesn’t work).

          • Scrum methodology (moving deliverables, changing scope, re-prioritizing tasks, etc. to get through the sprint with a releasable product or not) is not compatible with executives’ and managers’ desire for everything to be delivered on some arbitrary due date.

            Oftentimes, this leads to scrum-like practices that are truly nothing more than status checks by a SlaveMaster (ScurmMaster) manager who knows that it is impossible to complete all the work that business/marketing/upper management wants, therefore driving the team to work overtime and devaluing their labor with every extra hour needlessly worked in favor of pleasing his managers. It’s either that, or as you say, they get fired because Scrum and general agile methodologies are not compatible with hard release dates for each cycle, or even for the whole project. It’s why a lot of teams fail to meet their goals. Most similar agile software development processes suffer from the same problem and in my experience, every practice that I’ve seen in reality, no matter how far or close to the original model, demands closed allocation.

            Some companies are looking at adopting (and adapting) other practices like Kanban to software development, not realizing the process problem is not a problem with the process itself (just about any process (and oftentimes no official process) done well with the right team and the right humane, respectful leadership works very well at producing software), but with the company executives’ and managers’ downright refusal to hold up their end of the process-contract bargain.

      • Excellent synopsis.

        Managers are used to email services and weather apps that can be checked 23 times per day with no degradation of performance, and have lost sight of the fact that people don’t work that way.

        Power makes a person not care about others’ emotional states. It makes a person less intellectually and socially attuned. This is a problem when the work requires a person be in a decent-enough emotional state to think coherently.

  37. Hi I am so thrilled I found your web site, I really found you by error, while I was researching
    on Google for something else, Regardless I am here now and would just like
    to say many thanks for a fantastic post and a all round exciting blog (I also love the theme/design), I don’t have time to read it all at the
    moment but I have saved it and also included your RSS feeds, so when I have time I will be back to read much more, Please do keep up the superb work.

  38. Pingback: Notes On Job Hopping: You Should Probably Job Hop | DaedTech

  39. Pingback: What Programmers Want | Michael O. Church « Mark Turner dot Net

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s