Book Cat: Flow

Flow by Mihaly Csikszentmihalyi is about the psychology of optimal experience. Optimal experience is the idea that the perception of an experience is more important to your enjoyment than the nature of the experience itself. The popular conception of the book I had gotten was about how to produce a flow state and therefore be more productive. That was part of the book, but the reality of the concept was much more complex than I realized. The eight components that are used to describe a flow activity are:

  1. An achievable task
  2. Concentration
  3. Clear goals
  4. Immediate feedback
  5. The activity has enough depth to take up your full attention
  6. A sense of control over your actions
  7. Loss of sense of self
  8. Time dilation

Some of these components are things you can control to try to induce flow (1-6), and some of them (7 and 8) are what you experience under flow. Not all flow experiences have every component, and just because you meet the first six items it doesn’t mean you will have achieve flow. Flow is an enjoyable state but not all enjoyable experiences are flow eligible; you don’t achieve flow watching TV, it is a passive action not something you actively engage with.

The book was more about understanding that flow appears in any place that you achieve deep satisfaction than about exactly how to achieve it. Flow can be in the way you can lose yourself in any significant activity: playing sports, spending time with your family, at work, or overcoming adversity. It isn’t that flow creates satisfaction or activities that cause satisfaction have the innate ability to create flow. It is about the underlying way that your mind process experiences and what that means for building a satisfying life. There is significantly more to the book than a way to increase focus on an activity. It could almost be described as a philosophical text on the meaning of enjoyment in the human experience.

There was a section discussing the flow that some people found in overcoming adversity. There was a story of a man who found life after losing the use of his legs to be more satisfying since he stopped to recalibrate his expectations and found enjoyment in the challenge of living everyday life. There were other similar stories of those who overcame hardship and found flow in doing so. From a logical perspective there isn’t a way to see losing your vision as a positive, but there were accounts of people who did.

Since the book wasn’t what I was expecting, I feel like I need more time to digest what was there and what it means to me. The philosophical aspect of it reads much more deeply than most of what I normally read; even when it was prescriptive it was less concrete and more aspirational. I picked up a copy of another of his books, Finding Flow, which seems like it is more practical. I hope that I can take away more of the specifics of this on how you can live a more fulfilling life.

Looking Back Again

I had reflected back on my last job before. However, I had a thought today that got me in a reflective mood again. I miss being involved in any and all problems that came up. I was in a position that I would get tapped whenever anything went wrong and it wasn’t clear whose problem it was. I got to take it apart and find the root cause and either fix it or pass it off the team responsible for that area. The rush of having a regular stream of critical problems to deal with was intense. It had stratospheric highs, and it had some amazing frustrations that went with it; in all it was intensely involving.

I miss the puzzle of it all. I used to go to the office, read my email, pick the most immediately  pressing problem, and go look into it. The problem of it was I spent all day putting out fires and no time doing fire prevention. The knowledge to help prevent the fires was only really learnable through dealing with them. Most of the developer team wasn’t exposed to the problems in a way to learn how to avoid them. The problems were varied enough that you couldn’t just put together a brown bag session to teach them.

It’s exhilarating to be someone who gets to work on the problems but it also becomes massively stressful. The situation is bad for the organization as well. Problems get solved but the organization doesn’t really learn, so it will never get better. There was one particular incident that sticks out in my mind where another developer sent me this error message asking if I knew what to do with it. I responded immediately with an explanation of what was needed to fix the problem. The developer later asked how I knew what to do so quickly, the answer was I had spent 6 hours figuring it out the day before when someone else ran into the same problem.

I don’t miss the stress aspect of this when you’ve got problems six deep and someone asks if you’re able to help them and the answer is no. It’s difficult when the person whose problem is way down your queue wants to know what is going on with it, and you need to tell them it isn’t your priority right now. I didn’t fully understand how much stress I was under there until I had given it all up and moved on.

I managed to avoid some of the negative aspects of being a hero in software development. I kept to normal hours. I didn’t create situations that need to be fixed by my personal efforts. I didn’t try to be involved with everything. In fact, I was actively avoiding proactively getting involved in some places that looked like they were going to get into problems, because I felt that while their problem was going to prevent them from making progress, it didn’t endanger the existing system and therefore might be a learning experience.

By understanding and being able to articulate the various issues there that I did and did not enjoy, I hope to be able to optimize my involvement at my new job. Learning from your past experiences is the only real way to do better.

Dabbling in AngularJS

I got the opportunity to do some work on the front end recently. It’s my first exposure to AngularJS and it’s been a great experience. I’ve never been a big fan of JavaScript in general but this seems to be a great way to work with it. Angular is a highly opinionated framework; it specifies how to lay out the application, the patterns you should use to decompose the visual elements, the layering for calls into the backend, etc. It gives you a lot of tools for all of this: two-way data binding, dependency injection, tools for working concurrently, and testable abstractions for making remote calls.

The limitations are quite freeing since they guide you to a style that produces lots of loosely coupled small modules that are testable. The testing plus the compilation step gives a lot of confidence that the system will work when deployed. I haven’t been making any significant changes on the front end, but I feel like if I needed to set up a new project I would go with a similar stack to what we’ve got going here. I feel like I’d be happier with TypeScript since that more closely matches how I think about code. In my understanding it provides for better development environment integration than what I’ve been able to get with JavaScript so far.

The documentation has been some of the best I’ve seen so far for a framework. Each piece is described independently and there are examples of how they layer together with other. There are plenty of examples that work there in the browser, since it is all JavaScript . Even better, it all links to Plunker, which lets you edit the examples right there in your browser so you can play with it and see what happens. There have been a couple of places where the documentation has failed me. The documentation regarding promises and $q falls into the classic trap of making sense if you already understand what it is trying to tell you but is almost worthless when you don’t know what it means.

I’m still having issues with the modern toolchain for front end development. Fortunately my teammates who have are more experienced with this have gotten angular, gulp, phantomjs node, npm, bower, jasmine, and who knows what else setup. This means I can just hang new pieces onto the existing infrastructure without needing to know how to bootstrap the entire stack, which is good for getting started with it. This toolchain is complex and I’m not sure how much I need to know about each of them.

This is definitely better than my previous front end experiences, although front end work still isn’t something that I want to do lots of. Finding a tool set that I like better will make it easier to do when it does come across my plate in the future.

Book Chat:Scala for the Impatient

Scala for the Impatient is a reaction to the heft of Programming Scala. It recognized that Programming in Scala was a great resource but weighed in at 800+ pages and that it may make a better reference than introductory text. Scala for the Impatient attempts to capture the bulk of the value at a much slimmer 340 pages. Having not read Programming in Scala I can’t say if it captures the bulk of the value, but it does provide an amazing introduction to Scala.

The each chapter is labeled with a Scala level to give you an idea of how complex the topic is. This helped me since I could see that the chapter on implicits was labeled L3, the most complex level, and that most of the time you don’t need a feature like this. That helped signal to me that it was okay that I didn’t fully understand how to apply the topic right after reading, while I’m still a relative newcomer to Scala. I haven’t wanted to write any implicits so far, since I haven’t been writing anything too complex. But, it still helped when I saw some implicits in library code I’ve gone into; I have been able to follow along, although I don’t fully understand why the code needed to be put together that way.

I had issues with some of the exercises. There were some that asked you to think about why something was written in a particular manner, but there wasn’t an answer key, so it was impossible to know if you were right. I went searching on the internet and found people discussing the exercises but I would have appreciated a more authoritative and definitive answer. There were also places where it asked you to implement something, where it clearly meant for you to use some particular feature that was discussed in the chapter, but it wasn’t evident how you would implement it using those features.

I really enjoyed the ability to download of all of the example code, and code snippets from the examples. It made it easy to experiment with the example code and see what happens, without having to copy it all over. The errata was helpful, but there was a lot of it and it interrupts the flow of reading the book, but it doesn’t reduce the value of the book. Overall, out of the things I did to start learning Scala it was the most comprehensive. It has been my biggest time investment in deliberate learning for Scala so far and I’m glad I did it. I’ve got a copy of Programming Scala which I intend to get to eventually, but its significant heft may make it wait for a while before I dig into that to give a comparison.

Scala Intricacies

I ran into a couple of little syntax bits today that all added up to a bunch of wasted time. First was a call by name argument:

def passByName( t: => Long) = {}

This results in t essentially becoming Unit => Long that gets implicitly called each time t is used. This was not immediately obvious, and like other similar bits of syntax, it was difficult to search for. The name of the feature, pass by name, doesn’t help since it doesn’t immediately explain what’s going on.

The second piece of syntax was the ability to have multiple parameter lists to enable a special kind of currying:

def currying(a:Long)(b:Int):String = {(a + b).toString}

This is equivalent to:

def currying(a:Long):Int=>String = {(x:Int) => (x + a).toString}

This syntax is more compact and clearer. It also gets better as you add more items. It also interoperates well with implicit parameters since you can attach the implicits to the last parameter list and have them fill in but you get a clean function signature for everything else.

The third piece of syntax was an inheritance issue that happens when a trait extends a class. Normally a trait is mixed in using the `with` keyword and classes are extended using the `extends` keyword. At first I didn’t realize you could extend a class with a trait, having seen the self trait syntax:

trait Bar { self: Foo =>}

But I did so unknowingly and when I attempted to mixin that trait in a way that was illegal, I got a great error message which helped resolve what to do next, but didn’t explain why what I did was wrong.

Having two different syntaxes that allow for very similar but slightly different behavior seemed confusing. I found this post describing the slight differences between the two different syntaxes and what they mean. It mostly seems to be a style thing, the self trait syntax lets you extend whatever class you want but it needs to eventually have the self class. This may have some consequences regarding linearization although it didn’t come up in the referenced post or what I was doing. The trait extending class syntax requires that you extend from it directly. It also does give some additional options for overriding methods since they can call the super implementations.

The last piece was how context bounds work on ClassTag types. When you define a method like:

def myMethod[T:ClassTag]

it implicitly creates an additional argument changing the signature to:

def myMethod[T](implicit tag: ClassTag[T])

This argument propagates through to any other usages of T and enables the usage of tag. Figuring this out from the codebase itself didn’t work out well. Searching for associated phrases was unhelpful since it isn’t really inheritance and most of the documentation is listed under TypeTag and not ClassTag since the two work similarly. The other issue was that the majority of the documentation I saw during my initial readings referenced manifests, which were deprecated in favor of the ClassTag and TypeTag. I managed to get some assistance from some of my coworkers to figure this one out, but it wasn’t an easily searchable or understandable concept since it took inheritance syntax to create implicit arguments.

All four of these syntax bits are useful but have some very specific nuances. Like a lot of Scala language features, they are all useful and well implemented individually. As a group though, there is a lot of unique and quirky  syntax to learn. I’ll keep chronicling all of the various bits and pieces that I find that warrant more thought.