Editorial: On Choosing and Shelving Projects
Published by KermMartian
11 years ago (2013-04-24T06:22:35+00:00)
| Discuss this article
Members' projects are the lifeblood of a community like Cemetech. It generates buzz and brings in plenty of new one-time visitors when TI, Casio, or HP release a new product or piece of software, but for all the months and years in between, our members' projects sustain site activity and interest. Sure, we teach people programming for calculators and computers, but users are much more passionate about their own projects than answering questions, in the end. And in a community where the majority of members are motivated, intelligent, and creative, there are bound to be far more project ideas than hours in the day. I for one have a list of potential projects that grows by the month, and an uncomfortably long list of unfinished projects. While considering cancelling one ongoing project and taking up another, I collected a few thoughts I wanted to share on general skills for choosing your projects wisely, something I fear is sometimes ignored in the calculator-programming community.
One of the biggest problems I've noticed over my twelve or fourteen years as active member in the community is programmers picking projects that are either beyond their abilities or too large to keep them engaged. My experiences with users starting projects poorly-suited to their skills and attention span can be exemplified in two anecdotes, of course with names omitted out of respect. In the first instance, a member discussed a new z80 ASM operating system he wished to write, setting forth many of the features he wanted to include. I and others cautioned him to start small, and upon learning he was unfamiliar with z80 ASM fundamentals like bit math, recommended he start with a smaller project to cement his abilities and build up to the effort, time, and skills required to write a complete OS from scratch. Unfortunately, that suggestion was received as an attack rather than a friendly suggestion, and the project remains unfinished to this day.
A heartening counterexample can be found in another user in a similar situation, who set out to make an ambitious game. I and other users cautioned him to start smaller, and figuring that we had benevolent reasons for our recommendations, he took the advice. Months later, he completed a few smaller projects, then was able to breeze through the larger project; at the end, he looked back and agreed that he hadn't been ready for the larger project. He admitted he likely would have gotten frustrated and quit in the middle. And therein lies the problem: projects need to be grandiose enough to hold the programmer's interest (not to mention potential users' interest during the development process), but not be so elaborate that they're never finished.
And indeed, when so many fun projects cross your mind that you end up with growing lists of future and in-progress projects, it's equally vital to know when to pursue and finally complete one project, and when a project just isn't worth your time anymore. The latter category covers my Sandpaper FTP client for CALCnet and potentially Tetric B for the TI-84 Plus C Silver Edition. In both cases, I came to the realization that continuing to sink effort into the project would be a waste of my time. In the case of Sandpaper, I completed enough of the program to make it a neat proof of concept (browsing the ticalc.org archives from your calculator and transferring programs between calculators over the internet works), but I recognized that in the age of ubiquitous smartphones and laptops, it will never be more than a novelty. Perhaps a decade ago it might have been genuinely useful, but taking the time to support all the other file types and complete the Python code to download files from Cemetech and ticalc.org would be wasted effort.
The project I'm considering permanently shelving, Tetric B, falls in a subtly different category. While it works as it should and could be completed in another 5 or 10 hours of TI-BASIC coding, I don't feel that it represents a truly fun game, and would be too slow when finished. Whether it would be frustrating to users and lead them to think of me as a poor coder, or be disappointed with the TI-84+CSE as a whole, I feel I would be doing users a disservice to release it in its current form. I could spend more time trimming, optimizing, combing over the source code, but is that really a good use of my time when I could instead attempt an ASM version?
The overarching message is that there's no panacea, nor even a clear problem. Programming, building, and hacking are fun and wholesome activities, sure to help you think logically and get further in life. However, those annoying administrative details can't be ignored to keep you (and the community) happy. You must be mindful of starting and never finishing projects, probably because you picked projects you don't have the ability, focus, or time to finish. At the same time, you shouldn't hesitate to attempt something you're not positive you can do, keeping in mind that you can always drop it later and aren't contractually bound to finish the undertaking. What experiences have you had watching yourself and others start, stop, drop, and finish projects? I look forward to hearing reinforcement and counterpoint on my experiences in the calculator coding community.
Permalink
Members' projects are the lifeblood of a community like Cemetech. It generates buzz and brings in plenty of new one-time visitors when TI, Casio, or HP release a new product or piece of software, but for all the months and years in between, our members' projects sustain site activity and interest. Sure, we teach people programming for calculators and computers, but users are much more passionate about their own projects than answering questions, in the end. And in a community where the majority of members are motivated, intelligent, and creative, there are bound to be far more project ideas than hours in the day. I for one have a list of potential projects that grows by the month, and an uncomfortably long list of unfinished projects. While considering cancelling one ongoing project and taking up another, I collected a few thoughts I wanted to share on general skills for choosing your projects wisely, something I fear is sometimes ignored in the calculator-programming community.
One of the biggest problems I've noticed over my twelve or fourteen years as active member in the community is programmers picking projects that are either beyond their abilities or too large to keep them engaged. My experiences with users starting projects poorly-suited to their skills and attention span can be exemplified in two anecdotes, of course with names omitted out of respect. In the first instance, a member discussed a new z80 ASM operating system he wished to write, setting forth many of the features he wanted to include. I and others cautioned him to start small, and upon learning he was unfamiliar with z80 ASM fundamentals like bit math, recommended he start with a smaller project to cement his abilities and build up to the effort, time, and skills required to write a complete OS from scratch. Unfortunately, that suggestion was received as an attack rather than a friendly suggestion, and the project remains unfinished to this day.
A heartening counterexample can be found in another user in a similar situation, who set out to make an ambitious game. I and other users cautioned him to start smaller, and figuring that we had benevolent reasons for our recommendations, he took the advice. Months later, he completed a few smaller projects, then was able to breeze through the larger project; at the end, he looked back and agreed that he hadn't been ready for the larger project. He admitted he likely would have gotten frustrated and quit in the middle. And therein lies the problem: projects need to be grandiose enough to hold the programmer's interest (not to mention potential users' interest during the development process), but not be so elaborate that they're never finished.
And indeed, when so many fun projects cross your mind that you end up with growing lists of future and in-progress projects, it's equally vital to know when to pursue and finally complete one project, and when a project just isn't worth your time anymore. The latter category covers my Sandpaper FTP client for CALCnet and potentially Tetric B for the TI-84 Plus C Silver Edition. In both cases, I came to the realization that continuing to sink effort into the project would be a waste of my time. In the case of Sandpaper, I completed enough of the program to make it a neat proof of concept (browsing the ticalc.org archives from your calculator and transferring programs between calculators over the internet works), but I recognized that in the age of ubiquitous smartphones and laptops, it will never be more than a novelty. Perhaps a decade ago it might have been genuinely useful, but taking the time to support all the other file types and complete the Python code to download files from Cemetech and ticalc.org would be wasted effort.
The project I'm considering permanently shelving, Tetric B, falls in a subtly different category. While it works as it should and could be completed in another 5 or 10 hours of TI-BASIC coding, I don't feel that it represents a truly fun game, and would be too slow when finished. Whether it would be frustrating to users and lead them to think of me as a poor coder, or be disappointed with the TI-84+CSE as a whole, I feel I would be doing users a disservice to release it in its current form. I could spend more time trimming, optimizing, combing over the source code, but is that really a good use of my time when I could instead attempt an ASM version?
The overarching message is that there's no panacea, nor even a clear problem. Programming, building, and hacking are fun and wholesome activities, sure to help you think logically and get further in life. However, those annoying administrative details can't be ignored to keep you (and the community) happy. You must be mindful of starting and never finishing projects, probably because you picked projects you don't have the ability, focus, or time to finish. At the same time, you shouldn't hesitate to attempt something you're not positive you can do, keeping in mind that you can always drop it later and aren't contractually bound to finish the undertaking. What experiences have you had watching yourself and others start, stop, drop, and finish projects? I look forward to hearing reinforcement and counterpoint on my experiences in the calculator coding community.
Permalink
Advertisement