YOW Conference – #yow15

I had not been to YOW before myself. In my previous job I had sent my team there though; the timing works out perfectly for a business that tends to be quiet over Christmas and the new year.

I had been to TechEd before, and that was the closest benchmark I had.

YOW definitely wins on a broader scope of topics, and yet not so scattered that it was hard to find a relevant topic in each session timeslot. I have been to TechEd with timeslots reserved for walking the floor, because despite 5-6 sessions running in parallel there wasn’t one that I actually wanted to see.

TechEd wins on the catering front, hands-down. But then, in all the years I went, it never ceased to amaze me how well-oiled the Microsoft conference machine is, and the amount of effort they put into a great show.

Having said that, YOW wins hands-down on cost… it’s kinda the way they pitch their conference – focused on the technology and affordability at the expense of spectacle. I don’t think that’s a bad call, because TechEd was definitely never a trivial sell to management.

And yet… the one point I have a hard time qualifying specifically; YOW doesn’t feel as amenable to making new connections on the floor. During sessions the focus is on the speaker, and during breaks it is on getting some food and finding a place to eat it. Maybe it’s the TechEd lunch set-up around large tables that force you to sit down with strangers that helps? Maybe it’s the social evening of fun they put together (one year: go-kart-racing in the parking garage… yes… seriously) that makes friendly conversations easier to come by. I don’t have a clear answer, but YOW does feel stiffer than TechEd.

Having said that… if you’re just there to learn, the set-up is ideal.

Keynote 1 – It’s Complicated…
Adrian Cockcroft

To my shame, I barely remember the opening keynote.

I hadn’t had coffee yet.
I was trying to work out when I was going to be where.
And then I had 11 sessions and 3 more keynotes with memorable elements.

I think it just displaced (almost) all my memories.

The one thing I recall with clarity is the question how it can be that the most complex piece of technology in existence today is usable by kids as young as 2 years old in a meaningful way; the mobile phone. Something about it’s design is the pixie dust that hides the million things you don’t want to do right now.

Session 1 – Rethinking MVC with React Native & ReactiveCocoa
Ben Teese and Sam Ritchie

I was only superficially familiar with React before this talk, so it probably wasn’t aimed at me. But I still learned a lot about the way React uses it’s Virtual DOM to do delta-updates on-screen, and how that can be made to translate to native apps on mobile devices as well.

I believe Angular 2 is going down a similar path of supporting some kind of Native variant, although I may have just dreamed that. Either way; not quite relevant to me at the moment.

Great talk though, good speakers, especially the groan-worthy punny pictures.

Session 2 – 40 Agile Methods in 40 Minutes
Craig Smith

Spoiler: it’s actually 50+ minutes; the session ran a little too slow to make good on its titular promise. Having said that, it was a very enjoyable whirlwind through a lot of Agile Development approaches (some of which didn’t look anywhere near as Agile as they purported to be).

There were a few slides that specifically piqued my interest, but the pace prevented me from taking notes, so I look forward to the slides getting published. Especially the slide with a book that Craig recommended as providing a good underpinning of why Agile works.

Great talk, and more useful than the frivolous title might lead you to believe.

Keynote 2 – Using Formal Methods to Eliminate Exploitable Bugs
Kathleen Fisher

Oh yes.

Totally this.

It’s been only 17 years or-so since I graduated from University, and at long last the central pillar of the Computing Science program of Eindhoven University of Technology is actually becoming useful.

See ma, my degree has practical applications in the real world!

And apparently, Australia is one of the fore-runners in this field. I don’t want to say it’s because of me, but hey… I’ve been here 17 years now. Coincidence? I think not!

In all seriousness, it is great to see Formal Methods taking their rightful place as a central tool for the development of provably correct software.

Session 3 – Adaptive Security
Aaron Bedra

The key tenet of this talk was: exploit your logs; exploit them for all it’s worth.

Know what your messages mean, count them, and then look for patterns. And then act on those patterns. And start simple, because the business knowledge that produces will lead to requests for more of the same, and before you know it you’ll be tracking and measuring everything.

I couldn’t think of better real-world advice.

Even beyond just security matters.

Session 4 – Production Haskell
Reid Draper

This was by far the greatest disappointment of the conference to me. Based on the excerpt I had hoped to see some samples of practical use of Haskell in a real-world production scenario.

In the end I walked out before the session was over, because I just couldn’t muster the will to look at further tool-chain scripts to build Haskell. That was so not the point I was coming to see.

I’m sure I could figure it out myself, but I wanted to come and be sold on the idea.

Session 5 – Pragmatic Microservices: Whether, When and How to Migrate
Randy Shoup

I slumped through this; not a bad talk, but after a full week of Udi Dahan, there wasn’t really a lot more anyone could tell me about big balls of mud and how to take bites out of them.

I had hoped those nice big open questions in the title would lead to new practical insights, but I think I just kinda zoned out and let my afternoon snack digest.

Not a bad talk, just nothing much in it for me.

Session 6 – Property Based Testing: Shrinking Risk in your Code
Amanda Laucher

This talk felt like a “missing link” between Formal Methods, Unit Testing and .NET Code Contracts. After listening to it all, I like the idea of higher-order tests, and I see how you could leverage them in procedural languages.

But it feels like perhaps it’d be easier to just go Functional, or use Theorem Provers instead of wasting this approach in its pure form on C#. Still, I like the ideas underpinning this way of testing, because as I’ve blogged previously, I’m very unsatisfied with the cost/benefit balance of most of the automated testing I have been exposed to in my working life.

Keynote 3 – Engineering and Exploring the Red Planet
Anita Sengupta and Kamal Oudrhiri

Anita is a great speaker. Kamal was clearly nervous.

Having said that, it’s hard to botch a topic as inherently interesting as trying to land complex and fragile technology on another planet within a very small target area. It’s hard to appreciate how awesome the stuff is that JPL and NASA do without someone explaining all the details that you’d never have thought of.

I secretly suspect there are still a lot of Waterfalls in these places to deal with the careful design required for a release that you don’t get a second chance at. Once it leaves the planet, it better work.

Also, it made me want to go and see The Martian again.

Session 7 – Building Microservice Architectures in Go
Matt Heath

This was actually a very fun Microservices talk. Not as much hands-on Go as I might have hoped, but some very salient points were made. It hadn’t occurred to me before that the combination of a language that statically links everything together with a very lightweight container is immensely powerful for Microservices / Service Oriented Architecture.

I guess he just made a very compelling case for dotnetcore without even realising it.

Also, he was an excellent and engaging speaker. He felt by far the most polished out of the speakers I saw. Having said that,… the thongs were visually incredibly distracting.

Session 8 – Agile is Dead (Long Live Agility)
Dave Thomas (Pragmatic)

And just as I thought thongs would be about as distracting as it could possibly get. Bare feet on stage.

After this talk I feel very self-conscious about my use of the term “Agile” as a short-hand for Agile Development Practices. A very well-put rant against the commercialisation and co-opting of common-sense to extremes where it just stops making sense altogether.

I suspect the fifth agile tenet that he can no longer remember might have been “Pizza over Steak”; that sounds like something a programmer would declare.

I guess the biggest lesson from this session is a cautionary tale; to keep an eye on the practices you follow and to make sure you don’t fall in the trap of trying to buy Silver Bullets. We all love them so much, and we know they don’t exist, but we still buy ’em.

Keynote 4 – Thriving in a Stochastic World
Don Reinertsen

And this one takes the title for “dullest yet most worth taking note of”.

The speaker reminded me of a professor with a slow drone. I’m glad I managed to barely keep my eyes from shutting, because the key thesis on how to exploit the asymmetry of the upside and downside of experimentation in an unpredictable environment is a great lesson for all start-ups. Heck, all technology businesses.

I would have hated to miss that nugget.

The lead-up to it, I could have done without I think. Maybe start closer to that point and then spend more time on concrete examples, and it’d be a much more relatable talk.

Session 9 – Making Hacking Child’s Play
Troy Hunt

This one was a lot of fun. Also terrifying.

For opening gambit: a dumb YouTube video showing a terminal with a clueless teenage voice-over explaining how to DDoS someone with a “ping -t” command, and how it’ll only work if “your network is powerful enough”.

A brilliant feint.

Later in the session, the most terrifying thing ever, an early-teen girl, in her early-teen bedroom, speaking into a laptop webcam selling DDoS services to knock your gaming competitors off the net. And completely serious and real.

We live in a world where the tools to disrupt services on the internet can be wielded by the completely clueless. It’s like a phaser; you just point and hit the button and stuff happens.

Very effective presentation.

And also, we’re all doomed.

Session 10 – DevOps @ Wotif: Making Easy = Right
Alexandra Spillane and Matt Callanan

Another talk that didn’t quite make good on its title, but nevertheless a talk with some interesting points.

Basically, Wotif ended up crawling out of the pit of despair by creating a better deployment story, but rather than using the hard-sell, they developed it alongside their existing deployment path and then let market economy take care of the rest.

“Do you want to go in the release queue, wait weeks, then have your code hit production; all safe and secure, or would you like to use this faster SLIPWay which can turn around your deployment in an hour, but you’ll have to change a few of your assumptions and processes?”

These were the only paired speakers that had put their talk together so that their perspectives complemented each other well. Not flawless, but definitely seamless.

Session 11 – Play in C#
Mads Torgersen

The biggest under-sell of YOW.

The title doesn’t do the content of this session justice by a long stretch.

For warm-up, we walked trough the history of C# (Mads leads the language team at Microsoft), with some miscellaneous barbs and snipes aimed at Georges Saab who did a Java talk before this session.

“C# 1.0, back in 2000, where we introduced value types”, /significant long silent glance to Georges/.

Poking fun was only the secondary purpose of this quick retrospective, because his real purpose was to show the language evolve to where it gained Roslyn. And then he went into a live demo.

He starts up Visual Studio.
He starts a language rule project.
He starts a nested Visual Studio within which the language rule he is developing lives.
He edits the language rule with code-and-resume.

And as he adds this new language rule and it incrementally applies squigglies in the nested VS, and then adds automatic correction options to apply fixes to the code; I want to play with Roslyn so desperately now. It is FxCop on steroids. It is magical. And also a little meta-insanity. But the good kind.

And then to finish he runs through some of the new language feature options on the table for C# 7. Note that hyperlink right there. That’s the GitHub repo where Microsoft keeps the live list of language feature discussions going on for the next version of C#. Microsoft are now not only open-sourcing their framework, but they have also opened up the design process. So have a look around and be part of the discussion!

It sounds like Pattern Matching by types, strong Tuples and non-nullability are strong contenders for features that might be in. But no promises just yet.

I could not have wished for a better closing session, because it sent me into the weekend very energised. I then proceeded not to play with Roslyn for lack of time after my other chores, but I think that flame will burn through a while longer.

My next goal: devise a talk worthy of YOW and get onto the speaker roster.
It is easy to criticise, but much harder to step up and do it.

How About a Digital Gaming Revolution, Mr. Turnbull?

PAX is a conference for gamers of all kinds, and geek culture more broadly.

But you wouldn’t have guessed it from the length of the room-overflowing queue leading into the session “Boss Level: Meet the Brains in Charge of the Aussie Games Industry”. The most political session at the conference. Scott Ludlam’s presence on the panel is always a dead give-away.

There were plenty of questions about how to change the status quo, how to make games a more serious part of the Australian economy, how to get taken seriously. And it sounds there is slow progress, but still…

…I feel frustrated on behalf of the panelists when people as “Tell us what we should do?” or “Tell us how we can get meaningful change?” As if permission to act is required. When in reality the best thing everyone can do is to put their best argument in the ear of their local politician. Nothing motivates politicians better than mountains of individual arguments, because they betray a level of passion for the subject.

The dirty little secret of politics is that the less effort you have to take to make your voice heard (copy-paste campaigning, or signature gathering), the more of it you need to carry the same weight as a dozen well-crafted personal messages. Effort counts, not volume. Effort in lobbying translates to effort to get politicians elected (or challenged).

I’m not a citizen. So I don’t get to vote. But I still have an argument to put forward from some simple facts that were incredibly easy to gather from the prompts of several speakers. So here is my bit for the cause.

Globally, the movie industry is worth about $90 billion this year (and climbing).

Globally, the music industry is worth about $27 billion this year (and declining).

Globally, the video games industry is worth about $114 billion this year (and rising rapidly).

Malcolm Turnbull talks a good game in support of the digital economy. Labor has thrown their support behind this message. Getting support for the software industry should be a slam dunk.

And based on current trends, next year the video games industry is going to be larger than the movie and music industries worldwide.

And game development studios have a much more direct path to access the global economy; we already do well in Australia considering the general lack of support the industry gets.

But in light of the numbers above do the movie and music industries get generous support, whilst the games industry gets absolutely none? Success in the latter will be a much bigger factor for the success of the Australian digital media industry than either of the first two.


Time to put money where the mouths are. How about extending some tax incentives into the industries of the future, and set Australia up to punch above its weight internationally?

Now, share this post with someone.

And then make contact with your local politician, and make your own argument why this matters for your career, your economic future, your passion. Because that’s how it is done.

ADSD with AOA and Udi – Day 4

It has been four days since I slept.

I am hallucinating Authorities (aka Services), Bounded Contexts, or is that Business Components? Up is down, down is up. Everything is abstract. Everything is physical but different. Or not.

Today we moved at a much steadier clip through our materials. I was more alert by necessity, and there were fewer tangents, although still enough. There’ve been a few cases of not-really-questions-more-comments-to-try-and-impress, but far more frequent are in-depth tangents that feel like individuals trying to get some free consultin’ out of Udi.

It is of course hard not to bring your real-world scenarios into the learning experience, but there is a difference in the feel of a question motivated by not-quite-understanding and a question that is looking for a solution.

Today was actually surprisingly more concrete and nuts-and-bolts. Still provocative and even surprising in places though, but I wouldn’t have *that* any other way. Why yes, yes, let’s connect the javascript client straight to the database; and the case he made was surprisingly compelling all things considered.

I cannot quite tell how he felt about CQRS; the tone and body-language was somewhat dismissive, but he explained it with a level of nuance and determination at odds with that posture. He was definitely dismissive of Event Sourcing though. And we’re not allowed to use Udi Says for justification, but it was hard not to sympathize with his assessment of the limitations on its value.

He still reveals some things with a larger sense of mystery and caginess than I think is warranted, but at this point I’ve decided the showmanship is just getting the best of him.

And… I was so hopeful.

We got to 200 pages out of 250 around 4pm. I thought today was going to be an “early” one (i.e. 5:30pm for example), since I knew he had a further speaking gig in the evening, and surely he eats?

In the end he raced through to page 237 by about 7pm. I’d have said that bodes well for an early mark tomorrow, but I really have no idea what to believe anymore. I’m doing my best to stay focused and absorb everything throughout the day, but it is … so … hard.

One more day.

I can do this.

And then, hopefully, a more in-depth summary of what I got out of the experience.

The Answer Might Surprise You.

ADSD with SOAAOA and Udi – Day 3

Dear diary, today is day 12 of my 5-Day Training Course.

I would complain about the energy drain if not for the appreciation that Udi is investing so much of his time. Every day starts at 8:30, and goes well past 6 pm with very limited breaks. It’s a … marathon? (I hope?) We’re now 30 hours in with at least 20 more to go that I can tell, excluding further homework tomorrow.

I am a bit mystified why Udi uses the word “Service” so much when he clearly has a distaste for its nebulous definition and general appropriation. “Authority Oriented Architecture” sounds like a much better descriptor overall, even if Authority isn’t ideally unambiguous either.

IT managed to go through all the good words by the end of last century, re-defining them all into meaninglessness.

The pattern in Udi’s style is abundantly clear by now; cleverly selected examples without singular answers, and a well-honed skill at arguing, together make for a lot of head-scratching around the room. I am enjoying thinking around the provocative propositions he throws out there, but I cannot help but feel there’s a level of empty calories about the exercise.

There will be no technology advice anywhere along the way. That’s an implementation-detail that is case-specific and therefore not something he can (or will) give us. I think some in the class are still hoping/thinking we may end up there, but that’s not the direction this course is following.

There will also be no scientific underpinnings for the theories. De-composing architecture along the lines of his advice is a good thing, because. And by squinting just right I am convinced overall that’s true, but I wish I had something more concrete to hang that on. Case studies. Empirical evidence. A rigid mathematical proof (I can dream…), but that’s also not where this is heading.

It’s a very valuable exercise at stretching the mind, and learning new ways to approach architectural and design decisions though, and that’s not to be sneezed at.

Still no silver bullets, sadly.

ADSD with SOA and Udi – Day 2


Apparently I am back in school now; after a long day (8:30am – 6:30pm) I have a homework assignment for tomorrow. I had hoped to get some extra sleep tonight, but no luck.

Using Thing-Oriented-Architecture, I am modelling the service boundaries for a hotel booking system tonight. I probably will save some for on the train tomorrow morning, because I could barely keep awake today and if I don’t sleep well, tomorrow will be worse still.

As much as yesterday felt like the set-up for some grand unified theory on distributed design, after today it feels like there aren’t going to be any answers, just increasingly vague questions. And a lot of my own opinions. So maybe more than anything this is a course to help me figure out what I believe myself? With some rules-of-thumb thrown in?

So far the single most useful piece has been a helpful question to determine whether services are sitting in the right context together (or not). I can tell it’s going to get a big work-out in time.

And I’m looking forward to the suggested approach to pull information back together into a cohesive interface. I can kinda see where Udi’s leading, but it is still a little bewildering. This may be exacerbated by the fact that he is clearly purposely constructing worst-case examples to push boundaries.

I’m hoping tomorrow brings more answers than new questions.

I’ll hold off on holding my breath.

ADSD with SOA and Udi – Day 1

I am learning this week.

Advanced Distributed Systems Design with Udi Dahan.

So far, I have acquired many new questions that I didn’t think I had need of, and I am hopeful that in another 4 days they will all have disappeared again whence they came. I am an optimist.

One thing missing from the copy of the slides we all got was the reference table for quick lookup of relative latencies in computers; it’s good to keep in mind how much slower memory is than the CPU, and how much slower an SSD is than memory, and network than SSD and reboots beat everything. I kinda feel an urge to start suffixing method names for nasty latency surprises to make it a bit more obvious.

As my mind wandered onto tangents, Conway’s Law took on a whole new dimension too. I wonder if software organisations should ever re-structure if there isn’t a need for software re-architecture.

I have so many provocative notes in my little booklet that I’m not sure how to turn into cohesive provocative statements. I’m also not sure which ones I actually believe yet, so maybe I will have a more nuanced view to filter them through towards the end of the week.

There are definitely things I disagree with, possibly strongly, but I haven’t given them as much thought as Udi, so I do not feel qualified to disagree overtly just yet.

First, I need to get through all these damned questions.

Testin’, What is it Good For?

Not quite absolutely nothin’, but I am starting to wonder.

More tests means more coverage means more green that changes to red at the slightest change. 100% test coverage means 0% freedom to change a line of code without changing a test as well.

At the start of the month we retired a truckload of tests at work, and the world didn’t end. We instated a rule that tests that are red for 3 consecutive days get terminated with extreme prejudice. Always red = no value.

But I have been thinking. What is the value of a green test? I mean, a test that is always green. Tests that have never been red are no more valuable than tests that do not go green. But it is so hard to let go; so tempting to think that a test surely inherently has value.

But do they really?

What makes a test worthwhile? What are tests for? How many?

Bug-free software is a white whale. Every test is a constraint to change. Like any other code, it isn’t free; keeping it is costly. So, I guess the answers are “just enough” and “giving us confidence where we need it” and “when it proves a real invariant truth”.

I just need to work out a practical applications of those holistic answers. But it definitely starts with “less is more”.

Three Whys

“Why?” is the most powerful question in existence.

I hadn’t thought much about it till a year or two ago when I experienced a CTO that wielded it like the probing tool it is. “Why” doesn’t judge. It doesn’t presume that anyone is wrong. It just asks for an explanation, and at the end of it you either learn something new, or you discover a fallacy. You win either way.

I was of course also aware of Simon Sinek’s excellent TED video on his theory about purpose (disregard the sound quality around the start; from memory it is quite poor).

I hadn’t given “Why” much more thought other than as a tool for pitching.

I have sold “Why” short.

Change of Job

I have been working at my new job for about 6 months now. A few months ago, our corporate core values were unveiled, and I am proud to say that “Make Mum Proud” is literally at the top of the list.

But more significantly, “Care About Why” was the one that kicked my mind back into gear.


Always there.

And I decided to buy Simon Sinek’s book “Start With Why” which is an expanded written version of the TED talk I linked above, essentially no additional information, but a more full exploration of the power of his central thesis that customers by “Why” you do it, not “What” you do.

Companies that do well have in his experience one factor in common; they know why they do what they do.

Why for Companies

He makes a compelling case that companies with a strong purpose, a strong “Why”, outperform companies without one. And before you think a glib “To Make Money Of Course!”, that’s not a “Why”, that’s a “What”.

Apple’s central purpose is revolution. Microsoft’s central purpose is unlocking potential. SouthWest Airlines’ central purpose is to bring air travel to the common people.

Those clear “Why”s do not predestine these organisations to greatness, but they create a framework for authenticity that consumers buy in to. And as long as the organisation keeps living by its “Why”, the consumers that identify with it will continue buying. It’s the stuff religious computer wars are built on.

The “What” of the organisation should flow from the “Why”, and by staying aligned, it proves the “Why”.

When organisations lose alignment they decay; like Apple did when they got rid of Jobs in the 80s. Like Walmart has done since giving up on “Making quality goods affordable”, instead focusing on lower prices at all costs.

Why for Departments and Why for Teams

I had a sense though that “Why” applies at more than just the top level of an organisation, but I was having some trouble formulating why. Ironically.

Organisations without a good why have to rely on every level of management to carefully refine and align plans with their bosses, through the VPs, all the way up to the CEO. That’s hard work. When you don’t have a clear purpose, you cannot rely on everyone marching in the same direction without detailed orders. Don’t get me wrong, Apple still needs middle management, but when they are steering for that next revolution it has to be a little easier when everyone up and down the management chain knows what the company is about. Trade-offs at the lowest levels can be resolved in line with the central purpose without continuous supervision.

So, why bother with “Why” below the top?

I think though that every department and every team must have a purpose of their own; obviously not completely distinct from the corporate “Why”, but aligned with it and in support of it.

If I were to work in software within Apple, I think there’d be a strong “Why” driving for an integrated experience across their products. “It just works” has always been their mantra, and that doesn’t just happen.

If I were to work on iTunes within Apple (shoot me now!), I think there’d be a strong “Why” driving for tapping into the consumers’ sense of identity and the artists with which they identify.

But those “Why”s are more malleable than the corporate one; every re-organisation is a signal that there is a “Why” to re-align based on prevailing conditions within or without. Companies rarely re-align their complete identity. And even more rarely succeed.

Bonus – Why for Individuals

This fourth “Why” gets touched upon by Simon in his book as well. But it is of a slightly different nature. It’s worth keeping in mind though, because when your personal “Why” gets misaligned with your “What” you’ll feel it. You’ll know something is wrong.

And what it usually means is that it is time to move on.

You cannot expect an organisation to adapt itself to your personal “Why”, and although you certainly can, I wouldn’t recommend following the “What” just for the sake of a known job; change is scary, but a misaligned “What” is more painful than you realize until you finally let go of it.

Now excuse me while I go ponder my Team “Why” and my Personal “Why” some more.

(Unit-)Testing State of Mind

My mind has been steeped deep in the quagmire of automated testing for the past few days. If ever there were an area of software development where I wished for a silver bullet that I could just load and fire…

I’ve gone from a job where testing was predominantly a lightly automated activity, to a job where large swaths of the testing effort are automated to a high degree. I definitely prefer the latter in principle, if only there were a definitive book of recipes and best-practices to follow.

I enjoyed watching the Pluralsight video on Code Testability; it has the best explanation of what makes testing code hard that I’ve ever seen. The side-by-side examples in which he shows how using dependency injection increased what he calls the “sphere of influence” (or the directly testable surface) of the code was an A-Ha moment for its sheer clarity.

And another video that has gotten lost in the blur in my memory made a great point regarding keeping tests descriptive and linear. Unit Tests are easy to write because they do not branch or loop. They test one thing well at a time, and as a result feel more reliable; being able to read and trivially understand a test is a major strength.

And yet… it bothers me when a lot of the hands-on examples in videos still show how to test an “ArgumentException” type gets thrown. I blogged about exceptions what feels like an eternity ago (Exceptions – 3 specifically), and ArgumentExceptions should not be caught; they aren’t for code to deal with, they are for code to try and avoid at all cost. So why test them? Like… ever?

There are plenty of proto-guides on (unit-)testing best practices, but few if any get beyond the obvious: isolate your test cases, pick structured names, be wary of mocking, test one thing only. But that still doesn’t really give any guidance on what is worth testing. Writing tests is easy enough, writing the right tests, and no more than necessary, is the hard part.

Are there resources out there I haven’t found yet?

Cannibals and Pirate Lords

I feel guilty for doing nothing.

On my weekends, I spend a lot of my time in books and television. I let it wash over me, but I feel like I should be doing something more constructive with the time.

I feel like I should be working on something, a new language, a new project, a new idea. Or being out with people, somewhere, anywhere.

I guess it’s a struggle between the introvert and extrovert.

On weekends, the introvert tends to win more often than not. I save the extrovert for Monday through Friday it seems, maybe because he is so damned useful at work?

So, this weekend, right now as a matter-of-fact, I am watching some Hannibal… because I can.

And I have a box-set of Pirates of the Caribbean waiting to be studied in detail… because I need to learn to be a better pirate for work-related reasons. Also D&D, but “for work” sounds more interesting and mysterious so that’s what I’m going to label it.

I haven’t quite worked out whether this means I need to let my hair grow or if I need to buy a bandanna and a hat.

Time will tell.