Just Get Away From Me

One of my pet peeves reared its ugly head again today. I had to help some other developer on the team figure out why his dev environment wasn't working (again). I sat at his machine, did my normal routine, and things just magically worked. At this point I was ready to head out, since everything was fixed. But, he just had to stop me and swear up and down that I hadn't done anything differently than the way he had been doing it. I just shrugged and said, "Well, you're all good now..." But, no, he had to continue with his little rant about how he had been doing that all along.

You asked for my help, I helped you. We're done. I don't care about your theory that all of reality or computing in general is conspiring to make you look like an idiot in my eyes. I already consider you an idiot. And don't mistake it for some friendly, "Now, how do you suppose that happened?" exchange between friends. We're not buddies, we're not pals, and we're not friends. If I liked you and/or you were competent it may be a different story. You have neither of those luxuries. Communicating with you in any way is an effort that makes my skin crawl and my nuts ache, let's not tax poor Greg any more than is necessary. Please drive through.

Share and Share Alike

My group has a machine that is apparently crashing every few days or so. Someone has to keep opening up a help ticket with our internal IT department to get them to "fix" the machine--this, more than likely, consists of them walking into the server room and turning the machine back on. Since we don't actually use the machine any more, no one has entered a help ticket for the past week or two.

I know there are other groups within the company that probably need additional hardware badly enough that they would diagnose the problem and gladly take possession of the machine. Unfortunately, there's no budget for them to buy their own machines and, if my group gives up the machine, we'll likely be in the same position as they are in the near future--in need of hardware but unable to get through the red tape to acquire it. Of course we wouldn't be able to count on someone else's generosity for the same reason we ourselves are not generous. What a sad situation.

More of the Missing Manager

Just to update people, my manager has missed the first two daily meetings of the iteration. It's a good thing we're not trying to release this thing any time soon...

You'll Work on Crap, and Like It

So I find more and more that if you are a capable developer and can think your way through normal problems, your reward is often that you get the crappiest assignments. Very rarely is there ever anything interesting and/or fun for me to work on at my job. In the few instances that there is something meeting this description it is usually given to someone less capable because they can't seem to handle some difficult task we have to do during the iteration. Who gets the tasks that no one knows what to do with? Why, that'd be me.

I think this is bad from a personal standpoint of course, but I also think it hurts the product, the company, and the other developers over the long run.

It hurts the product because if you regularly cannot give a majority of assignments to developers because it is "too hard" for them then you obviously have inferior developers on your team. I know there are exceptions to this--some people are domain experts or just much better at different parts of the technology or maybe the developers are still being trained on the product. Hopefully you're not having to train them on the technology--that means you're hiring / retaining the wrong people or that you pay so little you can't attract good people.

It hurts the company in multiple ways. Not only are you putting out a crappier product but you're either boring or angering your competent developers. No one wants to work with people that can't do their job. Plus, since they're getting the crap detail 90% of the time, the good people are typically not getting to work on anything exciting. Let's face it, developers like to work on cool things (almost as much as they like to refactor code). That brings us to our next point of how it hurts the developers (and the company at the same time).

It hurts developers because they're unhappy and unfulfilled (poor bastards). If I know that my tasks every iteration are 1) do the programmatic grunt work these other morons can't figure out and 2) "mentor" the morons (also known as watching a group of retards try to hump a doorknob) so they can work on something easier/more fun (but get paid close to the same amount) then I'm not going to be a happy camper. That makes your good developers a little more likely to quit. We established that you can't hire or retain the proper people in the first point and therefore are unlikely to be able to replace them with another good developer.

Now you begin a long downward spiral of technical incompetency and non-innovation in a long, boring maintenance cycle of a crappy product--at least until you have your next IT revolution (happens every 6 years or so, I think). If you're making money it means you can buy smaller, more nimble companies that are working on cool stuff and suck the life out of them too.

Your Solution is Part of the Problem

My group is at the end of an iteration. We are supposedly done with our work for this iteration. The code is frozen. No more changes. But, in today's stand up meeting, the tech lead was very insistent that we could sneak a few more changes into the code. The items he wants to put in are very minor pieces of functionality that we didn't quite get to in the time allotted. Nothing will be broken without these additional changes, it's just not 100% complete.

In a shocking moment of good judgment, our manager actually expressed his opinion that it was too late, the iteration is over, long live the next iteration. So now we're going to get to witness the classic battle of wills between the manager and the tech lead. This is the first instance I've seen of a real disagreement between the two of them. It should prove very interesting and educational. I say educational because, although I think my team is just plain rotten at the top, this will be a great opportunity to see what kind of commitment the manager has to the agile process in addition to whether or not his tiny tech ignorant boat can weather the storm of the superior product knowledge. Will he be beaten into submission for fear of appearing stupid / confrontational or will he stand his ground? It's so exciting.

Incidentally, this leads me to believe that the attitude of the tech lead in combination with the looming issue of story card acceptance reports are acting as a substantial barrier for my group getting jiggy with agile. It is also the first direct evidence I've had that the tech lead is a much bigger part of the problem than I had initially believed.

Update: And the tech lead wins by a nose!!! We're adding in just one tiny little wafer thin feature. You know, only because it's so small and technically the iteration isn't really really over. It's more of a slush code freeze than a rock hard code freeze.

Not That That's a Bad Thing

If you ask many of the people I work with what it is they like about our little company, a sizable chunk of them will say, "the people." In general, we have a pretty competent and cool bunch of people here--besides half of the ones I work with directly. It is a pleasure to work with intelligent, reasonable people with a similar sense of humor to your own. As an employee, I can think of nothing better than having co-workers that I consider friends.

From a company standpoint, that is probably trouble. It means that your employees may be more loyal to each other than they are to you. They probably don't give a shit about your long term plans and generally don't want to be part of any pep rally that involves drinking Kool-aid (a very overused metaphor that isn't entirely accurate).

The big problem for a company isn't that you don't have rabid supporters, it's that when one of the "cool" people leave they are more likely to take the people they have enjoyed working with with them. This continues as each exiting member suddenly looks around one day to find that they don't particularly like many of their co-workers (the replacements). And if you believe that your people are your greatest asset (as some companies purport to do) and if you train your new hires through some form of shared tribal knowledge passed down from worker to worker, then it only gets worse from here. Suck it and smile, sweetheart--there's trouble on the horizon.

More Team Problems Identified

I was talking with a co-worker this morning and we hit on some of the many problems with my team.

• Non-Technical Dev Manager - This causes unnecessary strain on our technical resources because we have to stop and explain things to him. I don't think a "manager" is a generic person that can be grafted on top of any problem and just begin making things happen. I believe you should actually understand what it is that you're managing in order to do an effective job.
• Over-Insulation of Developers - On my team, it is again the role of the tech lead to interact with other teams and go to all generic meetings. The idea is that by isolating this overhead on one person, everyone else's velocity immediately goes up. The problem is, you've identified your most capable technical person and decided to piss away his expertise in meetings rather than building software (you know--the way you make your money). Couple that with the fact that programmers usually want to write code (not attend meetings) and you have an unhappy developer on your hands. In one fell swoop you've made your most capable person a non-contributing flight risk. Another interesting side effect of this is that, if the information isn't disseminated (which it isn't) everyone else on the team feels like they're out of the loop. Everyone burns their velocity trying to figure out what the fuck is going on. You get nice things like, "Don't you remember, we talked about that in that meeting with--oh, that's right. You weren't in that meeting."
• Too Much Dead Wood - I've already mentioned the problem with incompetent people. I'll use this opportunity to add something that another manager told me. "The problem with dead wood is not just that it is dead. It's that whatever killed it can spread and kill off the healthy wood." I assume he was still talking about programmers, but you never know. Anyhow, those turdlet developers on your team suck the time and the life out of your good developers. Now, other teams are apparently being more successful at either eliminating their duds or bringing them up to speed. I'm not sure where the failing is on my team. Perhaps it's the fact that we have a 1:1 ratio of good to bad developer. Maybe it's me. Who could say.

Well, that's enough of a rant for now. One last point, the real knee slapper in all of this, is that upper management views my team as very successful. But, it's populated with the unhappiest developers churning out the crappiest code. The other teams apparently are beginning to feel like the process is working. Luckily, upper management has suggested my manager have a talk with the other guys and get them to be more like us.

Stepping Up

As I've mentioned before, my project inherited some sub-par developers a few months ago. Well, recently, one of them decided that we were going too slowly with him. He wanted more responsibility, more freedom, etc. You know--to be a real programmer. I, of course, am opposed to this until he demonstrates his ability to "do no harm" to the code base and the ability to think and act for himself. How should he demonstrate this? Fuck him. That's his problem.

Well, this iteration we gave him a couple of tasks. One was to add some controls and information to an existing web page. The other was coordinate with a member of another team about some issue. Halfway through the iteration, I find out that he's "blocked" on adding the controls. We have a brief team meeting and discover that his issue is that he wants to have a philosophical debate about whether or not the controls are needed. After a few minutes we pound it into his head that they're needed but that it is irrelevant as its not his call and it's a simple task--just do your fucking job, moron. Well, then it kind of comes out that he doesn't know how to do the task. So, it sounds to me like his whole debate was a cover for the fact that he doesn't know how to do something. Fair enough. However, I just got through doing the exact same type of work last iteration. He could have copied the damn code straight out of my stuff.

His next issue was that the member from the other team wasn't available. So, we picked up the phone and called the guy. He answers and we start trying to go through the questions our noob was supposed to be asking him. Well, it turns out that the noob doesn't have his questions ready. So, his second blocked issue is also due to him not doing his goddamn job.

That's a great way to get more responsibility, by the way--fuck up the easy stuff I give you then try to hide it. Genius.

We're Off Track

Well, the manager finally showed up to the daily meeting today only to discover that most of the tasks we're working on are blocked and possibly at risk for delivery. Furthermore, the senior person on the team is now a bottleneck and the potential blockage on most of the tasks. This happened because that person was handling some of the management duties and cross team interaction. As the manager was MIA for several days, that burden increased meaning they had less time to work on "real" work. Also, typically, this person is usually the catch-all for any set of tasks. You don't know who has time to do task A? Throw it on the senior member of the team. The overdelegation by the manager (or downright incompetence if I'm being honest) coupled with the underdelegation of the senior member makes for a nasty situation.

I'm sure at some point everyone will be asked to work a little harder and come together as a team to help get us back on track. I wouldn't mind doing such a thing if it was for a good reason (not just someone failing to do their job), but me busting my ass to cover someone else's leaves a bad taste in my mouth.

Why Can't People Follow Instructions / Think

We upgraded a library yesterday, so it requires each developer on the team to follow a couple of steps to get their environment up to date with the latest changes. Inevitably two of the people I would fire (if it were up to me) send emails that the changes don't work for them. In addition, the body of the email is basically, "It didn't work on my box." No information about how they tried hard to solve the problem themselves OR any useful information like a log snippet.

I decided that I didn't feel like helping them any time soon. Someone else stepped in and said, "You need to do get the latest from source control." Then the person sends an email saying that fixed it, followed by another saying, "Oh wait. No it didn't." Then another saying they did a "full update" and that that finally did fix it. Why, oh why, can't people a) use some common sense and debug a problem themselves, b) provide adequate information to get the help that they "need", or c) actually follow the instructions for the fucking solution. The whole email exchange took 11 whole minutes. After the first email, who doesn't spend more than 11 minutes trying to determine if they're being an idiot (except of course an idiot).

Day Three Without a Manager

For the third day in a row, my manager did not attend the morning meeting. He's apparently off with his other team doing some planning. I think this demonstrates either an unwillingness or an inability to juggle the two projects simultaneously--he has the ability to move at least our meeting to a more convenient time.

How Very High Tech

We have a real rocket surgeon here that prints out UI screenshots on a color printer. He then tapes the printout to his wall, for quick reference I guess. Unfortunately, he doesn't have a scanner. This would allow him to scan the printout into the computer so he could store it electronically...Remember, thinking outside of the box is only good if you're not a dumbass. Otherwise, the box is there to force you to think in a way that will keep me from killing you.

More Management MIA

The manager of my team has missed the last two daily meetings. Luckily for him, this team pretty much runs itself. Unfortunately for us, I'm sure he's getting some measure of credit for the team being "successful."

Maybe Another Computer?

So I go to help out a member of another team with some problem a couple of weeks ago. While I'm helping him out, I can't help but notice that he has two desktop computers and two laptops in his office. I don't have a laptop of course but that doesn't really bother me unless I have to sit through too many meetings. Then it would prove useful to get some work done while listening to people ramble. What struck me as funny is that when I commented on it he just said, "Yeah, but that laptop is a couple of years old." Well, fuck you. I'd take a piece of shit laptop just for the fact that I could drag it to a meeting and browse the web or actually have a computer to do a presentation on if I needed it (not that I want to give presentations). Maybe if you had a couple of more laptops you would have been able to debug this problem your own damn self. Ass.

Architects

For the past couple of months, the developers around here have been pretty anti-architect. It's not that we don't value what the role should be, it's just that the people in that position don't seem to do anything. As near as I can tell, they play around in PowerPoint all day and go to meetings. They're there to make upper management feel better by showing them that we have "experts" on staff. They don't actually solve any architectural problems. In the rare instances that they interact with developers they seem to just nod and say things like, "Ah, yes. SQL. Interesting. You could do it that way, I suppose. Yes." When they're not making asses of themselves in person they're writing articles about Egyptian magicians not knowing how to design software or some such shit. You know, things that are supposed to make me go, "Hmm."

Well, we filled out a survey for management as to how effective we thought the architects were in their role. The answers must have gotten someone's attention because for the first time ever, I've seen architects attending the daily status meetings as well as the iteration planning meeting. They still don't fucking contribute anything to the architecture of the product, but now at least they're present to try and sidetrack the meeting in a vain attempt to demonstrate some measure of technical competency. Is this an attempt to impress me or intimidate me? Because frankly I just find the whole thing sad. It can't be a good feeling coming to work every day scared that you're going to be exposed for being the fraud you are.

The Downside of T-Shirts

Don't get me wrong. I love to get free stuff, especially from my company. Unfortunately, whenever we give away a t-shirt, everyone gets one and then they all wear them to work. So, if I don't want to look like one of the moron triplets, I either have to never wear my freebie shirt or find another tech worker and trade them for a shirt from their company (because presumably they've got the same problem). Maybe someone should write a website to coordinate this--SwagSwap?

Consistent Technical Interviews

I guess in any organization of non-trivial size, it's hard for different groups to communicate any information at all. Also, even in the instances that information is effectively communicated it may very well be ignored. There's a lot of tribalism at large companies, especially those built through acquisition.

A recent incident of this came when a group close to mine interviewed people for a technical position. One of the candidates was underqualified so he didn't get the job. The surprising thing is that he then interviewed for a higher technical position with another group. In theory they would have found out that he had already interviewed here and gotten input from the group that had done the interview. In practice, they interviewed him and went ahead and hired him as an architect--even though he wasn't qualified to be a developer.

We've already got a company of angry developers and MIA architects that are grossly underqualified to do their job. A brilliant strategist would realize this and hire not just another inane architect, but one that the developers have dealt with directly in the past and for which they have no respect. This saves time. I don't have to go through a honeymoon period where I pretend they know how to do their job only to discover (after many weeks) that the most complicated thing they've ever designed is a PowerPoint presentation. I can start resenting them immediately. Think of the cost savings.