I wrote this post for the Communitech blog. It’s cross-posted here.
Say you’re about to start designing a software product. You’ve got a few ideas and a blank whiteboard. You’ve gathered together people who understand the problem you’re trying to solve and the people who will value the solution.
You could brainstorm a bunch of features and start building them, but how do you know which features will actually be used and which will end up buried in some menu, untouched?
To avoid that, you need to get your product into the hands of users in order to get feedback (and revenue) as soon as possible. “Product Sashimi” is the term coined by JB Rainsberger for a set of techniques that help you thinly slice your product to deliver the simplest thing that could possibly work. Delivering a simple product early means you can find out directly from your users what additional features they would find valuable so you don’t have to build the ones they won’t.
Ten years ago today, I posted my first blog post.
Okay, technically, that was on my old, hand-coded blog, and I’m lame even after almost 4 years, I haven’t imported my old blog into this one, but woo! 10 years!
Equally technically, I was posting something like blog posts on my old homepage, starting around 1998 or so. They weren’t archived or anything, I’d just insert a couple paragraphs between <hr> tags on whatever I happened to feel like writing about at the time, replacing whatever was there before. No, not a blog, but my blog was an extension of that.
My ideas about blogging have changed quite a bit. I originally wanted a place I could write anonymously about whatever I felt like. Then I decided that blogging anonymously was horribly pretentious and nobody actually cared. Now I’ve got Twitter satiating most of what used to drive me to blog. That’s my current excuse for why I don’t hang out here quite as much, anyway.
Ten years. That’s a long time.
Neil Gaiman beat me by a week.
When I started at my current employer (about 18 months ago), I got it in my head I should take advantage of their training budget and proximity to uWaterloo (like the kids are calling it now) and take a course.
For one reason or another (sanity, mostly; also scheduling), I wasn’t able to take the compilers course in my 4th year. Compilers is one of the big project courses. In terms of workload, it’s well behind real time (the train course) and graphics, but it’s still nothing to sneeze at.
When I was an undergrad, I think I would have probably preferred to take graphics. But as you get older, you mature. Or something. Yeah, graphics is cool and fun, but I think it would be a harder sell to get my employer to pay for it. Particularly when your employer has its own proprietary language to maintain.
For my part, I want to encourage people to make their own languages, because doing it makes you a world-class programmer. Seriously. Not just a better programmer, but a best programmer. I’ve said it before, and I’m sticking with it: having a deep understanding of compilers is what separates the wheat from the chaff. I say that without having the slightest frigging clue what “chaff” is, but let’s assume it’s some sort of inferior wheat substitute, possibly made from tofu. –Steve Yegge, The Next Big Language.
I don’t know if I’ll actually make my own language, or move to the compiler team at work, but I do know that understanding this stuff is really, really useful and fundamental to software development. There’s a lot of computer science-y stuff that’s not especially useful, but compilers are everywhere.