Stories about Software


Low Cost Legacy Help

If I think back a number of years, I can remember sitting in a software shop and feeling like the iconic stranger in a strange land.  I valued writing clean code, practicing TDD, refactoring away from procedural, legacy cruft, and generally improving my craft.  This was not otherwise common.  There were architects in that place that were long on seniority and opinions but short on chops, and they really, really liked them some global state.  And class size?  The bigger the better.

I seriously felt like I was in some kind of weird, parallel reality.  We’d have lunch & learns and watch things like Uncle Bob videos or talks from Channel 9 or whatever, and I would leave thinking that some kind of brainwashing A/B trick had resulted in me watching a different video from everyone else.  It was discouraging.  

I made progress in fits and starts.  I’d refactor a method here, kill a singleton there, inject an interface here, delete some dead code there.  But, then I’d go for a long weekend trip and come back to find a new singleton with more global state than its recently deceased cousin.  It was two steps forward and one step backward on a good week.  Like wading upstream against a raging, waist-high river, it was slow, exhausting progress.

I remember thinking that it’d be great if I could plead with one of the speakers in the video to come in and talk to people in this shop.  Maybe if one of the folks from the video was there, speaking live to them, something would finally get through.  Or maybe the video hero would take pity on me and offer me a job.  But I also knew that this was a pipe dream because hiring a consultant like this would be wildly expensive.

A lot of years have passed since then, and my life has evolved considerably.  I make most of my living doing coaching and helping improve software development craft.  Other parts of my living come from making videos and writing books about the same.  And through it all, I’ve never forgotten that feeling — a feeling with which, I’d imagine, many reading are familiar.

I’ve recently piloted with great success a new coaching model.  Think of the Chess TDD series, but imagine that instead of building a (non-trivial) toy application, I was doing a codecast in which I refactored some nasty legacy method in your code base to make it testable and narrated over it, explaining what I was doing and why.  The beauty of this approach is that we can pick some problems that are representative of your code base, and you can refer to the videos for context when doing refactorings from then forward.

This has proven to be a good option for small shops because it’s low touch.  It doesn’t require much if any synchrony, and, perhaps more importantly, it doesn’t require flights, hotels, a multi-day engagement fee with opportunity cost, or advanced schedule clearing.  It’s really just a matter of billable hours, which winds up being something like three hours per hour of video footage.  And five-ten hours of video footage is a surprisingly large, helpful amount.

Think of it this way.  It’s like someone recording a Pluralsight course wherein they refactor your code.  So if you’re reading this, and you think your code base and/or team could use a kick in the pants, feel free to reach out, even if it seems like a long shot.  There’s no charge for us to talk and even for me to sign an NDA and take a look at your code.  You can tell your boss or whomever that I really just kind of jump into problem solving mode and only start to think about billing arrangements once I’m convinced that I can contribute meaningful value to you.

Because, honestly, it’s also a lot of fun.  :)


I Have a New Book

It’s been an interesting week with respect to my philosophy about the future of labor for knowledge workers. This post about corporate idealists and seniority got relatively popular and attracted around 10,000 readers. If you’re a regular follower of this blog, you know that one was just the latest in a series of a few posts I’ve done on this topic and you probably also know that these are coming from my work on a book. But this understandably wasn’t immediately clear to new readers, and so I got a smattering of inquiries as to where the book was for sale or whether it could be pre-ordered. I invited those folks to stay tuned or sign up for my mailing list, but alas I had nothing to offer.

A few days later, I noticed the hashtag #talkpay on Twitter, promoting the controversial but clearly forward-thinking idea that making salary information confidential is problematic in a variety of ways (specifically, in this case, that it facilitates gender and racial pay inequality). I’m not a salaried employee, so I couldn’t offer information about my salary, but it did prompt me to tweet this:

As you can see, this was a pretty popular sentiment, which jived with the reception my post about salary negotiation hacks received. There appears to be a great deal of appetite for reconsidering the knowledge worker’s relationship with the corporate structure.

To this end, I decided over the weekend to put an end to my large-batch approach to writing this book and include anyone that wants to come along for the ride right from the outset. I wrote my initial introduction to the book and published it on Leanpub (most of the material I’d been gathering is still scattered in a large document on my personal google drive). Beware, there’s not much there, but that will change. In the coming months, I’ll be writing to the book almost the way I would to a second blog. So, stay tuned.

The infant book is now officially on Leanpub and officially for sale. I have absolutely no idea what I’m doing when it comes to marketing or setting price, so please bear with me. It’s doubly confusing because Leanpub offers a lot of different options for differentiated pricing. The minimum price for the book is $1 and the suggested price is $4.99. The suggested price was just the default, and the minimum price is 1 cent more than the default for no particular reason other than selling things for 99 cents seems somehow hokey to me. I considered making the initial minimum price free, since there’s not much book there, but data about whether people would pay for the thing or not is a lot more meaningful if people have to pay for it. If I made it free, I might get a lot of spurious information (lessons learned from Lean Startup and 4 Hour Work Week).


Now, here’s the nuance. You can get the book for free. I wanted to be sure to offer that option to people that are regular fans and followers of the blog and will provide feedback as I write it along with support and shares. So I created a coupon that I’ll send out to the DaedTech mailing list as well as anyone who signs up for it from here forward. Also, I’m not going to lie. If you just email me, I’ll send you the coupon too, but I’d prefer to do it through the mailing list. For those of you on the mailing list, look for the coupon email in the next few days.

As I said, I have no idea what I’m doing when it comes to marketing, so I hope this makes sense and isn’t crazy. I wanted to err on the side of giving too much away if I erred in any direction. Weird as it sounds to say, I’ve never regretted erring on the side of giving away content. People seem to live life petrified that they’ll give something away for free when they could have wrung a few dollars out of it, but for me, the goodwill and engagement created by giving away content has paid far more dividends down the line than a few dollars.

So I cordially invite you to join me on this book journey. And, naturally, I invite you to invite as many of your friends and colleagues as you please! :) I’m excited and looking forward to this, and fascinated to see how it goes.


Some Changes to DaedTech Because I Want to Build a Thing

If I squint hard enough, I see an odd symmetry to my life that can be book-ended pretty simply with the phrase, “I want to build a thing.” I say this now, and I said it when I headed off to college, but I didn’t say it all that much in between. At least, I didn’t say it in the macro sense. But let me start the story a little before college.

As a kid, I was pretty equal opportunity when it came to academics. This was eventually born out somewhat empirically by my nearly identical SAT scores for math and verbal. So even though I had aptitude for math and the sciences, the first actual profession I aspired to in a non-childish fashion was to be a writer/novelist. I was pretty sure that I would make my living this way until it came time to apply to college. Here, I punted on a decision, applying to what I perceived to be the most rigorous major/school at each college and reasoning that I’d sort of force myself to make a decision. Mission accomplished. After weighing options and finances, Carnegie Mellon University in Pittsburgh was my best option and they were pretty good at Computer Science, so Computer Science it was. The world was enthralled with dot-coms, I’d always liked hacking around on my programmable calculators, I was told I’d be printing money when I graduated, and so I headed off to school saying, “alright, I’m gonna go build a thing!”

AirportMetalDetector Read More


How My New Pluralsight Course Can Help You

I spent a good portion of this fall working on a Pluralsight course.  It was originally going to be ready earlier, but it’s a lot harder to get a course recorded in a hotel room than it is in my comfy office at home. Nevertheless, I finished it up some weeks back, and it was just released on New Years Eve, 2014.

Earlier this fall, I wrote a post called “Have a Cigar.” In it, I described how I thought we as developers had essentially opted out of controlling our own destiny by adopting the attitude, “I’m a programmer and I don’t care about that business stuff.”  Sometime later, I read this post by Michael O. Church and realized there was a nice tie-in with autonomy as well.  Programmers feel they have more “geek cred” by eschewing “business matters,” but they also know that they’ll have autonomy when picking an RDBMS in a way that they won’t when discussing what the tools and software budget should be.  It’s a completely understandable sentiment.

But unfortunately, the road to controlling our own career destinies travels through “the business.”  If we want to lead existing organizations or found new ones, we can’t operate as if we were in some kind of technical think tank.  We need to learn to solve different kinds of problems, and in order to do so, we need to play on the home field of the MBAs, project managers, CPAs, and C-levels.  And to do that, we need to be able to communicate effectively in their language about concepts in our field.

It was toward this end that I made this Pluralsight course, entitled, “Making the Business Case for Best Practices.”  I wanted to start a conversation and provide some tools to people in our line of work that are looking to help people understand why they’re doing what they’re doing.  I wanted to give you a way to say, “We don’t just do practice X because it’s ‘the right thing.’ It also helps us make money.”

One thing I’m asked pretty frequently is “how can I convince my manager/the CTO/the project manager/etc. that we should do TDD/continuous integration/code review/pair programming/etc.?”  Usually, they’ll say something like, “I know it’s the right way to do it, but how do I make them see that?”  My response is generally something like, “How do you know it’s the right way to do it? Does it help your company make or save money?”


Often people are surprised by this response, especially because I’m such a proponent of many of these practices.  But the reason that I’m a proponent of them is because they’ve helped me and companies I’ve worked with to meet their goals with the aid of software.  In other words, TDD isn’t the right thing to do because it is a superior approach, but rather it’s the right thing to do if it helps generate revenue or reduce expenses for the company commissioning the software.

It’s important to understand that because it’s important to understand that software is a tool and not an end goal.  If you’re a developer or working as a PM/line manager for a software group, it’s easy to view the software as the be-all, end-all. But in reality, you’re writing software to help do something more basic — automate an expensive, error-prone process, help customers communicate, run some kind of hardware that end-users use, etc.  And so the only thing that really matters when you’re discussing how to write that software (TDD or not, pair programming or not, etc) is whether the practice will help the software’s stakeholders achieve their goals and/or save money in the process.

Once you’ve come to understand what truly matters when discussing how to approach writing software, you’re in a much better position to make your case to the people that control the purse strings.  Imagine that you’re trying to make the case that your group should use static analysis and the crusty old architect with 25 years of seniority is stymying you.  His argument is probably something like, “blah, blah, 25 years, blah, blah, tried it before, blah, blah, can’t work, blah, blah, pointless, blah, blah kids these days.”  But his argument is likely to carry the day due to his tenure if you argue back with “blah, blah, right thing to do, blah, blah, saw at a conference, blah, blah, Uncle Bob, blah, blah, my grad school text book.”

But now, for a minute, imagine that you’re in the CTO’s office with the architect and he’s just made his tiresome case.  Instead of making a similar one, however, you plug in your laptop and start a slideshow where the first slide says, “Static Analysis is going to save you $13,000 per year in your budget.”  I bet you he snaps to attention and watches carefully as you lay out your case in the subsequent slides.

I wrote this course to help you do just that — to help you make the case for practices that you want to adopt not because they’re “best” but because they’re profitable.  I’ve been using this approach for some time now, and I’ve had a great deal of success convincing the people that needed convincing that my approach was sound.  I’m hoping that, with the aid of this course, you’ll have luck doing the same.

I couldn’t be more serious about the need for technical people to reclaim “the business” instead of shying away from it.  So I encourage you to take some time, learn the language of business and learn where and how software practices fit in to improving the bottom line.  Your career will be better for it, and so will your endeavors.


Retrospectives Are So New Years 2014

The last couple of years, I’ve posted yearly “retrospectives” about this blog. Last year, I actually mentioned that I’d started doing this because it seemed like something other bloggers did and then I kept doing it because I like continuity. This year, I’d like to take the opportunity to stop.


I suppose some reading might be mildly interested in which posts of mine in the last year were most popular, how my demographic splits looked, or how many visitors I had per month. That is, if I told you in this post, you might read through to the end. Or, you might not. (It’s okay if you wouldn’t — I wouldn’t bother either, if I were in your position).

Thing is, none of that matters very much, so I’m going to dispense with the artifice for its own sake. I’ve never been much for traditions anyway; pretty much everything done at weddings bemuses me. The important thing is that I write these musings of mine and you read them and appear to appreciate them and I, in turn, appreciate that. I appreciate you spending a few minutes a few days a week reading what I have to say. Seriously. There is a truly infinite number of ways in which you could spend your time and you’ve opted to spend it reading what I have to say. I am grateful for that. Thank you.

At this point, read on only if you’d like to hear me ruminate a bit about this past, weird year of our Lord, 2014. (In case you’re wondering, I haven’t taken this blog toward religiousity — “AD” means “Anno Domini” or “In the Year of Our Lord” so every time you date a check this year, regardless of your religion, you’re dating it “In the Year of Our Lord 2015.” I believe this is why people have pushed a bit for the designation 2015, CE or Common Era.) The rumination will be relatively brief and light — I promise.

Last year, I talked about growing up as a blogger. This year, I’ve grown up as a human. At the beginning of 2014, I was running an IT department. In the last 12 months, I bid a reluctant farewell to that job to strike out on my own as a free agent. It was a difficult decision but I had, in essence, become convinced that I would not find what I was looking for in the corporate world and I essentially opted out… at least as a salaried, W2 employee. I accepted the fact that life as a Company Man would inevitably disappoint and decided to try a different tack.

It’s been fun and interesting. I’ve grown my freelance application development practice a bit, but I’ve really branched into true consulting. What I mean by this is that instead of trading hours of software development for dollars, I’ve begun to favor offering my services as a velocity multiplier — working with organizations and teams to help them understand how to be more efficient at developing software.

Perhaps more important (and salient to this blog) than any of that, however, is my development as a content creator. A year ago, I had two Pluralsight courses and a couple of fresh E-Books. Today, I have 4 Pluralsight courses, 3 E-Books and 2 actual, printed books. While I’ve grown professionally in terms of leadership and consulting, I think I’ve grown even more in the arena of content creation.

As someone fortunate enough to have enjoyed a nice career as a software developer, the emphasis on content creation may sound strange. It’ll probably sound even stranger when, coming from a heavy STEM field, I explain that it was virtually assumed when I was a child that I’d wind up being a professional novelist or, at least, a writer of some sort. And so, the opportunity to fuse the fields of software work and writing is particularly appealing to me.

I don’t know exactly what’s coming in 2015, but I can tell you a few things. First of all, I’ll definitely keep writing to the DaedTech blog. Secondly, I’m going to keep working with Pluralsight. Beyond that, I’m planning to start doing some professional copywriting in the software industry and also to write a book from scratch. (If you’re interested, the loose working title/premise with which I’m operating is “Developer Hegemony: The Future of Work”). And, of course, I’m going to keep coding, keep working with developers, keep running teams, keep looking at your code bases and offering thoughts, keep loving technology and keep solving problems.

So, thanks again for reading, please feel free to check back and hit me up whenever, and have a great 2015!


A Thanksgiving Apology

I’d like to wish all (American) readers here a Happy Thanksgiving. I’m probably not going to make a post for Friday and perhaps not Monday, so this will be it for a little while. I’m rarely home these days, so I’m going to take the opportunity of being here to relax and visit with family. So, enjoy your own holidays or, if you’re not in the US, your rest of the week and weekend.

Also, I’d like to apologize for a situation brought to light yesterday by this tweet:

For those of you reading without the benefit of ad-block, I’d really like to apologize. It looks like at some point the disqus settings around advertisements reset to “show ads and shady ones at that.” I have no idea when I last updated disqus, so this has probably been going on for a while (I knew disqus would show ads, but I didn’t realize how gross they were). Those should be gone now, so please let me know if you see nonsense like that again. Looking at the credit I’ve earned through this accidental revenue source, the earnings aren’t nearly high enough to start asking the question, “does dignity have a price tag?” I’d rather provide a pleasant reading experience.

For anyone interested, here’s how to get disqus to stop doing that.

Anyway, for the holiday, enjoy this picture of a turkey:



Hot off the Presses

Instead of your (semi) regularly scheduled post, I’d like to mark something of a milestone today. As a child, I was pretty sure I had it figured out. I was going to write science fiction novels for money and alternate between roaming around the world and living in the woods. I’m not sure exactly where I went wrong, but somehow I got slightly off course and wound up roaming the country, living in legacy code bases and fleeing from people waving Gantt charts. But, all is not lost — I now have two printed, published books to my name.

Links to 3 E-Books have appeared on the right-hand side of my site for a while now, but 2 of them are now available in print. So you can go to Amazon, order, and receive a real, bonafide, bound, glossed and printed book that I wrote. Or two.

Here they are.

Starting to Unit Test: Not as Hard as You Think


This book is more or less what you would expect, given the title. It assumes that you’re a developer who’d like to have some experience writing automated unit tests. But… you don’t know where to begin. The book invites you to relax and assures you that it won’t be so bad to learn if you set yourself up for success.  It also might be a great thing to slide casually to people on your team that can’t seem to break themselves of the habit of writing legacy code in real time.

If you’d like a copy, here’s the Link to Amazon

The Expert Beginner


This is the synthesis and refinement of a series of popular posts I made some time back. It’s about the unfortunate journey that some people in the tech world take from novice to “not very good, but I was the first one here so now you have to listen to the dumb stuff I tell you.” Somewhat cynical on the surface, it really underscores what I perceive to be a muted, industry-wide tragedy but one from which recovery is certainly possible.

If you’d like a copy, here’s the Link to Amazon

Enjoy, and for those of you hoping for the next Chess TDD post, it’s in the works.  I have some of the video for the next one, but it needs audio.


Happy Independence Day

Here in the United States, the 4th of July is Independence Day. Traditionally, this holiday is celebrated with barbecues, warm weather activities, beer, and blowing things up, generally in the form of fireworks both professional and amateur. Given that it occurs on a Friday this year, it’s a big 3 day weekend here for most (though as of last Friday, my life is kind of a constant semi-weekend where I work on weekends), so I anticipate readership being a lot slower than normal as people are going to be at pool parties rather than browsing their RSS feeds.

While I do have several posts that are ready to go, I’m going to save those for next week and just wish all of my fellow American readers a happy 4th, and all of my other readers a happy weekend. To celebrate, please enjoy this picture of a bald eagle holding a sparkler:



On My Own as a Free Agent: DaedTech Grows Up

In 2013, I made a mildly rambling life update post. In it, I described that I had decided to leave the job I had at the time with the intention of job seeking and blogging about it all the while (and also possibly striking out on my own). Things passed in something of a whirlwind and, when the dust settled, I had an offer and was back to W2 employment the Monday following my last Friday at the previous job. So many lost opportunities for interview anecdotes and “holy crap I’m actually on my own” posts about what it’s like to be a freelancer.

Well, the good news is that I’ve managed to double back after taking the commonly traveled road and set out this time on the one less traveled. Take that Robert Frost; I’ve now taken both roads and it has made all of the difference. Anyway, my point here isn’t to antagonize icons of poetry, but to announce that, starting this week, I am now in business for myself.


Like last time, my situation is somewhat fluid. I’ve agreed to consult with my now-former company on an extended basis and will continue my work with Pluralsight and on the blog and in the community in general. I have a few engagements lined up, both potential and scheduled, and the aim at this point is to start building and broadening my book of business. But there are also a few companies I’ve had conversations with about various intriguing full time opportunities. So the next month or two will probably be a busy, marginally confusing and formative time for me that is likely to determine the course of my career in the near term future, depending what I decide to do.

If you’re interested in working with me in some capacity, look for updates to the site’s menu soon to formalize and organize my thoughts, but I’ll speak to it a little bit here in the shorter term.  I’m willing to do some software application delivery work — essentially implementing applications needed by prospective clients.  But two areas in which I see myself as a fairly high value add, given my experience, are true consulting and what I’ll loosely describe as coaching and related delivery.

In the capacity of “true consulting,” I can bring a variety of experience to bear, ranging from line level development to C-level departmental management.  If your firm needs advice on implementation or architecture, I can certainly supply that, but I can also help provide gap analysis, recommendations for technical strategy, ROI calculations for software initiatives, help selecting and evaluating candidates/staff developers and plenty more.  Under the heading of coaching, I can help your group out with agile transformations, implementing and selling external stakeholders on accepted best practices (automated testing, continuous integration, TDD, automated builds and deployments, etc), mentoring/teaching developers, performing code reviews, speaking to your group etc.  But beyond that, I’m happy to put my money where my mouth is beyond just coaching; if you want to hire me to clean up your group’s build, move you over to a new source control scheme, refine your ALM tooling, etc, that’s an excellent fit for me.  And, if any of you reading are not in a decision-making position but would like to see these changes implemented in your group, I have a knack for selling management on change and sidestepping Expert Beginners.  We can talk and see if maybe we can’t get a meeting with your management and the winds of positive change blowing through your company’s halls.

Those are the arenas in which I see myself being most valuable to prospective clients, and I really enjoy working with developers and people in the industry, so I’d be happy doing that sort of work.  But really, I’m open to anything that sounds interesting.  If you have an idea for a project you’d like to work on with me, a pitch for a startup, a full time position you need filled (I’d probably really only be looking for leadership roles if I were going to consider W2 work), some writing or developer evangelism (but only if I believe in the product) that you need help with, or really anything you can think of at all, please don’t hesitate to reach out.  I’m always up for a discussion.

I don’t doubt that I’ll have more refined messages about what I’m doing later, and certainly I’ll have posts about my experiences, struggles, and learning moments.  My goal here was just to make a quick announcement of what I was doing and invite those interested in possible arrangements to reach out so that as many interesting opportunities as possible presented themselves.  Someone recently asked me what kind of working I was looking to do, and my eyes sort of widened and a really obtuse response came out before I could stop myself: “interesting work.”  This was actually an intense bout of honesty, though, and I don’t know that I’m looking for too much more than that, in terms of the work.  I’m looking for an opportunity to be autonomous, diligent and creative, and to solve challenging problems.  Beyond that, I kind of grow where I’m planted.  I could be happy working on implementing programming language, detangling a nasty legacy code base, selling your management on the virtues of iterative approaches, cranking out code for a product idea, writing an interesting story about a compelling developer tool, and just about anything in between.  So please don’t hesitate to reach out with anything that you think might be interesting, fun or challenging, and I promise in return, I won’t hold back on relating anything interesting about my experience, even if it’s lessons that I learn from embarrassingly stupid or naive things that I do as a fledgling business owner.


Starting to Unit Test: Not as Hard as You’d Think

I happened to read a post by Dror Helper the other day, in which he said:

I believe TDD and “unit tests” has been done a great injustice by not giving it a cooler name – preferable one that doesn’t have the word “test” in it – because it’s a PR disaster!

Wow, that had never occurred to me, and yet he’s spot on. “Unit test” is a wretched name for anything. It seems somehow to combine all the worst elements of propagating uncertainty in arithmetic with lab measurements and double checking all of your answers on a scantron exam. I just bored myself half to death typing that sentence, so it’s little wonder that the concept of a “unit test” is often met with a visceral “ugh.” I mean, we could at the least call the test suite a “verification checklist” or something, implying that you’re marking progress as you complete things. It’s not exactly a skydiving trip, but it has to beat “unit test.” But I digress.

The lack of appeal of the name, the feeling of already being pressed for time without taking something else on, and the natural resistance to the unknown all create barriers to entry when it comes to unit testing. In order to get started yourself, or especially to convince those around you to do the same, it’s necessary to overcome those barriers. I have a good bit of experience with this in a variety of environments and from a variety of roles. Over the last year, I did a string of blog posts that were essentially my talking scripts for a series of power point/demo talks I gave. These were meant to be an introduction to unit testing.

The series actually became pretty long, and as I was finishing it, I decided to put it into E-Book format. So, with the help of my editor, we turned it into fluid book, and with the help my publisher, we published it in all major E-Book formats for a cost of $4.99. Here is the book on the publisher’s site, and here is a link directly to Amazon
for Kindle readers (full disclosure: I’m experimenting with affiliate links, and that’s why I’m specifically linking Amazon directly).

The title of the book is “Starting to Unit Test: Not as Hard as You Think,” and I feel that the title really captures it. My goal was to trade practice purity for reducing the barriers to entry. In other words, the message was, “don’t feel like you have to start full bore with 100% coverage, TDD, and anything less is a failure — if you just introduce a few tests into a few places in your code, consider that a win.” I also did something else that I haven’t seen others do as much, which is to explain that some types of frameworks and code present unit testing nightmares, and that newbie unit testers should avoid them until they reach a higher belt.” What I’d like to see people take away from this book is a feeling of satisfaction from experiencing a sequence of small but real wins.

For you mythology buffs, this is Sysiphus actually making it to the top of the hill.

For you mythology buffs, this is Sysiphus actually making it to the top of the hill.

By and large, you could get this content by reading through my blog posts on the subject, but if you want it in a compact format, here it is. Not to mention, if you’re trying to sell your team on the merits of unit testing, a book is probably going to have more cachet than a series of blog posts, and the one link to the book is going to be easier to distribute than the giant collection of links for the individual posts/chapters. So get it if you’re interested, and encourage your team to get it if you’re trying to introduce the concept, especially since I close out the book by making a business case for unit testing (this making cases for best practices is actually going to be a theme of mine in the future).

Enjoy, and thanks for reading (the blog and, hopefully, the book)!

Acknowledgements | Contact | About | Social Media