Sunday, August 7, 2016
Naming files is not just something that is relevant for code. I first discovered that I might have a problem when I was uploading screen shots to the web. Since I had only taken one or two screenshots for each application's respective promotional page, I had named all of the image files either "screenshot" or "display". After uploading all of the images to the service I'm using, I noticed that having all the files named the same thing could be an issue. This isn't an issue when you preserve the directory structure which labels the application at the root. I think that with a program I can think of everything as one piece of work, but my documentation, flowcharts, and other files might need to be a little more portable. If I were to display code for any reason, I might even have to make further changes, but working with my business-related documents is enough work for now. I'm not sure what process or procedure this falls under, but having a large amount of files with the exact same name on the same computer can't be a good thing. I'll have to decide how much work this is going to be, but I've already started the process of adding product IDs to some of my generic filenames.
Thursday, July 7, 2016
I think that I am approaching the conclusion of my summary documents for the moment. I still have a fair amount of work left to do and some of it covers some pretty complex topics. The majority of what I have remaining is going to be fairly redundant technically and would be a very interesting task for a volunteer, intern, or even someone that has just started working for me. I know this is a long ways away, so it's something that I will probably finish myself eventually. Right now, I think that my time would best to be spent working on other tasks. I have a good amount of my products fully documented and almost everything is at least outlined (I decided that I'd write outlines as a sort of table of contents). So far, the documentation has given my company a lot of depth that I feel very good about. As a pleasant side-effect, I have also generated some interesting art work and todo items. I think that I still might need one more layer of documentation that goes even further into detail, but I haven't decided what that's going to be yet.
Friday, March 4, 2016
Even more exciting news for my promotional area. I have added an area for whitepapers. So far I don't really have enough content to brag about, but I think that the idea is important enough to mention at this early of a stage. I was reading an article online about how white papers create important for a company so they can be taken seriously in their field. I thought that was worth trying. I generated a list of possible topics that I could write white papers on and have had some pretty interesting results so far for my topic board. The list is supposed to be things that my company is currently doing that could be considered to be new or at least not overly documented so far. This excludes all of my engineering work so far (which would be called a patent anyway), so I'm focusing mostly on business and marketing topics as they relate to my engineering work. My first white paper was titled, "Blog Marketing" and as you might imagine it is about this blog. I haven't put much time into reviewing it yet or gotten a peer to review it, so I have it in my drafts folder. I'm hoping that eventually I'll be productive enough to have stages of drafts and final versions. I know I won't need a lot of white papers to be taken seriously at first, but having a process in place is helping me to mentally prepare myself.
Saturday, January 30, 2016
As an unexpected yet interesting side-effect of my new venture into summary documentation, I have created a companion area for my promotional materials. I now have business documents that go along with my promotional web sites. I see these documents as sort of a mix between a technical justification for my product existing and an actual marketing guide that would convey strategy information. Much like my summaries, I am trying to break the section up into several parts so that each area of the product will be covered. For example, for a game I could have documents that would explain what I would want the advertising strategy to look like, what I think the pricing and customer experience might look like, and then any miscellaneous notes about things like product sales direction, possible customer programs, or any other notes I might want to mention that would help to sell the product. Obviously, there is going to be some overlap with these documents, but I think that might be necessary to reinforce the important ideas and to help create a process for going to this area to further understand differences.
Sunday, December 20, 2015
I added a marketing overview document to my collection of company business guides. Keeping with my usual format, it is largely a series of bullet-points that form a sort of template for things that a marketing department can expect out of my company. I think that this approach is easier for me to view later when I'm trying to make decisions or decide where I should be going. My marketing overview is a big step away from guides in the strategy area about actions I should be specifically taking. This is more of a resource overview and how the materials that I have created are going to help guide the companies progress, and possibly change if I am fortunate to see enough success. Overall, I think that my general business area is starting to look more complete than I would have expected. Having something is place is the best way to build on your success and this overview is both a much needed representation in the area and a sort of conclusion to the strategy area.
Saturday, November 7, 2015
My second venture into my new layer of documentation sees me starting an experiment that I feel is going to prove very useful to the overall direction of my work. My last project was not one of the largest projects that I had, and I only gave it two summaries that were about two pages long each. I think that that is going to be among the shortest that my summary documentation is ever going to get. That is supposed to be a full explanation of all the parts of my product in about four pages. It doesn't sound like as much as it should be, but I covered every area of the product. My new documentation project is going to be a bit more ambitious. I started by creating an outline that describes the general characteristics of the four different sections that I'm going to be writing summaries about. This means that I will hopefully end up with about eight pages of documentation for the technical specifics of my project. I'm hoping that this will end up as one of the smaller sets of documentation for my projects and this will be pretty much the minimum amount of writing that I will expect from now on. This isn't going to be a rule because there are exceptions, but I think that I will feel better about the direction of my company knowing what I should start to expect.
Friday, September 25, 2015
I have officially started my newest layer of documentation and I have already decided that it is not going to be sufficient. Now that I have all of the negative stuff out of the way, I'd like to talk about how awesome things are going so far. I chose one of my simplest projects to use as a sort of test run for my documentation process. This way, I would be assured that the complexity of the project would not limit the amount of useful information available in any way. It is also a lot easier to organize my thoughts with only a few aspects to discuss. So far I have already noticed that there are a few parts of my code that I am not as familiar with as I had thought I was. I didn't need to actually open up my compiler to verify anything (although it wouldn't be a bad idea), but I'm going to guess that I will need to in the future. I think that this documentation is going to give me a very good idea how things are going to go if I ever hire anyone to work with my code. Anything that I'm having a hard time explaining, they're going to have a hard time working with either because of the complexity or the way that I decided to organize my work. This documentation is also going to tell me how skilled I will be at explaining what I have done. So far things have gone very well, so that seems like a good sign for my future employees.