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.