If your software matters, you will write it in C++

Several years ago, at the 2008 ICFP, I was droning on about how awesome the F# programming language was the the language's creator, Don Syme. While Don appreciated my zeal, he put my irrational exuberance in check with a very insightful comment to the effect of "if your software actually matters, you will write it in C++".

The point isn't to claim that C++ is the "one true language", but rather that any benefit a programming language has for the programmer doesn't matter. If writing code in language X makes you 100x more productive but produces slow code, then all your users will notice is that your programs are slow.

Of course, like many of the great debates in computer science, there are a lot of nuances here about the importance of development time, language familiarity, platform adoption, and so on. However, I have provided an absurd proof backing up Don's comments for your amusement.

Proof: "If your software matters, you will write it in C++"

Definition: "software which matters" 

"Software which matters" is defined as:

- Software which is used by hundreds of millions of people daily.

- Software which generates billions of dollars in income annually.

Lemma: "software which matters" must be maximally optimized

"Software which matters" must be maximally optimized for { speed, ease of use, feature set }. Suppose by way of contradiction that some "software which matters" was not maximally optimized. It would be possible then, for an objectively better piece of software to exist. In such a world, over time, the objectively better piece of software would become more pouplar original software would cease to matter due to losing customers or revenue. [  ]

Proof

Step 1: Consider all programming languages requiring a virtual machine and/or runtime environment. (Java, C#, Python, and so on.) In exchange for niceties such as { memory management, runtime type checking, etc. } a non-zero amount of work must be done. For example, code must be JIT-compiled or a memory manager must be initialized. Such a non-zero startup cost violates the maximally optimized lemma, and rules out all such programming languages.

If you can shave 10% off of the startup time or memory footprint of software the matters, you will.

Step 2: C and C++ are the fastest known programming languages*. (* ignoring Fortran.)

Step 3: The only remaining languages for which "software which matters" can be written are C and C++. However, all reasonable C programs can compile using a C++ compiler. ("Reasonable" is intentionally undefined, like most of the C-standard.)

QED

How to Write a Technical Book

Currently my nights and weekends are spent working on the second edition of Programming F#. First of all, let me thank any of you who have read the first edition. Hopefully you enjoyed it.

Revisiting my old work has not only given me a chance to not only correct some errata, but also an opportunity to reflect on the whole book writing process. (Which started for me in the summer of 2008.) This post will serve as my mini-guide and scarecrow for anyone who is considering writing a technical book.

How to Write a Technical Book

Step one: don't. Whoever told you writing a book was a good idea lied to you. Whatever misconception you have about being a famous and respected author is also incorrect. I'm not trying to be ironic or cute here, I actually mean to tell you that you shouldn't write a book.

Start a blog. Go on a speaking tour. Write the world's greatest tutorial/website for your technology. Start a podcast. Do whatever it is you can to get your message out, but I urge you not to write a book unless your motives exactly align with what you will actually get out of the experience.

My motivation for writing Programming F# was to get the word out. I was at Microsoft working on an amazing new programming language, and I wanted to make sure that programmers showed up to the F# party.

While I knew that I wasn't going to make a lot of money, I thought that I would be able to earn a a tidy sum from the book. Perhaps enough to put a down payment on a house! Or at least zap those college loans floating around.

Read the following sentence slowly: writing a book will take more time and you will earn less money than you think. Now, after you have adjusted your mental model of expectations, reread that sentence at least two or three more times.

Fame

On the book shelf next to me I have about 100 books. Of those, about 50 are "technical" and on the subject of computer science, programming languages, technologies, etc. Of those books, I can name maybe 10 authors. (And I suspect for most people 10/50 authors is very high.)

My point is that while the author of Enders Game or Twilight is an important detail, in the technical book world it is not. People are going to buy Essential Microsoft SQL Server 20XX regardless of who wrote it, as long as the XX is the most recent release. I don't want to sound too much like a curmudgeon here, but I'm sure people will be interested in buying a book on F# 3.0 regardless of whether or not I write it.

So if you have big hopes of starting your literary career with that great Java book you have been planing, I'm sorry. But you are just the source of the product for a publishing company.

Fortune

Another thing to keep in mind is that you won't strike it rich either.

Books, like most other creative medium, pay based on royalties. You will earn something like 10% of all profits from the sale of your book. So, if your book makes its publisher $1,000,000 in profits then congratulations! However, not many books are going to sell that well. In fact, not many books even pay out past their advance.

Programming F# has done (what I would consider) exceptionally well. In fact it's even been translated to Japanese. However, I did the math and I would have been better off working at Taco Bell than writing for O'Reilly. (OK, I didn't actually do the math and can't say this for certain. But, I think at Taco Bell you would get free food, so I think the advantage is in Cheesy Gordia Crunches.)

If you are stubborn enough to avoid my advice and sacrifice a year of your life, then please read on at your own peril.

Obtaining a Publishing Deal

The first step of writing a technical book is getting a publishing deal. (Actually, self-publishing is super easy to do these days - especially if you are just targeting digital distribution.)

While being a "technical author" means that readers don't care who you are, this actually works in your favor because publishers don't care about you either. That is not to say that publishers don't treat their authors well, I actually love my O'Reilly task masters. It means that technical authors don't have to be a household name, they just have to be able to deliver a good book.

Every technical title published has a shelf-life measured in years if not months. So if you have a timely idea on a new technology publishers are eager to hear from you.

The story behind Programming F#

When I decided I was going to write a book on F#, I was extremely nervous. First of all, I had never written a book before and second I have never been particularly gifted with written word. Nevertheless, I put together a small proposal and emailed it to O'Reilly.

I was expecting a rejection with the intent on getting the ball rolling. Perhaps they would say I need to blog more to establish some writing chops. Or perhaps to take on a co-author who had some writing experience.

As it turns out I got a response the next day to the tune of:

"Hey Chris, this looks good. Why don't you change X, Y, and Z and I'll get this approved next week. Have a nice weekend."

That's it. As it turns out, O'Reilly was looking for someone to write a book on F# and I happened to fit the bill. Working on the F# team at Microsoft probably sweetened the deal. (Programming F# was actually the second F# book in the works at O'Reilly, the first one never got published; but I'll save that bit of F# lore for another day.)

So you have a publishing deal. Now what?

What Type of Technical Book

In college a room mate of mine purchased an 800-page book on XML. Do you think the subject of XML requires 800 pages of exposition? Well, the book's six authors did. Programming F# on the other hand, clocked in at around 380 pages.

One aspect of Programming F# that received the most criticism is an aspect I am the most proud of: it is short.

At the start of the project I set out to write a concise book about the F# programming language. Not the .NET runtime, and certainly not WPF application development using F#. I set out to write a book about the F# programming language and left the subjects of databases, UI development, and XML to other authors.

This brings us to the first and most important thing to consider when writing a technical book: the type of book you are going to write. A summary like "web programming in the YFL language" is not good enough. Will your book be a reference book, dense with fact and requiring lots of flipping through? Or will it be a tutorial, walking the reader through and end-to-end experience?

There certainly isn't a right or wrong type of technical book, but it is paramount to understand what the book is trying achieve before you write anything.
The Writing Process

Once you have the purpose of the book in mind, how do you actual go about and write it? I would suggest using the following organization.

Table of contents

Create a new document titled "Table of Contents" and in it put a billeted list with three levels of indentation. At the highest-level bullet are chapter headings. Below that are your H1 and H2 headings.

At this phase of the book you are super-excited and raring to just dive in and start writing. You must resist this urge as long as you can. The "Table of Contents" document is the master plan for your book and the only thing keeping it focused and coherent. (Opposed to a bunch of random anecdotes, facts, and examples.)

Once you have a clear picture of the entire book, down to the H2 section you then need to create a schedule to keep track of the state of the overall project.

Status sheet

Create a spread sheet titled "Status" and have a row for each chapter of the book, including the foreword, introduction, and possibly the index. The columns should be used to track the state of each chapter as you progress along from "outline" to "draft" to "tech review" and so on.

Whenever I moved a chapter of the book past a given phase, I would put an X in the cell which would then trigger conditional formatting to paint the cell green. This way I could see how far along the book was (and what needed the most attention) at a glance.

Q - Ch12 - Reflection

Finally, start writing the book. I recommend creating a document for each chapter of the book and naming the document with a letter to control sort ordering. (For example "A - Foreword", "B - Preface", "C - Ch01", and so on.)

This convention might seem like a strange optimization, but I assure you that the number of times you will need to quickly locate an arbitrary part of the book will be non-trivial. And having the sections of your book in the correct order will be invaluable.

The Writing Stages

Once you have the software setup to actually write the book, next comes the iteration. Depending on your book project there might be a different number of stages. Since I was a first-time author O'Reilly hired a developmental editor for the project, Brian MacDonald, who was awesome.

Outline

When you finish the outline you will think that the book is clearly organized and you will have a firm grasp of the material. You will also think that you did such a good job organizing the book that it will take less time than you thought it would. You are incorrect.

First draft

You will work on the book for months grinding away at each chapter. You will avoid parties, movies, and any other social outing because you will be busy working on the book.

The day you finish the first draft will be the first day since you started writing that you are actually proud of your work. You will think that the first draft is the best thing you have written in your life. And, hopefully, it actually is.

Second draft

After finishing the second draft you will realize just how terrible of a writer you are. You will also curse the Word grammar engine for missing that one, common error you make all the damn time. You will be proud you never showed the first draft to anyone.

Unfortunately, little of your first draft was salvageable, and the parts that were contained insultingly poor punctuation.

However, you will persevere and finish the second draft. You will have learned from your mistakes and shaped the book into something even better. At this point you almost want to mail the manuscript to your college English professor to show them how accomplished you are.

Post developmental editor

After seeing your development editor's corrections you would feel sorry for them if you didn't already feel so humiliated. You think that you don't need someone pointing out that sentences are supposed to have verbs. Or that "receive" isn't spelled like "recieve", but evidently you do.

The corrections will be so painfully obvious, so gloriously bad that you are shocked that you even wrote it that way in the first place. You will question whether you sent them an older version of the file, or perhaps some gremlin snuck into your computer and altered the files.

Either way, you know what you have to do so you just revise the text again. And this time when you are done it finally feels like a completed book. You print out all 200+ pages and go over every single page with a red pen, several times.

Now the book is done except for a technical review, where people will compliment you on your insightful examples and clear exposition.

Post tech review

You will contemplate purchasing a firearm. Perhaps several. And trying to track down the insulting bastards who chose to troll you while writing your own book.

"No, it doesn't work that way!" you will shout at your monitor while you read their feedback. Eager to prove your point, you will try some experiments. And sure enough, you will realize that you were wrong. In fact, more than wrong. The foundation of your entire understanding of computers will rendered invalid.

The pain of rephrasing large swaths of text won't sting nearly as much as the realization that you have been misspeaking about your favorite technology for perhaps years.

Final edit

After seasons of work you are finally done. You take a deep breath and finally relax. Knowing that your hard work has been completed. People will finally be able to read your hard work, and understand what you hare sacrificed for.

Amazon feedback

You will read your first review on Amazon.com, and want to react like this. Your readers will tell you that the they liked some other book better; or instead wish you had written a different book.

*Bonus* Second edition draft

When you get the offer to write the second edition you will feel uneasy. You will know just how much work went into the first edition, but feel assured knowing that you wrote a great book the first time.

While correcting known errata you will find grievous technical errors and sins against the English language hidden in the book's text. You will be shocked that no one has found these errors sooner, and terrified at the thought of how many more you will discover.

Even worse, your task isn't merely polishing existing text, but rather attempting to add updated content without breaking the existing flow/theme of the book. And, just like last time, you are writing about a subject matter that is constantly evolving and not even in beta stages...

Shipping

If you aren't somehow dissuaded by this blog post and succeed in surviving all of the stages of writing, you are now the proud copyright owner for a book. Configurations!

The thrill of seeing your own book on store shelves never gets old, and neither does meeting people who have read your book at developer conferences. There is one thing to watch out for though: book signings.

One thing you need to be prepared for is when people ask you to autograph their book. I know what you are thinking, "Sure, I'll just put my name, write a cute message, and it will be quick." I wish that were the case.

Instead, people with names you have never heard of, names which you have no hope of spelling correctly, will ask you to make it out to them every time. And that "cute message" will be impossible to come up with on the spot. Instead, you will just try to scribble their name just illegible enough that they can't verify you got it wrong and go with one of several catch phrases.

If I ever write another book I'm going to come up with a solution to this problem...

Anyways, go forth and write books about things you are passionate about! Don't say I didn't warn you that the process would be a pain in the ass, but it is worth it. I look forward to reading it.

On Google's 20% time

Recently I had a long conversation explaining the ins-and-outs of Google's 20% time, and I figured it would be appropriate to share it publicly.

TL;DR: 20% time is awesome and you should get your company to do it.

Caveat Emptor: The Google employee handbook defines the company's official policies concerning 20% time. This blog post is my own personal interpretation.

Back when I was interviewing, I was very suspicious about Google's 20% time. I've heard rumors about products like GMail coming from 20% time. Marissa Mayer even quipped that to half of Google's launches in 2005 came from 20% time efforts.

Seriously!?! If a company spends one-fifth of its time futzing around how can it get anything done? 

The truth is that while every Googler has the opportunity to take 20% time to work on whatever they wish, it isn't carte blanche to take Fridays off and play X-Box. Having a 20% project doesn't mean you are responsible for 80% of your job; more like you are volunteering to put in 120% the effort.

At Google performance is measured by impact: benefit to Google and its customers. If an engineer is able to have a big impact, then spending some cycles on a 20% project is no big deal. However, if someone was having difficultly meeting expectations as-is, then contributing to a 20% project would be a poor decision.

In short, the attitude at Google is: "We trust you to do what you think is important with your time."

20% Projects in Practice

Not everybody takes on a 20% project, but those that do usually fall into a few board categories:

"I have something interesting to do"

Some people use 20% projects to pursue their passions. For example, there are Googlers who teach classes at high schools and colleges. Some have desks, go to PTA/faculty meetings, the whole bit.

Other people spend time organizing projects such as GoogleServe or facilitating classes internally. (I, for example, am proctoring a course titled Having Difficult Conversations tomorrow to help Googlers, well, have difficult conversations.)

This has negligible impact as far as engineering efforts are concerned, so it's unlikely that teaching Introduction to Algorithms is going to get someone a promotion. But the people engaged in these types of projects are likely happier and likely more engaged in their work.

"We could use help" or "Team dating"

Other times, 20% projects are used to describe temporary within the company.

Imagine GMail and Google News and a hypothetical feature. The GMail guys have a great idea -- delivering a daily newspaper to your inbox. That way as soon as you log in you could see the highlights of the past 24 hours.

The Google News folks might be excited to add this feature, but are likely already working on other big projects for the quarter.

Rather than GMail simply waiting the weeks or months it takes for Google News to get to that feature, some GMail engineers might start working on Google News in a 20% capacity to add the changes necessary to support the daily digest scenario.

Of course large teams are more likely to work with one another, but the point is that if you have a good feature to contribute then just add it! 20% contributors are welcome to add features and address low-hanging fruit.

Also, volunteering to work for another team in a 20% capacity is a low-cost way of doing transfers. Rather than interviewing to change groups, an engineer can simply try working with them and see if its a good fit first.

"I have an itch to scratch"

Occasionally there are problems, sometimes endemic, that nobody has the time or authority to fix. The classic example is the origin of GMail. A lot of Googlers were unhappy with the email software and figured they could do better. Rather than waiting for a VP to staff a team and issue a mandate, a few engineers just banded together and started writing code.

A few years later GMail was released publicly and used by millions worldwide.

This is the basis for that "Half of Google's launches in 2005" reference. If you see a problem, 20% time gives you the freedom to be proactive and just solve it.

Personal Experiences with 20% Time

As nice as 20% time sounds, does it really work? Since I've been at Google, I've take advantage of 20% time on a few occasions. Here are my experiences; your mileage may vary.

Project A - Dating an engineering team

Shortly after I started I wasn't super-excited about the project I was working on, and was really intrigued by Project A. So I met with their tech lead and signed up to do deliver low-hanging fruit that quarter. (Bug fixes, a few independent features, etc.)

The next quarter, I transferred to the other project as my full time responsibility and stuck around on my old project as a 20% project as a transition / finish up remaining work.

Project B - Gathering hard data

About a year ago, a lot of people were talking about "creating a death star" and how easy it would be able to implement one using "lightsaber crystals". Such a project would be amazingly successful if we added killer features like a "trash compactor inhabited by a Dianoga".

Sick of informal meetings, cloud-talk, and brainstorming I started writing code. About two full weeks working full time on my prototype I had a demo. As it turns out "trash compactor inhabited by a Dianoga" wasn't as exciting as we hoped and this projects "hypermatter reactor core" was kind of a deal-breaker. So alas, Google's plans for "creating a death star" had to be scrapped.

The project didn't have any impact, so it didn't necessarily advance my career any. But the experienced enabled me to learn some new technologies and provide some concrete data points for future experiments.

Project C - Trying to seize an opportunity

When WebGL was checked into Chrome's experimental branch, I knew that a slick, 3D, social game on Google+ would be a hit. So I figured I had a few months to come up with a project and cause a big splash when WebGL was finally generally available.

I met with some friends and we started working on the project. We got pretty far on creating a 3D  engine, asset management, and so on. But unfortunately we weren't making progress fast enough. In the few months it took us to get a semi-playable demo there already were a glut of existing games ported to WebGL. (Example 1, example 2, example 3, etc.)

With our small window of opportunity gone -- and the crushing reality of how much of an investment modern games are -- we decided to kill the project.

But again, it was a great learning experience and now there is a game design and prototype there, perhaps only in need of a pivot to be revived! And, had this minor risk had panned out there could have been a huge upside to Google. (Specifically, thousands of man-hours wasted in pursuit of "points".)

So there you have it. In my experiences 20% time hasn't been about zoning out of work, but rather staying engaged and having the freedom to take advantage of opportunities. At Google there is a strong sense of trust between the company and its engineers, and 20% time really exemplifies that phenomenon.

What to do when you aren’t getting promoted

Edit: A reader on Google+ pointed out a pretty serious omission: this post makes no mention of your manager. AKA the person who is tracking whether or not you will actually get that promotion. I'll save my comments on "managing up" for a later post, but in short they play a pretty important role in this process as well.


For many people, it is nearing annual performance review time. A time when some lucky engineers get promotions -- along with fame and fortune -- while the rest of us are left to languish for another year, slaving away with more responsibilities and fewer perks.

Obviously the tech industry isn’t that cold and gray, but it can seem pretty disappointing when you are feeling ready for a promotion and don’t get it. This post is about the sorts of activities you can do in-between promotion cycles. Rather than, say, sulking.

But first I need to explain what a promotion actually signifies. Promotions are a recognition of the level of work you are already doing. The operative word in that previous sentence is already. With the exception of Texas politics, it makes no sense to promote someone into a role they can’t perform. Instead, people should earn the title of “senior” or “principal” when they have already demonstrated that they can successfully perform in that capacity. (This promotion-after-demonstration concept mitigates the impact of ineptitude due to the Peter Principle.)

You might be wondering then, “How can I perform a job if I don’t have the associated title? People won’t listen to me if I’m not an architect!” Let me spill the beans on another secret regarding promotions: a promotion does not give you any more authority than you already have; it may however add credibility. If nobody likes your ideas now, they still won’t like them if you have “senior”, “principal”, or even “partner” in your job title.

This revelation leads me to the first thing you should do when seeking a promotion: observe.

If you want to join the people higher up the corporate ladder than you, take a step back and observe them. What do they do well? What are their strengths? Why do people listen to them?

Occasionally you will find a bozo with a fancy title, but more often than not those people have skills and experiences you can learn from.

Even better, consider putting yourself in their shoes. What strengths do you have that you could be utilizing more? Are there weaknesses you should address?

If you aren’t sure what the steps are for reaching that next career stage, you should first gather data. Once you have an idea of the work required, go ahead and ask for help. The fancy business-school word for this is networking.

Networking does not mean hanging out in a smoke-filled bar with people  you don’t like. Having a good rapport with your coworkers is a form of networking. And taping into that network doesn’t mean asking them for money. It can be something as simple as asking to pair-program a tricky interface, or getting an early code review for something you are working on. Or even something as general as “What should I do when I’m not getting promoted?”

There is an immense value in knowing people outside your team, group, company, or even walk of life. You never know when having an extended network will come in handy. Perhaps your team needs to hire someone with a specific skill. Maybe you need to reach out for advice. Or perhaps you just have a crazy idea in need of a home.

Arguably a person’s personal network shouldn’t be linked to whether or not they get a promotion. But since a person’s effectiveness, influence, and impact is tied to their network the two are at the very least correlated.

But how do you go about building a network? As it turns out, people have already solved this problem for you, inviting others just like you to get together to share ideas and experiences. All you need to do is show up! A few quick Google searches can get you info about conferences, user groups, give camps, and startup weekends. All which serve as fantastic opportunities to network.

And not every conference requires spending several thousand dollars on travel and lodging. There are many local conferences and user groups. These are sometimes harder to find information about -- so it helps to network with developers in your local area.

Even better than going to a conference is presenting at one. Presenting is much easier than you think and is a great way to build expertise and credibility in a particular area.

This brings us to our third thing to do while you aren’t getting promoted: study.

Let me take a moment to give you the best tech career advice you will ever hear: don’t do the same thing for 20 years. No matter how good you are at your given technology and how much your employer loves you to just do the same thing every day: don’t. In other words, actually get 20-years experience; don’t get the first year’s worth of experience twenty times.

Beyond promotions, if you allow your raw skills to atrophy you are crippling your ability to find a new job and limiting your future opportunities. Constantly incorporating new ideas is a must.

So where do you go to learn new skills? First, you can start with the many other tech-related blogs out there. But in case you are looking for something meatier, let me first shamelessly plug my book.

If spending 30-minutes every night reading isn’t for you, consider starting a reading group with some coworkers. Pick a book (or a paper) and meet every week to discuss a chapter or two. It’s a great way to be accountable for the material as well as start the discussion about how to apply it to your office or work environment.

However, IMHO the best way to learn is to simply experiment. I’ve benefited immensely from Google’s 20% time. For example, I wrote a simple voxel editor in WebGL. I never got around to finishing my 3D game, but it was a great opportunity to learn the Google Closure and use JavaScript for more than DOM manipulation.

Remember, experimentation doesn’t have to be about what you are working on. Follow your passions!

Observing, network, and studying may sound a bit overwhelming. Fortunately my last piece of advice for you promotion seekers is to simply relax.

Sometimes the best way to grow is to step away from the keyboard and live your life. Perhaps the thing holding you back isn’t your work but rather just how people perceive you. Would you want to give that guy or girl who is chronically stressed out more responsibilities?

Your life isn’t actually what happens during the hours you are at a keyboard. And a promotion, no matter how big a raise it entails, won’t alter your life.

Anyways, hopefully you have some ideas to keep you busy for the next few months. If you do end up getting promoted next year because of this advice, feel free to donate part of your fame and/or fortune to me.

On the importance of other people’s hard work

NOTE: As I return from a long hiatus from blogging, please excuse the overly agressive tone of this post. I don't want to disparage any of the teams I worked with at Microsoft, just point out some opportunities we had for getting more done by doing less.

At the start of the Visual Studio 2008 product cycle I was working on the Indigo Tools team, tasked with adding WCF tooling to Visual Studio. On what would later be known as the “Add Service Reference” dialog, or this guy:

The hardest decision we had to make during the product cycle was the very first: how will we implement our feature? We had to choose between two very different approaches.

The first was to build a wrapper on top of the existing WCF tools, specifically svcutil.exe. Svcutil.exe did everything users would want from the Add Service Reference dialog and more. So all we would conceivably need to do is add some hooks to the tool and put a UI on top of it.

The second option was to start from scratch and duplicate the functionality of svcutil.exe. This would mean rewriting the guts of the tool, but make it much easier to integrate into Visual Studio.

After much debate we went with option B: coding our own thing from scratch. Ultimately we erred on the side of making it easier to integrate into Visual Studio.

As you can probably tell from the title of this post, in hindsight that was a mistake. Visual Studio doesn’t support nearly as many WCF service types as we would have liked, it generates poor code, and has a poor user experience to boot. (Click “Show All Files” in Solution Explorer and just see how much crap is added when adding a service reference.)

The problem was that we did exactly what Joel Spolsky claims is “the single worst strategic mistake that any software company can make”, and that is to decide to rewrite code from scratch. Instead of building off of an existing code base and refactoring it to suit our new needs, we instead chose to rewrite the stack from scratch.

Let me expound on the perceived pros and cons of using existing code (EC) or rewriting from scratch and using new code (NC).

The aversion to reusing hypothetical existing code or EC is that it never does quite does exactly what you want it to do. (Because, obviously, if it did you wouldn’t have a problem using it.) EC either doesn’t support the features you need, doesn’t implement them in the way you want, or perhaps is just formatted in a way you don’t like. Also, it would be naive to expect the documentation for EC to be complete, well written, and thorough.

In reality however, EC is actually perfectly fine. (Think about it -- someone used it for something, so it can’t be fundamentally flawed.) The real problem with EC has is that you didn’t write it, and therefore it seems too complicated to work with. But, more on EC later...

Suppose that you bought into the assumption that reusing / refactoring EC was a bad idea. So you instead introduce new code or NC. Hypothetical NC is a well-researched solution, engineered to solve your problem elegantly and efficiently.

Most likely you will start writing NC with lots of unit tests, but even so, eventually bugs will creep in. (Most likely from features NC must support which you didn’t envision.) You will fix these bugs, but leave TODO comments for the larger ones. And of course, since you are busy coding you don’t have any time for real documentation. So you scale back your vision for NC and the second it half-works you forget about NC and move onto the next problem. (Thereby abandoning NC and perpetuating the EC vs. NC struggle.)

NC always seems like a great idea at first, but it runs into the same problems as EC: writing clear code is hard. Documenting code is hard. Finishing code is hard.

My thesis is that reimplementing anything is a waste of time. That’s right, I used the totally bold and flame-bait word "anything".

If you work to improve existing code, then you and the code’s existing developers/users benefit. You fix some bugs, contribute some documentation, and leave the world better than you found it. The word here is synergy -- everybody wins.

But in the case that you try to go about things on your own, nobody wins. Even if NC has more bells and whistles than EC, the world is worse off. Why?

Because you’ve made an even bigger mess for the next guy. Previously the choice was just between reusing EC and writing NC. Now, they have to chose between EC, NC, and newer code (NC++?).

And, even if this EC, NC, and NC++ situation wasn’t bad enough think of the critical fixes that now need to be made to all the duplicate code in the world. Security updates, breaking library changes, compiler updates, and so on. By introducing new projects you increase the overall cost of housekeeping.

Let me break away from the hypothetical and talk about real examples. Look through these lists and think to yourself: does every one of these contribute something novel to the universe? Or would mankind be better off if the effort spent in creating that new thing had been spent improving the old one? http://en.wikipedia.org/wiki/Category:Open_source_content_management_systems

http://en.wikipedia.org/wiki/List_of_build_automation_software
http://en.wikipedia.org/wiki/List_of_text_editors
http://en.wikipedia.org/wiki/List_of_compiler-compilers



Especially for the text editors list. Is there anything you can’t do in Emacs? What else could you possibly want?

Despite what Richard Stallman and the hippies at the FSF tell you, I think the real benefit of FOSS comes form people not having to worry about solved problems.

Certainly licenses, politics, and egos may make it difficult to follow another developer’s lead and work on an existing project. But I urge you to think twice before writing any new code. Ask yourself, has this function already been written in the history of mankind? And if so, how can you take advantage of that and not write that function. Just go search for it!

Let me provide a specific example of the benefit of not rewriting code with another Microsoft war story. Fast forward three years from my WCF experience and I’m working on the F# team trying to ship Visual Studio 2010. We were a small and agile team with an immense amount of work to do. But due to Don Syme’s amazing leadership we were able to produce a great v1.0 product on time and with a few more features than we expected.

That is not a typeo. We actually able to ship more language features than we thought we would.

One such feature came in during a weekend Don Syme was in town. The team decided to spend a Saturday afternoon hacking away on the codebase, but rather than just fixing bugs we wanted to add something bigger and meatier. Of all the options we considered, we settled on a new language feature of dynamic support.

One of the big features the C# and VB.NET teams were adding to their compilers for Visual Studio 2010 was support for dynamic types.

It took a team of people -- dev and test -- working on adding this feature to the C# and VB compilers months, and yet we were able to add it to F# in an afternoon*.

How? By simply doing the easy part and reusing all of their hard work.

Implementing these dynamic types in F# required two pieces. First, syntax support for differentiating dynamic calls from regular ones. We did this in F# by adding the (?) and (?<-) operators. Second, you need a runtime binder to determine how dynamic calls get dispatched. (I.e. how to deal with method overloading, name resolution, and so on.)

Adding syntax support for two operators is quite easy, the bulk of the work for adding dynamic support would have been in implementing the F# runtime binder. However, the key observation is that we didn’t actually need to write a new runtime binder. There already was an excellent dynamic method binder for C# which worked just fine.

All users need to do is copy and paste this code (by Matt Podwysocki) and you are set. While the corner cases for name/method overloading for F# don’t exactly match up with C#, for 99% of cases you won’t notice.

That, in a nutshell is the importance of leveraging other people’s hard work.

It is easy to get distracted with ‘how’ to implement something, and forget it is ‘what’ you want to enable. It is important to leverage any and all pre-existing work. Not only do you have an opportunity to save time, but you also get to build up on the insights, innovations, and efforts of those before you. This sets you up for long term success, both in terms of maintenance.

putCharacter vs. putPixel and my new blog

A few years ago, and I regrettably don't even remember the context, Miguel de Icaza quipped that there were two types of programmers in the world: those who used putCharacter and those who used putPixel.

For the putCharacter programmers the end goal is productivity and getting the job done. putCharacter programmers don't care about the nuts and bolts of how it works, they just want it to work.

Contrast that with the other type of programmer. putPixel programmers don't care so much about productivity as they do understanding how the system works. If you have a good understanding of how to put and read pixel data to the console, putting characters is just a matter of abstraction. However, that understanding never comes cheap. What would have been one line of code, putCharacter('x'), now becomes a labyrinth of font destriptions, VGA adapter settings, and other low-level nuts and bolts that are hardly documented and seldom intuitive.

Right now you are probably thinking, "There is no way I'm a putCharacter programmer. I'm far too { smart | experienced | hip }." But you are probably wrong. Unless you are writing a compiler, operating system, or database you are probably using putCharacter. I would even go so far to say that if you are using C# then you definitely are a putCharacter programmer.

Think about C#/VB.NET's Edit-and-Continue feature. You can write/edit program code while it is running under a debugger. Features like that don't exist for people who measure twice and cut once.

But this post isn't about ragging on putCharacter programmers. I'll admit that I too was a putCharacter programmer, and loved it. In college while my friends were always working on labs until the wee hours of the morning, while I could get by with devoting only an hour at most. My peers were struggling with learning Linux, Emacs, and command-line debugging with GDB. I was doing everything in Visual Studio. I had a IntelliSense, I had a graphical debugger, I had... no need to learn anything.

The problem with the putCharacter mentality is that it forces you to be dependent on someone else for their tools or libraries. This, in my opinion is the danger of using the Microsoft stack. If you never look beyond putCharacter then you are immediately limited by the functionality it provides. What if you need to print in color? Or a unicode character? If the putCharacter system you are using is missing a feature and you aren't willing to resort to putPixel, then you are probably screwed.

Anyways, the real intent of this post was to announce that my blog has moved (yet again) to a permanent home:

http://blog.aChrisSmith.com/

In my own effort to become less of a putCharacter programmer I've started working on a blogging package of my own. (Called GAEB.) To address your first two concerns:

• Yes, it is missing (important) features
• Yes, it has (horrible) bugs

But I'm not writing GAEB because I actually care about the blogging software. It's more like learning how to putPixel on my own terms.

30-day challenge for October decided

Quick update on the 30-day challenge front. The votes are in and "meditate 10-15 minutes a day" won by a strong margin. So far, so good. I'll keep you posted with any insights I can gain from my inner-self later this month.