Curiouser and Curiouser!

'Where shall I begin, please your Majesty?' He asked. 'Begin at the beginning,' the King said, very gravely, 'and go on till you come to the end: then stop.'


Okay after even more time away it's unlikely anyone reads this but I'm happy to say that I have my blog working again!

At the moment I am working on general systems theory, cybernetics, value mapping, psychology of price, building Arduino based MIDI modulators (currently using a guitar string and cello bow), business coaching, leadership, and Clojure/ClojureScript.

Time to start posting about some of this stuff!

12/07/2015 17:49 by Matt Mower | Permalink
More about:

What to expect from being a programmer

I answered a question in the reddit learn programming sub yesterday from someone who was about to take their first programming class and wanted to know what to expect about this thing they are embarking on. Here's my answer, maybe you can leave a better one?

It's a very interesting question you raise. I suggest that a good analogy is to becoming an apprentice carpenter.

You will be given a bunch of unfamiliar tools and materials and told "make a chair, start with a simple one like this."

Over time you learn to master the tools so that you can handle them well, you learn the tricks of the trade (how to make hinges, and seamless joints), things not to do or how to recover when you've chiselled the wrong bit (sorry my lack of carpentry knowledge is now failing me). Eventually with enough time, and having turned out enough chairs, tables, cupboards, stairs of increasing quality, you are an artisanal carpenter and can make wood do anything you like.

That takes a lot of practice and dedication.

In the context of programming the tools are languages, learning their syntax and (more important) their semantics, learning the toolset (compilers, build tools, and so on), learning the frameworks and libraries from which you assemble software, learning good idioms, and learning how to problem solve. Eventually after turning out a lot of software of increasing complexity you can make it do anything you like.

This takes a lot of practice and dedication.

At this point you probably end up running a shop full of carpenters and get an ulcer dealing with recalcitrant wood suppliers and clients who don't know which floor their stairs should go to, but that's a story for another question.

The main thing to focus on is enjoying the problem solving aspect: thinking your way through problems is the piece least taught and most important to programming successfully. If you enjoy this, and are willing to put in the time, you will go far and enjoy making many things.

Good luck.

08/08/2014 10:01 by Matt Mower | Permalink
More about:

Consultancy is hard

I'm out of the habit of writing, particularly about stuff where I am uncertain, exploring, learning, or in the dark. So this post wasn't easy to write and probably won't be very good. But it's a start...

Consultancy is hard. I'm not the first person to reflect on this I think. And I am certain I wasn't alone when I assumed that the hard part was knowing what you know (or, perhaps, using what you know).

The most obvious lesson I have learned so far is that, rightly or wrongly, most people see consultancy as a business in which people buy advice and/or skills from those that they trust to help them.

From this perspective being a consultant is about selling trustworthiness over competence. Because trust is so very hard to create 'on demand' you also look for anything that can short-circuit this process. For a lot of consultants I think this boils down to "shared background".

My background doesn't look very consultanty. I'm not ex-KPMG. I haven't worked for huge brands or hip digital agencies. I've spent 20 years in the software development world trying to bring applications into the world.

Sometimes I feel this acute sense of being an impostor in calling myself "consultant". My inability to point to an impressive pay-day from the startups I've worked for doesn't help with this feeling.

So, why continue..?

Last year I did an introductory cognitive behavioural coaching course. This year I am mentoring for UnLtd. While under no illusions about how much I have yet to learn, still I'm learning a lot about working with people who want to achieve things.

From the coaching course I learned that helping other people isn't about telling them what to do so much as helping them reveal their own insights about what to do. I have lots of ideas and "insights" and I love sharing them. Partly I think I love feeling clever. Learning to rein this in, that my own self-worth isn't dependent on people perceiving me as clever is a tough one. But I know it's right.

Mentoring is different to coaching because there are times when your mentee really does need advice or practical guidance. But even here I am feel the more non-directive approach works best. I am uncomfortable being thrust into the role of expert and prefer to see myself as a peer who is, perhaps, a little further down the road. Suggestions then are more what I feel they should be: sign-posts from a fellow traveller.

Up to now consultancy for me has been very much about communicating what I know and/or doing it for a client. I've felt that this is what is expected of me and that my value is very tightly bound to these activities. But, I am wondering, is that true even here?

As a coach, mentor, or consultant different things are expected of you, and you use different techniques. But I think the best bit of any of them is when you help people find their own way of unlocking what they need to and achieving a goal in life/business.

As a consultant I would like to blend what I see as the strength of coaching & mentoring with my own skills, experience, and judgement. I think the possibilities I see in this are why I continue.

For example: I am looking at games and trying to design games in which I can embed my own experience & judgement but which, in the playing, allows the player to use what they know to the best advantage: moving from "advice giving" to a kind of "guided exploration".

I haven't tried it yet but feel like this is a very interesting, potentially worthwhile, area to explore.

From where I sit today my own goals seem very far off and I worry that they are unattainable. I have so much to learn and in the business of creating a growing business, more still. But I have some excellent supports and feel this is a path worth pursuing.

If not an easy one :-)

I'm very interested to hear from others who've trodden these paths and hear what they've learned along the way...

13/07/2014 11:14 by Matt Mower | Permalink

Across a vast Clojure gulf

Having conquered the Clojure Koans I'm doing some of the 4clojure problems to help me improve my Clojure skills.

One of the interesting things about 4clojure is that you can "follow" other users and, once you have solved a problem, you get to see their solutions. The advice is to follow some of the experts so that you can see what a real Clojure solution looks like.

It's both instructive and depressing to do so. By contrast with some of the solutions from people who've done all 155 of the 4clojure problems mine are are verbose, inelegant, and betray my ignorance of much of the deep power of Clojure's abstractions.

Here's an example:

"Write a function which returns the first X fibonacci numbers."

(= (__ 3) '(1 1 2))

(= (__ 6) '(1 1 2 3 5 8))

(= (__ 8) '(1 1 2 3 5 8 13 21))

Here's my solution to the problem:

(fn [n]
  (map (fn fib [n]
     (loop [n n]
       (condp = n
         0 1
         1 1
         (+ (fib (- n 1)) (fib (- n 2))))))
   (range n)))

To be fair to me, it works. But it's long-winded and doing far too much work. Let's take a look at what a more experienced Clojure programmer might come up with. How about:

#(take % (map first (iterate (fn [[a b]] [b (+ a b)]) [1 1])))


#(take % ((fn fib [a b] (cons a (lazy-seq (fib b (+ a b))))) 1 1))

The key difference is the use of a lazy sequence (via either lazy-seq or iterate) that generates an infinite expansion of the Fibonacci series. Then it's enough to just take as much of the sequence as required.

It's enough that this approach didn't occur to me, although I did try to think about better ways of generating the sequence (even thinking about iterate but not being able to see how I could apply it). The elegance with which my mentors generate their sequences is pretty inspiring.

I'm not beating myself up too much. Some of these guys may have prior functional experience or have been using Clojure for years. But it does rather highlight the gulf I still have to cross to master this language, not to mention paradigm, I have chosen.

10/05/2014 16:44 by Matt Mower | Permalink

Thoughts on a different kind of thinking & writing space

It was a throw-away thought while I had Facebook open but I had this idea about a writing space that breaks the strict reverse-chronology of blogging and is instead like a note book but also a shared notebook in terms of bi-directional links to other notebooks and one that dynamically weaves relevant content from other notebooks maybe by inclusion, quotation, or referencing.

But thinking back to the 1990 documentary Hyperland (if you remember that far back) where rather than something being deemed relevant and "sitting there", as so often happens, it's more offered to you and your decision about whether it's interesting/relevant or not feeds into some parallel process that mirrors your own writing/thinking.

So the process is dynamic process both in terms of content but also in terms of interaction.

If this were to be interesting I think it's somehow because of whatever function decides relevance over time and content.

This feeds into a history of ideas I've had, going back almost 20 years, about creating some kind of intelligent notebook. I'm quite interested in the idea of maybe publishing these kind of notebooks as "brains" via Git so as to allow them to be versioned, branched, merged and so on.

One day I'd like to be able to build such a thing...

05/04/2014 13:29 by Matt Mower | Permalink

A moment of connection

On Republique station a middle-aged Chinese gentleman was playing the flute and a strange instrument like a hexagonal violin.

I wanted to give him something but being both intimidated by the Parisiens and embarrassed to find maybe €0.50 in my pocket I waited until the train arrived before walking over and dropping it in his case, then heading for the train.

As I sat down I glanced back at the man who looked up just then and, nodding at me, smiled. I smiled back although I became suddenly self-conscious.

I persuaded myself to look again and he met my gaze and smiled again, a warm smile, as he bent to his playing.

I could so easily have bowed to my fear and given him nothing and, worse, missed this momentary connection with another human being and playing that we both enjoyed.


12/03/2014 11:06 by Matt Mower | Permalink
More about:

Juxt a minute

Caveat lector: skip if you're not interested in the experiences of someone learning Clojure and functional-programming.

At the moment I am reading the excellent Clojure Programming from O'Reilly. It was one of the first books I bought but I found it a little formidable as an introduction to Clojure. I'm finding it a lot more digestible now.

In it I came across an example of the excellently named juxt function. Reading the docs I found it a little difficult to get my head around:

Takes a set of functions and returns a fn that is the juxtaposition of those fns.  The returned fn takes a variable number of args, and returns a vector containing the result of applying each fn to the args (left-to-right).

It's actually really simple but the use of the word juxtaposition made me think it more complicated than it is. To whit:

juxtapose (verb) place or deal with close together for contrasting effect: black-and-white photos of slums were starkly juxtaposed with colour images.

But what was the contrasting effect?

The O'Reilly example was:

(juxt quot rem)

as a replacement for:

(defn euclidian-division [x y]
    [(quot x y) (rem x y)])

and, as I played with the output of the function, the penny starts to drop. Then I see it, that the contrast, the juxtaposition, is in how each of the functions passed to juxt interprets its argument(s).

It seems to me that juxt is like a map generator. But where map is about mapping a function across a sequence of values, juxt returns a function that maps a sequence of functions across its arguments.

So now I felt I understood it but I wondered how I could make use of it myself. I use map all the time but in what circumstance do you need to apply a series of functions over a value?

In calculating the value of a polynomial the degrees are, essentially, functions of an argument x where x is raised to the degree and multiplied by a constant, e.g.

2x2,3x1, or -1x0

The result of each of these degree functions is summed to get the total value of the polynomial for x. In Clojure terms we could say this is summing the juxtaposition of the degree functions which might look a bit like:

(defn polynomial [& degrees]
  (comp (partial apply +) (apply juxt (map-indexed (fn [degree multiplier]
             (fn [x]
               (* multiplier (Math/pow x degree)))) (rseq (vec degrees))))))

polynomial is a function that takes as it's arguments the constant multiplier of each of the degrees of a polynomial starting with the highest and ending with the power zero. It returns a function that takes an argument x and returns the value of the given polynomial for x.


# Calulate the value of the polynomial
#   2x^2+3x-1
# where x = 3
((polynomial 2 3 -1) 3)
# => 26.0

I use juxt to create a function that takes an argument and return a sequence of values obtained by passing the argument to each of a sequence of anonymous functions that calculates the value of one degree of the polynomial:

(fn [x] (* multiplier (Math/pow x degree)))

I then use comp to compose the function returned by juxt with a function that sums the individual components to give the total value for the polynomial at x.

I'm quite happy that I understand juxt, found a reasonable way of using it, and also managed to get comp in there too!

Update: Marshall Bockrath-Vandegrift (llasram from the #clojure IRC channel on Freenode) came up an alternative implementation using ->> threading macro to pull the function pipeline inside out, replacing the more cumbersome (rseq (vec degrees)) with (reverse degrees) and using Clojure's anonymous function literal syntax #(..) instead of (fn ..).

(defn polynomial
  [& degrees]
  (->> (reverse degrees)
       (map-indexed (fn [i m] #(* m (Math/pow % i))))
       (apply juxt)
       (comp (partial apply +))))

I think this one is more readable and probably more idiomatic clojure. Thanks llasram.

05/02/2014 16:00 by Matt Mower | Permalink