Equational

Misfits of science Talented people are outstanding at what they do best... and often dysfunctional in one way or another. This post is about how to manage talented people. And especially about managing them within organizations that need a lot of collaboration (e.g. software development). I'll start with a quote from a TV show from the eighties: "Everybody that is worth the trouble is a little weird" (To be found in  episode three of the Misfits of Science )   I have worked with many talented people that were "pretty normal", yet I would need to argue that the majority of the "good people", those that are worth the trouble to "keep", from a management perspective, are also "focused in their own way". And even the talented people that did not show outward signs of "idiosyncratic" behavior, had their special side, which within work organization often showed up as social issues in abrupt or surprisin...

Here my attempt to match up design patterns with functional programming constructions: Chain of responsibility Fold request across the chain of handlers, at each step returning either (using Either type) request to continue fold (possibly with transformed request), or returning handled request indicating that fold is finished. Command Request is held in data (e.g. as discriminant union) Interpreter Language is available as typed data structure (e.g. discriminant union) and is interpretable with functions calls. Alternative:Language is defined in monadic form (e.g. as function calls)  and is interpreted as part of the monad's interpretation. Iterator Exposed traversal functions hide data structure of containers. Functions typically work on zipper focus adapted to the containers structure.   Mediator Exposed functions stay at top/root of exposed data structures. Memento Use immutability and exposure of intermediate states to allow recovery, restart or alternate...

My favorite skateboarders these days are Rodney Mullen, Ben Raybourn, Chris Haslam, and Chris Cole. There is an interview of Rodney Mullen where he says he is looking for a special "silhouette" in skaters. In fact, he is saying the he is looking for uniquely talented skaters that have internalized their skating into their cognitive growth process. To give you a mental image of what I am saying: We all need things we can lean on to grow. What I mean by "leaning on something", is that we use it to support us, we use it as dependable reference. When we are young we lean on our parents. Later, most of us lean on our social/economic "fabric". Yet others lean on their own selves. If you are unlucky, this self "leaning" may make you a unpleasant narcissistic person, yet if you are more lucky you do not lean on a "synthetic" self created social reference, like a narcissist person, but on a self created non-social reference. And for the people...

Have you noticed that people can make sense of what does not make sense when they do not understand it? That is the "soft" and "analogic" property of our brain: we can make sense out of nonsense,  and this is ok, when we do not know it is nonsense! A waterfall process will take nonsense, and then often spend the money while delivering nonsense. Agile process will take nonsense, and fail iterations, and... just go on, spend your money, and  delivery nonsense, or...,  recognise the stalling as a failure to deliver the requirements (e.g. sprint stories), and then force the requirements to be rewritten for the next development iteration. The next iteration may fail, but again the requirements will need to be rewritten. Yet if you are truthfully applying an agile process, each failed delivery will again attempt to reformulate the requirements to be achievable and in the end what was not understood and is blocking you becomes understood and you either stop the project, ...

Maintaining consistency within parallel, distributed, high-performance, and stream oriented programming is all about accepting one thing: when it comes to consistency, that is dealing with failures, don't promise too much too soon! And that is the whole notion of eventual consistency: you sometimes need to wait for things to get resolved. "How much you wait" depends typically on how much money you have invested in infrastructure, yet it also depends on how fine your system captures failures. Let's start with the eventual consistency.  In traditional transactional models, consistency, the knowledge that your system is "doing well", is assured by approaching each operation "transactionaly": if an operation fails, make sure nothing is messed up and that consistency is maintained.  Yet in the "new" world of massive parallelism, need for high-performance, and the like of streaming models, it is often simply impossible to maintain consistency...