Revisiting The Phoenix Project

In one of my first posts on this blog, I reviewed a wonderful book called The Phoenix Project. The key lesson I got from the book then was that work in progress is a killer. Work in progress, that is, anything to which you have given time or effort, but which has yet to give you anything back, kills productivity. Another way to think of this is that productivity is hurt by starting some things before we finish others. (Look at it this way: If we always start a new task, and never work on an old task, we will finish nothing. If we always work on our nearest-to-completion task, and empty the queue before starting new things, we will finish everything, but may start new things only slowly. The best way to manage time is in between, but certainly closer to the second.)

The idea that we should finish things is hardly shocking. Joel Spolsky has written about it. It was the topic of a recent episode of .NET Rocks, and John Sonmez recently tweeted:

“Of all the habits you have developed in life, which is most beneficial? Mine is finishing things.”

For this post I am going to take it as given that finishing old tasks before starting new ones is better than starting new ones all the time without finishing anything. What I want to look at instead is why it’s hard. Why is it hard for me to finish things I start? What should I even finish? What should I even start?

MPJ recently did an awesome video about the difficulty of focus. The hard thing people never want to admit is that focusing on something means not focusing on something else. If we want to focus on making the user interface prettier, we are going to spend less time making data retrieval faster. Time allocations are a zero-sum game. To give time you must take time. So what should we give time to, and what should we take time from? That question seems hopelessly broad, so I’m going to try narrowing it to a more manageable focus: What should I start?

In The Phoenix Project, the IT department learns to start meeting deadlines by limiting the release of work. That is, they start to limit the rate at which they take on new projects, and this keeps them from blowing deadlines on projects they’ve already committed too. I seem to already have 43 side projects in flight, so maybe I shouldn’t take on any new ones for a bit. Maybe to start a project, I need to reconcile myself to abandoning an existing project. That would be hard, but the alternative seems to be always having 43 partially completed, messy codebases on my hard drive, which doesn’t really help anyone.

This post has turned into a long-winded and sort of depressing way of reaching this message: Finishing things is important, and it requires not starting new things till the old things are done. Queues are better than stacks for time management.

(Speaking of time management, @SteveAlbers and @jsonmez recommended Kanbanflow. It’s awesome. Check it out.)

Starting things is easier than finishing them, but finishing them is more important. I guess that’s a hard lesson.

Till next time, happy learning


Motivational Book are Motivating

Earlier this year I read Soft Skills by John Sonmez. It’s a book about non-technical (i.e. “soft”) skills that contribute to one’s career as a software developer. The subtitle, “The Software Developer’s Life Manual” really does mean it. The book covers finance, fitness, nutrition, job interviews, salary negotiation, etc.

Reading Soft Skills was a fantastically motivating experience. I found myself more interested in my future and motivated to improve it than I ever have been. There is a lot of advice in the book. Some of it, such as particular tips on job interviews and salary negotiations, I haven’t tested out yet because they simply haven’t come up. Others, like trying out audiobooks and starting a blog, I have tried. I’ll limit this review to commenting on things I’ve actually attempted, rather than guessing about the things I haven’t tried. Test everything and keep the good, as they say.

Recommendation 1: motivational books are motivating.

Continue reading “Motivational Book are Motivating”

Find a Code Camp Near You

The other day I attended the Nova Code Camp. (For those of you outside the Washington D.C. area: In this case “nova” means “northern Virginia” not “gigantic explosion of an aging star”.)  There might be a code camp near you, with a name of the form “<short geographic nickname> code camp.” You should go. Continue reading “Find a Code Camp Near You”

Three Facts about ASP.NET Core

Last Tuesday, Jeff Fritz (@csharpfritz), a program manager on the ASP.NET team at Microsoft, spoke to the Pittsburg .NET User Group about ASP.NET Core. After the meetup, I had a chance to speak to Jeff, and I asked him what he wished people knew about ASP.NET Core. These are my words, based on the notes I took during our conversation. Here are three things Jeff Fritz wants to get out there about ASP.NET Core:

1. It’s Built on Stuff You Know

The first thing I learned from Jeff’s talk is that my early interactions with ASP.NET Core had a little friction because of missing tools not missing ideas. In other words, I was trying to do a familiar thing (write some ASP.NET web applications) in an unfamiliar way. This unfamiliarity creates the illusion of difficulty, so we can focus on what we do know, and use the docs website to fill in the gaps.

MVC is still the basic pattern. C# syntax is the same (and getting better all the time). We still have Json.Net. In short, the fact that I had trouble finding my way around the new project layout in Visual Studio is a difficulty that’s both superficial and temporary. The tooling will come, and when it does I’ll learn it. And speaking of tooling:

2. Visual Studio 15 will Help A Lot

Visual Studio 2015 (the current version) shipped before ASP.NET Core was final, but Visual Studio 15 (the new version) will be designed with ASP.NET Core in mind. (Also, VS15 is available in preview.) I think that having well-thought-out menus and templates in the new Visual Studio will eliminate a lot of friction. Visual Studio 15 Preview 5 is already easier to do ASP.NET Core in than the previous tools I’d worked with, and I look forward to seeing the experience move. (Also, aside: Microsoft has been very responsive to feedback about VS15. I asked a question on Twitter about the licensing and received a response within hours; I opened a small bug report and someone starting investigating it within days. Thanks guys!)


(This is a screenshot of using the command line tool, dotnet.exe, to start a blank dot net core application.)

3. Core is Converging with the Framework

This means that the difference in available functionality between different implementations of .NET will go down. Right now, if I want to write some C# that can be used in 2 places, say in a Xamarin Android app and a Windows 10 desktop app, one option is a portable class library. The limitation is that a portable class library is always a subset – the intersection of the features available in each of the targeted runtimes. My portable class library will only have features that are available on both Xamarin Android and Windows 10. The pressure of diverging .NET implementations tends to reduce compatibility between the runtimes.

But the .NET Standard inverts this pressure – it defines a standard that any .NET runtime should meet, and then the implementers of the runtime and libraries on each platform can push to meet that standard. In other words, the runtimes will be converging on a standard, and developers can target the standard, instead of targeting the intersection of diverse and divergent feature sets.

After this talk, I am excited. I can’t wait to start using ASP.NET Core.

Till next time, happy learning!


Right Little Thing: Second 90%

The “Right Little Thing” is a category of posts I use to share quotes that have really helped me, and to explore why. (They’re called the right little thing because they remind me of the moment when a teacher says the right little thing, and suddenly the student gets it. My first post in this category has more info.)

Today I was listening to Developer on Fire, which is a fantastic podcast that I recently discovered, and I heard an interview with Daniel Moore, the creator of HyperDev, which is an awesome product I recently discovered.

Amid all this awesome, Daniel said something in his interview that really struck me. He said:

When you’re 90% done, then it’s time to start working on the second 90%.

Daniel uses this to capture the fact that the innovative, interesting, solving-cool-problems-with-code part of software is not enough to make a shippable product. If you want to make something people will pay you for, you have to be prepared to put in the “second 90%.”

I’ve recently been contemplating all the half-abandoned side projects I have, and thinking about finishing up, and I think that the part of what happened with these projects is that I didn’t budget for the second 90%.

This saying can also help a lot of project managers. I know I’ve tripped myself up at work by telling a boss I was almost done with something, when I was really almost done only with the problems that I knew about. I could have saved myself a lot of estimate-revising and a little face by saying, “I’m about to start the second 90% of the project.”

This principle reminds me of Hofstadter’s Law:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

I think that’s the whole lesson this week: in work and in life, remember to account for the second 90%; when you’re 90% done with what you think a project will need, roll up you sleeves and get ready to do the second 90% of the project.

Till next time, happy learning,


Those Prophetic Compiler Advocates

The other day I was reading the Internet, and I stumbled across a few posts advocating that one should write a compiler as a side project, because it will teach a person so much computer science. Despite having 43 side projects, I decided that the posts advocating that people write compilers as a side project are really, really convincing, and started fiddling with one right away. (If it ever gets into a state where I’d want other people to see it, I’ll put it up on GitHub and put a link here.)

In particular, Steve Yegge advocates writing compilers as a way of learning some of the really important things in computer science.

After I read that post, I started thinking about all the weird things I’ve worked on that are really a lot like compilers. For example, I worked on a project that allowed users to make tagged email templates, so that they could write things like “Dear {contact:firstname}” and it would come out as “Dear Frederick” or whatever when they sent the email. To get this working, I needed to compute the smallest set of queries that would let us populate all the little variable fields in the template. To do this, we split a string into tokens, build a tree out of tokens (where contact table is the root, intermediate nodes are tables we’re joining to, and leaves are columns we’re fetching data from), and emit a different strings, composed by arranging the tree’s nodes. The new string is a query we can send off to the database. It’s a weird-proprietary-email-language to weird-proprietary-query-language transpiler, but at end of the day it still tokenizes, parses, builds a tree, and emits code for consumption by some other program. For some value of “compiler” it’s a compiler.

I was working on a similar project the other day. Basically, some queries should be done through a REST API, and some queries can be done by calling SQL server directly. The API is easier to call, because it’s part of an existing SDK and someone else already wrote the complicated code, but calling SQL is a lot faster, so we want to call SQL when the query is simple enough that we’re confident of getting the SQL right. So we need to, guess what, convert the filter expressions and column sets and whatnot from the query object into some kind of tree, walk the tree, decide whether we can emit SQL, and if so emit SQL. Again, this is a lot like a compiler.

I noticed both of these projects’ similarities to compiler building after reading Steve Yegge’s post. It’s weird how slowly computer science changes, in some ways. I mean, compilers have been on computer science curricula pretty much forever (at least, forever in Internet years), and it’s 2016.

But there you have it. Being able to build a simple compiler that takes in strings and emits instructions is still super important. Turns out those prophetic compiler advocates were onto something.

So, if you really want to do something with computer science that will drive your skills forward, consider building a compiler. I hear the “dragon book” (so named for its cover art) is the one to read, and it’s definitely on my reading list for the future. When I get through it, I’ll make sure to post a review.

Till next week, happy learning,