Saturday, November 17, 2018
Features, Features, Features!!! They are what keeps an audience interested. On a personal note, crafting ideas that tend to be "attention grabbers" can be quite rewarding. I might borrow from something that I found to be working well. While I don't want to sit here an preach about how having a redundant product line could be helpful in some way, I think "tact" is what we're searching for. Yes, successful features of one product can be used to enhance a second product. And yes, everything that is produced could "go viral", could be redesigned dozens of times, or could never quite find it's intended audience. Features are something substantial that we can add to our toolbox, if needed. Yes, it's a bit much to claim that a product with "a bit too much" in terms of features could be forked and turned into two seperate projects, but we do have backlogs for a reason, and we are striving to stand out in some way. For now, I'm going to assume that complex properties sections and "little known uses" are for much larger code bases. There is nothing wrong with being a "home-made" software business. While it might not be something to yell about, having a neat little display with something to offer to customers......is nice.
Thursday, October 18, 2018
Get the code working as quickly as possible. This means we are not learning a new language, trying out a new layout approach, or messing around with some "get it out the door" marketing plan. Even if this sounds like what we are trying to accomplish. New languages are for learning (and perfecting) in your spare time, not in the middle of a time crunch or while trying to gain traction for the investor types. Yes, this may seem drastic, yes, this may seem redundant, but when we're trying to make the most of our productive hours, we want to have positivity on our side. When our, "old fashioned" approach looks similar or less efficient to something else, that's because it is. It could be, under some circumstance. Getting a task done is not something we want to be negative about around a consumer. We understand what the customer wants, what pitfalls or obstaces they may encounter, and we craft them a solution. We make them something they didn't know they needed, but suddenly have found a use for. We've created positivity with our features and functionality, which can find a way to an area where once there was negativity! This is working code. A product.
Monday, September 17, 2018
Refining a product, tuning a product, testing and improving quality, whatever this process may be, it is often not as glamorous as it should be. Recently this process or idea has changed the shape and direction of my company. I have found meaning where there was previously a giant pile of code. The glamour of this process lies in the vision you are creating for your customer. My "vision" was taking a fairly uninteresting, yet functional game giving that game a finite difficulty. This means that players will always face a particular challenge while playing my game and may now work on their approach and skill at execution. Making these changes requies attention to detail and the ability to "test" various customer situations and probable mistakes a reasonable person might make. Now that I have this process as a part of my toolkit, I will be able to access it more often because I have been there before, I know where I am going, and most importantly, I understand how the pieces are starting to fit together. Additional work and/or goals include the winning over of the user from their initial impression, playing the market through variations on our application options, and eventually trying to gain traction with a fanbase.
Friday, August 24, 2018
A portable code base has been achieved for the first time in company history! This historic day saw the packaging of the "high scores" area for our gaming division into a jar library file then distributed and deployed to not one, not two, but four of the companies current gaming entries. All games were completed, packaged up, and now have links to "launchers" except for one game which was held back due to difficulty and gameplay concerns. The biggest win of this day is not the availability of compiled, runnable code, but the ability to make changes to the library file once, and then distribute those changes without having to worry about tiny inconsistencies. This is not going to be something that will be marketed, probably ever. It's not a huge internal win. The system is now in place, the ideas are going to be there for future work, and hopefully, it will help influence how the company works going forward. If several projects share a common component and it's decided that the said component is going to change, this process is going to deliver those changes in a professional manner.
Thursday, July 26, 2018
The marketing ploy that is my "demo sandbox" has been wildly successful. Until recently, only marginal progress had been made here and there, sort of a layout for online storage areas with public links. Yet, the true success of the demo area was buried deep beneath moss, peat, rocks, bedrock, and even magma itself. The heart of the demo area was the ability to point to a centralized entry point for an application. To boldly claim that ALL libraries, dependencies, files, features, and anything else that I wanted to put in the distribution(distrubutable? package?) had made it onto the customer's computer. That from this one point, we know what was working well, and what was still going to be an issue in the future. Immediately, something that is working well has the ability to download, unzip, launch, and utilize every feature of an application from start to finish without any compilation or tutorials to follow. Leaving in those little shortcuts that we take while developing our code may not seem like a bit deal until you are ready to give a presentation and are caught unaware! Or perhaps you told a perspective partner that your finished product was a little more polished than what they are currently looking at.... Running a business is not all parties and cornbread, it takes a lot of hard work!
Sunday, June 24, 2018
Social responsibilities tied to coding are not worth mentioning in a blog, but are a required part of every engineer's career. We all know that code that is not marketed is not viewed as important, end of story. Whether it's to your own team, a customers, or an audience at random, someone viewing and working with what we've done is required for it to be useful. The same can be said for education. Everyone that is an engineer or writes code at all at some point has to have some form of education as to what it is that they are doing. What is happening is not the important part, but how we apply this to our work and our productivity. Attending the most recent Oracle confrence allowed me to view my GUI coding from a new perspective. I thought they wanted me to work with concepts that they simply did not include in their priority list. After discussing my problem on engineering forums, I realized my bigger problem was attacking a specific problem for which I had no context to. These social responsibilities are what lead us in a positive direction. They help get us moving when we are stuck. Sometimes, just being visible and improving our education can lead to places we would not have gotten to otherwise. I've found that sometimes, after being "social" enough, older projects simply seem differnt because they are viewed from another perspective. This can lead to unforseen breakthroughs, ideas, and much more. Although nothing fancy, it is something that is a part of the way people work.
Wednesday, May 23, 2018
Continual progress is not something that can be claimed so early in the development cycle, but is a concept that can not be overlooked. After a piece of code has been written, it is a part of a body of work. A body of work that can be referenced, updated, expanded upon, or simply used as a point of reflection for something even more extroridinary in the future. For most coders out there, the biggest obstacle to revisiting old work is the mental block of having to "get back" to their old project. This means finding all the old connections that made the magic happen. Re-learning all those little "work arounds" that accomplished the task at hand. These and numerous other obstacles can make a simple task into a much larger task than we'd like to think about. Writing code that works well with previous designs and styles is that much harder. Adding code with an updated style might be a bit of a reach, but the point is, a code base is something real. A code base is something substantial that is worth keeping track of. Something that can be worked on, but should be viewed as more of a "pleasant" responsibility. I, the coder, am going to slightly improve the foundation from which I have built my house upon. Hopefully your efforts will not go unnoticed.