Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Problems with blog

You may have notice that my blog was completely unreadable recently and is still hasn't fully recovered. For the past 2+ years I've used blogger to host my blog and Google sites to host little things like CSS files and logos. Well I got a warning a while back that Google sites was going away and being replaced.

Foolishly I put off doing something about it and am now dealing with the consequences. I'll be working hard over the holidays to get things back up and running, but in the mean time at least it's readable. Because the browser caches files it's possible that this could have been a problem for some time before I realized it, but I'm hoping you haven't been inconvenienced for too long.

Profuse Apologies.

Developer vs Manager Responsibilities

Have you ever had a manager disregard your opinion? Make a technical decision contrary what you recommended? Ever get frustrated by it? Well don't. It comes down to a difference in developer and manager responsibilities.


Your Responsibility as a Developer

You might be saying to yourself "My responsibility? Duh! Get out the code, do my job!", well, yes and no. In addition to your job, you have a responsibility to your manager to provide solid information that they can use as a basis for their decisions. You're in the trenches; you know better than anybody what they need to know. You're responsible for bringing information and situations to their attention for them to act on.

You're the data input. Occasionally, if something is important enough, it's your responsibility to strongly push an point that you think is critical. However, once your boss has made it clear that they've made their decision, it's your job to follow their direction and move on.

Don't like it? Become a manager! Give up the joys of code for the monotony of meeting after endless meeting as your hard won technical experience melts away (the sad truth for most, but not all, who make the transition).

Their Responsibility as a Manager

You may not be aware of this but managers have a lot on their plate and even they don't get to call all the shots. They're fighting office politics (so that you don't have to). They're taking the information that you provide and arguing for more time or resources or what ever else it is the team needs. They're using the information you you gave them to make decisions about what the team's tools, strategy, staffing and priorities should be and often they're presenting that information to their boss for approval.

Here's the thing: If your boss makes bad decisions it's on them. It's their neck on the line. Of course it might blow back on you too, but in an accountable organization it's still on them. And given the internal politics of most companies your manager also has to tread carefully; they can't push hard for everything. They have to choose their battles... and so do you.

Choosing your battles

I know you've heard the saying "The squeaky wheel gets the oil", but a wheel that squeaks too often can become part of the background noise and be ignored completely. The reality is that some arguments can't be won; more importantly some arguments shouldn't be won. I know that in the vulcanesque mind of the programmer arguments are weighed based on their logic and merits only. Unfortunately the real world works differently.

Social Capital

There are often many valid ways to view a situations based on conflicting priorities and there can be many conflicting, yet compelling arguments depending on the view you hold. In these situations you gain social capital by yielding to others on topics that you consider less critical to the team and you spend social capital when you push your view-point forward ardently (whether you win or loose). My advice? Yield whenever you can and push forward only when you think it's really important (and only if there a chance of winning).

I know this sounds a lot like playing office politics and to some extent it is. That's not what I'm about though; trust me, I despise office politics but the sad reality is that if you're constantly the source of conflict, constantly the one with the only right answer, constantly rocking the boat then you will quickly find your opinions shunned and ignored. Even if you're right.

Going the distance

Team structure, rules, and the status quo evolve over time; "the way things are" can't be changed over night. If you really want to have an impact then you have to bide your time and work towards what you think is good for the team over the long haul. Often you'll find that your manager is in agreement with you and already working the same long term strategy with their boss and piers. Over time you will earn respect, trust, and social capital and, if you wait patiently, you'll be ready when opportunities present themselves to share your well thought out views and to influence things for the good of the team.

What are your thoughts?

Good design vs Bad design

Good design is a pleasant surprise. It makes you wonder: why wasn't it always like that. Take the following picture for example. Even with the context removed the functionality is obvious. I love this fan.

Bad design isn't always obvious until you put something to use. The chair below is in a I.T. recruiters office. It's narrow and the protruding chair arm easily snags men's pants and is just high enough to rip them thoroughly. At the time I was extremely embarrassed that I ripped my pants and a little mad at myself, but out of curiosity I asked the recruiter if anyone else had had it happen to them. He confided in me that several people had including himself!

I'd be willing to bet that, like me, most people who ripped their pants felt it was their fault. It's funny that victims of bad design seem to blame themselves, while the beneficiaries of good design take it for granted.

Last time I went back the chairs were still there; just something to ponder.