Ponderous Programmer

Want your staff to support 'The Company'?

noreply@blogger.com (vwdiesel) — Wed, 11 Feb 2026 16:19:00 +0000

In my previous post I talked about how the company/corporate values matter and that you really should be seeking to fully engage your staff in setting those values. The reasons WHY are numerous and I attempted to layout those backing reasons. One of the items that I didn't discuss in that post - what happens when you ask the staff to 'hype' the organization in public forums.

At many times in my career - the companies that I have worked with have requested that I spend time using my personal online persona in supporting, retweeting, reenforcing the various interests (hint: and values of) of the company. They may request that I repost - like - or other wise 'bump' a specific post to enable it to have a larger reach and larger impact on the platform in question. This request has come to me in a myriad of forms over time and has involved one or more of the following platforms:

Linked In, Google Reviews, Facebook, Glassdoor, hiring/personnel sites, etc.

Here is the thing though, if I want to be seen and feel as if I am being true to myself AND in public be understood to be supportive of and aligned with a certain set of values, then I have to also believe that the corporate values and things that I would be 'bumping' for that organization also align with those values. e.g. I want to be seen and understood to be true to myself, and true to a certain set of values. If by supporting the company in bumping content and posts I am betraying those values because I feel the corporate values are either unaligned or are made empty because i was not offered the opportunity to buy into them... then I won't be doing any bumping. Being requested to 'help' the company doesn't help me if what I am supporting is contrary to who I am or the persona I am attempting to portray. In the best case scenario - I am granted the ability to essentially 'ignore' the request to support the specific company posts. In the worst case - the company makes supporting them a part of my review and part of the determination for raises and promotions. As I said in my previous post - how we win matters and if you couldn't bring me on board with the values of the company and work to get me aligned and involved with those then mandating I take an action that affects my personal / social credit is going to fail at best and be harmful at worst.

It should also be noted - that having the staff bought into the values will allow them to continue to be supportive of the organization long after they are no longer on the staff. How the staff interacts with the Organization when they leave voluntarily matters. As a company writing and then having them sign documents when they leave that they will not directly impact the companies reputation is a cop out to the idea that you should be working to gain them as net supporters rather than net detractors while they are working for you. Not everyone will be a super supporter - but better to be over 50% of the staff supporting you then having the broom on the floor again and asking people to jump over it.

You want your staff helping the company grow? You want them singing praises to others about working there and how great a situation it is - GET THEM INVOLVED IN YOUR VALUES. Give them reason to support you, not commands to do so.

Your culture, buy-in, and the corporate kool-aide

noreply@blogger.com (vwdiesel) — Mon, 01 Dec 2025 14:25:00 +0000

There are plenty of things that annoy me about how companies run things, from the compute environments that we all work with, to the red tape and paperwork that is mandated by every organization that I have ever worked for. None of these items is nearly as annoying as missing the opportunity to set a culture, to create a feeling of community for all the people that work in the organization. Having a culture established and providing a framework for how everyone behaves and considers their role within the organization is vital - in my opinion more so than simply 'making money'. I have not seen anything be nearly as essential as the shared culture a company (and their staff) has.

A tale of two situations

Situation one:

I used to work for a company long long ago in a land far far away in my youth (ok, it was my 20s... but I might as well have been five). In this company when we were on-boarded - all of us went through the same training, we were all told what the values of the company and the values of its people/staff were. All new staff were introduced to existing staff in the company that held those same described beliefs and values. Now - It didn't hit me then, but this was one of the most powerful things I have ever been involved with. This company was taking steps to align all the staff to the same culture, to the same goals, to the same ideals. In short - they were working to get everyone pointed towards the same North Star set of values.

Aligned to the North Star....

This on-boarding, described the values everyone was asked to be beholden to. This process allowed people to know what the company was doing and why they were doing it. The Kool-aide (TM) gave permission to all the staff to BEHAVE in a way that aligned with those values, and invite them into also owning them, espousing them, and upholding them in the interactions and work they were doing. In short - this 'training' actually got everyone in the company roughly pulling in the very same direction. Making the entire company a force to be reckoned with.

In contrast to the above, I have also had the cliche experience of having zero buy in and zero involvement in the values of the company I am working for - the difference is striking.

Situation two:

In this situation - the company is new and small, not yet having all the trimmings and trappings of a larger organization. In this case, the values of the company have not yet been established let alone written down. Training/on-boarding is not really yet defined, hiring practices and interview type/style not yet clarified etc etc. As the company is growing and changing - there exists an opportunity to both define the values and get the staff bought into those values, have them "Drink the kool-aide" if you will. There exists a unique opportunity to get everyone marching towards the same North Star, going in the same direction. Getting EVERYONE pulling for the same things.

What actually happened was values got defined with no involvement of the staff. Everyone was introduced to the values created long after the values had been launched into the public eye. A huge miss - allowing silos, and poor communication to continue rather than have the staff buy in at even the basic of levels.

We are more powerful marching together - and even MORE powerful marching in ONE direction

A common value, a common direction, a common goal that everyone shares IS powerful. Having this alignment up and down the chain of command enables staff to make independent decisions that are in line with the company North Star using the corporate values as guiding bumpers. This alignment allows all the staff to challenge choices one another are making. This alignment allows for empowerment and flexibility. Without this buy in - lots of meetings to get alignment, lots of items where management feels the need to intervene because the decisions don't have the necessary context and framework. In the end even if it were the case that corporate values were going to be decided only by Upper Management - for everyone else the illusion of having a choice matters in winning them to your side. If they can actually BUY IN - it would be even more powerful leading to great outcomes. Flexibility, and and and - your company more powerful than it was.

In the end "Its how we win that matters" - Enders Game

There are plenty of cliches out there about corporate values and how they are created. IT IS POSSIBLE however to create values and have them be meaningful and fulfilling and direction setting for the staff and the market as a whole. WHEN you can do this - there is no telling what you can accomplish. When you don't do this - you and your staff will just be blah, jumping over a broom stick that has been placed on the floor. We should all strive for something better.

I am broken, but don't require fixing

noreply@blogger.com (vwdiesel) — Wed, 30 Oct 2019 12:49:00 +0000

Was sitting in church listening to the sermon and contemplating all that has happened in the past few months of my life. The sermon this past Sunday was addressing those times when we are sure we are right and those times when we need to be nudged out of our comfort zone. It was the latter of these things that lead me to this post's title "I am broken, but I don't require fixing".

I AM BROKEN

Life has thrown me a series of curve balls
-----------------------

There are times in our lives when something, someone, some situation comes along that pushes or nudges us out of our comfort zone. There are times when we have our notions challenged such that we need to stop and contemplate them beyond just a cursory "Oh isn't that interesting..." This sermon was one of those times for me as I began to realize that my current life state was "Broken" but broken by the situation/choice such that it doesn't require fixing. I am broken in a way that doesn't require someone to come along and lift me up and dust me off. I am broken because what I thought was true, or the things that modeled my world have been disproved. I am broken in a way that allows me to stop and consider what about my world model was wrong. I am broken in a way that provides the opportunity to change how I go about moving forward in the world. For me I have found the following to be my 'Broken' process.

Mourning the Broken

Large life events all have a process that they will trigger and that process may be long or short. It is hard to tell in advance how long a given event may cause one to feel that they are in mourning but it is an important aspect of being broken I believe. In the cases where I have been broken in my life there is always a feeling of loss. The loss can be physical - meaning someone passing or perhaps the lost of a possession, or something emotional like a good friend moving far away or someone you once talked to all the time falling out of touch. Time has to be taken to consider the loss what impact it has had and why has it had that impact in order to attempt to move forward from it. Cry, laugh, smile, focus on the content of the event so that you can feel it fully. In order to mourn it properly you have to be able to see it fully for a moment in your life and its meaning to you. In order to mourn you have to be able to see what needs of your own that thing, that person was filling for you.

Picking up the pieces

As you consider in your mourning what is it that is left behind? What can I take from what has happened? Sometimes you may even be tempted to ask why me? Coming forward from a position of brokenness requires, I believe, that you be able to look at your own reaction to what has happened and understand why you have reacted in a given way. Are you angry? Are you sad? Are you feeling a mix of different emotions? Why are those emotions the ones that have arisen in the current broken state. Maybe you are upset with yourself for feeling, maybe you are upset with some other external factor for how it is or how another individual appears to feel. All of these things, all of these questions and their answers are part and parcel to being broken. Like looking at a bit of sea glass carefully and wondering how it came to be at your feet - each instance and question above needs similar scrutiny.

I don't need fixing

In short I don't need fixing - I need support. I need to be able to put the situations of my life into words, feelings and context that I understand. Moving forward, one step at a time, requires an ability to process without stuffing or ignoring the situation that created the brokenness. Being broken, I think, is like having a surgery scar but on your psyche ... its permanent and part of the story of your life. Scars don't require fixing - just time to heal.

Closing

While I was writing this post originally (now a long time ago in relative terms) I found the following quote:

Treat things as "habit not hill." Meaning excellence is a minute-at-a-time habit, not a hill to climb. Same is true of being less broken, it's a minute at a time habit to improve, not a hill you are standing at the bottom of looking up at the top saying "I need to climb THIS?".

Invisibility - Rise above background noise

noreply@blogger.com (vwdiesel) — Sun, 20 Aug 2017 21:16:00 +0000

There was an article published by Technically Philly recently entitled:

"Does Philly’s tech scene have a sexual harassment problem?"

The article seems to have had precious little to say about sexual harassment or the role that it does or doesn't play in Philadelphia's technology scene. Let's just address things head on shall we?

Philly's tech scene absolutely has a sexual harassment problem. Why? Because Philly does, because tech in general does, because people do. No way around this fact of life.

There has been a great deal of press about the sexual harassment in tech in California and the Silicon Valley and while those places are not 100% representative of tech across the U.S.A. it would be disingenuous to think that problems there are not even a little bit reflective of possible, well hidden problems elsewhere, including HERE.

Privilege, Challenged

The news has been awash recently of commentary relating to race, nationality, skin color and most recently the events that occurred in Charlottesville, VA. I would observe that there is a common thread in them all - being a white person in the US confers a blindness on many that prevents them from seeing the benefits of their own privilege as a result of their background or skin color. The same is true for gender.

Sexual harassment hasn't happened to me...so it must not be wide spread
Sexual harassment must not be happening because I haven't seen it...so it must not be wide spread
Sexual harassment happens in a small percentage of cases...so it must not be wide spread

I observe that sexual harassment happens all the time, however most of the time people are willing to look the other way, give the benefit of the doubt, or somehow explain away that thing that they actually saw occur because "reason". It hardly matters what the reason is. As a result of this we are collectively part of the problem that continues to compound. I want to encourage people to recognize the differences in their reactions as a result of privilege they may enjoy, to see and call people out for their harassing behavior.

Screaming, Fatigue

Like other forms of discrimination - sexual harassment is 100% real and it gets tiring pointing it out:

I admit that I don't know about my circle of friends’ and acquaintances’ experiences - because I haven't asked - however I would venture to say that the majority of my circle of friends have also had some form of harassment (from mild to outlandish) leveled against them. The article from Technically hurts efforts to raise visibility for harassment because, as one person I follow said:

"...this [article] does not help the lack of belief in the problem. 'Cause now people can share this [article] link & be all, "What? Nothing to see here."

Take the time, read, open your eyes & mind

It takes diligence to acknowledge that there might be a gap in your knowledge, or a gap in your vision. The idea of modifying your default stance for a given situation likely needs to be actively (mentally) challenged in order to be able to see situations differently or to see situations are/were not what you assumed them to be. Time and effort has to be put in to understand others’ points of view, others’ feelings. Speak up, speak out at any an all opportunities that present themselves.

* Authors note: It is my intention to compile additional helpful reading links, things that I found helpful, that have opened my eyes or provided me insight into who I am. I'll try to post those in a day or two.

Examples:
https://technical.ly/philly/2017/09/18/amber-wanner-linkedin
https://technical.ly/philly/2017/09/05/sexual-harassment-problem/

On Today's Election results...

noreply@blogger.com (vwdiesel) — Wed, 09 Nov 2016 18:48:00 +0000

From twitter... 5'7 Black Male - ‏@absurdistwords, I tired to capture this without changing any of the meaning or the structure. These words capture the sentiment I have in relation to what has just happened in this country and I am thankful for his having written them.

I woke up out of my dead sleep an hour ago. I knew Trump won before I went to bed. I just thought I might have a full nights sleep first

 I'm the only one awake at my place so woke up lonely and deeply sad.

So I came here. Looking for something.  Sometimes it just feels too big, too overwhelming. The deep hatred and anger in America had always been there. But sometimes Sometimes you know a relationship has been over for years, but hearing the words "I don't love you" still cuts deeply

That is where I am .

I know America hates me. I know it is full of bigotry and ignorance. I have no illusions It still hurts to hear  This feeling I feel now is one I haven't felt in years. Not since arguing kids out of jail.

I had a girl on probation...  She'd done everything we'd asked of her. The hard work, the soul searching, brought up her grades, stayed out of trouble.  She had done so well she'd been selected to represent our program in Albany.  But the case that had brought her to us a year earlier although minor, was a probation violation. But nobody had bothered to violate her.  So here we are with our model child, excited to advocate for juvenile justice. And the police come to arrest her  I had never been an expert witness before, but I tried my best to present her case.

"She is EXACTLY what you want from us!"  I spoke of her achievements, her grades, her progress, her mentorship of others, her empathy, her dedication  She turned to me after I stepped off the stand and said "Thank you, Mister for fighting for me. Its not going to matter"

My heart broke  "They're gonna to see all you've done"

"No, Mister. They won't"

"But..."

"Its ok." I knew she was right, but I a 20 something idealist wouldn't accept the truth this 14 year old kid didn't even question . The system didn't care about her. Didn't respect her. Didn't care if she rehabilitated or not.

I thought reason might prevail

She knew  

As I watched the light go out of her eyes as she was led away something in me broke

I left the courthouse and wandered the street in tears How could it be THIS fucked?

How was I so powerless to lose a child who should have been a model case?

How could the system be so dense?  I've never been caught off guard by the system and its hatred again.

I wasn't tonight either

But the FEELING is back  - What did happen was this

I studied that case. I pored over it. Every bit of evidence, every word of testimony, every trick prosecution used . I fucking armed myself with knowledge and vengeance.

I couldn't do anything more for this girl, but I could do more for others . On that stand, I'd been unprepared for the dirty tricks. I would never be again. I never was again . I squared off with that prosecutor five more times and sent him packing each time. 

There is nothing we can do to change the outcome of this election.

Its done.

But we are not.  This is one if those times. Where we must break. To take in the overwhelming reality and face it head on with all the pain it brings.  Don't put on a happy mask and pretend it's normal. There's nothing normal here.

Its ok to break. 

America needs to sit here an cry it out for a moment because we are face to face with the truth of our country

We can't pretend anymore. Its time for our illusions to come down.

That we are in a post racial society
That the crowd will do the right thing
That facts matter
 We need to come out from behind our comfort zones and bubbles and look at our country without the lenses of exceptionalism .
Now we know.

We are not more empathetic than Germany
More savvy than Brexiters
We are not more serious about our democracy 
We're just a fallible country full of regular fucking humans like everywhere else.

We. Are. Not. Immune. 

So don't spend the next few weeks yelling at everyone and passing blame.

Take a deep breath.  When you exhale, realize that we are still in this together. And we have a chance. If we choose to take it, to drop our facades . I am thankful for you. All of you. For your support, for your love, for your passion.

Let this be a day of clarity. Let today remind you to connect with others. Share in your pain. Marvel and grieve. Trump's presidency is a result of us not really seeing each other or our country for who we are and what it is.

We can fix that.  We can fix it especially if the elevation of Trump wakes us up to the truth of bigotry.

I see a lot of surprised white people this morning.  Im talking to you now surprised white people.

I wanna bring you in for an empathy moment.  This feeling you have right now. Amazement that the country could be so short-sighted, that it could embrace hate so tightly?

Welcome. 

This despair and dread you feel. The indignation, the bewilderment, the hurt, powerlessness, the fear for family and livelihood?

Welcome.

 That knot in your stomach, that feeling of heartache? That uncertainty about your safety? The deep sense of fundamental injustice?

Welcome.

 For many marginalized people, this spike in distress you feel this morning is what we feel EVERY morning.  That feeling of "How could they possibly...?" is precisely what we feel with every incidence of excused violence, disenfranchisement, denial . I do not say this to diminish what you feel today. What you feel is real and valid.

I'm giving you an opportunity to truly empathize.  For it is the lack of that empathy that allowed America to shrug as the marginalized shouted warnings.  Today the imaginary wall that divides your experience from ours has come down.

You have the chance to commune with the rest of us.  This needs to be a moment where you realize that you are not alone in your pain.

That there are those of us who know it intimately.  Let this be the last time you are surprised by the prevalence of virulent hatred in this country.

Let it be a moment that opens your eyes  . This is a time that you can move on from the childish insistence that America is #1, grow up and recognize it as gravely ill.  This can be a time for you to stop side-eying those who insist that something is and has always been something deeply wrong.   Skip the hand wringing about how you didn't see this coming and move to the part where you get on board to come down into the trenches.  I see people talking about how Trump is #NotMyPresident.

Yes he damn well is.

It's really important that you get this cause its key.  Compartmentalizing this problem solves exactly nothing.

Refusing culpability for America's actions is how we GOT Trump.   Trump is an opportunistic infection that America let fester and grow in an immunocompromised environment.  America's neglect of its own health comes directly from its stubborn insistence that nothing is as bad as it looks . When we minimized the outrage about rape, about racism, about fascism and ignorance, about marginalization we created a space ripe for Trump.  Trump is our President because we and the people who voted for him are still in the same boat as much as we'd like to deny it.  Another country didn't elect Trump. This one did. Your neighbors and relatives and co-workers and friends did.  We are inextricably bound. We cannot wish this half of America away.

But we can sure as hell challenge it.     

Needs, wants and everything in between

noreply@blogger.com (vwdiesel) — Mon, 25 Apr 2016 12:56:00 +0000

I don't think that the following statement should be surprising to anyone but:

EVERYONE WANTS TO FEEL LISTENED TO

The reason, I think, is that everyone wants to feel like they have equal shot, equal footing to have their needs met. It isn't possible to have your needs met when the other people involved in a conversation are not interested in listening to what you have to say. Beyond that it is increasingly difficult to have your needs met if you are not able to articulate what you actually need.

Sounds easy right - you just have to be able to say what it is that you need... You just have to put it out there and allow it to be heard and then your needs might potentially be met, so what makes it so amazingly fucking hard to ACTUALLY do?

Social interaction, moral codes and judgements

My theory is this - over time we are taught as kids by our parents, and elders about things that we can't say or can't do. Kids are negatively reinforced by their elders about how they use their words and are told that the choices that they make can hurt people. As kids we are taught to take care with other peoples feelings and often the ways in which we are taught to do this are statements like:

"...don't say that..."

"...you can't say that to people, you'll hurt their feelings..."

etc.

But we are rarely positively reinforced for using words and other statements to state what we feel and need while also not hurting the people we are interacting with. Think of it like sharing that toy that there was only one of when you were little. Someone else was using it at the time you wanted to also play with it. Now you have choices, you can walk over and take it, you can ask to play with it, etc. However when young we often don't consider beyond ourselves and we don't often have a role model for interacting. We learn as we go about what gets us in trouble and what doesn't including some of the sneaky "I get my way without getting in trouble" actions that can be taken.

Speculate for a minute though - what IF what we modeled for our kids and others was as truthful as kids tend to be, telling things like they see it with few filters but the words were chosen to be clear and concise and non threatening.

Marshal Rosenberg lays out a discussion and conversation model called nonviolent communication. Where he describes the ideas of stating clearly what you observe about a situation, describing how it makes you feel and as a result what needs you have around it. Seems straight forward but is actually amazingly difficult to do. Think about the last argument you had with someone, do you think that you would have been able to be level headed enough to not escalate the conversation with angry commentary but rather stop and say what you observe and what you feel? Ya, I didn't think so - I know I certainly don't - but I am trying.

Imagine if you will

Now - lets go back to the kids. I mentioned them earlier because I wanted to speculate what our adult interactions would be if we were able to example for our children when they were young a method like nonviolent communication. Kids are unfiltered and wonderfully blunt, they say what they see and their interpretation on it. Kids are not afraid to tell us how they feel, but somewhere along the way as we grow up the interactions we have and the things we are told by our elders drum out of us the ability to just say how we feel, and what we need. I love to speculate how much better a place the world would be if we could all get our needs met. I for sure am looking to get my needs met, and using nonviolent communication where I can to help me articulate them.

Trust - Ebbs and Flows

noreply@blogger.com (vwdiesel) — Fri, 08 Apr 2016 12:00:00 +0000

I find myself thinking about trust a great deal lately - it is another of those life things that seems to be rising to the surface enough that I should likely pay attention to it. A friend of mine in fact just said

"Trust once lost, is hard to regain."

Which is why I am now sitting here typing out this post.

From a very young age I found that I was able to read people fairly well. I was certainly not perfect at it as 'reading' someone is a bit of an inexact science but I found I was fairly good at determining quickly if I was bound to trust the person standing in front of me long term. Sometimes body language would say one thing and their words something different which would leave me feeling like I couldn't trust them. Overall I was often left wondering about interactions with individuals long after they had occurred trying to understand why the conversation broke out the way it did, why certain things happened and sometimes why certain things didn't happen at all. The interesting thing for me is that while my instincts may tell me not to trust someone I often trusted them anyway. Glutton for punishment I suppose.

WHY

I have wondered for myself why it is the case that I always seem to start from a default of trusting someone implicitly even when my instincts may tell me otherwise. It seems to be my nature to start a relationship with giving it my all. I want to trust, I want to know I am trusted, I want to exchange ideas and know that ideas can easily be exchanged with me. To put it simply, I pour myself into the relationships that I have because I think it is important to be fully engaged and fully involved. This makes having lots of incidental relationships super annoying, because I am not much for incidental. I want people in my life that are willing to connect that way. I want people in my life that allow me to pour a bucket full of my trust into the relationship, instantly. In the reverse I hope for the same from them, but I can do no more than hope as their trust isn't in my control...

Trust Exchange

I had a conversation with my friend Maurice Gaston at one point about trust and trust as a flowing exchange between people. The idea that trust isn't something all on or all off at all points, that it more flows like a river or comes and goes like a tide. The discussion framed up some thoughts around why some discussions I have feel more relaxed and others feel more strained, as if some conversations require a great deal of concentration to get right and others go right naturally on their own. I think it does boil down to the trust that we have and the mental model we have built up of the person(s) we are talking to.

Chris Argyris, an American business theorist, wrote about these mental models we create for our interactions. He outlined that people over time generate a 'theory' of the person that they are interacting with and how that person will or won't react in situations that they are placed in. When we interact with someone else we try to reconcile the actions that individual takes with the theory we have in our mind for that person, if they match, we reinforce the theory being the 'right' theory for that individual. When the theory and the actions that are presented mismatch we get suddenly lost trying to reconcile and come up with a new theory for them that fits the new data and situation. He called out that this all occurs very quickly - likely at a level we don't realize we are doing it. Stay with me... bringing it back around.

I think the reinforcement or the discontinuity of conversations likely line up with the level of trust and the ease with which the conversations seem to occur. That trust ebb and flow maps directly on-top of Chris' commentary. When my theory of an individual is reinforced by that person's actions, I feel more likely to trust and less like something odd is going to happen. When my theory is constantly being challenged, I feel less likely to trust and the conversation and exchange is harder.

I am sure that there is MORE (much more) to this. This post just represents a part of my consideration of trust.

Trust for me means - Getting Hurt

I am a very trusting person, if you ask me a question I will give you the answer, personal or not. Comes with the ADHD and lack of mental filters for what I should or should not say. I have gotten better over the years about picking my words more carefully so that I don't come across as so blunt or surprising, but I haven't stopped trusting people by default. I want it to be the case that people I am involved with trust me and understand that as a friend of mine, that I would likely move heaven and earth to help them, often times at my own detriment. This has made me try to limit the number of close friends I have - but the reality is that most people I see often enough I would consider my friends and they all get equal treatment that way. Move the stars if it would help. It is painful though because often enough that trust only flows in one direction, and for me its hard to turn off allowing me to get hurt or used more than once. That too has changed over the years, but I am likely still not as careful as my experiences would dictate about how much trust I provide people (including those that have hurt me more than once).

Trust can also hurt when I don't pick my words more carefully and a raw feeling escapes to the surface and out my mouth. It often comes as a surprise to the individual involved.

Why is trust so hard to get back

I think that this is only human, we tend to focus on losses more than gains leaving people less able to see how much was there in the first place. It means that we feel so much more keenly the lost trust, no matter how small, rather than all the trust that has been exchanged over time. Changing that around is difficult because people are not wired that way. Consider your avg. IT help desk and all the vitriol they get tossed their way, no one ever calls them to say "Hey, great job your doing". We unfortunately focus on the negatives. Feels odd to me, because I get burned and go running back in, I wonder what does happen when you let go.

Enterprise source (Open source for the enterprise)

noreply@blogger.com (vwdiesel) — Tue, 05 Apr 2016 18:40:00 +0000

What is enterprise source

Enterprise source for me describes a way in which I can manage software development that involves more than just 'my' team in order to accomplish a given task within my organization. In a host of ways enterprise source mirrors how an individual contributor would work with any open source software project - building up a change that adds a missing feature or fixing an existing bug and then submitting that to the project. What I build/submit might be something of value to everyone, or it might only be of value to me specifically but it is up to the project as to decide if what I submit is worth while to merge and make available as part of their project. The same process is used in enterprise source with some interesting hitches that are worth noting which we cover in slightly more depth later.

Why would you want to do enterprise source

So - in the very small scale of the word organization you likely wouldn't have need to do this at all. If your a company of 10's of developers there may not actually be any occasion to do this at all. Enterprise source however makes a great deal of sense when you are a corporation of significant size, multiples teams doing work across the organization. In the the large corporation sense what you would like to have is teams that are decoupled from one another in a way that allows them all to move to deployment and delivery independent from one another. Different teams will have different product drivers and potentially be working on completely different lines of business that require them to operate independently. At deeper levels in the technical stack however the teams may all have to interface with a back office, or an API set.

In the typical organization the team in control of the API set will have their deployment schedule and will take stories and other content for delivery from teams needing things around them. The stories are organized and prioritized but may not meet everyone's needs. So rather than ask them to write the new code, I give the requesting team (the one with the need) the ability to write the new code into the API code base. Here is where things start to get really interesting.

How does it work

So now I have a change that one team can't do but my team can in order to essentially 'unblock' myself to move forward. Awesome. That API team allows me to submit code to their code base a-la Enterprise Source and get it deployed to support the actual feature function my team was asked to produce. I write what I need following their guidelines for development and using the information that they have provided to me in order to work in their code base. I make my change and submit it for code review which gives them the opportunity to give me feedback on the change my team was looking to make. A few rounds of code changes back and forth between my team and the team I am submitting code to and then the code is merged. That team then deploys on their normal schedule (hopefully following continuous delivery, so as quick as humanly possible).

What are some of the pitfalls

There are some human and technical drawbacks to this way of managing code bases and dealing with things inside the organization. Lets start with the technical drawbacks:

1) Who owns the machinery / hardware that gets deployed to

So my team submitted code to another team and they have deployed that code to their existing hardware providing me with access to the endpoint that I just wrote but this doesn't address situations where what I needed isn't like what anyone else needed. Now things get a little odd because with my team and the team I submitted code to we need to decide if new hardware would get stood up. Who manages that new hardware? Should the new hardware be something I deploy to all the time? Is the deployment in control of the team who 'owns' the code OR is it the responsibility of the team that submitted the code to get deployed? This can get messy quick. This writer also doesn't have a direct answer to these questions. It is an exercise in experimentation to find out what path works best for your teams and your organization.

2) Who owns the deployment process

As noted above this is a decent sized question that goes hand in hand with which team owns the hardware. You might be able to make use of the existing system for deployment easily, you may not and this will vary from team to team as while the infrastructure you are working on might very well be the same - in any company of size - the use of that infrastructure will differ and MIGHT differ greatly.

3) Arguments about the submitted code being 'Up to snuff'

Remember that in all cases there are humans involved so as a result personalities may clash. Teams should be aware that this is an almost 100% guaranteed conflict. As the owning team looks at their own internal process and moves the cheese for other teams that are submitting code to them. Things like code review, code style, testing style can become quite contentious if the discussion is not held in the open.

Benefits and impacts to the organization

The benefits to the organization focus mostly on allowing parts of the organization to slide past one another in a way that allows people to continue to move forward producing value. If one team gets blocked by another, dates become a discussion and people start to play games with he said / she said about when something might be able to be delivered. If teams are completely autonomous and allowed to do work at their own pace, then they control the dates and the delivery to their requester which prevents the dependency from causing to many if any issues. This form of organizational lubrication can be amazingly helpful.

Enterprise source is an excellent way to allow sections of the organization to share a common core code base and to continue to deliver on promises when everyone cares about the quality of the submissions and ownership of that shared code. If you find your team having dependency on another teams code base but they don't have time to make changes for you - consider offering to make the changes for them. Its a conversation starter that may lead to having a more open code environment for your organization.

Living with the gray areas

noreply@blogger.com (vwdiesel) — Sun, 03 Apr 2016 18:41:00 +0000

Agility is about living with the gray

In our travels as technologists we are constantly engaging in conversations with people about how technology works, should work, or has worked in the past. We spend time considering what we should be doing next and helping organizations to navigate through their individual challenges while attempting to deliver something great to consumers or simply to make the organization run smoother by utilizing technology to automate those things that are hard. We technologists write code, discover new things as we go along - our job as technologists is to live in the area outside of the known paths - we live inherently in the gray spaces where things haven't yet completely solidified. The idea isn't new but is just starting to come into power, this idea of living in the gray spaces was brought to light when the Agile Manifesto was penned - the manifesto opens with the following:

"We are uncovering better ways of developing software..."

Indicating that we don't yet know all the ways we might achieve what we set out to accomplish, but we'll discover at least one way. Along the way we may find many ways in which things don't work as well - but in doing so we'll learn what OUR path should be, or what path works best for us in a given situation at a given time.

Software development is all about living with the gray

When we as technologists (developers or otherwise) set out to do something new or to make changes to a system that already exists we are asked to 'create' something that meets a described need. When we start out, we may not be entirely sure how we are going to do the action of creation. At this moment we are confronted with hundreds of choices and hundreds of potential directions. We may feel a little overwhelmed but we are relatively well practiced at living with the gray space that choices create. We quickly navigate through the list of things we know, the list of things we don't know and start to devise ways in which we could experiment so as to understand what we don't know and "clear the fog" from the gray areas in our understanding. We may write example code as a way to experiment, perhaps a scratch refactor of existing code to fit in a new feature or trying something completely new by picking up a new technology or a new software stack. We use these techniques to help us get through the gray areas, solidifying things as we go.

One of the big problems is that while technologists are aware of and deal with gray areas in their understanding fairly well, most people that they deal with do not.

Humans deal with gray areas poorly

Inherently we humans seem to like control or at least to think we are in control. Uncertainty makes us uneasy. Equally, when there are a great number of choices that we could possibly choose from,  we feel trapped and our fight or flight reactions start to take hold. Outside of technology this is actually quite un-nerving to most people. As I stated above just about everything in technology is about living solidly in the gray areas and slowly working to make them less gray and more certain. The businesses that we work with and for however don't see things quite that way. Every company I have ever worked for would like to think that software development is an inherently known quantity, that software development easily equates to something that they know is straight forward like building things or assembling items. Software however is a creative process that defies being estimated up front. At the very start of a new endeavor we might be able to provide some context and information which can inform an estimate for how long it will take to accomplish but we should allow that initial estimate to more accurately relate to the gray that surrounds it, all the things we don't yet know. That first estimate should have a confidence interval - say 25% confidence with a list of all the gray areas that surround this beginning estimate and a set of steps for how those gray areas will be solidified and more well understood. This changes the discussion from - "Are we on plan for finishing X" to "What did we learn today and how did it impact our confidence we'll be able to do what was asked".

In short...

Software development, and by extension Agility, and other software development frameworks/methodologies have to help us deal with the gray areas. The systems we choose to use when developing software should allow us to embrace the gray areas. Frameworks we know about currently, Scrum, SAFe, Kanban all describe ways in which we can get context around what we are doing and allowing us to wipe away the gray. We can use small experiments to guide us to better places. We can learn to fail fast, as the faster we fail at doing something the more we learn. We can embrace the gray areas because that is where the learning is and it is where we expand our horizons.

It is a small world after all

noreply@blogger.com (vwdiesel) — Tue, 01 Mar 2016 03:12:00 +0000

In my travels I have met all sorts, people that mope, people that smile, people that bully. I have met people all over the personality spectrum including some folk that lie on the outskirts on either end of the spectrum. I have run into some unusually kind people, the folk that make you wonder if they are trying to pull something over on you - like they can't possibly be real. I have also run into some unusually cynical and bully types, individuals who for what ever reason, are hell bent on thinking that everything sucks and because it all fucking sucks your life has to suck too.

Why is this interesting?

Over time I have been exposed to the following idea over and over again:

You never do know who is listening

Now the people that told me this were attempting to instill a word of caution. Those individuals were trying to get me to see that the world was smaller than it looks. They were attempting to let me know, without being paranoid, that the person you talk to today may be the person to give you a job tomorrow. That someone listening in on a conversation may be the individual in control of some portion of your future life.

I was young, and stupid, and often driven by spite and certainly by revenge. Some of that is still true today. What I don't do as much anymore though is be spiteful, or seek revenge actively. It doesn't serve me, it doesn't serve others and it only leaves a minor impression a small uptick in my personal pleasure. It isn't a long term play, being spiteful and revengeful is a short term gain and doesn't look for the long benefits that can be had.

A manager once said to me...

Right, always wins. Eventually you'll be in the position...

He was absolutely right - as the situation that he was commenting on came to pass where I was the hiring manager in a position to provide or deny a job to someone who was at the time a complete dick.

"Anyone ... to show my skills can go fuck themselves."

So here is a thought, no matter how bad the interview, no matter how terrible the conversation - don't leave a note telling the hiring manage to 'go fuck themselves'. You just don't know who is reading, watching, listening and the tech community is just a little too small to burn bridges, or in this case toss some C4 into the middle of.

The lies I tell myself

noreply@blogger.com (vwdiesel) — Tue, 17 Feb 2015 02:17:00 +0000

When I was younger (now a great deal younger than I care to admit) I went to school in the Radnor School district in Pennsylvania. Radnor Township is one of the richest (in terms of per capita dollars) areas in all of Pennsylvania, my family and I however - were not on the same scale. I started my school experience with 1st grade @ Ithan Elementary.

I was socially different than most of my peers. This was not immediately obvious to me in school till I got to be in 4th and 5th grade. I tended to keep to myself finding it difficult to relate to those around me. I was tall - freakishly so for my age, which made it difficult to keep me in clothes that fit. I almost always had flood waters for pants as I would sometimes shoot through two or three sizes in days or weeks. This contented with my desire to just blend in because it was easy to see, and by extension make fun of, that fact that my clothes didn't fit. Not to mention that I wasn't at all interested in the word 'style' as it portended to what I wore unless it was possible to prevent additional ridicule. The problem with that was our family often was not able to purchase the 'stylish' things due to their cost. I still have memory of having one of those one piece snow suits and not being able to put it on completely during winter recess and the boy that punched me in my gut that same day because I decided to stand my ground that one time that one day.

My years in the Radnor school district left me with the jaded point of view that I shouldn't really care what other people think about me. I made a point of attempting to look past what people were whispering (or so I thought) or even pointing or saying directly to my face. I convinced myself that despite the fact that I see these people almost every single day, that at some point none of them will really be a part of my life and that their thoughts and opinions didn't matter because none of them were taking the time to get to know who I was, what I liked or disliked or even what I stood for. This idea permeated how I went about living my life. I didn't care much about my appearance - I was barely kempt by most male teenage standards.

So - why is all that back story important?

I realized something for myself the other day, I actually do care quite a bit about what people think about me - that I was lying to myself and others that I didn't care what other people thought about me. You see - I am amazingly empathetic and I connect with the thoughts and feelings of others easily. So easily in fact that it is somewhat like slipping on a shoe, or a comfy pair of socks. There are cases where that empathetic ability doesn't work as well - but for most cases, it works all too well.

Over the years I have come to think of this empathetic ability as a super power, because so many people don't seem able to connect with others the same way. The problem is that this connection, the empathy with others, drives a level of caring that in a great many ways I wish didn't exist. My empathy makes it hard to separate my feelings from those of others around me as a result I find it amazingly difficult to be around large crowds, public speaking is really hard, walking around in large cities like NYC are a drain to me. I know how to close some parts of my ability and myself down to try to prevent from getting drained - but it is difficult. I have a strong desire to be valued by those people around me, those I have chosen to be with at any given point in time.

I also find that my level of caring can be adjusted - caring more for those closer to me, that I can discriminate a bit, generating higher trust with those that are closer to me. I have learned that it hurts enormously when I misspeak, or misstep with someone that I care about, because trust is hard to rebuild, and I don't have a time machine to go back and say things differently than I did even if I want to. I have also discovered that words chosen un-carefully are a wonderful betrayer of intent just like a poorly timed or written email, txt, or tweet. I try to make those missteps and other events be learning events for me because no one is perfect and I am certainly no exception.

I said when I was a kid - that I leave my heart open, my being open, so that others can see and be involved with who I am and that by doing so I was also open to an enormous amount of hurt. This is still true today, the difference is that because of the history above, I am more discerning about how I care about being hurt. It hurts more when I screw things up with people I WANT to have in my circle and less with those I can keep further outside - but my lack of caring isn't an absolute like I thought it was as a kid. I am still learning how to deal with the ebb and flow of trust as a result of my caring. Still learning about the ebb and flow of value that comes from the people I chose to be with and those that chose to be with me.

Here there be Dragons - take care, step lively and be ready for the good and the bad. Still trying to figure it all out at age 41.

Generativity, an open door policy

noreply@blogger.com (vwdiesel) — Tue, 25 Nov 2014 02:30:00 +0000

So, I have had some time to sit and consider what it is about software projects in my work a day world that make for successes and what things make for interesting types of failure. Here is where my thinking landed me:

1) Being open, and inviting is a benefit not to be undersold

It sounds so tantalizingly simple when you type it out like that, so much so that you might read that line above as "...If you build it, they will come..." but that isn't quite what that line means.

When teams develop new software, the software being developed is sometimes about a new feature or a new thing that BigCo. wants to have as a product and sometimes is to scratch an itch that the team has. In either case, this new software is likely to be able to assist a whole bunch of people which same or similar needs (it is unusual for software to actually be built 100% single purpose). Because most software can actually serve many 'close knit' needs, once you or your team has taken the time to build, you should also take the time to advertise and allow other teams to make use of what you have built. Being open, means no matter what you develop that you essentially open the door to others to build, manage or deploy with you. Let other groups make use of the things you built, with as few a number of restrictions, provisos, caveats as humanly possible.

2) Protect the system, but keep the number of rules as low as you can

This is somewhat self explanatory - try to only put in place those rules that help you to make sure that the system is up, available, and working correctly.

3) Trust people to do whats right

When you open the door - you are opening your system up to whatever may come. To that point, you have to be able to trust that peoples self interest will also align with you and yours to some degree. Try to keep a light touch and trust that people will not go out of their way to screw you - or the system you built - that they are now using. If those who have been invited in through the open door do take advantage, know in advance how you would like to react to those coming to seek your new hot thing. Describe your "open door" so that people know what they are signing up for in advance.

4) Don't fall into the trap of N.I.H.

Part of doing work this way, with this mind set, is preventing yourself from going off into a corner and building it yourself because:

* You believe that building it yourself is the only way to control your own destiny
* Your team can't possibly be successful because your success is dependent on another team

It will always be simpler to modify something that is already built than it will be to go from scratch no matter how good your developers are. Work already done can trump work to be done in a great number of occasions.

5) Command and control will squash peoples desire to use what you build

Don't try to control the software and how its used too must - exercise just enough control to manage and maintain the quality of the system. I have seen plenty of people that believe that becoming the manager, exec, vp, director or what have you is all about being able to do it JUST the way they want. Nothing really could be further from the truth. The farther up the chain you go, the less desire to control you should have and the more trust you have to have that things will head in the right direction. If you attempt to stringently control things, no one will want to come be a part of the thing that was built and like holding a fist full of sand, the harder you squeeze the more sand you will lose, no way to hold it all.

Be open, be inviting, be willing to negotiate and understand how people will want to use your software. Be generative - providing space for people to get the most amount of benefit out of the building blocks you have already put together. It will eventually help the bottom line because everything being built will start to move faster, eventually.

A world of change

noreply@blogger.com (vwdiesel) — Fri, 21 Nov 2014 01:43:00 +0000

There are about a gazillion reasons we can come up with, all of which sound logical and justifiable, to avoid change. The #1 reason change gets avoided? People would prefer not to deal with a necessary change until they absolutely have to. As long as life is basically functioning, most people are happy to just not stir the pot. Everyone grows slightly complacent and they settle into a routine which they can wrap around themselves like a warm blanket. I am as guilty of this as the next person. I find ways to focus on work, focus on side projects, focus on anything other than those big blinky, claxon-y, signals that are trying to tell me to break from my routine and pay attention. The world is an interesting place - it is difficult to have the presence of mind and body to focus. If I am the only thing I have control over in the world however (which is true of everyone) then it is 100% up to me to break the trend, remove the blanket and attempt to change, hopefully for the better and hopefully in as much truth and honesty as I can muster.

Thank you world, forever grateful.

Roles for Making a great (software dev) team

noreply@blogger.com (vwdiesel) — Thu, 30 Oct 2014 12:51:00 +0000

I wanted to take the time to try to document the roles I think make up a great development team. This is essentially that raw brain dump - would be very interested in engaging discussion and conversation around these. What do you think - how has it worked for you - would you refine these in any way?

The Constructive tinkerer

This role describes a person that spends time looking at the problems that are facing the team and looks for ways to solve them. The solution can be already contained in the things the team does or may be something that team has not yet thought of or is currently using in the way of technology. This person spends the time to investigate, research, experiment with the different, better, worse ways of doing what needs to be done inside the team. This individual is often not directly involved in the shit triad*, meaning this role is often not doing product development work but is instead creating nice paved road surface for the folk who are part of the shit triad* to move faster and get more done in shorter periods of time. The work this person does tends to lay the ground work for a great deal of other work that the team does. Clearing the path and making things easier, more visible, more operational.

Additionally - this role spends time providing guidance and mentorship for the other members of the team. Sometimes the discussions being had are technical in nature, things like "How should I implement this new hot thing that product asked for..." and sometimes the questions/discussions are procedural and more team oriented... "I think that we need to make this type of error more visible and loud so that we can find a root cause and eliminate it." This role plays a part in providing a sounding board for a great number of activities in the team working to help the team understand the aspects of their software running in a production data center with real users, whom we want to delight - not make angry.

The key for this role - is that the tinkering with things, the new code, the clean up of old code, the discussions are all oriented in positive "We will use this ways". When the result of this roles tinkering isn't useful to anyone, the person playing this role doesn't get upset, nor defensive - they simple tuck that work away for some later time, or they drop the work all together. The constructive tinkerer is focused on what the team working with them needs. Decisions about the longevity of something are biased towards team needs and wants but balanced with what the larger organization needs from the team as well.

The curator (Those that care do)

This is an oft overlooked role for every software development team. This role may not even be a single team member but encompass how the entire team thinks about the code base that they work in every single day. The curator(s) are those that are deeply invested in the well being, well meaning, and intention of each and every part of the code base. Curating the code is important because as we all know, code that is no cared for tends to suffer from:

Bit Rot
Code that is left to sit eventually rots away. Of course it doesn't actually rot, but what does happen is developers lose touch with what the code was supposed to be doing. There is a lack of documentation, so there is no longer any institutional knowledge of the code and no way to gain it other than wading back into the code base to find out whats in there. Bugs stop getting fixed and people eventually would rather replace all the work than 'figure it out' all over again. This can be avoided when there is a curator around - because they are constantly looking at what can be made better - seeing where problems are and will get upset when something sits for too long without getting any touch/attention.

Different points of view
It is rare these days that a code base have a single developer. All the code that I work on is managed and maintained by either a team or multiple teams of people. The curator has the un-envious job of reconciling the differing ways that things in the codebase are accomplished. Ties are broken, discussions are solidified into a 'way' in which the code will represent a specific thing. The code gets cleaner as a result. Differing points of view have to be recognized and addressed by a curator or you will easily be able to tell which sections of a code base were written by whom based on taste and patterns of development.

New developers
New developers to the team are simply new and have to be shown a way. This demonstration is made easier when they can see that the code base looks a certain way and does things in certain ways. This is made better when they are also able to consult a curation individual for a team. Work can be made even cleaner when new developers know that there is a pattern that exists that they can follow and that the team is open to discussion for new ways and new ideas to change existing patterns.

New shiny thing
A curator helps to combat running off and implementing the next hottest, best, new, shiniest thing in terms of development. Sometimes new patterns and new ways of doing things are beneficial or needed. A curator helps to understand how that can be phased into the code base and how existing patterns can be touched and adjusted as a result. The curator helps to understand how much time and effort is involved in moving the WHOLE code base into a new direction or if the new thing should only be used in certain locations under certain conditions.

Those supporting the shit trinity - Knows Shit, Gets Shit Done, Gives a Shit

So every team needs some number of people that have the ability to get things done... and get those things done well. Those that support the shit trinity make up a fair majority of a team and ideally everyone on the team would fall into this category to some degree. This means that everyone on the team has the ability to play a roll in accomplishing the goals that the team has set out to accomplish. Sometimes the goals are development oriented and related to software design and coding, other times the teams goals are about the process that they use to get their work organized and ready to work on.

The helper/garbage man

You always have to be willing to take out the trash. This is another role that the entire team should be adjusted towards. The garbage in the case of a development team is the grunt work of fixing bugs, re-organizing code when it makes sense, basically anything that would be considered the bottom of the barrel in terms of development effort. The tasks involved are generally just tasks that need to get done in advance of getting to the nitty gritty of some new development that has been planned. Every team needs at least one, and hopefully the entire team would be willing to do this work because they know it is necessary. Having the team be adjusted to taking out the trash means that no one on the team feels like it is demeaning to have some amount of their work be involved with taking out the trash in the code base.

The adage that I think goes with this is that a good manager, exec, CEO doesn't believe that certain tasks are somehow beneath them, they see that it needs to get done and that currently no one is doing it so they go in pick up that slack and get it accomplished and then later look for ways to not miss getting that bit of work done in the future. For a team - this mentality in at least one person has to exist both because it is necessary to pick up what is left behind but also because it encourages others to also pick up what is left behind. In essence having an individual on the team that "takes out the trash" encourages people to not throw stones at already broken windows but instead to fix those windows and move onto something else.

The thinker (although they all have to be this way to some degree)

Software design, architecture and over all capability of the code to do a given task takes thought. It is not something that flows from the fingertips of generally smart people perfect the first time every time. Software development is a thought process, a process sometimes of trial (doing what you think will work) and error (seeing that what you did doesn't work) in order to get to the point where something is produced that meets the requested/stated needs of the larger organization. Sometimes the thinking on the team is encapsulated in one individual but I find more often that while one individual seems to do a great deal of the thinking/design that everyone seems to rally around that "nucleus" adding their own identity and thought process to the original. Making the thinker role more of an instigator role most of the time, using the power of the group to find all the holes in a design, to talk about all the corner cases in what we are doing and to aid in preventing the entire team from backing themselves into a development corner that they can't get out of. The thinker/instigator provides that stable guidance for architecture so that it evolves and morphs rather than needing a revolutionary re-write to get the team out of a bind.

Verifiers (although they all have to be this way to some degree)

Everyone should be interested in verifying their work. Sometimes this is a single individual that acts as the last safety valve for a team, making the last checks, T's crossed and I's dotted before the result of a development cycle, no matter how large, is verified to be doing what it was expected to when the development got started. In our team this has been encapsulated into a final check before deployment of the out put of the API. When we are getting ready to do the deployment for a given day, the code that has been worked on is deployed into a staging environment and then a script is run to look at the syntactic differences in the output of the endpoints in the api space. Differences between Staging and Production are noted, discussed and either acted upon because they were unexpected or dismissed as expected due to the code being deployed. Taking this action in the form of tests that each developer wrote during their development in the early part of a cycle and doing this final check at the end causes us all to 'verify' our work. Similar to the thinker above - when the team sees that this is expected they tend to start executing that way on their own with little to no nudging required.

The reporter - Someone has to tell the world

In the end the WAY in which you work is important, but just as important if you want others to work in the same way is that you go and tell them what you are doing and how you are doing it. Enter the reporter of the team. This is someone who likes to taut what the team does and succeeds in accomplishing. In a shout from the roof top sort of way this individual helps the success of the team become more common knowledge and more well understood by other teams. This helps to spread ideas and processes and allows others to start to ask questions as they investigate their own teams and how they operate to accomplish the goals they have set out on.

Please stop RESTfully abusing HTTP

noreply@blogger.com (vwdiesel) — Fri, 30 May 2014 15:01:00 +0000

So I have noticed this rather disturbing trend while building, deploying and consuming REST service(s) and it goes something like this:

"HEY all - Lets build a REST service to meet our new product need."

Every one in the room nods and says - "That is an excellent idea." They have heard the buzz word and they understand HTTP fairly well so they feel like they have an excellent bead on REST. People may even do a little light reading on the internet around the topic. They will understand that they can use HTTP to take actions on resources. There is however an odd understanding that creeps into the discussion and that is how to go about representing both good and bad states for responses to the caller.

The most annoying representation I have run across thus far is:

POST ${JSON} … 200 OK {status: error, reason: SYNTAX}

Caller posts to the endpoint over HTTP, a json object. They get back an HTTP status 200 (indicating everything happened ok) with a json body in the response. That json body has an ERROR IN IT! This relegates HTTP to nothing more than a transport protocol. So you look at the above and you say - "...well, whats the big deal with that - looks ok to me."

HTTP 2XX Status Communicates Success to Clients

First and foremost amongst the problems with this pattern is that HTTP clients of all varieties expect that any response with a 2XX class status code can be considered success. This is in the HTTP spec and is what a large number of clients in a variety of languages understand. When I am attempting to write a client against this service there is no way for me, just looking at that HTTP Status code, to understand if my request actually did what I wanted or errored out in some way. Doing this forces the receiver to need to inspect the body of the HTTP response, breaking a programming tenant I have personally had for a while, FAIL FAST. Because I can no longer rely on the nice fast HTTP response header and I am forced to actually read the HTTP body - I have to read the ENTIRE body to see if there is anything in there that would tell me what went wrong with my call to this particular service. Which brings up the next problem.

What format is the Body in: Parsing??!?

So with a client now not being able to fail fast and being forced to read the entire response body what other problems are there you ask? Well how about, the format of the body? Is the body json? is it XML? is it some binary format? HTTP has a way to tell you what was sent with Accept/Vary header combinations, but in all those cases I have to essentially parse out the response in some way. What if that parsing FAILS? What specific format does the response have to be in in order for me to correctly interpret the type of failure that has occurred? Does a failed parse attempt lead to a generic error? a specific error? What do you tell a calling client when its not something the client can actually do anything about? Suffice to say this is a mess. It can be cleaned up a bit - you and your clients can specify what format these things should be in and where you can find specific error messages and other information, however HTTP spec already provides all this information for you in a standard way if you were using it the way it was intended rather than treating it as a simple transport protocol only.

I hear you screaming

I understand that it isn't always a clean mapping between good/bad things that the APIs do and an HTTP status code that currently exists, but you should at least try to find simple ones that make sense and then look for consistent and reasonable HTTP extensions that give you specificity that you need. Take for example returning a 403 Forbidden as an access exception - and then returning a header in the response with a subcode indicating WHY that specific request was 403'ed. Example, HTTP status 403, X-SUBCODE-ERROR: 101 X-SUBCODE-REASON: User over allowed limit at this time.

Please do not RESTfully abuse HTTP as a mere transport, use what you know, fail as soon as you reasonably know you can and for god sake, please don't make me have to parse a response body in order to know what went wrong.

Transparency - These are not the facts you're looking for...

noreply@blogger.com (vwdiesel) — Fri, 23 May 2014 13:59:00 +0000

Oh recurring words, why do you haunt me so. This time the recurring word is transparency. I will focus this post to focus on the transparency in my work a day life as I believe my work and interactions going on at work are what triggered the recurrence of the word "transparency" and allowed me to see how it surfaces in other areas of my life.

Transparency is an interesting word when referring to a 'person' - thinking about this term evoke images of windows, cellophane, things that you are able to see through. When applied to a person I can here cliche sayings like "...Oh That guy - Yeah, he's an open book... as transparent as they come." Whats interesting to me is that a state of being or feeling transparent also falls along a broad spectrum of feeling. Feeling transparent evokes images of feeling sorry for oneself, of being the 'Wall flower' in the room. No one sees you, nor understands who or what you are. In the work setting though neither of these two types of definition is what people mean when they talk about transparency. In the work setting of Big Co. - transparency seems to mean providing a window into the 'items' being done by a person or group in a digestible way for the original requester of said information.

OK - Pause that statement is really tough to parse. Transparency (at least in Big Co, even if I don't happen to agree with the definition) in the work place is often defined as:

Is a person (not me) able to understand without asking me what was getting done by me or my team, what was planned to get done and how far along that plan had me or we gotten. In a loose sense transparency in Big Co. is quite synonymous with a reported status from me or the team I am working with. So lets break down the various transparency layers that might exist at Big Co.

Transparency with co-workers
Transparency at this level should be easy, these are the people that you work with after all. Wait you say, I don't like some of the people I work with... YIKES! Transparency at this level, I believe, requires a vulnerability on a personal level which will be hard if you don't happen to like the people you work with. You need to be able share life stories, kick back and enjoy some time together in order for those you work with to feel like:

1) They know who you are
2) They know how you will react in certain situations
3) That you will provide them with information you have

Transparency with your co-workers is about trusting that those working with you will understand and take care with what you share with them. Transparency doesn't mean they need to know every little detail of your life in and out of the office, but showing them you are human and have a number of the same life situations and issues that they do allows you to connect, and for them to FEEL like you are transparent to them.

Transparency with (direct) subordinates
Transparency with people that report to you is a different matter, but not entirely. Trust is still at the core of how people feel about reporting to you. Being transparent with people that work for you is about providing them content and context for the work they are doing. Transparency for a manager on the front lines is about connecting the workers to the work in a way that they understand and can engage with. This is a fine line, because it is possible to give them too much or to let your own opinions color how you deliver the information. However as long as people don't feel like you're hiding information from them, you can easily be seen as being transparent.

Transparency with (in-direct) subordinates
Transparency here is a great deal like transparency with direct reports, the same things apply. Still trust is a must, relationship growing is harder but just as important. These people my not be on the same floor or even int he same building - but to be transparent with them is to provide the 'windows' into what and how you are doing things that allows them to feel like they understand. Here - you have to invite them in and show them the house but you don't have to tell them how the house is wired for them to feel comfortable. Outside groups will make certain assumptions about how the mechanizations in your team operate but you may not have to correct them even if some of their assumptions are off or flat out wrong. Just make the information that they are interested in easy to get, and read and let them see it. They will feel you are being transparent.

Transparency with managers
So transparency from the lower levels to the higher levels in the organization is likely a much larger sticking point. In Big Co. managers and managers of managers have a tendency to want to be 'TOLD" rather than have to go "DISCOVER" how the work works or how the work is doing. This drives directly at my commentary above about transparency from bottom towards the top often seems to take the shape of a status report or other document. This status can not possibly communicate all the things so it has to be boiled down to the 'most important' but manager will often have missed the part where they provide a priority and a context to what is 'most important' meaning it is left as a guessing game. This guessing game, a mind reading game, is difficult to get around. Being transparent here is about providing the information in the best way you can, allowing the teams you work with to 'see' that you are doing that so that if there are errors in communication they can be directly and reasonably corrected. But in the end I think managers would be better suited:

Going to the Gemba
Managers should be interested in seeing the work for themselves now and again. They should be visiting with the teams doing work on their behalf, asking them if they have any questions, if they feel that they have what they need in order to do their work. This makes this higher level of transparency super easy - because the manager can see what is happening and ask questions about it. Conversations and details can break out in a real time way rather than disconnected by a document that is out of date the instant it is written and emailed.

In the end - transparency has so many different facets to it. Transparency shouldn't be about status - but in Big Co. it is, so be it. It is important then to know how to have and use transparency in the work you do. It will help you move in the organization when you would like to because people will know what they are getting rather than feeling like you're a surprise waiting to happen.

its not all dark and dangerous...

noreply@blogger.com (vwdiesel) — Wed, 01 May 2013 21:53:00 +0000

So as I have now become somewhat accustomed in recent months, words that keep showing up in my life trigger me to go into thinking about them and trying to understand what I can get out of them. The most recent of these words is "HELP". I spent 45 minutes talking about asking for help with some wonderful people in the Open Space session @ the Lean Kanban North America conference. The thoughts and discussion were amazing and helpful - and are incorporated in this post as well.

Help

The word evokes many images in my mind. I see pictures of someone in the water, unable to swim or unable to fight the current in the water and yelling for someone to come and help them. I see pictures of homeless people on the street with signs and cups seeking money from passer bys to get themselves their next meal or a warm place to sleep for the night. Pictures of friends and family members and the various things that they have asked for help with over the years flash by. While thinking about all those pictures it occurred to me that there is a picture missing that I think should be in the mix - and that is a picture of my co-workers asking for help. You see, in the context of work we don't seem wired to ask for or receive help from others.

Being seen as a burden

Asking for help in the work place is essentially to be seen as a burden on the person being asked for that help. This burden mentality seems to stem from the idea that asking for help is something that places one into a vulnerable position - and that vulnerable position then translating to a weakness that an individual shouldn't be showing at work. Why? Because if you are vulnerable or weak, then at work there is no way that you can possibly advance... you know, because you don't know enough of the right things. Suppose that you don't ask for help - you may still be seen as weak because it took you too long to learn or uptake something that so many people already know because they learned it previously at the organization. This too can reinforce a lower stature perception of people because everyone else looks with a bias - a bias based on having already learned the information which took you too long to learn. Asking for help means being vulnerable with someone. Asking for help means placing your desires out into the world and in most cases into another persons hands so that they can attempt to fulfill the request.

Everyone needs help sometime - even more so at work

So here it is, everyone will need help eventually - I think it is an inevitable fact that can not be avoided. People do seem to have a huge stigma against asking for help however. People who ask for help too often can be a burden, people who ask for help on simple things are seen as dumb, people who pander for money are seen as beggars and expected to go get a job. Some of those perceptions may be true - those people asking for help, MIGHT have been able to help themselves and the temptation is to assume they SHOULD have helped themselves. The assumptions around help generate a feedback loop that prevents seeing that someone might genuinely need the assistance. A trap is formed that essentially prevents people from being able to seek the assistance they need in the first place because we don't value people in our work place or in our society being vulnerable in the slightest. You need look no further than the things we tell our children when they get injured ("...Oh you'll be fine just get up and rub some dirt in it...") or boys when young about showing their emotions ("...stop sobbing, boys don't cry..." or "...man up you sissy...").

The human animal

Being vulnerable when asking for help not being a desired trait goes against what some would say is ingrained into our being in the world in the first place. The human animal is a pack animal, we want and need interaction and conversation by our very HUMAN nature. Too often we attempt to drive this part of ourselves into a corner however treating one another as soulless automatons that can do everything for ourselves. Humans are beings that need the touch, the nurturing, and the help of other human beings. Humans need to be connected to one another - help and help seeking is a way to take that care with someone else.

Practice makes perfect

Amanda Palmer has a TED talk that is all about the art of asking. Help and asking for it is something that can be practiced. People can practice knowing when to ask, what asking looks like and being gracious and generous when asking for the help that they need. In short - we all need to understand this and practice, practice, practice. We need to have the shared understanding of these 'help' interactions with one another. There needs to be the ability to see a request for help in all of its many and varied forms - being able to see it - REALLY SEE IT, would drive people to be so much happier than I think they are generally. Connections would be made - life long friends, a spark, a touch, were the connectedness we all know are there would show on the surface so everyone could see. I will be practicing this skill as much as I can in the near future... you should too.

Date Chicken

noreply@blogger.com (vwdiesel) — Sat, 12 Jan 2013 17:44:00 +0000

Through out my software development career I have been trying to understand how things work, actively pursuing the thought processes that people use to make their decisions. I spend time asking questions about the hows and the whys of what I am asked to do and produce. This action, over time, has produced a decent picture in my head of how software development should work and in many ways how it should never ever work. I have been able to understand the whys of certain actions and requests but the one 'action' for which I have yet to totally understand is the idea of software development "Date Chicken".

Date Chicken as I would describe it is the propensity of an organization to want to assign a date to a project without understanding or going through an understanding of the complexities around what has been requested to be developed. Date chicken comes about due to not having enough of the discovery executed such that any date that can be provided has to be provided with a long list of provisos and comments/risks about what in the world at large has to line up "Perfectly" in order to meet the date that is being published. So software development teams are asked to produce these "Plans" that indicate that we can meet the date IFF (If and only if) everything else in the world happens perfectly. What happens next, every other team produces the same sort of statement about their ability to meet the date and the fun begins. Management from each team begins to execute on the "PLAN" that has been produced, they organize teams, and instruct people on what needs to be done and they wait patiently for the first 'date' on the plan to come up.

Here the Chicken part of date chicken takes over. Basically the teams continue to plod along towards the date until that first date arises and a team has not produced the things that they 'said' they would produce and everyone else involved in the project gets to point out that 'their' dates will have to slip day for day with every day missed in the development team at the front of the train. Hence the 'Chicken' in date chicken.

Why is this so hard for me to understand you might ask - every software company of any size seems to do this...

Its difficult for me for the following reasons:

1) The date is a lie, perpetrated by someone else and then taken as gospel, which leaves me feeling like my management doesn't want me to tell the truth, ever. Ok - the date is not entirely a lie - because there is an OFF chance that the needed software shows up on "time" with high quality, but so far I have yet to see that happen when this game of date chicken takes hold.
2) Because the date is a lie everyone 'RUSHES' to turn out the thing that they were on the hook for before their date arrives. In turn this produces software of lessor quality, with production issues, that turns out to be hard to manage and maintain.
3) #2 causes our customer experience to essentially suck, driving the customers to complain or look for service else where, making my company look like the best of the worst.

I do understand that sometimes the date is important, there might be legal reasons or contractual reasons that a specific software development item must be completed by a specific date. However - when there is no specific pressure in this way, I would much rather have my management say "I want to give you the time to make the software 'RIGHT', and I am willing to wait to make that happen."

I don't think it appropriate for the waiting to be forever, but do think that a management statement that says something like "I would like to see something demonstrable in one quarters worth of time." or even, "I am ok to wait to get this right, but I would like it to launch this year" to be fine statements that reinforce the please build this right rather than fast. As we get closer to actually delivering the software requested it is possible to provide a VERY high confidence number on 'when' we are going to be complete. The further away from done however the less confidence in the 'plan' being the right 'plan' and the date, so much more a lie.

In the end - none of this is in my control, but I sincerely hope that it will be at some point if I either end up in a position to make changes, or have my own company making software. Date chicken reinforces all sorts of really terrible habits and I would rather not participate.

Courage

noreply@blogger.com (vwdiesel) — Sun, 02 Dec 2012 19:42:00 +0000

Courage

This is a word that has been showing up around me now for a number of months. This word would sometimes show itself to me deliberately, maybe as part of a conversation I was having, and sometimes would show itself to me in casual ways by showing up around me in my reading or in posts from friends. I had not been giving the word a great deal of thought though until this past day or two - which is ignoring my own rules about coincidences that go on around me.

So why am I bothering to write about it now? Life seems to be pointing me this way - so doing it seems appropriate now.

Courage is defined like this:

Courage, n.

The ability to do something that frightens one.
Strength in the face of pain or grief.

But I think courage goes quite a bit deeper than this definition. I think courage involves a great deal more than just overcoming something that scares or frightens. I think courage may involve a life time of things built up that may require being torn down before it can surface in a singular moment of overcoming what has been placed before you.

I would say that courage is not something that exists alone - it comes with fear, it comes with baggage and experience of ones past that can magnify the effect of a situation far beyond the regular "I don't want to get on that roller coaster." sort of fear.

Courage is something that seems to get harder as you get older due to carrying emotional and physical scars from everything that came before. Courage seems to grow to be hard because we all grow up and our social interactions start to take on apparent enormous meaning.

"Be who you are and say what you feel because those that mind don't matter and those who matter don't mind." - Dr. Suess

The people in your life that matter will be taking the time to understand who you are - they are the ones you don't have to careful around. Unfortunately we seem wired to also care about people who will not take the time to get to know who we are - we worry about bruising egos and causing trouble with the words we say. I am not saying that we shouldn't be observant enough to know when 'not' to speak, rather I am saying we are far more careful than I think makes sense.

From the movie "Finding Nemo":
Marlin: Now it's my turn. I'm thinking of something dark and mysterious. It's a fish we don't know. If we ask it directions, it could ingest us and spit out our bones.
Dory: What is it with men and asking for directions?
Marlin: I don't want to play the gender card right now. You want to play a card, let's play the "let's not die" card.

Dory spends time attempting to help Marlin to loosen up and to try things he has not or would not normally try. Throughout the movie Dory is challenging Marlin to see things in a different way - to see the things that are being missed rather than the things he is purposely doing. This constant pressure from Dory is forcing Marlin to ask 'WHY NOT' in relation to trying things - or allow others to try things. Dory is asking Marlin to bend his own internal rules, built up over time and as a result of Marlins having lost his wife. We can all get caught up with following the rules, when the rules are mostly self imposed and are not always in our best interest.

My point - doing anything courageous involves occasionally (ok, more than occasionally) overcoming a great deal of built up opinion, and baggage accumulated across our entire lives. The first moment of being courageous is hard, like going on a roller coaster for the first time, but each occasion there after gets easier and easier because we can see the positive benefits of having that courage in the first place. We have to be able to let go - and be ok trying the same thing more than once. We have to be willing to experiment with our lives, sometimes risk things more than we may like, but it is the only way to succeed in getting past things that may have hurt us in the past. Its painful to keep trying, and it can hurt - but you can not let it discourage you from doing so because the worst thing you could possibly do is give up.

Forward compatible data consumption

noreply@blogger.com (vwdiesel) — Sat, 01 Dec 2012 19:32:00 +0000

Forward compatibility means ignoring new fields should they arise ... passing them through if possible, ignoring them if they can't be passed through. i.e. FOCUS ONLY ON WHAT YOU ALREADY KNOW and ignore the rest.

This means in XML parsing, if you are using annotation based parsing - tell it to ignore fields and objects it doesn't understand and continue with the rest, or if manually parsing to only concentrate on known objects and ignore the rest.

Same thing for json, annotations (like Jackson) need to be told to ignore fields that can't be mapped into the objects in a known way and to proceed with everything it does understand.

This way other systems can include new information that could be consumed at some later date without impact to the system at hand.

Why is all the above at all relevant or important - these steps are vitally important to the compatibility of APIs that you might be developing. In order for the API to be forward and backward compatible as changes to it are made the API system must be able to accept new things or ignore things it does not currently understand. APIs have to hold themselves accountable for what they 'know' they can do - and things that can safely be ignored. If the API you are developing can't ignore things it doesn't understand, then errors get returned to the clients that may have otherwise resulted in a useable response from the API.

Agile Funding / Product envisioning - A lunch conversation

noreply@blogger.com (vwdiesel) — Mon, 25 Jun 2012 15:22:00 +0000

So - in a conversation recently where we were talking about how a large corporation like Big Co. deals with financing their programs, projects, products. The conversation turned to when is the appropriate point to include the engineering teams in the product development mix. The jist of the conversation was that similar to the idea in software engineering that it is terribly costly to use production to find basic coding bugs (bugs that can be caught with unit testing, and code reviews) it is terribly costly for product groups to be using engineering resources to test their theories about what the customers would like to see in the products that Big Co. produces. Adding to this conversation was an ongoing undercurrent of finance at Big Co. having a difficult time understanding how to measure and supply money to the organization in an 'agile' way, meaning how do you make the bean counters happy when talking about how to manage finances in an agile development structure.

So the question that followed from the discussion was - if finance at Big Co. is always looking to squeeze cost out of expensive things like engineering and they are having a difficult time trying to predict and forecast the overall cost in an agile development world, what is a way that product development could be structured that would make things easier on both sides (engineering and finance) as well as help the product folk find and refine their thoughts before ever having engineering develop anything?

I tossed out the following idea, what if you structured product development and finance in a pyramid like the following:

At the bottom of the pyramid, you have lots of really small, experimental teams. These teams could be made up of a product individual, an engineer, maybe an experimenter (someone to help setup customer experiments). Each one of the these teams would be financed based on the ideas that they are testing and each one would be given a finite amount of money, lets say $50k. Each team would also be strictly time-boxed to no more than 2 weeks work on a given idea/hypothesis. Big Co. could then run lots and lots of these little hypothesis tests and know for sure how much they wanted to spend because the dollar amount would be fixed to the number of test teams in flight at a given time.

Further up the pyramid each one of the teams near the bottom that uses the $50k they have been granted and produces a hypothesis that they can prove and have proven, a slightly larger team can then take up the mantle. This next step up gets a larger amount of money, lets say $200k, and their time box grows to something in which they can make the idea from the lower level a little more concrete and real - lets say 6 weeks (for Big Co. currently, this is two sprints worth of development). At any time these teams may run into insurmountable road blocks, or things that have no solution - in which case work can stop and they can move onto the next thing coming from the lower level. If however they produce something adding to the previous levels work, this can move onto the next level higher and be funded further.

Even further up the pyramid - we are getting to the point where things are much more well defined, there has been a fair amount of testing and verification of hypothesis indicating that the idea is sound and can turn into a product or a products new feature. The money granted can be quite a bit larger say $500k-1M or more. The time box to create can be slightly larger as well, say 24 weeks (half a year). I should note that increasing the time box does not mean that the shipment of this new thing waits for 24 weeks - it should still follow agile practices and be deployable at the end of every iteration (or in the Kanban case, after every story is marked complete). This is where the final delivery to the customer can happen.

At each of these levels the product team or business can choose to cut their losses based on real data from real customers saving them from having to finance what doesn't work and keeping the process moving as quickly as it can. This also prevents what I will call "Whim Based Product Development" because all the product work becomes based on testable and measurable facts.

Would love to hear your thoughts on these ideas - as they are just that, ideas. Like most things, they need work.

Your ORG Chart is a BLAME flow chart

noreply@blogger.com (vwdiesel) — Tue, 15 May 2012 21:27:00 +0000

Your organization's org chart might be more about defining a flow for blaming someone rather then helping you to understand how the organization actually works.

Traditionally companies create an organization chart to provide order to the madness and chaos. The org chart generally contains a name, and a title and provides this nice neat way to see who reports to who and who might have information that you might need to get. Boxes neatly contain people, grouped into other groups who report to managers who report to VPs and so on. The problem I see is that this same problem solving org chart can be used as a huge bat to bonk you on the head in an organization that values a command and control attitude.

In a traditional company (one that is likely headed for a huge spiral of death at some point, another post for sure) the managers all feel the need to manage. Managers are provided arbitrary features, that need to be done by arbitrary dates or at least it seems that way. Work items tend to lack context for why they need to be done in the first place. The missing context forces managers to attempt to fill in blanks with what they already know or can easily find out. This picture will be incomplete - but the all important DATE which was derived based on this information will be held sacrosanct. The team will work to deliver by that date, but will invariably run over and release some time after the original date. Sometimes this late delivery causes other things to slip and on and on.

No one is specifically held accountable for these date slips in the organization, but what starts to happen is that work items requested and placed onto a group but not completed begin to get noticed by anyone in that reporting tree on the org chart (remember that all important information dissemination device). This is a terrible reflection on the ability of that group of people from the org chart to deliver so blame starts to be laid. This blame may start at the lowest level, but soon works its way up the org chart and around the org chart following the connections on the org chart. This is a terrible feedback loop however, as blame makes people more defensive, and more likely to want to have really tight control over what is being requested and what promises are being made in relation to delivery. In the end - the org chart might actually be the worst thing for the company as it describes a way to shirk accountability off onto someone else for a failed effort.

In the reverse this same chart can indicate who to praise when things go right, but lets face it if your organization is already command and control it might be the exception rather than the rule that someone is getting praised for independent effort and thinking.

Imagine what would happen however if the org chart showed nothing more than how the 'teams' (cross-functional teams) related to one another, you might still be able to assign blame, but now its a team blame - which is easier to own up to and take accountability for. You org chart now isn't describing reporting structure and is less useful in providing a blame path and more useful in providing a way to discover where answers to specific questions can be had. It revalues the relationship of who reports to who into a teaming thing and a matrix idea. We might be better for a change like this in our companies.

Just a thought.

EDIT: I should add that this thought process was inspired by the comment from Claudio Perrone's presentation @ LSSC 2012.

Gentle Strenth - Wizdom Applied

noreply@blogger.com (vwdiesel) — Tue, 15 May 2012 20:43:00 +0000

My friend Karl Martino said to me one day a few weeks ago that I had wisdom. I laughed a little at the remark, which in retrospect I think I should apologize to Karl for as he was genuinely attempting to pay me a compliment. I thanked him but told him that I do not feel wise. I did however walk away from that conversation with a number of things spinning around in my head. These thoughts coalesced the Sunday of that same week when I was @ church, and my churches minister delivered a sermon on "Gentle Strength".

My minister opened with saying he was standing in a mess hall with the 3rd Battalion, 47th infantry regiment - waiting to deploy to the middle east with a peace keeping force. There were pictures hung all around the room with quotes under neath them - the picture above his head had the following quote:

"Nothing is so strong as gentleness and nothing so gentle as real strength"

Which he wrote down in his notebook and noted that the quote was not attributed to an author on the picture.

Going further into the sermon - the minister asked (and I am paraphrasing here):

Is gentle strength like the lioness carrying around her cubs despite those same jaws being used to feed her family by killing during a hunt her prides next meal, or the mother grizzly caring for her cubs but being the largest and potentially most fearsome of the North American animals. These animals are gentle with their young, but would resort to extreme violence in order to protect their young or if the need arose to go get food.

I really got caught up with this idea of gentle strength because I saw similarities in what Karl had called wisdom and what I was trying to become in my life - strong in leadership, but gentle in my exercise of the same. I really want to be a force to be reckoned with but to do so with a disciplined power, a gentle strength - so as not to leave a path of dismayed and destroyed in my wake and charge to make the world a better place.

My desire for this comes from several places, but I believe it to be brought from my experiences, the places I have been, the people in my life and the childhood I lived. I have certainly struggled to get my 'strength' under control, using my words to cut people, cut at them, or cut them down. However eventually being able to understand that I had an ability that others did not and what that abilities really deep and lasting affect on others was lead me to want to change that interaction. Call it self knowledge or self actualization but it came as I was on an internal search for a way to harness what was available to me and was 100% under my control.

I had used the ability to read and understand people to great positive and negative effect (mostly negative). My interaction with one person in particular had always had some ups and downs but was most of the time caustic and rather vitriolic. My understanding of the impact of this ability however was made clear to me in a single moment one winter around Christmas.

That year, many years after all those interactions had faded and were somewhat forgotten, a friend of mine indicated what sort of affect my words had on who they were, and what the affect of my "ability" was on the person they eventually became, how the way in which we spoke had impacted them, how my action had impacted them. That simple point, an instruction on life, THE thing that helped to move me along my path was right there - sitting in front of me and asking for nothing in particular, nothing more than clearing the air with me. That moment provided so much too me, I am ever so grateful for.

What solidified for me right then is that these types of learning experiences are all around us and can surface in ways we do not yet understand or expect. Take for instance how this post opened - with a friend of mine saying simply that he thought I had wisdom. I don't feel wise, I am just trying to live my life and leave people better for having met me, better for having known me, better for having touched paths with me - no more and NO less than what I get from them... those people that I interact with. I can expect nothing more and can give NO less than my very best every day - I can only attempt to apply a gentle strength to everything I do and apply wisdom (even if its just a perception of wisdom).

Oh, for those interested - that quote from unknown - the minister did find the original author eventually: The quote was from St. Francis DeSales, a man of faith - coming from a different place to the same conclusion.

The forgotten PhillyETE presentation tracks

noreply@blogger.com (vwdiesel) — Wed, 11 Apr 2012 18:22:00 +0000

So I am at the PhillyETE conference this week attending sessions on new technologies and systems that are available to me to work with in order to build systems that make my employer money. There are two tracks of talks that are decidedly non-technical at PhillyETE that while I am here I often attend. These other two tracks conference tracks do not often get very large audiences but I believe that they should, they are the management track and the agile track. The management track and the agile track are all about how work gets done inside of BigCo; these two oft neglected tracks are attempting to address how a development staff works together to get work accomplished. The problem is that the topic of how the work works is not particularly important to the development community - who seems to be happiest when they can sit and develop and not worry about those 'gory' details of what happens when they look up from their monitor now and again.

It's a game of people

Inherently, unless you happen to be the sole proprietor of a start-up doing all the work, development, hr and paperwork yourself, you are part of a system of getting work done at the company who currently employs you. This means that you, dear developer, are part of a system of people all working towards a goal. Hopefully you are all working towards the SAME goal, but I think that is the topic of a different post.

Because you are part of a system it is difficult for you to be 100% introverted - this is not to say that there isn't power in being introverted, I think that everyone needs time and space to ponder and consider things on occasion. The problem exists in your being part of a system that inherently requires interactions to a degree and level that you may not be comfortable with, development is a game of people, not one of code. The game is around having good people focused on accomplishing a goal, code, good code, is a consequence of that game of people. Each and every developer should be concerned with this game of people because it impacts how their work works. This game of people can affect how much time developers have to concentrate on their code due to unwanted or 'un-required' interruptions in the work day. The PhillyETE Management and Agile tracks are providing information on how to organize and structure teams so as to have those teams gel and become highly performing. These two tracks (management and agile) are all about helping teams to understand the game structure that they are playing within. PhillyETE is providing the tools for us developers to work with the system we are presented with at BigCo. to maximize our productivity and happiness rather then rail against it. The shame is that far to few people realize that these two tracks of management and agile are attempting to help teams of people (teams of developers in at least PhillyETE's case) to make the most out of the systems they work with and within. It shows in the low attendance numbers of these two conference tracks.

Reach out past your comfort zone

Developers are constantly reaching out past their comfort zone to learn new ways of doing their development work, new languages and new frameworks are constantly being developed and iterated on. There is a constant motion, ebb and flow of ways to accomplish a given programming task. I would love it if the development community would reach out past the code and the technology and realize that they work in a system of people and learn to 'code' the people system just as easily and simply as they code their computer systems. By learning to program the people system developers would very likely be making their lives and the lives of a great many people at the companies they work with and for hundreds of times better than currently exists.

We have to work with the systems we are given, but it doesn't mean that we can not work to change them and cause them to be better to achieve the things requested of us. What a much easier place to work BigCo. would become if this were the case - all of us working to improve the system we work in. I look forward to the opportunity to make those system impactful changes, day in and day out, I hope you will too.

Death and Craftsmanship

noreply@blogger.com (vwdiesel) — Mon, 14 Nov 2011 18:34:00 +0000

I have been thinking a great deal about software craftsmanship recently. I have Uncle Bob Martin to thank for making me at least think about it. There is however a life event recently that made me consider the topic in a deep way that I am not sure I really even considered before; you see I had been taking what Uncle Bob was saying about software craftsmanship at face value that is until my Grandfather passed away this weekend.

The Craftsman

When I was younger I used to go over to my grandfathers house, which was not to far from my own home, about 2 or 3 times a month. At the age I was at the time - going to his house was about being able to spend my summer in the pool that my grandparents had, it was about having breakfast, lunch and dinner on the porch, it was about the grill and the amazing food that my grandfather could concoct using it. The time that I spent at my grandparents house was rarely about the things that my grandfather did for work or what he had done as work because my interaction with him was mostly after he retired from the work a day world.

To my knowledge my grandfather worked for Boeing as a machinist making various parts and pieces for either helicopters or for the machines that were machining other parts for the same. What I didn't know until I got older is what an amazing skill my grandfather had for doing what he did - I did NOT realize what a craftsman this man was. You see, my grandfather was able to make the machines he worked with sing and dance to create very specific parts. He was able to set up lathes and other machinery to sharpen existing tools, or create something totally new. My grandfather was able to cause these machines to create parts that had tolerances in dimension of no more then a few 10,000ths of an inch, by hand, day in and day out. When he learned how to do this work he didn't have a CNC machine to program, things were not automated in any significant fashion, he was taught how to make these machines do his bidding by hand, with the lightest of light touches. My grandfather took great pride in what he created - in retrospect, I have that same pride now for what he accomplished doing that work.

Software Development

My grandfathers death and the realization of the talent he displayed when working with machining metal lead me to this, I don't think that my software design and programming should be any different. I should be able to perform gross cutting code as well as fine grained 10,000ths of an inch type code and have it all work. I should be able to call myself a craftsman of software by being able to have someone look at what I have done and say that it is complete and well done. Software craft-persons should be able to look at someone else's work and identify their own craft in it as well as to call out the simple and small foibles made by their compatriot craft-person. Performing the 'craft' of software development, turning ideas into code and doing it with quality and precision, is not easy and not everyone can do it - just like I can't do the things my grandfather did with his machines. However - practice, apprenticeship and other things that go with thinking of software as a craft to master can help you improve what you do, can improve how you think about the work that is software development.

I know from here on out I will be striving to be NEARLY the person that my grandfather was, and nearly the craftsman I know he was in his work. I will work every day to improve how I write my software because knowing who my grandfather was and how he did his work prevents me from doing any less.