Learn Build Play is on its way...

                I plan to start teaching nightly classes in the very near future.  Learn Build Play is getting ready for it.  It's anywhere from one to three months from now for its first class, as I’m getting everything else arranged and the site built up, but I figured now would be a good time to start talking about it.  

                A little background on me, I’ve got over 10 years of professional experience (what I consider being paid to program/administrate/test).  I have about 20 years of programming experience.  (I started with Basic in the 4^th grade, and never looked back, unless I thought some one called my name, or I forgot something.)  And about 6 or 7 years ago, I started teaching part time at colleges. 

                I personally hated much of school growing up.  I never went to college and it took me 5 years to finish high school, almost 6.  I had a saying all through high school, and beyond it, “Education is the most important thing to me and I’m not about to let school interfere with that.”  I’m really fortunate I didn’t let school get me down. 

                I learn differently than many others, but not too differently.  Some teachers were great; everyone learned a lot, had fun and gained a drive for whatever the class was about.  I also had the good fortune to move around a lot and see different schools, probably 10 different schools in 12 grades.  I got to witness lots of teaching styles. 

                Over the years, I started to learn myself better; to understand how I think, how to change, how I react, where I’m weak.  On a chance moment, I learned about the Continuing Education at Heartland Community College.  I signed up to teach Visual Basic 6, which used to be my strongest language.  I was one of those “forever” supporters of it that didn’t want to let the language die. 

                Over the next 3 years there, I took a game programming course that was essentially a 3 classes a year of learning hangman in visual basic, and turned it into a successful 10-20 classes a year game programming series.  It used various languages, VB6/.NET, BlitzBasic/+/3D,  C#.NET, and covered a variety of technologies such as graphics, physics, rendering, binary logic, networks, AI and more.  But most of all, (I believe) my classes were fun, engaging, and provided my students with a drive to learn more.  Most all of my classes received top performance evals.

                When I got a job offer to work at Microsoft, it was actually a hard decision to make.  I did not want to leave this place.  But on the other hand the largest company on my resume required me not to name them directly, I could only say, “a large insurance company in central Illinois”.  As far as I was concerned, Microsoft was the End-All-Be-All in the computer world.  Not the only one, but similar to being offered a position at Porsche (pronounced ‘Poor shuh’) or BMW, as they are pretty top end. 

                Eventually I decided to take it, but not until haggling with them for a week over pricing.  Once I got up here, I settled down, and it took me a year before I got to start teaching again.  This time with Bellevue College, where I’m still teaching to this day (part time contracts) for game programming. 

                I enhanced their existing course and expanded it.  But I have not had the flexibility I have been hoping for in class offerings nor many classes to teach.  With these classes, I’m hoping to be teaching more often.  I still plan on staying a senior SDET at Wizards of the Coast, but my evenings will be doing the activity I love most, teaching. 

                The classes will be 8/9 person max, each person will be provided a laptop in the class.  We will have a server environment, typically 2-4 hours in length, and you can get certified.  The certification program I have in mind involves building a project on your own, which covers the key topics of the Course, followed by a few questions by phone/in person, then an interview for a fake position mirroring the course.  While the technical skills are all that is required to get certified, a follow up description on areas to improve, including interpersonal skills and interviewing tips are all part of the course. 

                What’s the point of getting certified in something if there is not a reasonable shot to get hired for it?  No multiple choice test.  Anyway, I may post again several times prior to its activation, but it is on its way.  I’m presuming the first class in June. 

               

Getting Better by Giving Less...

                One problem that many people face is giving too much to their goals and projects.  We create one small goal for our project, or our game, but then we sit down for an hour and really think it through.  Every “good” idea we run across becomes part of the final project.  And you start to realize that the first draft of the projects financial needs are in the millions. 

                Bloating is one of the most common causes of failures in a project.  Even if it had another fault.  Imagine throwing similar resources at a smaller project, or developers, architects and testers time line differences, when the project is not only smaller, but simpler as well.

                This is all “fine and dandy” but how do we actually apply it?  I’ve understood this principal for years, but haven’t been able to figure out how to apply it until recently.  Whenever I would start building a game, I would try to start small, but the architectural excitement factor draws me in.  It is exciting to keep adding more, and unheard of to remove the things you come up with along the way.

                So here is what I have started to do with my plans.  I give in to my need to design awesome architectures and super simulations, and design full blown systems that I will eventually decide are too complicated.  Then I simplify them.  I start to cut out all the crap I don’t need.  In movie editing, they have a phrase, “you start cutting with a scalpel, and finish with a sword”  I reverse this.  Start with the sword.

               

                In fact, skip the sword and start with a rescue squad.  Salvage what you can.  Pick the most important part of the application.  Then the next couple of items, and rank them.  Next, reconsider what you really need to accomplish that. 

                I have this bad habit of wanting to rent servers instead of websites, whenever I start building a site.  If I were to get a server, my options would open up more.  I would have so much more available.  But do I need it?  I’ve never run more than 4 sites at a time, and site hosting VS. a dedicated server is a whole decimal less in cost. 

                Its not cost effective, it created more work, and I ultimately got less done.  So this time, I’m considering a site again, but I’m only considering Hosting a single site.  I’m paying 1/10^th the cost, and I have less of the stress.  I’m not dealing with fail over systems.  I’m not dealing with security.  I’m not dealing with Maintenance.  Huge amounts of the work are cut out, because I’ve decided on a course of action that accounts for the minimum requirements to get the same end result.

                The Same end result?  I cut my cost by 90%, my time by 50%, and my work load by even more.  I’m considering exactly what I want the consumer to see, and what EXACTLY is needed to provide it.  I’m also considering what I have tried and failed at.   What’s the last LARGE project I’ve completed?  None.  When I let my projects bloat, they fail, not from complexity, but from neglect.  The potential stress of trying to get it to work, makes me rebuild it from scratch or just move on to another project entirely. 

                One of the reasons many of us get into programming or game design, is because we see things as they are and want to add to it.  Whens the last time you’ve played a game and said, This would work better if it had this…  When is the last time you played a game and said, This would work better if we cut this feature out.  Its easy to cut out obviously annoying things, but what about things that don’t really help the end goal of the game?  What if we were playing in a game with wavy grass, where the grass images came from 256x256 motion tiles, instead of 512x512.  Would we really see the difference.  The second takes up 4 times the resources, and the end user might not even notice. 

                So, take a recount of past projects, and consider what the last project you designed was that bloated, and was it successful?  My advice is this, start small, stay simple and then scrap all the requirements that don’t help the ultimate goal of the project.

Mentor's Learn the Most

                One thing I’ve always loved doing as a teacher and mentor is, “Let’s try it, and see what it does.”  I often learn things I wasn’t expecting, or get new ideas.   There are many more reasons, but it’s time for all potential, practicing and professional programmers to stop thinking so much about how they will get their own tasks completed, and start thinking about the ultimate success of the company, teams and projects. 

                Even from a greedy perspective, helping others in the companies makes sense.  Helping others makes you a reference, or a known expert.  But, it also generates social connections, puts your name higher up on lists and introduces new opportunities. 

                But from a practical sense, it is even better.  You learn new ways of either doing things or not doing them.  You get good examples of both good and bad work, beyond what you have done on your own.  You get to experience other coding dialects within the same languages.  Everybody you work with will often have some valuable perspective that you can learn from.   

                So here are a couple rules of thumb to make sure your applying. 

*Always listen to the other perspective.  Try to imagine that the idea they are talking about is yours, and imagine ways that it could be made to work in different areas.  When you come to blockers, you’ll have really effective means of challenging it.  Not to mention you might learn something. 

*Try something new.  Technology and how it relates to the world are constantly changing.  You should never believe there is any form of end-all-be-all solutions.  You’ve probably worked with someone who knew they were right about something, and wouldn’t even bother to look at another perspective.  So don’t be that person yourself.  Everything in life changes, all the time, whether we want to perceive it or not. 

*Be willing to help when ever reasonable.  When we join a company, or a project, we are telling the rest of the team that we will do our part of the work.  So what does it mean if you get all your stuff done, but let everyone else fail?  Try to imagine that you are not yourself, but a part of a larger form, that is working towards one goal.  This will help you take the “I” out of TEAM.  Besides, if it’s a quick fix, you’ll be done really fast, and if it is not a quick fix, you’ll learn something from it.

*Let others know that they can use some of your time if they need to.  Just being available to help isn’t enough when many feel that seeking help, is embarrassing, and that others will probably just mock them, even just subtly.  Did you ever ask someone something, and they give you a look or expression that says in a mocking tone, “You don’t know how do to that?”  It is tough.  But if you make sure they really believe that you are open to assisting, that you see the project as a whole, they will be far more open to seek help faster.

Now, take a step back and imagine most of the difficult scenarios family and friends.  Apply this same logic.  Imagine how much it would have helped.  This is my basis of being a mentor.   It is my opinion.  I welcome you to apply it, learn from it, improve it or challenge it.

Perfect Code

                In almost any industry, everyone is always looking for shortcuts for what they need to do to get the customers what they want.  This is both a good and bad thing, and you must learn recognize what is good, and what is easy. 

                For instance, building games, you have options, like selecting a previously existing game engine, or producing a new one of your own.  Another might be, Should we produce the hardware for this game, or use existing platforms or OS's?  Another might even jump further out and say should we use existing graphics processor chips, or design and build one ourselves.  The short cuts in all these would be to ultimately accept an existing engine that already works on existing hardware.

                While there are many directions I could go with this, I'm going to take another direction, and that is in our every day choices, particularly for programmers.  I've discussed the use of standards in previous articles, but once they are set, we are often faced with the decision of skipping ignoring it for speed.

                When I worked as an electrician, Dan Webster, the guy I was training under, "If you don't have the time to do it right, you certainly don't have the time to fix it."  So why do we find ourselves stepping out of our self-imposed standards when programming?  Because we have two stages of development, and we need to learn to keep them separate, those being: Practice and Perfection.

                You've probably heard this one, "Practice makes perfect".  Since perfect is a strong word, I'm not going to debate its philosophical implications.  Instead I'll offer this meaning for how I'm using it.  Perfect Code, is code that you can fully defend every line, every capitalization, every comment as to why you have used it in specific, and that you would trust this code in production. 

                While we sometimes produce Perfect Code, we often tend to produce Hack Jobs, just piecing together code in any way that gets it to work as quickly as possible, or Band-Aid code, as my wife calls it, because it may be gushing problems, but this dinky little band-aid seems to keep it together for the moment. 

                We need to face facts.  We are not as good of programmers as we think we are.  "The only true wisdom is in knowing that you know nothing" – Socrates.  Compare some of your own code.  If it was part that you have done a hundred times, you will find your code is naturally cleaner, closer to something that you consider Perfect Code.  But if it's the first time you've created it, you'll tend to find shortcuts all over the place, little hack jobs.  You often tend to find yourself going back over it to clean it up and try to bring it up to your Perfect Code standards.

                So what does this mean?  Here is a good rule of thumb: If you find that you aren't following your "Perfect Code" standards, because they are tedious while you are building this part, then forgo ALL of your "Perfect Code" standards, and call it a practice.  Once you have figured out what works in the code, go back and do it right.

                If you find yourself heading in the direction of practicing, in your real project, copy the whole solution over to a temp location to try working on it.  Once you have completed a solution once, go to your real project and rewrite it, only following all your standards.  It is impossible to follow the Perfect Standards, while your knowledge is imperfect.