How I found it
I found about Dreaming in Code by Scott Rosenberg in a Reddit comment while looking for software development books and I was stoked! I thought then that it was about the makings of a calendar app, and even if it failed, it excited me as a developer who’s also a serial planner. I mean, look at my sched!
The company I work for has a delightful book allowance, so I bought this book along with Structure and Interpretation of Computer Programs. I was very giddy waiting for it to arrive!
How Dreaming in Code was
I admit, it was not as I expected, and it had been a very frustrating read. I’m now more than halfway past the book, and page 173 (out of about 400) drove me to write about it.
Well first, it’s not a calendar app, it’s a personal information management system. Which is… GREAT! I’m not really looking to build a calendar, but more of something like a journal. So PIM! I actually drew some really rough mocks and requirements yesterday, and I acknowledge reading about Chandler gave me some drive to actually get started. I even named it Monica! Yes, I know, Chandler isn’t named from FRIENDS Chandler, but he’s who Chandler reminds me of, and Monica is the stickler type of person that would probably appreciate my app.
Now why was I frustrated?
As my partner noticed, I’m not one for set ups. I found the set up (initial chapters of the book) halting and jumping around too much. I wanted to get started on the app itself, not much on history! But looking back at those chapters, they were actually nice-to-have context. It’s like being ushered in to the software development world and meeting its culture. So this one’s on me.
I’m not going to pretend to know any better than these veteran software developers. I DON’T. I’m green, especially to software development. I don’t even have an IT-related degree! But I’m one with the author here. It’s at this exact page that I was despairing and thinking “WHEN ARE THEY EVER GOING TO GET STARTED?!”
It felt like a lot of meetings and going-arounds without deciding or committing to those decisions. But then I am reminded that even I face the same in the small features that I have ever worked on. A lot of planning and researching, trying out one approach, getting a dead end, trying another, gets another dead end, going back and forth between approaches, then realizing my first one was better all along. AAAAAAAAAAAAAAAAAAAAA. And that was just a small feature, not even as important as architectural decisions. These people were changing how we treat information. It’s ground-breaking. And maybe the foundation they were trying to build would prove its worth of the time they’re giving it?
How has it been since
I’ve just finished page 235, Chapter 8: Stickies on a Whiteboard. I’m happy to report that they’ve made much headway since page 173. They’ve finally had a demo day, thank goodness. They’ve shed a lot of features for a while to focus on delivering a working software. I think that’s a good decision.
By page 173, kudos to the author for picking that moment, it seems like they have overcome the project’s activation energy, so it’s been less frustrating for me personally (*laughs*). I’m finally getting insights on their decisions for the app. Chandler already looks like SOMETHING, and I’m getting inspiration! It’s also nice knowing the people who worked on it and their frustrations. My personal favorites are Andy Hertzfeld and Andi Vajda.
On another note, I’m happy this book drove me to write about it because this blog has been sitting on just one post up til now. Hehe.
