killthemeeting

There's an interesting group advocating for telecommuting these days -- rural town governments.

Apparently, rural towns have had a population problem of late -- as young people these days don't tend to want to work on the farm, and all the information-worker jobs are found in large cities, people tend to leave small towns for the city or the suburbs.  Many of them want to live in a small town (or to return to one when they have children), but there's not a lot of demand for, say, an Enterprise Architect in a town whose largest employer employs maybe a dozen people.

Telecommuting to jobs in large cities is an obvious benefit to the workers, who get to live where they want -- at substantially lower living cost, plus without the costs of commuting -- while getting a job that's not available in that area.  The benefit to the town is less obvious but no less real: "People who telecommute, live and work here, are the best of both worlds.  They're big earners and they spend the money in town," says Dave Wilson, quoted in the article above.  He recruits for Kansas City and Wichita companies in tiny Sterling, Kansas.  It's a way for companies to bring high-income residents (with the local economic input and tax revenue that that provides) to town without having to lure employers (a task that often requires giving them huge government handouts, in the form of discounted leases, long-term tax breaks, etc.)

Right now, a lot of these employes are probably virtual call center employees, which while not the highest-earning thing out there is at least a "real" job you can do from home (as opposed to the mountains of envelope-stuffing "work from home" scams.)  However, there are definitely some other things out there that are employing virtual workers.

There are, however, some roadblocks.  While towns may be eager to lure telecommuters to reap tax benefits, state governments are fond of reaping tax benefits, too, and the law doesn't always favor telecommuting.  The Telework Coalition is trying to get a law passed to change the situation, but as it stands now, people telecommuting across state lines may end up paying state income tax twice.  The issue is that some states (e.g. New York) require state income tax to be collected on all wage income paid out by employers in the state, even if the worker resides in the other state.  But some states require state income tax to be collected on all income earned in the state -- even if it was from an out-of-state employer!  While this isn't a problem if you live or work in a state with no state income tax (e.g. Washington), or for an employer in the same state, it does discourage companies from organized telework programs.

This said, I'd find an extra 1-2% state income tax a pretty small price to pay to give up commuting -- especially since commuting costs me more than that now.

Posted by Grant at 10:44 AM | Permalink | Comments (0) | TrackBacks (0)

I observed in a previous entry that I found myself somewhat baffled by the software engineering process taken by some offshoring/outsourcing firms, and realized that one issue is that while these people were programmers, they weren't "geeks."  I realized then that there are actually a lot of things that are done differently by the "computer geek" set -- a group which tends to include all of the best developers I know.  Mainly, I've observed this in the differences between developers at my current employer (a large, traditional retailer) and my previous one (Microsoft.)

Geeks have different priorities than most people when it comes to software engineering jobs, and attracting and retaining them at a company can require some different strategies.  And they're worth attracting and maintaining, for two reasons: first, most of the really good developers fall into that category, and while you don't need all your developers to be superstars, it sure helps if some of them are; and two, because they don't care all that much about the money.

What does matter to them?  Several things:

• Autonomy.  Micromanagement drives them crazy.  This is a case where you must follow management-by-results, not management-by-tasks.  Figuring out how to do things is precisely what geeks enjoy about work -- tell them what you want, not how you want them to achieve it.  They'll figure something out, and be willing to go above and beyond what's required, because it's theirs.  Whereas if you give them a checklist, they'll do it haphazardly, because they're not invested in it.
  
• Isolation.  Geeks, all told, are not very social.  They do their best work when left alone.  The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy.  Offices are ideal for most development work, the only exception being the early stages wherein there's a lot more collaboration and brainstorming than actual coding.  Actual coding needs extended, uninterrupted quiet time (well, sometimes it's not quiet at all if you count music, but the sounds are chosen.)  Geeks coding get into the "zone" -- a 5-minute interruption can and will cost you an hour of productivity.
• Technology.  Geeks want to be on the cutting edge.  You're not going to retain one for a project writing Yet Another Database Front-End unless you've got a truly amazing work environment (or seriously overpay them for work that frankly doesn't require superstar developers.)  More interesting projects often mean more than higher-paying projects.  In addition, it's worth investing in the technology they'll use every day.  Sure, they may not really "need" a $4,000 dev workstation with two LCD monitors... but they'll be more productive with one, be happier working on it, and it'll do more to retain them than you would from a comparably-sized raise.  Ever having to wait on substandard technology to keep up with them is irritating.
  

Most importantly of all, though, geeks despise "politics," where by politics I mean any situation in which interpersonal considerations outweigh technical considerations.  They have no patience at all for things like:

• Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because "the boss likes it," "we've always done it that way," or "we're a [insert product here] shop."  They need technical reasons for using a technology, not somebody's feelings.
• Anything perceived as unfair.  While I said they don't care much about money, there is one situation in which they do care -- if they feel they're paid less than market value, or that someone else who's not as good as they are is paid more.  Trying to keep salaries secret helps not at all -- they for the most part don't understand why they should be kept secret, and thus will totally disregard any order to do so.   Of course, the problem is that they're often unwilling or unable to see any non-technical factors in an employee's value, which sometimes do play a part in compensation.
  
• Fiefdoms and silos.  Geeks want to get things done.  And they don't care overmuch who does them -- when engineering solutions, they'll totally ignore interdepartmental boundaries.  This isn't a bad thing; however, managers often think it's a bad thing, since they want their team to get the credit for it.  What these managers fail to take into account is that trying to get the credit for it results in not just an inferior product but also unhappy developers.

Though I'm talking primarily about work here, these characteristics do extend outside of work, too, particularly the intolerance for personal considerations outweighing technical (or whatever they perceive as "rational" or "logical" considerations.)  Geeks don't see the point of playing a game if they can't play to win -- it's not that they care overmuch about winning, it's that the game has a framework of rules, and that framework should be complete.  I think this is one thing that makes geeks thought of as antisocial -- they don't take people's feelings into account when doing things, because those don't fit into the rational, logical, predictable framework they like.  I think that how "normal-seeming" a geek is depends largely on how willing they are to sublimate this impulse in order to relate to other people.

Finally, when it comes to performance management, geeks need to be told, directly and clearly, how they're doing and what needs improvement, if anything.  Not being people-oriented, they probably can't read you.  They don't know if you're happy with them or not unless you tell them.  And they're certainly not going to ask.  While they deal extremely well with technical ambiguity -- they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome -- they don't deal well at all with ambiguity in other contexts.  Clear expectations and consistent feedback turn the job itself into a problem to be solved, which makes it much more satisfying to them.

I can't help but think there's probably some correlation between what I've observed as the "software engineering geek" personality and some MBTI or enneagram types.  It's probably not an exact mapping, but it sure is something that comes up a lot -- I can pretty easily classify most of the developers I've worked with into "geek" and "non-geek" if I try. 

Posted by Grant at 09:10 PM | Permalink | Comments (0) | TrackBacks (0)

The last five years have seen two trends take off: independent (or semi-independent) contracting for IT, and offshoring development work.  Both of these bode well for telecommuters in the workplace... eventually.

Here in the Seattle area, independent IT and development contractors are everywhere... and so are jobs for them.  If I post a resume on Monster, Dice, or any other job board, I am pretty much immediately inundated with offers for 3- to 12- month development contracts on small- to medium-sized projects.  I don't usually want them, due to the inflexibility (no vacation time, and they're just long enough that I don't usually want to commit to 6+ months without any time off), but they're there.  I must confess their presence doesn't do much for the idea of corporate loyalty -- their fixed length implies they're not interested in any commitment themselves, and their ubiquity means that anyone with the skills to get one isn't really trapped in their current job.  Rather than weeks or months of interviewing to get real employment, a developer can often snag a few months of contract work within a week or two just due to the sheer number of these positions.

Offshoring development work, as much as people complain about it, does get managers used to the idea of employees that they can't see and which don't even work the same hours as they do.  Of course, they have the comfort of knowing that wherever these employees are in the world, they do have some other manager breathing down their neck.  And they're also undoubtedly comforted by the mounds of process these firms tend to use.

I think its the combination of these trends that is starting to produce automated, telecommuting job boards for development and IT workers.  The two major ones right now are Rent-a-Coder and oDesk.

Rent-a-Coder's main flaw to the U.S. telecommuter is that it works too well.  The jobs people tend to post on Rent-a-Coder are straightforward, self-contained dev jobs for one person.  They're usually no more than a week's work.  Rent-a-Coder works as a reverse auction -- people put in proposals for how long the work will take, advertise themselves a bit, and state what hourly rate they're willing to work for.  Rent-a-Coder is a pretty reliable way for a skilled developer to find quick, straightforward, and usually easy work.

However, it's just as easy for developers in India or China.  Rent-a-Coder, being a virtual job market for people who will never meet their employers in person, is truly a global market.  If you're a teenager or college student, the $15-20 an hour that development work usually goes for might sound pretty good, but skilled professionals usually find themselves priced well out of the market.  Overseas developers with 10 years of enterprise Java experience put in bids of $13.50/hr... anyone in the U.S. or U.K. who can compete with their qualifications usually doesn't want to compete with their prices.

oDesk aims to be a different sort of market -- they target companies looking for "homeshoring."  It works more like a traditional job market, in that people post themselves with a rate requirement rather than just bidding on projects.  It's less one-way than Rent-a-Coder.  In addition, being targeted at more serious projects (there are a lot of long-term things on oDesk; it's not so biased at Rent-a-Coder's usually-tiny projects), the providers often command more reasonable (from a U.S. perspective) rates.  Their current home page quotes providers with rates up to $65/hr. for some skillsets... though it quotes some at $14/hr. as well, so obviously there's a lot of variability.

oDesk, however, goes far beyond Rent-a-Coder's simple matching.  Essentially, they aim to be a virtual temp agency, a Volt or ExcellData for the nation.  They provide all their contractors with standard software (SVN and BugZilla for tracking and version control, but also presence and videoconferencing software, timecard software, etc.) and have relatively standardized contracts.

On the bright side, oDesk recognizes that the biggest hurdle companies have to hiring telecommuters is one of trust -- managers, unable to track what people are doing since they're not in the office, need proof that they're actually doing work.  My preferred solution to this problem would be to track work -- that is, integrate with the version-control tools, bug tracking software, etc. to demonstrate tasks actually completed, and use status report deliverables to have employees state their progress and bring up issues so that if someone is falling behind managemnet is informed beforehand (or can fire an employee when he fails to meet a deadline not for failing to meet the deadline, but for failing to track toward it and lying about it in the status reports until that time.)

oDesk, however, does not take my enlightened, employee-friendly approach.  No, they have a different way -- spying!  oDesk's software screenshots the telecommuter's machine every 10 minutes to give remote managers a gallery of activity to browse.  They also generously provide their contractors with a videocamera, so managers can watch you wherever you are.  And the logs show not lines of code, or checkins, or bugs, but rather the number of keystrokes and mouse clicks per minute you've made.  The result is that you can get all the stress, lack of privacy, and constant monitoring of an "open-plan" cube farm right in the comfort of your own home!  Also, oDesk keeps 30% of whatever you're paid.

Obviously, I think oDesk is, to some extent, missing the point.  On the other hand, they're a business, and their customers are not just the employees but also the employers.  That trust gap is one of the most important things for them to bridge in order to get employers comfortable with telecommuting employees.  In the long run, I think it's a good thing for telecommuters -- having hired a few people through oDesk, a manager is likely to be more comfortable with employees he can't see, and less inclined to protest the idea when someone comes along wanting to be a truly independent remote employee (this time without keystrokes-per-minute clocking.)  This said, in the short run, well, I wouldn't work for them.

Posted by Grant at 12:52 PM | Permalink | Comments (0) | TrackBacks (0)

If you work in a sotfware development organization, you've probably heard a lot about "alternative" software development and project management methodologies, such as Agile, SCRUM, Extreme Programming (XP), Test-Driven Development, etc.  These are, of course, all alternatves to the traditional waterfall model (wonderfully parodied in the preceding link -- the conference linked to is, of course, not real.  I particularly like the session entitled "Pair Managing: Two Managers per Programmer.")

Most of my development experience came at Microsoft, which has its own software development life cycle (SDLC) and, for all its problems, still has a large number of very smart developers and a management corps consisting almost entirely of former coders.  As a result, I operated under the assumption that this SDLC was more or less typical for the industry, as it sort of vaguely lined up with the traditional waterfall SDLC.

And then I came to my current job.  Yes, I have found the IT shop that performs development on the unmodified waterfall model -- welcome to 1979.  The great majority of our software development work is outsourced to a contracting firm in India, and thus worked on overnight, largely out of contact with our management, and the amount of process involved is staggering.

On one recent project, the software development managers insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.

The code in question?  Five lines of SQL.

Yes, a 2-hour project took over a month.  Actually, it's not quite done yet, due to the repeated test cycles.  You might think all that documentation would have rendered bugs impossible, but if so, you'd be wrong.

Why on earth is so much process present?  Why does it take three documents and six meetings to write five lines of SQL?  There are twice as many pages of documentation as lines of code!  Well, having worked with the people involved on these documents, plus the development, and the testing, not just on this project but several others, I think I've figured out the purpose: process is being used as a substitute for competence.

The thing that's surprised me, though, is that process actually turns out to be a pretty good substitute for competence.  With enough steps, documents, design reviews, and test plans, I think that the proverbial 1,000 monkeys with typewriters really could produce a functional IT system.  The incredible amount of mutual reinforcement breaks the task down into such minute pieces that each piece is comprehensible and completable by anyone with even the slightest modicum of coding or testing ability.  It turns what is inherently a massively complex endeavor -- software engineering -- into little more than rote following of directions.  Each step is so long and involved as it must be performed in so much detail that the next step follows necessarily, without putting much thought into it.  The waterfall model enforces this level of detailing by making it nigh-impossible to change decisions made early on.  It also helps project management -- after years of this sort of development, the project managers know to a pretty good degree of accuracy how long each minute task will take, and can thus do a pretty good job coming up with a (shockingly long) timeline for a project in any stage of development.

The problem with this model, though, is that anyone who is halfway competent finds himself spending more time on process than on actual, productive development activity.  Everything is drawn out over a huge period of time.  I think this is the main thing that's been driving alternative methodologies like Agile and SCRUM -- the desire by skilled developers to sweep away all that process that's "in their way," and get rid of documentation and meetings.

This has led to the principles of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

This is pretty much the complete opposite of the waterfall model, and developers often enjoy working in such a model quite a bit more.  (This said, it can be done badly, as discussed in Steve Yegge's blog here, though that post eventually turns into Google-worship.)  Good developers, on the whole, hate process, don't like writing documentation, have no concept of or interest in business concerns, and like to code by the seat of their pants anyway.  A methodology that says "what you want to do anyway, that's good!" will naturally get a lot of traction.  Nothing gets developers excited like telling them that they don't need to produce documentation, the code is the documentation.

However, I can see that as much as I hate the process-bound development process I work with here, an Agile methodology would be a total failure with these developers.  They are simply paralyzed by the slightest bit of uncertainty, entirely unwilling to just figure out for themselves what will work.  They entirely lack both the ability and the desire to experiment.  In short, while they're programmers, they're not geeks, and that idea still seems somewhat foreign to me -- when I think about developers, I still think about people who program for fun.  But these developers approach programming like it's on an assembly line, and they need to be told the right way to do everything before they're willing to touch it.

So if you're faced with a very involved, complicated process to do something, stop and consider why that process is there -- it's possible, likely even, that it's there to remove the responsibility of making decisions from some set of people.  Sometimes that's because someone higher up is (or was) a petty tyrant and doesn't care for decisions being made by anyone but himself -- in that case, the process may be ripe for a change.  But sometimes it's there because the people involved are unwilling or unable to act without it, and in that case you change it at your peril.  While a more agile process would be better for me, and is better for the development teams at Microsoft and Google, it's not necessarily better for everyone -- not everyone is a self-motivated geek.

Unfortunately for me, I don't think this is a process I can change here.  It turns out that outsourcing development to India is so much cheaper that even if it takes four times as long, it's still a net savings. 

Posted by Grant at 10:13 AM | Permalink | Comments (0) | TrackBacks (3)

I think one of the major reasons people don't object more strongly to the commuting culture is that they simply don't realize how much it costs.  After all, it's only driving to work in the morning, how much of your salary does it really take up?  Well, for me:

• 31 gallons of gasoline per month = $79/mo., $953/yr.
• 672 miles driven per month; assuming a 100,000 mile vehicle lifespan, this depreciates my vehicle by $168/mo., $2,016/yr.
  
• Parking a few blocks from my building = $100/mo, $1,200/yr.
• Bumping my driving miles per year above 8,000 raises my insurance rates slightly.
• I waste a substantial period of time every day sitting in traffic.  Assuming I value my time by about what I'm compensated for it at work, this costs me $1,127/mo., $13,524/yr.

Good lord, that's a lot.  My commute costs me $4,169/yr. in actual costs, or $17,693 if you count lost time!  (On one hand, counting lost time is cheating a bit since I wouldn't really spend all that commuting time working, and I'm not paid by the hour anyway.  But since if I were offered the option to take a $13,524 pay cut to drop a day off my workweek, I'd take it in a heartbeat, I don't think it's an entirely unfair valuation of my time, either.)

And in many ways I'm getting off easy -- my car gets 22 mpg average (though honestly it may well be lower during Seattle's rush hour), it's a Honda that didn't cost all that much (keeping the depreciation cost down and meaning it really will last for at least 100,000 miles), and $4.75/day for downtown parking is cheap as hell.  With a Mercedes and a better parking spot, I could easily have $7,500 in actual monetary cost from the daily commute.

Think about that -- your company's requirement that you sit in a cubicle at work every day, even when it's not actually necessary for what you accomplish, is costing you $4,000 or more per year.  And that's cost, not wages, which means that not commuting would be the equivalent of a $5,700 raise in terms of how much money you would actually end up with in your pocket.

Of course, your company doesn't care overmuch, since you are paying that cost, and they are not.  However, I think if more people were aware of the true cost, they'd be more inclined to view telecommuting as the benefit it is, and making use of remote workers would be a more accepted cost-saving measure for corporations.  A $4,000 pay cut to work from home would actually increase my take-home pay, and that would be saving my employer money.

Posted by Grant at 07:09 AM | Permalink | Comments (1) | TrackBacks (0)