I discussed my personal project a few times recently involving playing with a programming project and taking a break from it. Much like writing a story, stepping away from a project for a period of time can help someone gain a little perspective.
My own project, without getting into too many details since it's still embarrassingly amateur, is at a point where it seems to work "well enough" that it could serve as a simple demo. In the process of getting to this point I've made a few observations.
One, if you lack a good spec that maps specifically what features you want and how to use the application, you'll probably end up with cruft that does little more than takes up space. I made a pass at the source code to clear up some test calls and experimental stuff I threw in. One function was called once, and it carried a "test" notation. The function itself described what the function did but not why I put it in there. I think I at one time had an idea for the program to do something that this function would help with later, but at a point after the application took shape the scope of my project kind of changed.
Two, it's probably a good thing to periodically go through and clean up extra crap from the code. It's a lot less to search through and trace when something goes wrong or wonky.
Three, just because it compiles and seems to work doesn't mean the impostor syndrome will fade. I suppose that by acknowledging there's a possibility I am working under the shade of the impostor syndrome umbrella I'm not actually experiencing it, but that's a rabbit hole I don't feel like pursuing here. Lacking experience in the field contributes to the feeling of frustration and inadequacy; I don't know if a problem I run into is similar to something my colleagues would run into or if it's a rookie mistake. In one example I was running a rough bit of approximation math to figure out if a couple of controls overlapped, then felt hugely stupid for not thinking sooner that there would be a method built into the libraries for detecting the collision of the controls.
Google told me there was a collision detection method. I experimented a bit, but it seemed that it didn't work properly, or at least not in the way I expected. Narrowed down Googling suggested that these particular controls don't do collision detection; the proposed solution was the math route I was first pursuing.
Four, keep track of your development work, for a reminder if nothing else. Maybe more experienced developers don't need to bother doing this, but I find a personal journal to be handy sometimes. Nothing too elaborate. I just go back to remind myself of what I've done and how long it's taken to do it. Days blur together over time...the list of what I've managed to do in my sessions helps jog my memory and keep me from thinking I've accomplished nothing.
Five, keep track of your issues and goals. I was keeping paper notes before, but now I've opened a Trello board to create notes. Think of a feature to add? Create a card for it. Find a weird behavior? Create a card for it. I simply created lists to classify the issues...features, quirks, etc...and then shuffle the cards around as tasks are completed.
Trello is a list of lists, not really meant for user as a bug or feature tracker. But for my needs keeping track of issues as a series of handy lists is adequate. Maybe professionals have a better way of achieving these type of tasks, but I'm not working on a team nor working on a giant project. Do other programmers or teams use Trello for tracking software projects, or particular aspects of software development?
Six, there's more than one way to achieve a goal, but figuring the "right" way takes experience. At least, I think it does. I've read conflicting accounts of the "right" way to design the logic flow of a program; what should go into a function? How big should functions be? What should go into a separate file? Are there certain practices that work for a single- or small-team program that others would cringe if they saw it?
I recently read of an analysis of firmware used in an embedded controller that apparently ignores most of what would be considered "best practices," yet was...is...in use in a number of cars on the road. Presumably this code was written by people who are experienced programmers.
I've also read more than one case of coders eviscerating other coders work as inept or incompetent.
Is there a set formula or best practice for doing this? Or is it a learning through experience thing? Or in the end, does it just not matter as long as it all compiles and runs as intended?
Seven, programming can be difficult, and there's a learning curve to even using the tools that makes this more difficult. A very long time ago I created elementary programs by typing line by line into the memory of a Commodore 128, TRS-80 or Apple II. Later on I typed lines into a text editor, creating a single document from which an application would run (or compile, depending on the language.)
Even later on I could create a large text file that contained most of what I needed to compile into an application. Certain libraries or adjunct modules could be created in extra text files and compiled in with includes.
Today's version of Visual Studio is simply overwhelming to the uninitiated. More confusing is the fact that you don't even need to touch three quarters of the features and still create a working elementary program.
Discoverability is remarkably difficult, despite great features like Intellisense to auto-complete what I'm typing, I was unsure how best to figure out if these particular controls were overlapping; there's a method that seemed that it should work, but it doesn't. Despite an integrated environment that looks like it was ripped from a futuristic movie, I am still scouring the Internet for example code to figure out how to do what I'm looking to do.
Some parts of the code seem to work as if by magic; it's most likely a deficiency in experience, but sometimes tracing what is happening at what point in the execution of the application is difficult, despite everything in the IDE meant to help with debugging and tracing the execution path.
That's what I miss from using simpler tools and text editors. There seemed to be less magic involved in debugging as well as understanding how and why things worked in the process; I know that if I were involved day in and day out with Visual Studio things would make more sense, but as someone using it sporadically, it's still amazingly complex. I liken it to being able to make a car start, go, and stop, but having no idea how to use the A/C, stereo or even the cup holders.
Once I can finish the personal project, I'm moving into playing with Rails. Ah...a text editor to create a usable application? Let's see if that suits me better.
Eight, your small project is not immune to feature creep. This may be related to not having a complete spec created beforehand, but as my own project evolved, I find myself not wanting to show it until it has all the side features implemented. Most of them would probably not even be visible to the end user, unless something goes wrong.
It could be argued that some of the items I'm looking to implement aren't really features, but rather bug fixes. "This works well enough, unless the network doesn't exist...it needs to check and throw an error to the user if that's the case" is a little different from adding a way for the user to control what color a font is. In this context I simply have added conditions to check for before being willing to release this as a 1.0 version for the scrutiny of others.
Nine, I'll never be comfortable showing my work. Anyone can come up with excuses for why something sucks. Working around people who are very good at something, and not working in a learning or apprenticeship capacity, makes the prospect of showing something to others quite intimidating. Primarily because I have no illusion that this is great work.
Then again, knowing that this could be ripped apart with questions of, "Why on Earth did you do this?" and, "How did this compile?" as a feared inevitability also implies that there's nothing really to lose, other than ego, in facing the feared inevitable. I'm not a programmer by trade, so it's not a direct insult to my competency. It's also not something I'm paid to do, and the act of creating this means an opportunity for constructive feedback from which to learn, if someone is willing to take the time to explain why something should have been done a different way.
These are the latest rounds of observation for my little project. I don't have a release date yet; my goal is to keep inching towards completion, which I am. Progress is progress, even if it's just in hour-chunks each week...
No comments:
Post a Comment