Best Job Application Ever

Usually, I try to use this space to talk about deep, meaningful subjects (or something). But every once in awhile I think there's room for a little levity. I happened to be digging around some files and happened upon a real gem I figured I should share. I almost submitted it to thedailywtf.com, but decided:

"Why the hell should I give them *my* content for free?"

Anyway, a few years back I was still just a lowly developer. We were swamped with work and desperate to find Perl developers. There was an alias set up for incoming job applications. One of the ones that came had this cover letter:

I am interested in a position in Computers and Technology in Research and Development with your company. I do possess many technological positions with scientific advancements and discoveries and skills that are not listed on my application and resume with some older employers. I am interested in developing novel technology for your corporation that is outranking outside of every text book and that is not taught at any university, company, or federal agency. My computer is the first computer on the Internet powering the entire Universe over thin air, which consists of optical motherboards, optical RAM, optical hard drives, optical processors, and automorphing anti-viral biological-plasmas replacing the solid-state nuclear magnetic computer. Some of my inventions are:

Optical Biological Digital Computers & Components Hyper Drives [FTL] [Faster Than Light] Warp Drives [FTL] [Faster Than Light] Time Machines [Direct & Real-Time] Biological Atomic Clocks [Direct & Real-Time] Liquid-Crystal Quantum Mechanics & Biological Continuum Liquid-Crystal Astrophysics Liquid-Crystal Physics Liquid-Crystal Mathematics [Differential Equations] Liquid-Crystal Science Liquid-Crystal Astronomy Liquid-Crystal Programming Liquid-Crystal Data Storage Liquid-Crystal Universe Mapping Liquid-Crystal Time Travel Liquid-Crystal High-Energy Cold Fusion [######] Liquid-Crystal Civil Defense Computer Systems Liquid-Crystal Cyber Health Care Liquid-Crystal Experimental Computers & Components Liquid-Crystal Nanobots and Nanotechnology

I am interested in starting as soon as possible. Please don't hesitate to contact myself at (###) ###-####. It will certainly be a pleasure in meeting as well as working with you. Please consider me a candidate for employment with your company.

Sadly, we did *not* interview this guy. Some thought it was a joke. I'm more inclined to think it was someone who was completely delusional and off his meds. But, hey, maybe the guy was totally legit. We may have missed out on a computer 'powering the entire Universe over thin air'. Crap!!!

Thoughts on Offshoring, Pt III

Last time I wrote about my experience with offshoring on a large migration project. Interestingly, as soon as we moved our code into production I was moved over to manage a completely different group. As a result of a company reorg my job had been promised to someone else. For awhile, it looked like I was going to be laid off, but after checking around a bit I was able to snag a development manager position within a different group . Ironically this new position was within a bigger group, the rising star of my company in fact. So what had at first seemed like a terrible disaster was, in fact, a blessing in disguise.

My new team had been formed around the same time my old team had started implementing its offshoring stategy. While in my former group we'd charted our own path (to mixed success), my new group had followed the path laid by the executives within our company, both in terms of their choice of vendor (which was located in India), as well as the way they interacted with the offshore team members.

In fact, when the topic of using offshore as our primary development force (it had been use in a minor capacity for quite some time), started to be discussed in earnest, the decision of who would be our official "offshore partner" was one of the first topics to be discussed. I was told at that time that one vendor stood out because of the contract terms we had with them. Our contract with them contained clauses such that for we would levy "SLA" penalties against them based on the number of bugs in the code they produced. Additionally, if the code they wrote resulted in downtime of our system (which would result in SLA penalties for us) we would also charge them.

I thought this punitive model of development one was a terrible way to begin the relationship and said as much to my director. I really hold with the Agile folks about the absolute criticality of trust and collaboration. Of course, Agile doesn't hold any kind of monopoly on these things, but they do tend to put particular emphasis on these qualities. They seemed to disregard the importance of these things entirely.
"You wrote bad code, I'm going to smack your hand!"

But then the whole idea that "SLAs" in the contract were the reason we preferred this company was a a bit of smoke and mirrors. In fact, it was offhandedly mentioned in another meeting that our new offshoring company had a number of the same people on its board as our company did. When I learned that, I stopped asking questions. As with most business decisions (at least in my experience) it seemed to be based around how those at the top can put or keep th e most money in their own pockets.

The interaction model with this vendor was roughly as follows: we would maintain a staff of "development leads" on site. The leads along with our higher-level solution architects would be our only onshore development resources. The solution architect would interact with our internal program managers and customers to create a high-level solution. This solution would then be further fleshed out by an onsite development lead. The onsite development lead would then interact with a corresponding development lead on the offshore team, who would divy out this work to the developers on his side. This offshore team would also have their own managers to oversee the work who would interact with their counterparts on this side of the world.

I was extremely dubious about this model with its emphasis on "hand offs" and overlapping team members. More personally I was concerned this would mean I'd be on the phone with the guys in India at 3am every morning, and so on. This was not a pleasant prospect.

Interestingly, however, as part of the partnership we decided to bring over a number of offshore team members (mostly managers, a few devs) who bridged the gap between our offices. It is mostly these poor souls who now end up on the phone late every night with India, or having to convey information across to the team overseas.

What this has meant for me os that my interations with offshore have been relatively painless. The pain has largely been bourne by the onsite representatives of the offshore team. There have been minor issues I've had to deal with, but keeping track of resourcing, communicating, etc has been facilitated by the onsite members of the offshore team. Of course, the devs themselves still have to interact, but when we need to have calls between the teams they are done early in the morning our time. Sucks for the dudes in India, but relatively okay for us.

Also, surprisingly the model seems to be working. We've successfully launched a number of very large projects using it. That said, there is one huge caveat, and it's this:

I don't think it's saving us any money.

While the work churned out by the offshore team is reasonably adequate, it's very evident to me that there's a tremendous amount of overhead. I have almost 25 offshore resources reporting to me, logging thousands of hours. I guarantee you were not doing anywhere near that much real *work*. Of course, one example is worth a thousand words.

Recently, we had a fairly small project come in. We had one of the onsite dev leads provide an estimate. It ended up coming in around 4-5 days of effort. When we reached our formal kick-off, it was apparent we'd allocated 2 offshore devs full time for almost two weeks (so roughly 4 times the amount of time) to do the work. We also had hours and hours of time for multiple onshore and offshore managers. If you looked at the totals for hte project, it was absurd. All for four of five days of work. I've seen this now several times. The offshore resources may be a third as expensive, but they seem to take two times as many hours (if not more) to do the same work as our onsite resources. Then you have to factor in the fact that the onsite dev leads are spending 50-60% of their time simply overseeing this work, that you have to allocated hours and hours of offshore manager time, and it and pretty soon you've just blown way past the cost of the doing it onshore.

But the weird things is the company *is* saving money, so it's hard to argue. The problem is that there is no reasonable state prior to the offshoring with which one can compare costs. In fact, prior to the move to offshore the company was using almost 70% contractors, who were *extremely* expensive. Many of them weren't even good, some were atrocious. Even a crappy dev in such cases could cost as much as $210,000 a year. Of course they personally only saw a fraction of that. I managed a team of about 5 developers at one point, all contractors. My team cost over $1 million a year. If these guys had been FTEs, even with benefits the team would have maybe cost $600,000/yr Of course, the offshore stategy--even with it's tremendous inefficiency--is saving money over this insane policy.

Think of it this way, your nutty uncle who thinks he's the reincarnation of Elvis seems quite tame next to Charles Manson. Whether or not our offshoring strategy is saving money over a *rational* approach using great FTE developers is quite a bit more questionable to me.

Next article I'll wrap up with a summary of each of my encounters with offshore and the conclusions I've drawn from all of this.

The Triumph of Bureaucracy

I know I'd promised to finish up my mini-series on offshoring, but I like to be 'agile' with this blog. If a subject comes up in my day-to-day life that seems worthy of blogging I'd rather cover that and return to the more calculated subjects later. In any event, I've had a blog on my backlog about bureaucracy for some time now. Now, that entry is still yet to come, but today I will a share a minor case study in the subject while it still has some immediacy to me. My own version of thedailywtf if you will.

I work for a company that does regular work for cell phone carriers (most of the major ones in the US). Our software is used by millions and millions of people a day and we generally have very rigorous SLA agreements around uptime, etc. There are stiff penalities (I'm talking hundreds of thousands of dollears) if we fail them.

Understandably, this has lead to quite a bit of process around our release process. The typical process is the Pgm for a given project puts together a SiS (short interval schedule) for release of code. A typical high level schedule might look something like:

1. File formal RFC (Request for Change) to internal teams and carrier


2. Create SIS (short interval schedule) detailing timeline and steps of release, go/no go criteria, and latest time at which a rollback can occur


3. Formal review of the SIS with development team, as well as technician, release readiness analyst, and tier 3 support

The release themselves always occur within predetermine carrier maintenance windows, which differ slightly between carriers, but typically fall on one or two days each week, from about 11pm - 3am. The release itself usually looks something like this:

1. Send formal notification to carrier


2. Check that all production monitors are in green


3. Disable monitors


4. Pulling a subset of boxes out of a given VIP (for a subcomponent) and update it with new code.


5. Return the updates boxes to the VIP and remove the other boxes from this same VIP to complete the update.


6. Repeat steps 4-5 for each affected subcomponent


7. QA smoke test


8. Go/no go


9. Send formal notification of completion to carrier

Obviously, this level of rigor is understandable when you're touching something that gets millions upon millions of hits per day. The problem is when it's not appropriate.

Recently, I've been involved in a minor update to a simple testing site we've provided to one of our carriers. It's a legacy app written in PHP and MySQL, whereas our production code mostly runs on .NET and SQLServer. It's consists of about 2 production boxes, with a MySQL instance running on one of them. It hasn't been updated in about 3 years and is provided by this carrier to its handset manufacturers to do a first pass test on new handsets that are being released.

There are a trickle of requests per day (I'm talking like maybe 10 on a busy day) and it has little visibility wtihin the carrier. There are a few contacts at the carrier who use it but thus far they've been pretty amenable to anything we've suggested as they haven't seen an update to this app in over three years. Our current project mainly consisted in adding a few new tests and removing a couple that are no longer used.

We asked if we could release it in the day and they were complete agreeable to this, saying they just needed to notify their contacts at the device manufacturers. Seems like a no brainer, huh.

Except our customer PGM team responded by stating that it's a production box and so it *has* to be released in a nighttime release window. We need a bunch of people to come in from 11pm to 3am. The fact that we could even release it during the day without any impact to users (there are two boxes and only minor additions to some table structures that wouldn't impact the 4-5 end users) even if we *didn't* have the carrier send them an email saying 'Stay out of the system for an hour' wasn't acceptable.

So, instead of having an email sent, having people make some minor updates during the day, and doing what the logical thing, we're going to have all the process and bureaucracy of the type of release we'd have if we were impacting millions of users. Why is that? Because people are incapable of thinking critically, they are rigid. Logic is immaterial to a bureaucracy. At times i feel like I'm stuck in the film "Brazil"

Sam Lowry: Excuse me, Dawson, can you put me through to Mr. Helpmann's office?
Dawson: I'm afraid I can't sir. You have to go through the proper channels.
Sam Lowry: And you can't tell me what the proper channels are, because that's classified information?
Dawson: I'm glad to see the Ministry's continuing its tradition of recruiting the brightest and best, sir.
Sam Lowry: Thank you, Dawson.

This is simply one example, but next time I hear a question of why even simple things are so expensive, I'm goign to have to bite my tongue. I don't even care to argue anymore.

Thought on Offshoring, Pt II

My first experience with offshoring, about which I wrote a bit last time, was fairly typical I suspect: have the expensive architect-level folks come up with a high-level design, then throw it over the fence to cheap code monkeys to implement. This is the dream of the bean counters and like many of the most flawed ideas in software engineering, the concept attempts to draw (unsuccessfully) from other disciplines, in this case manufacturing.

In fact, when my current company started making a concerted push towards offshoring a number of us raised signficant concerns, to which one director said simply "Well, Apple had made it work with the iPod".

"Designed in California, Assembled in China" says the back of the iPod.

Well, if Apple does it, it must be a good idea!

Nevermind the fact that manufacturing is completely different from software engineering. I don't even think the most ardent proponent of waterfall design would argue otherwise. And this is the fundamental flaw with much of the thinking that comes from business-oriented executives: they don't understand how moving "thought work" to 3rd world countries difers from opening plants for the manufacture of textiles (The fact that the director mentioned above was someone who came from an engineering background made the statement even more baffling). The only way I can understand their decision making is if the truly believe software is nothing more than a widget to be manufactured.

About 9 months ago I found myself in charge of development for a fairly large scale migration project. It had already been underway for about six months when I joined the project. The staff was largely comprised of onsite contractors, but recently the decision had been made to start moving to offshore to save money.

A few of us in leadership roles on the technical quickly circled around to figure out what the hell this meant to us all. We had quite a few concerns, most of which centered around the difficulty we expected in communicating with non-native English speakers located in another timezone.

We knew our company had several choices for offshore companies. One of the three companies had locations in the Ukraine and India, the other only in India, and the last in Costa Rica. Given that Costa Rica was only three hours off our timezone, we decided this offered a clear advantage in communication, even if they cost a bit more. We successfully convinced those above us that the marginal additional cost was worth using this company for the project.

In addition to their location, we were also worried about the quality of the resources. Of course, we needed them to be competent programmers, but we also needed people who could communicate clearly via email AND via phone. We told our Director that we wanted to screen every potential resource. There was reticence on the HR end of things to do this but the team volunteered to round robin the screens so we could speak to every individual.

Obviously, flying these people out to do in person interviews was out of the question. Even more than that the sheer number of people we had to screen through was fairly signficant. So, we settled upon a brief 30 minute screen conducted via WebEx. Obviously, we'd never hire full-time employees this way, but in lieu of something better a basic screen where we asked some basic questions, could assess communication (and specifcally English as a second language) skills, and toss them a simple programming exercise was a huge step up from simply taking on whomever the offshore company threw us.

In fact, I found this accelerated screening process to be fairly effective as in most cases those who couldn't speak English at all or who were completely incompetent as programmers were weeded out in the first 15 minutes. And watching another programmer via WebEx while he programmed away in his IDE of choice on his *own* desktop was the truest test of a dev.

Ultimately, I'd say the resources we saw from Costa Rica were just as good as those in the US. There were plenty of incompetent people who the offshoring company swore up and down had years of experience, but then that's no different than my experiences interviewing good ol' Americans in onsite programmers. The simple fact is most professional "programmers" can't program. Nationality has nothing to do with it. Granted, some of the offshore resources had difficulty in communicating and in most cases this actaully resulted in us screening them out. The main thing I think it's important to remember *isn't* that the resources are from offshore. They are not intrisically less talented than Americans. No, the real problem is the genesis of the offshoring idea, the real motivation stems from a devaluation of the resources themselves. The qualitative aspect is forgotten, so the idea of *screening* these people, which almost no one would sanction when considering hiring full-time employees, seems somehow acceptable.

It isn't.

Now staffed, we had to decide if the offshore resources would be a distinct team or augment the onshore staff. Since even our onshore developers weren't completely clear on what we were building, it seemed like it'd be pretty difficult to"design" a solution then hand it off to a self-contained team to implement. There was going to have to be a lot of back and forth between onsite and offshore resources. That combined with the fact that our offshore resources did not have much experience with our code base led to the decision to augment our existing teams with offshore resources, rather than spinning up a siloed team.

As we made out way through the next 6 months of work, sprint by sprint, there were a few definite problems that arose. One of the biggest issues was that it was very difficult to have visibility into what the offshore team members were doing at any one time. Part of this was certainly attributable to the fact that We 3-4 Scrum teams with over 25 total devs. I'm not convinced the problem would not have also occurred with onsite devs. The difference was that if the offshore developers had been in the office, it would have been relatively easy to wander over to their desks, ask them they were working on, and sit them down next to someone else to assist. Doing the equivalent via email and phone calls ended up being quite difficult and if many cases, simply didn't happen.

One of the biggest issues with using the offshore team members effectively was that our implementatoin of Scrum was itself very poor. I triend to make sure we had some type of sprint planning with each of the teams and made every effort to include the offshore resources, but typically the offshore resources would not speak up at all during hte planning sesssions and were not really engaged. Once we'd figured out the work, it was frequently the case that it had been determined by the onsite dev leads and they didn't feel confident in giving it over to the offshore resources without having to do most of hte work themselves since it required too much explanation and back and forth. This often left our offshore resources with either nothing to do or stuck fixing trivial, low priority bugs which didn't really matter that much.

Additionally, even when we had very clear tasks to give to the offshore team members, many of them would quickly get stuck, requiring as much assistance from the onsite leads was it would have taken the leads to do the work themselves. Additionally, they rarely spoke up when they had no work.

Many of the problems in my view, weren't so much *because* of the offshore team members, it was simply that we did not have a good enough handle on our process to overcome the geographical distance. Additionally, while we had screened many of the team members, a good number of them were inherited from other teams that had previously used offshoring, and so language and skill issues were still present undermining hte confidence of the onsite devs in their offshore counterparts.

What was most interesting to me, however, was what happened as we started to 'ramp down' the project. As we neared the launch date for the project I was under immense pressure to roll off as many resources, onsite contractors and offshore developers, as possible and as quickly as possible. At the time, it seemed like the worst of all possible worlds as I was being asked to roll off team members when the project was at its more critical period. I thought it spelled doom for us.

In fact, somewhat countintuitively (though it shouldn't have been as it's the same principal described in the Mythical Man Month, by Fred Brooks) we started to see the opposite. As our onsite program managers were rolled off, one by one, and as we rolled off the those on the offshore team which seemed to be contributing the least, we started picking up considerable momentum.

It was not so much the fact that we were using offshore resources, but rather that, even in spite of our best efforts, we were carrying a lot of dead weight that weighed us down. This dead weight was present both onsite and offshore Towards the end when we'd rolled off all but hte very best of the offshore resources, we only had 3-4 offshore devs.

In fact, when we'd whittled our offshore resoruces down to about 3-4 from the original 15 we were left with very capable programmers. In fact, the best of them were the equal of any of our onsite devs. They thought critically, communicated status regularly, and took proactive action when necessary.

And now that the program managers who were managing the teams had been gone and they were put in the hands of myself and another technical person and we gave the offshore devs clear direction. Soon, we started to gain a good deal of momentum. And what had seemed impossible to do with 30 people, seemed now achievable with our team of 10.

And that, to me, is the biggest problem with offshoring. It many ways it originates from a mindset that denigrates the value of the individual. Often you'll hear it in the context of, we'll replace 10 full-time developers onshore with 30 offshore developers. But the *only* way it can be successful is if the same values you'd apply to your onshore developers are applied also to the offshore resources.

Like everything it's all about the people.

I guess this is part 2 of 4. Next time I'll write about the implementation of offshore with my current team, how it is working and NOT working. and in the final blog entry, I'll summarize my thoughts on where offshoring is useful, my own thoughts on how to help make it successful, and conclude.

Thoughts on Offshoring, Pt I

My first experience with offshoring came about 4 or 5 years ago. My company at the time had hired developers in Romania to rewrite our in-house log grinding software. I hadn't really been involved in any of it, but I was forwarded an email from our Director of Technology. The gist of the email was that the code made him weep. It had enough gems to keep http://www.thedailywtf.com/ going for a year.

One bit of code to calculate the current date that ran something like 80 or 90 lines of Perl. Apparently, this:

($DAY, $MONTH, $YEAR) = (localtime)[3,4,5];

was just too easy for our Romanian friends. The rest of the code was similarly awful. This set the tone for my thoughts about offshore, which could be summarized in a single word:
No

Of course, with however much vehemence I've argued against the offshoring trend, I'm usually not in a position to make the final decision. And the bean counters at the top always love it. So, I've had many subsequent encounters with it over the past several years. Some of it has confirmed what I believed then, but I've also had a bit of a reversal on some of my opinions, namely I now feel there is a (limited) place for it. I kinda feel about it how I feel about the 'goto' statement. Yeah, really fundamentally, I think it's a poor choice, but sometimes it's the best option. You really need to know *why* you're doing it, though.

The largest chunk of my experience has been over the past 8-9 months. I've worked extensively with two different offshoring companies, located in two different countries, and with very different implementation strategies. Both of them have had significant problems, but these experiences are also what have led to my somewhat more nuanced view of the subject.

There are some great developers offshore. Let's get that out of the way first. The best of the best overseas are just as good as the best of the best in the U.S. Now, I didn't originally feel that way. I used to think that the mindset of those trained overseas just lacked the creativity and incisiveness of those trained here in the US or Europe. But I really no longer think that's the case. The problem of course is this. It's immensely difficult to recruit and hire *great* programmers even when you're interviewing and working wtih them face to face. Compound that with the fact they are located in another time zone and it's near impossible.

Of course, you're also going through a third party to hire these guys. Their companies will always tell you how great every one of them is, but they are looking to make a profit and it's unlikely their criteria for a good developer is anything similar to yours. Hell, I don't trust most of the people within my own company to make intelligent hiring decisions when it comes to developers, so it's pretty much a lost cause when trying to bring on offshore resources. But from experience the *only* way you have any hope to make offshoring work is to have the exact same (if not higher) criteria for every one of your offshore resources that you'd have for your onsite devs. Really, given the communication barriers, the time zone differences, and so on they need to be *better* than the guys you'd have onshore. You *must* insist on interviewing every one of them. Yeah, it takes a lot of time, but to do otherwise will guarantee that you're dragging around a bunch of dead weight. That a huge problem onshore *or* offshore. Of course, the problem with this is that interviewing and having stringent criteria for your devs, flies in the face of the primary motivation for using offshore.

Let's not be coy. The *only* reason any company ever chooses to use offshore is to save money. That's understandable to an extent. The problem is the people responsible for the decision to use offshore are almost invariably those from a business background with very little technical knowledge. To them it's as simple as replace X programmers in the US costing Y dollars with X programmers in India costing Y/2 dollars. The idea that one *great* programmer will be ten times as productive as a mediocre programmer is completely incomprehensible to them. This is of course a problem with any large company where the senior leadership does not have strong technical backgrounds. They make decisions that simply don't make sense (I'll leave further discussion of this to another blog).

Of course, that's why it's so difficult to convince the people at the top that offshoring is not the clear win it seems to be. They just don't understand how much difference one *great* programmer can make. Making them understand that 3-4 great programmers who are working as a cohesive team can equal or exceed the output of 40 mediocre programmers in India is not something they can really wrap their heads around. I've tried to explain it many times, but (most) business people simply can't see past that bottom line on an Excel sheet.

I guess that'll wrap things up for now. Next blog I'll try to get into more details, talk about the two main strategies I've seen employed for offshoring and the relative advantages/disadvantages of each, as well what I feel are the necessary criteria to make offshoring work, and where it may actually be worthwhile.

The Man in the Mirror

*pause*
*deep breath*
My name is Zac and I'm a manager.

Sigh.

Way back when--about two years ago--being a dev manager seemed like a ticket to easy street. To be honest, I don't know that I was completely wrong.

Back then I thought anyone with 'manager' in his title was either ineffectual, dead weight or, worse, someone who got in the way of really getting the work done by bothering me for constant (and pointless) status updates. The latter was primarily the realm of project (or program, if you prefer) managers, for whom I had a particular distaste.

In contrast, my dev manager didn't seem to do much of anything. He'd send out emails about 'flow' or his random, half-witted musings. He didn't participate in any of my daily work, he wasn't responsible for any particular project or any real work other than going to meetings and if shit hit the fan, finding someone to blame.

The closest analogy I can of to how I felt at the time was like a man who's fallen overboard in the middle of the sea, treading water in the middle of the Atlantic, while wave after wave of work crashed down on my head, pushing me further down in the water each time, until finally I no longer had the strength to come back up for air. Being a dev manager seemed like an awesome gig compared to that.

Let me get this straight. I don't have any real responsiblities, I send out random dumb ass emails, and I go to a bunch of meetings. Oh, and I get paid a lot more money. Where do I sign up?

When I arrived at my current job, it seemed like I'd arrived in the promised land. I pretty quickly started having some personality conflicts with my manager (I felt he was micromanaging me), but ultimately I settled into my role fairly well. I've moved around a few times within the company now, managing various projects and groups, and at times I've felt as thought I contributed something worthwhile. Much of the time, however, feel like overpaid dead weight. I am part of the problem. I am no longer a doer, I am *sigh* a manager.

Of course, that was what I wanted wasn't it? And, on the whole, my own self-flagellation not withstanding, I'm still a hell of a lot happier than I was than I was at my last job.

Many would argue I can still be thoroughly technical and engaged at a low level and that it's merely laziness or incompetence on my part that prevents this. Or at least, my own internal voice whispers that from time to time. The fact of hte matter is, though, that I directly manage at least 7 development leads and a total of 30+ developers including offshore resources. It's really hard to go too deep into any one project or code change. Now and again, I involve myself a bit more deeply, but hell, half my days are spent in stupid meetings or updating "resource loadsheets" to appease my manager. There is no way I have the time to look at code much if I want to get my other work done.

As a technical lead at my former job, I attempted this, acting partially as architect, part as direct contributor, and partly as manager and in general it always meant that my managerial duties (which is where I should have been directing most of my energy) were done poorly.

I'm not directly responsible for much of anything anymore. The expecations placed on me are, in some sense, pretty minimal. That's a blessing on one hand. On the other hand, I still am a dev at heart and I have moments of self hatred for being in this position. But again, it's precisely the position I aspired to be in.

At the heart of this is a question about the value proposition of any individual as he moves up the corporate ladder. Or at least this is the case for technical people. It seems that the higher one moves, the more money he makes and the more "official" responsibility he has, but the less that person really does in terms of getting day-to-day matters taken care of.

To be fair to myself, however, I *do* contribute real value. I push the other managers to look at why they have so many meetings, I continually question whether offshoring really is saving the company any money. But nothing that I do gets those lines of code written. And that's the thing I struggle with. I suppose there is need for people like me in larger organizations such as the one I work within.

But I think there could stand to be far fewer of us managers at my company than there are. Just as I did when dev, I still like to think I contribute much more value than the 4 or 5 layers above me that seem to do nothing. But then again, I suspect some (all?) of the devs beneath me really question what I do and what value I'm contributing.

There is no easy answer to these questions. I don't find what I do terribly fulfilling, but I make twice the money I made as a dev and my life is relatively stress free. I work maybe 45 hours a week on average compared to my old job where 60 hours was a "light" week. But part of me longs to code again.

I think the only solution is to be part of a small company, a focused start up, where there is a relatively flat hierarchy, where the doers and the managers are the same people, where the people at the top are as technical as the people doing the actual work, and a director is never afraid to start coding away if necessary. The problem is those types of places usually are from most accounts high stress and low pay. And I've had my fill of that.

So, I guess, a manager I stay.

Buying a new computer

I don't buy new computers very often. Once about every 2-3 years seems to be my current pattern and since just about two years have passed, I suppose I was due. So, I bought a new laptop.

Now mind you, there was nothing fundamentally wrong with my current laptop. It's just BIG. I'd noticed a few co-workers carrying around spiffy little netbooks and now that I walk to and from work each day, my 7lb laptop starts to be a bit tiresome to carry home each day. I bought it about two years ago as a 'desktop replacement'. At the time my only computer was a huge Dell XPS desktop I'd bought in about 2005 to play games. It seriously is like 3 feet tall and weighs about 30 lbs, so the laptop seemed tiny.

The biggest motivation for getting the laptop was to checkout the code I'd been working on and get it running somewhere before I left my last job. Not with the intention of doing anything nefarious, but rather I find I can't remember jack shit unless I have example code where I did it before. Most of my coding is little more than copy-pasting, I guess. I'd probably struggle to put together "Hello, world!" in Java without some code lying around.

So, I started with the idea of getting a little 10'' netbook to carry around. A few people I know even have IDEs install and seem to be able to use them. But once I started looking at the tiny-ass screen I realized my vision was nowhere near good enough for that to work for any appreciable length of time. After reading a few reviews, I settled on the HP dv2. At 12.1 inches a little shy of 4 lbs it seemed portable enough, but could be used as my primary machine.

For the money (about $550 before taxes), I don't think you can beat it. 4GB ram, 260 GB harddrive, Athlon Neo, discrete video card, 12.1 WXGA.

But then my doubts started to gnaw at me. It didn't matter that the dv2 seemed to run Vista just fine (most netbooks can't). Even Eclipse booted up pretty quickly. Still, I started to obsess that the thing was just a little too big to carry around. I needed somethign smaller. The battery life wasn't quiet long enough at 3.5 hours. I need at least 6 hours. Oh, and it ran kinda hot. I don't want a hot computer! I also read comments about how the Neo, not being a multi-core processor, would bog down with multiple apps. I wasn't sure I noticed that problem myself, but I started to think maybe I did.

So, I took the damn thing back and went to lenovo.com to configure some crazy ass 12.1 inch x200 on Lenovo for over twice the money. It has a 2.4 GHz Core 2 Duo, 160 GB SSD HD, 6+ hour battery, and is marginally smaller.

Will I really see any benefit? I doubt it. In fact, the Lenovo won't be able to play games since it doesn't have a discrete graphics card. Some people have gambling addictions or alcohol, I have this OCD thing where I have to have the best available computer possible. Nevermind the damn thing will be outdated within a week of its arrival.

Thus far, I've tried to keep this blog fairly specific to the topic of software development and this is really a bit off topic. But thinking about my goofy need to have "the best", I can't but help draw some parallels to software development. Often we can get something that pretty much does everything we need with a fairly low cost, but then we start imagining needs
"Maybe the customer will change his mind and need this extra feature."
"Oh, we need to make sure that the screen loads in 0.2s rather than 0.3s"
"Oh, what if we need to store this extra data in the table, we shoudl design it so it's completely extensible and easy to update"

And quickly the budget and timeline have exploded, when in all liklihood the customer wouldn't have really noticed the difference and will never use the extra features that required so much additional effort. Of course, solving that problem is one of the mandates of things like Scrum and XP, but even when we use them I think engineers tend, by their nature, to gold plate things. Hell, the example of my laptop purchase shows how much even I can be driven by "emotion" rather than real logic.

I guess I should start saving now for my next computer. Two years isn't a very long time.