I’m just here offering a quick nod to doing small things in their own time. The larger project may be an already launched piece saas or just a few jagged files rapidly dividing into autonomous application. You sit down, set up and stare bug eyed until the outlines of embossed form rise out of the sterioscopic noise. Then there’s that thing that you wanted to do. It’s just a little tiddlybit over here that works toward a user flow or dries your foundation hard to support some serious load. It’s not there yet but hooks in here, so you open the files and start into making it so. Bit by bit it comes together resplendent in error messages that you know as you see them to be right signposts guiding you in course corrections and understandable mistakes. Then one moment it’s there. A few more steps to flesh it out and account for those lingering edge cases and it’s right. Done and come into it’s own time where it will guide many executions and leave you in silence to come into the rest of your life.
The End
November 11th, 2012 § 0 comments § permalink
This is the end
Beautiful friend
the end.
The Situation
Time’s been tight and it’s been a challenge to find time to work. Nevertheless, I’m committed to delivering fairly substantial upgrades to a project, which I will then have to support through a crucial 2 month period. This is the predicament of writing production code on a deadline. Stuff needs to be done, sure, but above all else, when that deadline appears it all has to work. We go from looking at tests and running through different scenarios to hearing from (in this case) tens of thousands of people who find the bugs for you. The former is a lot more comfortable than the latter and the latter is creeping closer just about every day.
I’ve spent a lot of time mucking about with schedules and workflow schemes striving for the ideal smooth project deadline landing where the features materialize and bugs melt away in a even arc leading up a comfortable couple of weeks of testing then launch. That generally hasn’t worked for a variety of reality based reasons.
It recently struck me how individual work sessions are microcosms of the larger arc of a project. In order to better understand the end of a project I decided to do an inventory of the ways that work sessions end.
The Good
The ideal that I am for is to sit down with a plan, execute it, perhaps clean up some mess along the way, lean back with a satisfied nod, then stand slowly and stalk off to my next activity with poise and clean focus. This doesn’t never happen. I have been forcing myself to simplify my work session goals, which has led to a number of these bam, done sessions. This exercise is largely meant to help me achieve more of these.
The Bad
I’d call a work session bad if some progress has been made but it was not finished or done well. Usually, I just don’t finish things. This pushes work forward. The next time I sit down (or sometimes weeks later) I have to circle back and pick up the loose ends. This, itself, can suck up an entire work session. Also, the demented client side artifacts of incomplete or skewed code can be mentally disturbing to you as a developer testing other stuff. If this code makes it to a place the stakeholder can see, well, there’s no telling how the may react or what sort of sentiment it will introduce into your relationship.
Harbingers of the bad:
- The weak mind, tired body or other lack of energy. Start, sputter to a stop, give up as your mind is sucked into internet low pressure systems (reddit, fb, or whatever addictions you harbor.)
- Scope creep. There it is, the thing to get done! Doin’ it, but wait, there’s this architecture that needs to go in, and this other piece can be re-factored to conform it it, wop some fe structure needs to be shifted into another template for reuse, but then variable names need to be changed which really should lead to a naming convention change across these files.. and why not, may as well change that field name in the db… BAM, woah, right, this is accessed here and fed into there and displayed around these parts so let’s move through this and change that. Ah, ok, all is working again, what was I working on? Well, I got all this done. Time to check out (before finding the other 7 small bugs I just caused.)
- Scope shift. Workin’ on this, working on this, and, wait, there’s that other function that’s just right here. Should just be a few methods here and there and a template or two. I’m already in the code so I’ll work on that. At this moment of perfect programmer perception the glimmering image of the clear path to feature implementation drop kicks the less appealing work in progress straight out of my left nostril. Whether this view is a mirage or I actually get that other thing done, who knows. The initial fragment of work usually doesn’t get finished. The next time around the exposed sharp edges poke and it hurts.
- Giant drooling baby attack, or other indefensible invasion of concentration. The giant drooling baby can take many forms. It could be a pet, a spouse or a friend who clamors into your personal space and eviscerates your concentration. The giant drooling baby lurks within. It could even be you who is that baby, as even the most disciplined among us has impulses and urges that scoff at your carefully laid intentions and pull you off into some abyss or other. The giant drooling baby is very real and compelling, since there are things in life that are more enjoyable and often even more important that the task at hand. It makes a good case, but nonetheless can lead to bad work sessions.
- Re-research. You look. You find. You read. Fizzle. No effect. It’s good to keep up with things and check out stuff, but side trips through the blogosphere and isle of man pages can derail an otherwise productive work session. If I’m trying to get something done mid project 9 of 10 times I’ve already committed to a methodology. In these cases researching is not only distracting but dangerous; it often leads to scope shift. Engage not in the cottage industry that would fill your brain for minutes at a time for the low low price of a single click.
The Ugly
The ugly session generally starts out from the start with one of the aspects that can make a bad session. It is by force of will that we dive in anyway. Without focus, however, we can leave things in such a bad state that it’s best to roll back and start over later or, worse, simply do wrong headed refactoring or ship something off for stakeholder review with blatant problems. This latter is a strange psychological phenomenon that amounts to the programmer’s mind that understands exactly what is wrong not properly respecting the non-technical mind that would see the outward problems, wonder how it could ever be so bad, and often loose faith in you and the project in general. Programmers beware.
So, what sorts of endings do you find yourself having to your work sessions?
A workout for programmers
March 5th, 2012 § 0 comments § permalink
Let’s say you’re have 3 projects open at the moment. You’re dragging on all of them. Time is slipping and stakeholders are getting nervous. You look at yourself and say, “damn it, me, get going!” But this doesn’t work. You know it won’t because you have to say it. Then your significant other (or your hamster or whatever) looks at you wierd and you get a glimmer of the sad truth that you are weak, thin. It sucks to be like this when people are counting on us… and also there’s that whole mortality thing where we only have so much time before we die.
It happens and it’s rough, but never fear! Pay me $19.95 and then all your problems will be solved! (Sorry, I just watched TV for the first time in months and was shocked at how pandering and wretched the advertisements were, so I mock them)
So there are three projects hanging over your head. Stake out the next hour and,
- Go to your place of work. How are you? Did you come to this point in time strongly and with intention? Should you have brought a drink, used the bathroom, told someone that you’re getting into something and established boundaries? How is your workstation? What could make it better? Is it messy? Disorganized? Ergonomic? Don’t do anything about this stuff now, just acknowledge it. If it’s important, find yourself doing it later.
- Think about the first project to be worked on, at a general level: what is it? where are you in the project? what were the last steps? what’s to do next? Why are you doing it? Who are you doing it for? Who else is involved and what’s their role? What, exactly, is your personal responsibility? Do all the parts fit together to make a coherent whole? Will the project work brilliantly, well, alright, or not at all? How much do you care, and are you ok with that?
- Open the appropriate programs: Get your tools laid out just the way you want them. This includes editors, text environments, man pages, etc..
- Make sure you have all your passwords, paths, config files, administrative consoles, etc… at beckoning call if you need them. There are few things more frustrating and wasteful than deflating a clean focus because you’re locked out of your own server or don’t know the location of a config file…
- Touch on lessons learned: what part of your own process are you trying to improve this time around? Open up the files and track down the lines of code, or scan commit logs, or go through user flows. Touch, tactilely, that flow, pattern, process that you are developing as you work on the project. What does it feel like? What role do you see it playing in your greater development?
- Plan your session: what are you going to do with the time you have? Or, what things need to be done and how/why are they prioritized? How are these tasks going to fit into the product? How do they impact any deadlines? How do they fit into your larger goals and overarching intentions as an engineer, and, if applicable to you, artist?
- Think about your solution: what constructs, patterns, refactoring strategies are you going to use to get the job done? What will the code look like? Feel like? What sort of nasty bits will come up? What parts are smooth? What sort of compromise will you make? How do they fit in with the existing coding standards? Do tests need to be written? Comments? Version control contortions? How will this impact the performance, stability, scalability, etc.. of your greater product or code? How can what you’re doing benefit from open source projects, or contribute back into them?
- Close everything without changing a single bit and start from 1 with the next project.
Spend 20 minutes in this manner with each of your projects. Doing so will exercise the parts of your being that should be strong and lithe during the activity of programming and project work. While this exercise doesn’t accomplish any work it embeds useful forms and tenacity into the supportive parts of your personality upon which you depend when coding.
If it is hard to come up with 20 minutes of things to think about and move through, there’s a good chance that your project is faulty or that you could be getting more personally from the experience of working on it. If you can spend longer, go for it, but don’t only do this.
Enjoy your work!
Sensitivity
February 12th, 2012 § 0 comments § permalink
I’ve been programming for 22 years now, professionally for 12. It’s been the longest standing, rewarding pursuit of my life. One of the most fascinating things about it is how personal the path is; there are so many directions to grow into, so many things to learn, so many ways to improve. The products of programming are endlessly fascinating and unbelievably powerful. I’m just coming across a new way to develop my practice that’s completely unlike the courses, books, tutorials, blogs, etc… that have been my primary focus thus far.
Over the past year, I have had several notable occasions where I felt that something was wrong in my code, did not act on that feeling, then had it come back to bite me weeks or months later. Each time I was on deadline, immersed in process and otherwise stressed out. As I moved through the endless last miles I would feel a distinct sort of anxiety. It wasn’t just time pressure or the general mixture of tiredness and responsibility. When I stopped for a second and thought about this sensation, I realized that it was coming from the fact that specific edge cases weren’t being accounted for. I knew I better revisit certain files and make sure to go through certain workflows.
I was aware of defects in my code at a visceral level even though the situation was preventing me from taking the time to think it out (it was the situation, I swear! 
). In these few notable occasions I didn’t follow up, causing myself and others hassle down the line.
One of the most valuable tools a programmer has is a natal connection with their code. Coding is creating. As the codebase moves through those first few tenuous alphas it is something taking shape out of nothing. The form is driven by your ideas and given substance through languages, libraries and tools. During this time you are intimately acquainted with all its flashes of brilliance, solid elements and skeletons in the closet. In these early stages it cannot live on its own; not functional enough to use, not substantial enough for another coder to pick up from.
If it were that simple, then programming would be straight forward and mechanical.
The hard truth, that takes resolve and bravery to confront, is that this code is an intimate reflection of you. The form that it is taking is a tangible manifestation of your ideas and concepts. The violence that is done to an idea when it is first brought into the light of day can be hard to bear. It is an extremely delicate thing to bring an idea into alignment with the tools and forms that it can take while still preserving that kernel of truth or meaning that you find in it in your mind. It’s not just that so many epiphanies flare like shooting stars from the heavens then disappear forever into the silent oceans. Its simply evidence suggesting that you’re not good at what you do.
Things get more complicated when code is not just your art but also your profession. This reflection of you is linked to your income, the roof over your head, the food you eat, the compulsive first world lifestyle that would be fearful to loose. Beyond this lies the politics of group dynamics and bureaucracy, which can fully detach the inherent qualities of an action from the judgments that it inspires. I am fortunate in my day job that my organization is functional, but I have seen places where it is not.
Ultimately, the feeling that I put down or let slip away was anxiety, anxiety of failure (or mediocracy, as I’m not currently in danger of professional failure); a mortal anxiety wherein I realized that I may be unable to take this next step, fully realize the opportunities that my previous success has brought about; the anxiety that is the nothingness that is left when your energies are spent and you’re left looking into the abyss.
I’ve been turning the beginners mind portion of my practice to this anxiety. Giving it the space it needs for me to realize why it’s there, then attaching the importance to these reflections through applying effort to resolve the underlying issues. It is dispelling a lot of weakness that I’ve carried around and infused into my code. I’m pretty psyched about it.