Friday, July 19, 2013

thought work

Today was a thought day.  I spent the day contemplating the direction of my company.  One of the more important ideas was the ability for me to expand in terms of employees.  If new hires can not or do not want to read my code, I am going to have a difficult time convincing people that working for me will be worth their time.  Going over the data_discussion documents (which is part of the genetics project in the science sector) was well worth my time.  For starters, it outlines what exactly my technical advantages are and how I will be able to communicate those advantages to the scientific community which will be knowledgeable in biology, physics, calculus, etc, but may not be as knowledgeable in certain aspects of computers.  This could be the most important part of that area, because if a customer does not understand why they would buy a product, they will not buy that product.

Other thoughts included my rate of development, how that effects my overall ability to maintain my organizational system and company reputation.  The rate of development is something I often forget because one usually thinks, the more accomplished the better.  I feel that sometimes if a developer is not careful, they can sacrifice the smaller details to expand functionality.  This has both advantages and disadvantages, but today I was focused specifically on how that effects my ability as one person to stay organized.  If I keep developing for the sake of writing code, I'm going to end up with a big "pile-o-code" instead of an efficient system that's going to be around for a long time.  I know that everything that I do will have to be viewed and probably worked with by another person at some point.  There are the obvious points that will get skimmed over, documentation, organizational charts, code reuse, and code readability.  But currently I'm still just one person that has to maintain all code by myself.  This means that when I switch from one part to another, I have to remember, or more often, relearn what I was doing at the time.  I also have to remember to keep all parts of my code current with the standards and techniques I'm working with at the moment.  Sometimes that's a bigger deal that other times to apply a new coding standard to old sections that may have complex dependencies or parts that were "good enough" at the time. 

Finally, I went over how my company reputation is going to be significant going forward.  This means that everything that I code is going to be a part of my company.  This won't seem like a big deal most of the time, but some people are going to think, why is a research lab wasting it's time making computer games?  Why would we fund a social app that's not going to be around for very long?  And of course, how does my smallness hinder me in my ability to move forward?

No comments:

Post a Comment