analytical view

i had an email from a friend come in yesterday. one of the things it said was that they did not want to be analyzed. i was told by someone a few years ago that i was very judgmental for a person who promised not to judge. when creating the profile for this blog, answered who i am with “a liberal arts major, turned software engineer who doesn’t get to code anymore; now focused on debugging life”. that sentence does capture me, but it may need to be explained to be understood.

i attended a catholic “liberal arts” college and was given a dual major, at a school that does not have dual majors. it was almost accidental that i have this achievement. i simply enjoyed two subjects that i recognized were really one subject presented from two different world-views. reading the same works, and being told they had different meanings or messages was fascinating. the fact that the same work has a different meaning two doors down a corridor than it did in last semester's room was not lost on a searching mind that naturally questioned all information; especially when presented as truth not to be questioned.

my liberal arts period deepened my love of learning, and taught me to read all sides and understand that the same point can be believed different ways by different groups. i am sure this is not the message the benedictines intended when they began the college in rural new england; but the renaissance was not expected to occur when the university of paris was opened either.

i then found a job that allowed me to create models in my head and later see them run in the world. the fact that my models anticipated a user’s needs without them needing to tell me what they were was key to my ability to succeed at the job. the trick was to constantly ask what i would want as a user of the system, and then to convince others to let me build it that way. this required me to both think about the issue from the users view, and to communicate that view to people who thought they knew better.

time and again i was told to stick to the agreed scope. normally i would turn over a system that visibly matched scope but beneath the sheets was able to run in the way that i thought it should. soon after delivery, someone would come to me and ask how hard it would be to make the software work the way i had pushed for. people expected me to say it was a big effort, i would smile and say “don’t worry, i can make it do that”. while they were busily testing something i knew ran correctly, i was off playing on the next thing i wanted to do; the thing i should have had no time for because i was busy changing the first implementation.

being able to improve something means understanding it in the first place. there are three ways to learn about a system. reading documentation is the way we always ask for, the reality is most of the time there is very little documentation and it’s outdated or misleading. you can read the code, which is always right but sometimes hard to grasp if you don’t understand the style. lastly, you can debug.

debugging is not fixing software, its watching it run and analyzing the behavior and internal state. bugs are when a system acts in a way that is not anticipated or understood. the fact that the people cannot find the defect by reading the code is the heart of the debugging process. the lesson learned is that sometimes you need to have a complex system running so you can observe it. to quote ayn rand (also a developer of sorts) “when you see a contradiction, check your assumptions”.

so i no longer get to code. yes, i do some coding on the side. i wrote a pretty cool piece of software this summer that had only three minor issues in it. i delivered it quickly and took the pressure off a team that was overloaded with another project. it felt good to design and build, and then turn it over to someone else who learned from it. that is development, and it’s what you miss when you stop doing it.

now i get to design and build things that are not software. i get to decide on team structure, skils to push onto someone (hoping they see why i am pushing them), colors of walls, message of a message and the flow of a slide deck. i also get to decide which data is important to watch and how to communicate the values. as well as, what things to save and which to let go.

i get to do a lot of debugging, but not the type i trained myself to do. i get to read someone’s documentation and then to watch the running system. it’s interesting, it’s exciting and frustrating at times, but it’s nothing like the debugging of my prior career. for the first time in my life, i have decided that process does matter. this is a strange concept for the kid in geometry class that could get an answer but not do the steps. debugging is all about learning to understand the need to watch and test at each step.

my adult life has been one of learning to learn and later learning to analyze. i have a career built on analysis of things that no one asked me to analyze. being one step ahead, having randomly decided to research a technology the week before a client called to ask if i knew anything about it. being able to anticipant how a system was designed by watching it, being able to intuit the place to look for a bug when one was reported. these are the skills that allowed me to excel.

the issue becomes, these skills don’t work in the real world. or rather, they work to well at times.

the next skill to learn might be to not discuss the areas of the system i think we should be changing scope on. sometimes, leaving scope alone and not pointing out a better way is what the user really wants in the system.