Here’s a few splintered thoughts from my email exchange.

• Enlightened, for me, is about happiness that comes from being content; unenlightened is just trying to be happy.
• There are many solutions for every problem, whether I am aware of them or not; and the problem has already chosen the best solution, but I have not found it yet.
• Code from my heart because I should trust myself first.
• Be part of the exploration, not just an observer.
• This moment is more important than trying to figure out how it impacts the future, because I can deal with the future in that future moment.
• Passion is constant whether I succeed or fail.
• Let the project plan me, by bending to suit the situation not and not bending the situation to suit me.
• The code I write knows everything, because every line of code has an impact on someone else or some other piece of code.

Now I’ve decided to actively explore why I write code, or why I wish to continue doing what I am doing.  I am not sure what I will uncover in this exploration, but I know that it will be very personal.  I don’t even know if it will be worth sharing, that’s why I am sharing so early.  It just felt right.

I think it will be really tough, but I take solace from my 9 year old son who told his 6 year old sister “Getting hurt is part of playing”.

PS: I don’t think Jimmy will ever ask me a “How’s life?” question again

It’s true, the method won’t be reused.  It’s also true that most us were taught in some Programming 101 course that you should create a method, function, procedure only if you are going to call it more than once, otherwise just leave it all inline.  I value ubuntu coding, and so I have learned to unlearn that naive rule.  When I make my code more readable, I get more reuse out of it.  The reuse I value is not really about the number of repeated method calls or number of inherited classes.  I value the increased reusability that is achieved when more developers are able to read my code and walk away understanding my intention, clearly and unambiguously.

Let me put it another way.  Your code is a representation of your model.  Your model should be used to drive all collaborative discussions about the solution.  That’s where you get the real reuse in your model.  If people can’t understand your model, then your model can’t be re-used for further discussions.

So often we write code in isolation and the code reflects our personal interpretation of the problem and a personalised solution too.  We easily forget that other people will execute this code, modify it, and, at the very least, read it.  Coding is a social exercise first, then a technical exercise.  We have a responsibility towards increasing the probability of success for the next person or team that will work this code.

We can write code in isolation that is of high quality, focusing on self and metaphysics of quality, etc.  That’s a zen view and it is about you.  I like to think (believe?) that Ubuntu is zen for a group, not for an individual.

In Zulu, the Ubuntu philosophy is summed up as

Umuntu ngumuntu ngabantu

which roughly translates to

A person is a person through (other) persons

And in geek-speak it is

A developer is a developer through (other) developers

I get better because you make me better through your good actions.  And the opposite also holds true: You get worse at what you do when I am bad at what I do.

How do we write ubuntu code?  It’s not hard.  It’s based on “old” principles and wise words of many people.  It’s old material but worth revisiting with ubuntu glasses on: when you think about what the effect is on other developers and what the reciprocal effect will be, back onto yourself.

Reveal your intention, not your implementation. If you have designed a project management app with tasks and decided to implement it as a graph, call the class Task and give it a method called resolveCyclicDependencies().  Don’t create a class Node with a method called topologicalSort().

Avoid side effects. Let a method do one thing, and one thing only.  It’s frightening how many developers don’t do this.  For example, if you add a line item to an invoice, don’t update the total.  Have something else that calculates the total.  Basically, be boring and predictable.  I long time ago a SQL guru looked at my code and said “The optimizer does not like fancy code”.  Same thing.

Broken metaphors. Metaphors exist for conceptual understanding.  Once you get the conceptual break through, leave it.  It’s ok! Trying to build an economic model with a metaphoric model of fluid flows (or bears and bulls!) will just create havoc downstream.

Where am I? Figure out where you are in the bigger picture.  Are you upstream or downstream?  Is someone going call my code to create that Book object? Am I going to call someone else’s code to get the Customer object?  In other words, know what you supply and what you consume.

Fail fast. Assert! It’s allowed in production code too.  I would rather fail quickly and dramatically than delay the effect until it is obscure.  More importantly, when I read an assert then I know that the particular condition is critical.  It is an invariant that must be honored.

Pairing. Programming in pairs is an active exercise, not a case of a second syntax checker.  I see many teams that pair mechanically and it does nothing for increasing code quality at all.  If you practice active pairing, you are closer to ubuntu coding.

There are other techniques which increase the collective responsibility of your design and code such as context maps in strategic design, values and attitudes such as responsibility and feedback.  I’ll deal with those on another day.

But for now, I think that

Code is code through (other) code!

Do you have any other ubuntu coding techniques? Attitudes?

I have a fear that as a community we promote the top 1%.  I hear developers being labeled such as rock stars and ninjas.  It’s no different to junior developers and senior developers.  We find all sorts of measures to be in the top 1%:  Twitter follower-count, Facebook friends, LinkedIn connections.  I think such labels and measures create an air of exclusivity and elitism to the detriment of 99% of the people.  NINETY NINE PERCENT !!

My 1% rankings have always been nothing more than a fleeting moment.  Once I won a book prize at school and I got an award for some design in university and meal voucher or two for a job well done.  It was meaningfully great in that context, relative to the others in that context.  But it was perceived as such by a few at that moment in time.

Looking back, I feel sad.  Not because of the scarcity my top 1% ranking, but by the reflection that those fleeting moments did not have lasting value to those that were in that context with me.  I should have made it count more significantly.  These days, I want to do things that touch others meaningfully.  Is my my code worth reading and from which you can learn?  Did our conversation over coffee move us closer to understanding each other?  And I want to be affected similarly too, by 100% of the people, not just the 1%.

Sometimes you’re in the top 1% and sometimes you’re in the bottom 99%.  But you will always be part of the 100%.  I am nothing, yet I am everything.

I think I am actually searching for a muse.  Something that will be my creative genius.  I gave up trying to be a genius a long time ago.  Now I just want to learn from those that are better than me, whatever the context.  Maybe my muse is the sum of every engagement with the genius in each person with whom I work and live.

Hmmm, as I age, I think the slight contextual shifts that I go through now feels less like the massive catastrophic continental shifts.  Much nicer.

In the past few weeks, I’ve had a few instances where I realized that some people were,  basically, asking me for DDD rules – steps for building an aggregate, when and how to use the specification pattern, etc.  There are no rules for the noobs for these things.  But I think I can constrain the environment so that the noobs can focus a bit more intimately with these aggregates and specifications.    One rule I put down was “When working with the following … don’t work outside of this Java package”

Essentially, my proposition is that rules for noobs should constrain the learning environment, not the subject being studied.