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.

Why use standards and which ones?

                An entity without standards is chaotic.  I’ve seen, experienced and even generated my own projects that had no standards (back in the day).   From all these, I’ve seen some common traits:

1)  If the coding takes long, like more than 16 hours, it starts to get complicated to work through and keep things in the bit of architecture you originally intended.

2)  You find that as you move along, you need/want to rebuild parts of it to simplify them or just because that part doesn’t make sense to you anymore. 

3)  After leaving the project and coming back, or entering a new project from someone else built the same way, you tend to think it would be easier to rebuild the whole thing, than work with the existing code. 

4)  You lose track of the meaning behind certain methods, classes, variables and processes, and when you look at it, you don’t understand how  it seemed so clear at the time. 
5) Bugs start showing up all over the place. 

6)  You start applying little hacks here and there that keeps things working in very specific conditions.

7)  Fixing a bug usually produces two more, 1 you get to see right away, and hides out for a little while. 

8)  If any timeline was generated, it has been exceeded.

9)  If the project isn’t very important, the developer will drop it.

10)  Developers get sick more often due to stress.

11)  It is fun to start, but after a short time, the fun is gone.

The list goes on…

                If you find your code, team or other’s suffering from the symptoms, it’s a pretty good sign there is a lack of a standard (at least a good one).  I’d also like to point out that a programmer without standards does not make them a bad programmer, but it does make their code more susceptible to the symptoms above.  Just like OOP is a step over the basics, having solid standards is a step above that. 

                So I’ve listed some of the bad things that happen.  Now on to the solution. 

                When it comes to standards, I’ve got a saying.  There are many right ways, and many wrong ways, but only one right way.  :D  (it makes sense in a moment)  The point is that while there are many good standards to follow, you have to choose one and stick to it.  Standards are no good if they are not standard.  2 weeks ago, I posted a way to document standard processes.  (here)  Now I’m going to give you some ways to find and keep your standards in specific. 

                The first thing is to know why you follow something.  There are many outdated standards, which are outdated for good reason.  The second is to be open that your own style might not be the best.  (This is something I consider all the time.)  Hungarian Notation was pretty big for a while, until they realized (not everyone knows this) that by following Hungarian Notation, you are actually reducing the implications that should be used through vocabulary.  Lets take a look at 2 variables “_adAmount” and “prices”.  Looking at the Hungarian Notation on the right, which is using an “_” to show it is a private variable, “a” to indicate it is an array, “d” to indicate it is of doubles, and “Amount” to give it a name.  Now, following some more modern standards, we see “prices” which is lacking all the symbols and details of “_adAmount”.  It is lowercase, indicating it is private.  Price indicates a decimal is needed and also implies the accuracy needed of a double.  The fact that it is plural implies an array of some sort.  Both of these followed a standard.  Hungarian got away with “Amount” though.  Amount is questionable, amount of what?  Amount of time since the last loop?  Amount of apples?  There is nothing in Hungarian Notation standards that sets up the implications of its meaning. 

                Sure, you could have chosen “_adPrices” as your variable name, but what standard are you pushing that requires that?  Another developer may have entered this and just used “I” or “x”.  The point is that the word is often chosen because the developer needs a “notch” to refer to for a variable.  If it’s only for a single method, they often use smaller less obvious terms.  While these work great for the quick entering of data, in order to figure out what it is, you have to take a look through the code to see how it is used.  I recommend keeping a standard where things make more sense, and are easier to read with native English. 

                Now to the key point, 1 true standard.  The point is for you to write down your standards that you will follow.  But, you also need to record the defenses with it.  (Why this is best)  And finally keep it open for critics.  Anyone who works with you, should also follow this standard, or successfully argue why to use something different.  You are not allowed to use a “because I said so” or “because I’m above you”.  The whole point of this is to make better code, not stick to some obscure ideology you grew up with, because you aren’t open to change.  Be practical.  When you write down defense, also include challenges to it, even if you keep that one.  Later on if you find a better way that solves more, then upgrade and keep it.  Don’t hold to practices that are not defendable.  You’ll find yourself hurting in the long run, and may not even realize it.

                One Standard:  All standards are defendable, or they are not standards.

                One Standard:  All standards are open to change from anyone who has to use them.

                One Standard:  Have a standard. 

                One Standard:  Keep it practical.

                One Standard:  Keep it Easy to find, Easy to read and Easy to use.

                One Standard:  KISS: Keep It Simple Stupid.

                One Standard:  Keep it flexible.

                One Standard:  Keep it living.

               

Open-Book Management

                I just finished reading a book called Open-Book Management, by John Case, which I originally figured I would read the first chapter and decide I already had a lot of the ideas that the book would have to promote.  I was wrong.  When I first selected it, I saw it as keeping open with employees, and keeping a clear goal and vision.  While that is important, this book is actually about Money. 

                It taught me several things about how to keep employees driven at all areas.  I’m about to describe part of the book, but by all means, not even close to covering it.  If you find any of this helpful, GO BUY THE BOOK.  You won’t regret it.  If you are trying to exist as part of a company, run one or are starting your own, you have a responsibility to make that company successful.   Especially if you are running it. 

                While there are many who want their companies to be successful, there are few who actually make companies that want to be successful.  The difference is small, but very clear.  Think of any random gas station, or fast food place.  At the corporate level, you have lots of people who are running around trying to make the company succeed, and exceed in its industry.  Now imagine the cashier, or the person who made your sandwich.  What do they care if the company is thriving or not.  If they only get 25 people in that day, instead of 500, they’ll be happy, because its less work for them.  They get paid the same whether they serve 10 or 100 people an hour. 

                Now think of the customer.  Does the customer care one bit about how much the corporate layer’s are doing to try to keep the company afloat?  No.  They care about the service they get.  They care about the quality the sandwich was made.  They care about the speedy handling, and the accuracy of their order.  Corporate can do all they want to “streamline” and provide the fastest method to deliver the service, but it really is the employees that give the customer their clear feelings regarding the quality of the company.

                So what can you do?  How can you make all the different people, EVERYONE that is part of your company, interested in making the company succeed?  Open-Book Management starts with opening the books, the financial books.  Exposing the numbers for all to see.  Then training the different areas to be able to clearly understand how certain parts of it affects them.  As well as starting some kind of profit sharing. 

                There is no part of any company, that is there without having some effect on the bottom line of the finances.  If you can show them how they have a direct impact on the success of the company, and give them goals to improve their area, and if their area improves, then they can get bonuses from it, suddenly it is not just a job, but a goal.  The average employee will see that they can have a real effect.

                If the person doesn’t care how the company does, no more than guaranteeing their paycheck anyway, it is only a job.  If they want more jobs, there is a section for that in the news paper, online services dedicated to finding new ones and networking to find more.  But if your company provides them with a strong feeling of connection with the success and failure of the company, then you’ll be able to retain employees longer, there will be more open communication, more areas will be found that can improve.

                There is another key to this Open Book Management though, empowerment.  You need to give people the power to actually make change, at least in their own areas.  You need to keep open communication between all layers of management about ideas that could improve the company.  Honestly, who is going to know better about how to save money at the customer service level, the employee who is working it every day, or the VP sitting 3, or more, layers up? 

                The higher a person is on the management ladder, the more power they should have at shaping the company as a whole, and primarily deal with keeping communication up with those that report to them.  It is more often that management thinks that the lower levels of the company need to be directed, told what to do, when more often than not, they just need the initial training, and someone to help keep their obstacles cleared. 

                If you get the chance, I recommend reading it, as the author explains through many stories, how this can be applied, and what issues people went through to get there.