Debug Yourself

December 19th, 2014 § 0 comments § permalink

There’s bugs in your code.  They could be causing repeated system crashes and costing millions ($) or just causing the odd visitor to shake their head and click away.

Know that at a fundamental level, there’s a vibration in you that is connected through something akin to string theory to every unfortunate software pattern, ill conceived coded concept, negligent gap in understanding or blatant typo in your code.

Work is force times acceleration.  It’s your exertion in effort in relation to a change in the state of what was there.  And I’m not talking about dinky low exponent changes.  Acceleration is an x^2 concept, so it isn’t concerned with simply what’s there, or with how the world happens to be going along, but with how you change the way in which the world’s going along.  (If you want to get really fancy pants you can exert change in the ways others work and operate at an x^3 level, but, having tried this, I can warn you not to take the choice lightly.)

Work is also bi-directional.  If you apply work to something, it applies an equal and opposite amount of work on you.  In other words, you change too.  If you work in bugs all day long, the bugs will work into you.

So what do you do?

It turns out there’s two things to do with time put toward debugging.  You can either fold the past into the present or the future into the present.  I recommend doing both to degrees that vary depending on your current predicament.

Debugging existing code is a sublime opportunity for you to come to know your own history.  We are historical creatures, in that we have come to be who we are through exactly so many precise things that happened.  There’s no way we can get any perspective on all or them or perfect perspective on any of them, but working to improve your past work is a huge step in that direction.  Knowing who you were as clearly as you’re able and working to identify and change that legacy changes who you are now, hopefully advantageously.

Writing new code with a mind to the that have scuttled through your code and dreams is great stuff to do too.  It’s easy here, though, not to debug yourself before you bequeath your bugs into your next project so watch out.

Anyway, I’m out.



January 28th, 2014 § 0 comments § permalink

My cultivated reaction to frustration is to put it down with a shaky handed cattle bolt to the head.  I then stand over its incompletely killed soon to be corpse and bask for a second in some ideal that convinces me that it’s good, right, just, noble, beneficial, categorically impelled to destroy non-rational rumblings from the deeps.

Im introducing a new bill into the legislature of my soul.  I’m calling it the Exasperation Proclamation.  The spirit is to not loose sight of the fruits of frustration as I put it down.  My executive branch has ratified it and legislative is split but currently attaching riders to make all sides agree.  We’ll see what the judicial does in real time.  It’s just an elbow poke to my meditative mind saying, “Hey, take note of that too.  Useful stuff there, taken in context.”

I’m a white whaler type.  I work hard a lot and take on huge things.  I love what I do and, other than necessities for the maintenance of sanity (NMSs), don’t see any real separation between work product and art, or work time and play time.  I often, however, strive long and hard for something big and far away without allowing myself to feel that I’m failing to get there.  Then, generally, I find myself short on time with winter coming and fall back on stress to push me through to doing a good job.

Behold the motivation behind the bill: I know this is going to happen all along, but let it do so.  This seems to be in large part due to the fact that I don’t listen to what I know at levels below the motivated me that seeks fulfillment and refuge in the doing.

I need some leverage, so I’ll pry apart a dualism.  Frustration that comes from things that are ‘my own damn fault’ may deliver some actionable insight into what I should be doing right now instead of blissfully swooping through productivity, fingers spread into ineffective feathers.    Frustration from pressures pushing in from things that should not be needs to be allowed to tell me where I need to push back.  It’s getting weary holding these two halves apart but it’s productive as this idea is fruitful still.  You cut an apple in half to see if it’s rotten.  Don’t see any rot?  Doesn’t mean it isn’t in or half or the other, but it’s easier to be sure.

So thank you and wish me having had luck in my corner of this universe, both throughout the time between my writing of this and your reading and into the future.


January 25th, 2014 § 0 comments § permalink

I’ve been oscillating through a bunch of different levels of productivity when it comes to programming over the past couple of years.  There’ve been and continue to be many reasons why: babies, new old house, shift to a pseudo management role at work, indulgence in self-sabotage,  etc…  Through all this, however, I’ve been consistently and often desperately trying to code as much as possible.  I’ve pretty much confirmed that coding is one of the three or four legs of the table of my overall wellness.

Instead of simply opening my laptop and working, I’ve often taken the time to think about the practice in different ways.  Having done this for quite a while, I’m finding that patterns are emerging.  Here are a few of them in no particular order:

  • High level musings.  These are the most fun.  Problems and solutions run together forming a vision of the future.  My mind riffs along pretty fluently in my programming languages and techniques to describe a very plausible scenario.  These ideas are extremely amusing, sometimes even to other people in the rare occasion that I communicate them.  In times like these where my priorities explicitly lie elsewhere, these thoughts are almost always capped by the one-two step of recognition that I will not be able to implement them followed by a frantic mental scramble to employ some sort of memory device to save them.  I do a pretty good job of staking down these ideas and often remember them with clarity years later.  The problem is that I forget where I put them so it takes a miracle of random chance for me to trigger that pattern that dredges them up.  I find it strangely mildly satisfying to know that I’ve had them though but experience shows that implementing them is vastly better for the ‘ole state of being.
  • Brick wall.  Get up to speed then *splat*.
  • Mental code crawl.  Sometimes I just go through the code I’ve written as it appears in my memory.  I usually rifle through an active project.  This process is a lot like playing through a song or remembering a night.  The body of work sort of unfolds in it’s own way.  Mental notes, otherwise lost, tend to get dislodged and float to the surface along the way.
  • Epiphany induction.  Certain states of mind conduct epiphanies.  Sometimes a circuit is completed when performing activities such as the others in this list.  Wham.  Awesome.
  • Bug aversion.  I’ve been up against some bugs that have sucked so much that I’ve averted my eyes and avoided them via avoiding working all together.  I’m not proud, but it happens.  The good news is that it’s usually exactly when I’m avoiding staggering and groping around a debug for another hour that I have the epiphany on how to solve the bug.  At least I have that going for me, which is nice.
  • Fuck it, I’m tired.

Repo repo on the wall…

October 16th, 2013 § 0 comments § permalink

What do you see when you look at your code?  What are the occasions that you open up the files and read through them?  What are you trying to get done?  at what pace?  with what sensibilities?

Many common ailments that chronically strike programmers stem from code image problems.  Simply put, our image of what our code is differs, often dramatically, from what it is, what it does, how it runs, what other programmers see when they read/use it.

People are generally the worst judges of themselves.  This extends to the code we write.

How many times have thoughts of style, architecture, bugs, etc… flooded your mind the moment that you send someone else a link to look at what you’ve written?  How many pre-qualifications have you sent out like calvary leading your code into an epic battle of judgement that is sure to come?  How are the feelz that manifest from the chemicals that are released into you system?  Bad?

If your answers to these == true, then you have a problem.  Each of these are symptoms of a code image problem, which is probably holding you back and generally making you miserable in other ways too.


There are sleek, efficient, popular libraries out there that make anything I’ve written look like a pile of dog shit.  At lest they do if I spend a lot of time reading, rereading and analyzing them.  When, on the other hand, I recognize that what I’ve done is crap but then circle back to stare at, smell and taste the crap, I realize that it’s not crap after all.  It’s actually clay.

The reason your code looks like crap to you is that you’re too close to it.  You can’t see it.  Then you look over and see this sparkly thing that does something better.  Your own image of your code ceases to be related to what it is and becomes a representation of a lack of what it’s not: that other stupid fresh ultra library.

But what, exactly, is so good about that other code that has the power to cancel the very essence of what you’ve done and replace it with hollow emptiness?  This is the question you should keep at the forefront of your mind.  It needs to be a knee-jerk reaction to the ulcerous feelings of inadequacy that ooze from your clamped shut eyelids when you walk through your files.

Once you’ve found why you react so strongly to some code, grab that and hold on to it.  Is it something that’s relevant to your work?  Implement the fuck out of it.  Is it a trick of syntax that is slick and clean?  Start employing it.  Is it a style du jour that exemplifies another amazing step in the constantly progressing culture of coding?  If so, crank your smile up one more notch (or further flatten your poker face, or deepen whatever comportment you sport) and carry on.

The important part is that you close the other code and start spending time with your own.  Failure to do this leads to fetishization.  It becomes enough to wield statement about mythological coders and idealized techniques and your capacity to create fades.    Yes… I love this style.  It is.. beautiful.  Your eyes grow and grow as your flesh decays and rots.  It’s a trap, a tragic fate.


Love your code for it is part of you.  Dwell on it as you would reflect on your own actions.  Read through it for it’s own sake without being driven by drums to refactor or add features.  Spend time.  Have ideas and that arise from purposeless moments and honor them through implementation.  Find where you can employ the real things you love about other code in your own.  Reap the benefits of mental health and wholeness of self.  Prophet.

Small things in their own time

January 29th, 2013 § 0 comments § permalink

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,

  1. 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.
  2. 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?
  3. Open the appropriate programs: Get your tools laid out just the way you want them.  This includes editors, text environments, man pages, etc..
  4. 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…
  5. 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?
  6. 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?
  7. 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?
  8. 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!




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 wolf of the steppes
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.