focus

this is a bit of a wandering post, but i know i think best through writing things out, and while personal journals are a great thing, i cannot force myself to write them if there is no (even hypothetical) audience.

i think as i get older, i realize that there is so much stuff out there that i am interested in, that the importance of focusing is becoming increasingly apparent.

the distractions are getting more targeted and more fine-grained – it is getting simpler to fill up all the cracks of time between activities – reddit, twitter, google reader – scan the headlines while you are waiting for the build, and boom – you’ve blown your stack and lost the context. this is when discipline often loses to muscle memory; i suppose it is the usual story of combating the addiction. all this technology i surround myself with to be more effective just makes it simpler to waste time without achieving anything.

in this sense (all other things being equal), i find pair programming to be very helpful – it is so much harder to get distracted with someone else sitting next to you.

in certain cases i’ve observed that the proverbial order of magnitude difference in productivity between individual developers can simply be attributed to the ability to focus.

this became even more apparent to me in the past year at work as i have been faced with thousands of stored procedures for a given system – some of these storprocs being 2K+ lines long and recursive(!). talking about a new level of immersion!

one behavior i am guilty of is perfectionism in the face of overarching bigger goals – trying to make something flawless all the while the solution has to be out now and has to be good enough. i think i became immune to rolling out frameworks when a quick point solution is needed, so now the battle has moved to a finer level – testing as risk management, for instance – in the absence of time i test the stuff that is most likely to contain bugs, and i test coarse-grained user-level functionality first instead of polishing up individual unit tests.

but really, all this “micro focusing” business above is not that bad and is quite manageable on day to day basis. what i am trying to figure out though is how it applies to my career in general.

my problem right now is that after a decade in IT i realize that i have some hands-on skills that would always be in demand, and that there always will be plenty of filler work that will keep me busy and provide some sort of satisfaction (the kind similar to mindless exhaustion you feel after a workout).

i know i tend to become absorbed in day to day stuff, and lose the sight of everything else. NYC is dangerous in this respect – the pace and the energy make you work harder, and one can get fixated on something with a lot more intensity. this is when i find myself performing all sorts of yak shaving feats; is it really what i should be spending my time on?

i think paul graham got it right in his essay – NYC has the drive and the ambition, and i feed on it, but i also need to be fully cognizant of its true target. doing something pointless twice as hard isn’t something i am after.

so what is it that i should be doing? so let’s see if i can talk through this.

i always took pride in knowing a great deal about a lot of technical things all the while aspiring to grasp “the bigger picture.” i enjoy being able to build things, drive them to completion, and deliver. i also know that i like dealing with people, solve organizational problems, motivate and build teams.

i really enjoy doing hands-on stuff, and i am pretty good at it; at the same time i’ve seen all too often that most of the technology problems stem from people problems. it pains me to be on the receiving end of business blunders that render my technical efforts useless.

one of the trends in large companies is increasing specialization on many levels of IT. it is inevitable to a degree, but this is precisely where my skills would be least utilized. the image that haunts me is the nine to five drone with atrophied knowledge of everything but the immediate responsibilities of everyday job, unable to survive outside of the large corporation. there are plenty of slots like that – just waiting to be filled.

i want to work in the environment where people around me do have a vision that we all share, and this is what drives our everyday work.

i also like small teams (or small companies) – you get to do a lot of different stuff, you learn much faster, and you feel the impact you make.

so ideally it comes down to focusing on my strengths and consciously building upon them, which means spending less time on everything else.

it sounds quite absolute and final (an also quite fluffy), so perhaps a better approach is to set a goal, timebox it, and focus. if it works – great, and if not – review and start again.

• current work: spend less time on it; spend less time on filler work; focus on business – actually read the pile of books i have here instead of reading up on tech stuff.

• spend more time on hobby projects, get back into languages/platforms i abandoned, pick a few projects and actually contribute; build the brand – push for talks at user groups, use real name in forums, blog more on technical topics.

as far as career choices go:

• i’ve done the enterprise architecture thing for a couple of years before, and despite the raging pundits that the title has accumulated, i think there are great things to be done. you do not have to abandon the technical skills, but you have to realize that your success does not depend on tech anymore. you do end up building and running systems in this role, but they also include people, culture, and organization – not just technology. there is a lot to be said about systems thinking, and there is plenty more reading i need to do. i am also yet to find a good no-bullshit community that thinks along these lines (so far i’ve been really enjoying Stu Charlton’s blog for instance) and people i can work with and learn from…

• …which leads me to consulting. what appeals to me here is focus on solving a particular problem (compare that to a less focused role of a regular employee), as well as a great variety of problems, and generally a higher level of expertise expected. you grow and learn so much faster, and ideally this might lead to a product idea, if you see the same problem repeated over and over again. one skill that i know i have is what jerry weinberg calls “jiggling” (see Secrets of Consulting and Are Your Lights On?) – helping people get “unstuck” by asking questions, suggesting tools, practices. often i realize that in many teams although i could do all the work myself, the team would get so much more out of me if i create an environment where people can learn and grow on their own.

• another option is a product/program owner in a larger company. the biggest selling point is the diverse set of skills required and the sense of ownership. you have a bigger picture, you are responsible for it, and at the same time you need tech, people, and organization to be a success.

• the refinement of the above is a startup – you build and deliver a product. your impact is tangible, you actually “own” something, and you contribute on many levels, which is a great use for a broad set of skills.

• and the last option is to get a foot in the door in a larger company as a regular developer (since this is an easy lowest common denominator that is versatile enough and faceless enough) and then try and grow into some sort of a role similar to one of the above. it is terribly inefficient though – most of the energy will be spent on the wrong things.

it does help to write all of this out – having a stake in the ground is a start. let’s see how it goes from here.