Introduction

This is the first entry on my new personal blog. At some point I’ll move over my old personal blog entries into this system.

I like using a personal blog, in addition to my business blog, because there are some statements I don’t really want to be associated as Official Words From Wilcox Development Solutions. Especially articles like this one (all about self doubt).

It does feel good to be writing for fun again. I’ve been doing a lot of writing lately, but professionally, not casually. Casually I haven’t written it years.

Ok, now on to my rant

Last sprint I had 2 tickets kicked back to me in development. 2 tickets out of 10. That’s a 20% reject rate, which is borderline unexceptable.

Yes, I completed double the story points I normally do in a sprint, but it shouldn’t matter. I need to get much better at coding quickly.

I thought I had gotten better: a particular side client of mine tends to want things quick and fast. Two weeks later he’ll also want them flexible. So I thought I had gotten better with this client: I tried to make things both flexible and fast using whatever trick in the book I could use. (cog actually being a trick I could apply on the project, with decent success).

But then it comes back to 20% reject rate this sprint.

So I’ve encounter problems like this before. The advice I was given at the time went something like:

Rather, when things are not going well (whether it is
programming, driving, or playing basketball) the key is to
recognize the problem and take extra precautions until it
passes.

For driving, you have to be willing to slow down and turn
off the radio to minimize distractions.

For playing basketball, you have to be will to pass more
than shoot and not try to blow by the guy you can usually
blow by.

For programming, you have to be willing to stop plunging
blindly ahead and ask for feedback/direction.

So there’s a catch here: There’s no way to be blameless. The following are actual scenarios I’ve run across when coding. Seriously, I’m not making any of this up.

• You try to think about what the client would want, and implement things that “they’ll ask for anyway”. Result? You get yelled at for giving the client something they didn’t (explicitly) ask for, and they get mad for you over complicating a project. Or worse, you get people saying: “add ‘making the assumption that you can read minds’ to the list of problems you’ve had lately.”

• You hitch your thing on the simplest thing possible, or don’t try to put yourself in the clients shoes/empathizing with them. Result? You get yelled at for giving them the wrong solution, a half implemented one, one that’s not pretty so it sucks, or one that has crappy code quality.

• You try to make something pretty and you get yelled at because you’re a programmer, not a designer, and you suck at UI design, don’t waste time on this because obviously you don’t know that the proper margin should be 8 pixels between separate capsule-style toolbar controls per the Mac OS X HIGs, duh.

• You don’t make something pretty and you get yelled at because it sucks because it looks horrible (and this is why you can’t design UIs), and/or get the bug thrown back in your face because “it doesn’t work” because the UI has a glitch.

• You are careful about your tickets and try to get other’s input first, and you get yelled at for not going fast enough.

• You try to go faster, to get more tickets done in less time, and you get yelled at to take extra time until the problem (of a lack of quality) magically goes away, as quoted above.

I think my reputation (or profession) requires me to shoot for perfection, and to beat myself up and try to get better when I’m not perfect.

I give my clients detailed (2-13 pages, depending on the number of work sessions and timeframe) invoices for just this reason: they are welcome to look over everything I’ve done and if it’s not acceptable they don’t have to pay for those hours.

And maybe that’s it: realizing that no matter how hard you try sometimes, it won’t be right. Which sucks, because of the shooting for perfection thing.

So the thing about the basketball analogy up at the top: that’s all about confidence. Let the person re-prove to themselves that they can make 6 foot jumpers and then they can back up further and further until they’re hitting 3 pointers like normal.

Granted, this approach helped me to an extent this last sprint: instead of starting on big story point items I started with small tasks that I knew I could finish off in an afternoon, even with a bit of distraction. I avoided tasks that would take me most of a day’s worth of concentrated effort because I knew I wasn’t getting that out of myself (or the environment. I’m not going to 100% blame myself here… the workplace wasn’t very conductive to work for a few days. Conductive to gossip and project complaining, yes. Work? No.).

But then there’s the other thing: if various clients throw 5 fastballs at me, can I get better at catching (more, or all) of them in a timely manner? (Yes, this happened relatively recently also).

I need to get much better at coding quickly, while also at a high level of quality (low percentage of kickbacks).

It could be that some people would call what I need, or what I’m after, deliberate practice. (The people over at the Business Insight Blog have excellent set links related to this topic. Really, it’s amazingly comprehensive.). My guess is that if you want to make insanly pressured 3 point shots that you have to practice, not the 6 foot jumpshots, but back at the 3 point line.

But I’m not really sure. Maybe in actual basketball you practice insane 6 footers and work your way back to the 3 point line. But I think at this point the analogy for software engineering breaks down anyway.

I just know that I want to have high quality code, quickly delivered. And boy do I need to get better at this!

It could be, of course, that this is helped or solved by two things I’m pretty poor at:

• Attention to detail
• Making assumptions that a thing can only ever work one way, or not seeking enough expert feedback when implementing something. (Yes, this might be caused by the first item).

I’ve been ragged on before about picking complicated solutions to problems, which I’d like to think I’ve worked out of my system, mostly. (My coworkers might disagree after hearing some issues I bring up at story point sessions). But I try, really I do.

4 out of 6 of the above points might be solved by taking time to stop, consult, re-clarify and then move forward. I do pretty much suck at this. This may be some of the problem: going off on a tangent to have it be the wrong way, then having to redo the work.

I was going to write about unclear specifications maybe not really being the programmers fault, but it is. Well, ok, mostly. Specifications that, after 2 weeks of drilling down on, and you’re still learning stuff (on the day it has to ship), yeah that might not actually be the programmers fault. I’m going to take some pride here and say that it’s actually not the programmer’s fault. (Yes, this situation happened to me too).

It could also be I’m deceiving myself and I’m not as much of a perfectionist as I’d like to think I am. That it bugs me not because I really care about getting things right, but because I’d rather not get yelled at. Which is an important distinction. Which could be, but judging by the number of times I’ve screamed through a muted microphone to someone on the other end of a Skype chat because they’re DOING IT WRONG does seem to imply the former.

So maybe I can boil it down to two things I need to do to get better:

1. Get better at nailing down requirements up front, all the way, so I know what I’ll be coding
2. Code faster! With Better Quality!

And part of me very much strives for this: then there’s the part of me that says “No way to be blameless”.