Tuesday, December 24, 2013
When you're working for yourself, you don't really consider taking time off. You pretty much just work until you can't or get sick or something and then work doesn't happen anymore. I know it's because I'm new to this whole assigning myself tasks thing, but I still seem to be having a hard time with it. When I can just sit down and do as much work as I want, anytime I want, I seem to have a hard time slowing down to some sort of healthy, maintainable pace. I start to notice this when I'm not really getting as many things done or can't think of things to do, but I usually just try harder making things worse. In the future I'm going to need some sort of way to get things done and stay healthy (side note: I'm not actually unhealthy, just not very productive).
Friday, December 20, 2013
I used my useful coding project to test out a new GUI platform and things went better than I had expected. I'd been looking at this platform for a while and finally found a solid use for the technology that was awkward at best before. In addition to this new feature, there were several aspects that were automated and all of the corners were nicely rounded like graphics of the future. They also have a very sleek size and color scheme. I liked the overall presentation so much that I'm considered upgrading some of my other projects to have the nicely rounded corners. The only problem that I can see with this is doing things too quickly and making a big mess, or getting a bit too futuristic too fast. Don't ask me why exactly, but it seems like something I'll want to gradually do.
Friday, December 13, 2013
How much time exactly should I be spending on something that might not be a fully-realized project? Today is pretty much the second day that I've been working on a GUI to help me organize some of the data that I've been collecting in order to help me stay organized and be more efficient. So far, it's not really going to be a big let-down if I never use the code for anything because I haven't really spent much time on it. But the further I get with the project, the more I seem to like it, so I kind of want to spend more time on it. At the moment I don't have any important issues or projects that are going to be more marketable, so there aren't really many negatives to continuing my work.
Tuesday, December 10, 2013
I'm realizing how important it is to stay current with all of my documentation and paperwork. When you do a lot of work and don't keep all the proper documentation up-to-date, it can be an overwhelming task to try and sort through all the things that have been going on, remember small parts of large projects, and what was important vs. what was just some random thought or some reach goal. The better you get with keeping track of all the paperwork, the more you are going to know where you are in all of your projects so you can get actual work accomplished. At this point it isn't really a choice, I have to update my paperwork to a point where I can efficiently make meaningful changes without feeling like I have to read several novels to insert one line of code. Making changes while you are thinking about them is not nearly as difficult as making changes to things you haven't been thinking about.
Thursday, December 5, 2013
I think that as a rare follow-up to my last post, I would like to mention some of the key factors for writing a good technical spec document. Obviously if it's a format document, that's going to be pretty easy, the format and any information explaining what it means. For other documents that do things like highlight features, I want to keep in mind my intended audience. I'm either leaving notes for an engineer so that they will know the intended purpose of the project (and possible explain a few not so obvious features), or I'm trying to explain something to the marketing division that might not ever actually see any of the code in the product. Either way, I'm not trying to go into any sort of depth about the features that I'm talking about. I want to give someone a very brief overview of what's going on, but not really any of the how-to that would explain some of the more private aspects of a product.
Monday, December 2, 2013
Since I've been struggling quite a bit to stay motivated and find things to do, I decided to work on some of the easier tasks that I've been neglecting. I managed to do some flowcharting and write up some very short technical highlight specs. I think that the key to a good flowchart is that it should be fairly easy to write. I know that I could have a flowchart documenting almost every part of code that I write, but that's not really practical in a business environment. I also don't want to give out more information than my engineers will need to comprehend what they're working on, but just enough so that they will be able to quickly start working on any given project. I've even found that some projects really shouldn't have flowcharts at all since the code itself should be well written to understand what it is that you're seeing. This would be for projects with only a few connected parts or not that many features.