Practice
This December, I will have been practicing programming seriously for ten years.
That will mark the tenth anniversary of me starting to learn Perl. I have been programming ever since: websites, scripts, tools, projects, assignments, apps. I've written web templating systems and mailing lists. I've written data-converting tools and room-planning tools. I've written utility functions and testbed systems. I've written hundreds of unit tests, thousands of tags. I've designed, written, tested, tweaked, and marketed five iPhone applications. I've probably written a hundred thousand lines of code. Maybe a lot more; web pages can be pretty verbose.
And lately I've been feeling ready.
Ready to stop doing this for entertainment, for education, for practice. Ready to do it for real. To work on products, not projects.
I've already started doing this with my apps (or at least some of them-Meticulous is more project than product). And I'm finding that products are more satisfying than projects are. That last five percent-the spit and polish, the usability testing and attention to detail-makes you ache, but having done it you're infinitely more satisfied with the result.
And so for my final year project at university, I asked to do a lovely product: a location-based shared note-taking system. Something I thought would be interesting and challenging, but very doable, and likely not commercially viable (so I wouldn't want to do it with my Architechies time).
I thought I had this plan approved, but my partner and I messed up and never got things formalized, and we had to shop it around to other professors. (Or rather, he and the other guys we've recruited had to do it while I was convalescing.)
And the word was this: it's too small. It doesn't have the scope to be a year-long project.
I think the professors misunderstood what we (or at least I) were trying to do, though. I don't think they understood that we wanted to write a product. That the goal wasn't to turn in something that barely met the specific parameters laid out at the beginning of the project; it was to produce something robust and complete and right that fit those parameters.
So we're doing a different project instead, one off their list of suggestions, so we know who will want to supervise it. I'm upset, not just because I've been looking forward to doing this for months, but also because of what I'll be doing instead. It's basically a clone of Dropbox, a file synchronization service.
I feel like I could write it in a month of weekends: one to get my brain wrapped around FSEvents and the equivalent folder-monitoring tools on various OSes; one to write a tool that figures out which side has changed files and update the other side; one to make server-side change signaling efficient (instead of polling); and one to make transfers efficient (differential) through the application of something like the rsync protocol. There you go, Dropbox. No creativity required.
It's a project, not a product. And when I'm done, it'll belong to the university, so there's no point treating it like a product.
It makes me want to drop out right now, fly home, and spend the rest of my life avoiding having a boss who can veto my product ideas.
Oh well. I guess I just have to get through the damn year.
I just wanted it to be better than this.
(P.S. I'm screening comments because my parents are likely to see this post. Don't worry, I'm still reading them.)
That will mark the tenth anniversary of me starting to learn Perl. I have been programming ever since: websites, scripts, tools, projects, assignments, apps. I've written web templating systems and mailing lists. I've written data-converting tools and room-planning tools. I've written utility functions and testbed systems. I've written hundreds of unit tests, thousands of tags. I've designed, written, tested, tweaked, and marketed five iPhone applications. I've probably written a hundred thousand lines of code. Maybe a lot more; web pages can be pretty verbose.
And lately I've been feeling ready.
Ready to stop doing this for entertainment, for education, for practice. Ready to do it for real. To work on products, not projects.
I've already started doing this with my apps (or at least some of them-Meticulous is more project than product). And I'm finding that products are more satisfying than projects are. That last five percent-the spit and polish, the usability testing and attention to detail-makes you ache, but having done it you're infinitely more satisfied with the result.
And so for my final year project at university, I asked to do a lovely product: a location-based shared note-taking system. Something I thought would be interesting and challenging, but very doable, and likely not commercially viable (so I wouldn't want to do it with my Architechies time).
I thought I had this plan approved, but my partner and I messed up and never got things formalized, and we had to shop it around to other professors. (Or rather, he and the other guys we've recruited had to do it while I was convalescing.)
And the word was this: it's too small. It doesn't have the scope to be a year-long project.
I think the professors misunderstood what we (or at least I) were trying to do, though. I don't think they understood that we wanted to write a product. That the goal wasn't to turn in something that barely met the specific parameters laid out at the beginning of the project; it was to produce something robust and complete and right that fit those parameters.
So we're doing a different project instead, one off their list of suggestions, so we know who will want to supervise it. I'm upset, not just because I've been looking forward to doing this for months, but also because of what I'll be doing instead. It's basically a clone of Dropbox, a file synchronization service.
I feel like I could write it in a month of weekends: one to get my brain wrapped around FSEvents and the equivalent folder-monitoring tools on various OSes; one to write a tool that figures out which side has changed files and update the other side; one to make server-side change signaling efficient (instead of polling); and one to make transfers efficient (differential) through the application of something like the rsync protocol. There you go, Dropbox. No creativity required.
It's a project, not a product. And when I'm done, it'll belong to the university, so there's no point treating it like a product.
It makes me want to drop out right now, fly home, and spend the rest of my life avoiding having a boss who can veto my product ideas.
Oh well. I guess I just have to get through the damn year.
I just wanted it to be better than this.
(P.S. I'm screening comments because my parents are likely to see this post. Don't worry, I'm still reading them.)