Javascript Defense

Ok so I have gotten a little bit of response from a few guys at work on my post http://gameprogrammertechnicalartist.blogspot.com/2011/03/programming-languages-to-know.html with Javascript coming in at number two. Let me start by saying I know there is a lot of bad Javascript code out there. Some of it is ugly, some of it is even uglier than ugly, but what is written in the language is not the same as the language itself (the same case can be made for English).

If you do not have the chance to go to school for programming and are purely self-taught, Javascript is probably the best language to learn. You will have a lot of options to learn more core concepts and lower level details as you delve into programming and encourage even the most casual programmers to explore. The one thing I can recommend is to go for books over website examples. Sure there are some great examples online, but there are so many poor examples it is often hard for a beginner to know the good from the bad. In the case of books, they are usually a higher quality, just be sure to search out any errata or bug fixes that may be available in the case of mistakes.

One video I would recommend any Javascript enthusiast is http://www.youtube.com/watch?v=hQVTIJBZook by Doug Crockford (creator of JSLint and developer of JSON), who talks about his book JavaScript: The Good Parts (which I may have to pick up at some point). One of the best quotes from the video and good advice to any programmer or language developer is it is "easy to make things bigger, hard to make things better".

For those too busy to watch all the video, you should check out http://www.jslint.com/ for any and all Javascript but beware as "JSLint will hurt your feelings".

I understand that with any language, there will be those who vehemently attack or defend it. In the end, it should always come down to the right tool for the job. For certain tasks (like I don't know client side webpage scripting), Javascript is a fine tool to use.

Cheers,
Michael Hubbard
http://michaelhubbard.ca

Book Review: The Practice of Programming

A good book for those just starting out or wanting to look at programming again with a fresh set of eyes, The Practice of Programming by Brian K. Kernighan and Rob Pike has a good approach to teaching programming. Instead of focusing on syntax or abstract concepts right from the get go, the book instead looks as programming as a disipline with concrete examples.

Things like thinking about style of the code you write (use short names for private local variables, longer more descriptive names for more public variables), being consistent with the work, using active names for functions, breaking up complex expressions and algorithms and data structures.

Probably the most interesting coverage of the book is the Markov chains program that is written in multiple languages C, C++, Java as well as some information of Awk and Perl. Seeing how the same functionality can be acheived in multiple languages is very informative, and the book shows how the transition and design changes with the language.

Some of the chapters on debugging are also great, and the advice and examples are useful for everyone. Also, really taking time to think about the code and what it is doing, even in a hectic fastpaced environment is very good advice, and sometimes gets lost in the pace of the moment.

Overall, it is a good book for beginners, easy to read and to the point (and not the size of a phone book like many computer books). I would recommend it to anyone with an interst in programming, especially those just starting out.

Cheers,
Michael Hubbard
http://michaelhubbard.ca

Book Review: The Productive Programmer

An intersting book The Productive Programmer by Neal Ford has some great tips for the everyday and really brings out interesting concepts about the daily tasks of programming, as well as some good advice such as "Don't Shave Yaks"(where you can delve so far into a problem you end up solving everything but the problem) and YAGNI (You Ain't Gonna Need It).

The book focuses on useful tips, but really emphasizes reflecting on the kinds of stuff you do. If you begin to see ways of doing something better, you will look for it all around you. Things like, if you always have to navigate to the same directory over and over again, create a shortcut. If you open up the same files every morning, use an accelerator or automate that to do it for you. If you have to send the same email report every week, automate that too.

Probably my favorite idea from the book is "search trumps navigation". Anytime you have to find something, you waste both brain power and time when you have to look through folders or files to find the one you need. Instead, use tools to find what you need. For my Visual Studio friends, I always use ">of myFileName" in the search bar to get the name of the file (this quickly became the most popular way of searching to those I introduced it to at Ganz :P). This is a lot faster than having to search for that class or file through thousands of files. For those on Windows that really miss out on grep (Ford mentions cygwin) but I recommend giving Astrogrep a try http://astrogrep.sourceforge.net/ .It is free open source, allows regular expressions and displays the contents of the file (you will never go back to Windows Explorer for searching again).

Ford also focuses on aspects of eliminating distractions: turning off popup messages, using rooted views for a directory, and automating everything that usefully can be (interaction with websites, spreadsheets, rss feeds, build machines etc.). The later chapters focus on more code examples such as test driven development, source code analysis, as well as some philosophy and psychology applied to coding.

All and all a good book especially for the ideas it will bring about of how to improve your own productivity.

Best of luck,
Michael Hubbard
http://michaelhubbard.ca

The Programming Languages to Know

The programming languages to know (for Game Programmers and Technical Artists), but can really be applied to almost any programming task:

1. C++: The language to learn, and while I like C, object oriented programming is nearly always a better approach for large game projects. This is the language that job market talks in, is the language you want to be taught in university and the language you should be the most comfortable with. While a number of other languages are gaining interest (see C#) the low level control and history of code written in C++ will keep this language in the running for a long time (or at least until C++0X).

2. Javascript: While this may surprise some, this is the language for Adobe product pipeline scripting. Need something automated for Photoshop, Illustator or After Effects? Of course you do... always automate any tasks can be automated, and with javascript this will be one of the only options that these products have API support for. It was also great for some XSI scripting back in the day. Oh and it doesn't hurt that it is the language of client side websites either.

3. Python: This is quickly becoming the language for scripting and glue logic. Once, I would have put Perl here which is great for tasks you need a "swiss army chainsaw", but if your script needs to be maintained or is very long, it is often better to go with Python's object oriented approach. Maya including Python (along with MEL) also bumps this signficantly up the list.

4. C#: Really? Sure, more indie engines like Unity or XNA are worth picking up and playtesting with. While you can use Javascript with Unity, for a very large project it is worth going with C# and the tools (Visual Studio or MonoDevelop) that go along with it.

5. Cg (shader language): If you learn this NVIDIA shader language you will find both HLSL and GLSL a snap. If you are looking at Unity's ShaderLab or the very cool cgFX you should definitely pick up this language in your toolkit of skills.

Other languages that are great to know about are web based languages like Ruby or PHP, some other more unusual languages like Prolog or Scheme (so that you can think about solving problems in different ways) and of course knowing and using a little assembly never hurts (if you really need to optimize).

You will likely look at other languages in your career: such as Java, Obj-C, Lua and more. In fact, the more languages you know and practice with the easier that it will be to transition to other languages. Most languages (especially the popular ones) have lots of good books on them, and lots of examples, but don't worry so much about the syntax anyway, learning the syntax and key words is only the first step. Learning how to program effectively can be done in any language, focus on the language you work in, and learn it inside out. Learn how to architect software, break down problems into solutions, how to optimize and debug what you have written, and what it really comes down to is being able to think in a programming language. When you learn other languages, picking up the syntax differences and a few specialties in the libraries shouldn't be too hard to pick up after that.

If you really want a challenge, you could always try http://www.muppetlabs.com/~breadbox/bf/ or try some of the more obscure ones at http://c2.com/cgi/wiki?HelloWorldInManyProgrammingLanguages and http://www.99-bottles-of-beer.net/

But only if you are up for a challenge...
Michael Hubbard
http://michaelhubbard.ca

RateMyEmployer.ca

In case you did not know there is the site for rating employers: http://www.ratemyemployer.ca/ But how useful is it really for you as a potential employee? Well, from what I can tell, most of the time the ratings are generally pretty negative. This has to be taken in context, and a company that has a lot of employees but not a lot of ratings may potentially be a decent company, while a smaller company that does not have a lot of employees but a lot of negative ratings may not be very good. If you are lucky you will have a lot of comments and will be given reasons for why they were rated that way, either positive or negative. Having only one comment (positive or negative) is usually not enough information to accurately assess whether or not it was just one happy or one angry employee posting from a good or bad day.

For those of you still in school also check out http://www.ratemyprofessors.com/

Regardless, if you are really interested, it never hurts to do a little research. If you are scoping out a new job, try and check it out before you apply. See if the people are happy working there (if you can ask them), check and see if people flood out at 5:00, if there are a lot of fancy cars in the parking lot, if people are smiling or are walking zombies. What kind of stuff has the company produced, do they have a good track record of many successful products, or are they struggling? Another good indication is how much activity (new and leaving) does a company get on Linked In ? Do they have a lot of turn around, and what kind of people are they bringing in (experienced, or fresh out of school)?

It never hurts to do your homework, after all, it is your life.

Best of luck,
Michael Hubbard
http://michaelhubbard.ca

Book Review: Taming the Tiger

An interesting book Taming the Tiger: The Struggle to Control Technology by Witold Rybczynski, is not a programming or art book, but rather an interesting reflection of technology throughout history. The book brings up some intersting concepts, man as the prostetic god (able to extend his reach, life, travel and abilities far beyond natural levels all through technology) and the idea of houses as a comfortable living machine that we stay reside in.

The book also includes how technology is prevades all aspects of our society. People who barely remember their highschool physics are require to take sides in the nuclear power debate, "the fragmenation of modern society and reduction of shared experiences means people form opinions on most subjects on the basis of second hand experiences" (Rybczynski, 26).

Rybczynski delves into a number of historical backlashes against technology (Captain Swing and the Luddites, industrial revolution risings, Ford assembly worker overturn etc.) and the inability to "rollback" technology once it has been introduced (only delaying the inevitable). There is also a lot on the "Shock of the Machine" and how cultures try to adapt to new technologies.

Rybczynski has some great quotes about how technology is intertwined with our own society it is difficult to talk about (or tame)."Part of the difficulty of taming the tiger is we can't see the animal clearly. It is easy to identify the boldly striped beast in a cage, but in the splotchy light of the jungle its colors become confused with background shadows. So too with technology. It is easy to discuss in isolation, but immersed in the opacity of human culture its outlines frequently become indistinguishable from its surroundings" (Rybczynski, 213).

"Just as we have discovered that we are a part of the natural environment, and not just surrounded by it, so also we will find that we are an intimate part of the environment of technology. The auxiliary "organs" that extend our sight, our hearing, and our thinking really are an extension of our physical bodies. When we are able to acept this, we shall discover that the struggle to control technology has all along been a struggle to control ourselves" (Rybczynski, 227).

Interesting stuff,
Michael Hubbard
http://michaelhubbard.ca

Book Review: Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects

A great book by Edward Yourdon, Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects. Being part of a crunch turned to death march projects, this book speaks volumes on the subject and is a worthwhile read (hopefully before you start on a project). For a death march project to occur, one or more project parameters exceed the norm by more than, 50%, time or resources needed that are not available results in a death march. Yourdon continues with the disturbing news that "Death projects are the norm, not the exception", even with the data that "the average project is likely to be 6 to 12 months behind schedule and 50 to 100 percent over budget."

How do death marches occur? The book describes a number of possible catalysts: company political reasons, naive promises made by marketing, senior executives or naive project managers, naive optimisim of youth (build any system over the weekend), "marine corps" mentality (no sleep necessary for "real programmers"), intense competetion, startup mentality, or unexpected crises. Yourdon stresses the political aspect as the most likely candidate of a death march. The politics can boder on the completely irrational: "Hysterial optimism, which is when everyone in the organization desperately wants to believe that a complex project, which has never been attempted before, but which has been realistically estimated to require three years of effort, can somehow be finished in nine months" (pg 10).

Why do people participate? High risk, high reward, naivete or optimism of youth, buzz of working closely together, Mt. Everest syndrome, alternative is unemployment, or revenge. The results are sacrifice personal health, mental health and personal relationships. I also talked about some of this in my post: http://gameprogrammertechnicalartist.blogspot.com/2011/01/why-do-people-crunch.html

If management expects time and budget to be padded they are expecting the estimation of schedules to be some "negotiating game", but is also likely to be some degree of naivete and lack of understanding of what really goes on. The owner of a death march is often a much higher-level manager than would be normal for the software project, usually with a long hierarchy of shareholders, stakeholders, project managers and customers in between and around. A long hierarchy often gets distorted on the way down to the project manager, where (on the way down) additional elements are tacked on to the message, bloating the project scope and timeline, with additional requirements, constraints and processes.

The major cause of death march projects is politics, often related to the negotiating games. Management always wants the enormous luxury of a promise of what something will cost, how long it will take and not have to worry about these factors, and also gives them a scapegoat for blame if the promise is broken. Senior management needs to share the burden of uncertainty and allow for changes at all levels, not bringing in someone for an on the spot estimate and building their entire project around something that has not been careful worked through. Always defer instant estimates, and always give +- estimates like 3 to 6 months, or 6 months +-50%

The book talks about four different categories for death marches:

High moral & High chance of success = Mission Impossible (a lot of hard work, but exciting)
Low moral & High chance of success = Ugly (marine corp mentality, whips cracking).
High moral & Low chance of success = Kamikaze (try and go out with one last hurrah)
Low moral & Low chance of success = Suicide (no alternative)

The interesting thing is that these values are all relative to the individual programmer. Some programmers may feel they are on a Suicide project, while others feel like the same project is a Mission Impossible one. People's commitment changes over time, almost always in a worse way.

Work has to be mutually beneficial, and if the threat of being fired or bypassed for a raise or promotion are common, then the strongest bargaining chip you have is displaying that you are ready to walk away from the relationship, if the results aren't mutually acceptable. Two specific issues that also have a significant impact on motivation, and which are usually under the manager's direct control: rewards and overtime. Bonuses are tricky and can backfire, at a startup with part of stock option available they may be a good modivation (like tens of thousands, or millions of dollars), support for the whole family, taxi service, grocery service, and helping to provide medical attention to the whole family. This costs money, but usually a very small amount. Give extended vacation (they will need it) not just a few days but extended period of time. Consider a paid sabbatical (6 months to just work on whatever they want it to be), and loaning project equipment.

The main focus of the dealing with death marches is "triage", where each task is separated into "must-do," "should-do," and "could-do" categories. After all the tasks have been separated, all work is done on the must-dos, then the should-dos and then the could-dos (if there is time). The idea behind this is if "80-20" rule holds true, the project team might be able to deliver 80 percent of the "benefit" of the system by implementing 20 percent of the requirements (if they implement the right 20 percent). Stephen Covey puts it in First Things First [I], "the main thing is to make sure that the main thing is the main thing."

Yourdon offers some other project manager tips as well.

- Project leaders should put in as many hours as possible to lead by example.
- Target 60-80 hours a week, but know your limits, everyone reaches a point of diminishing returns.
- Need to be trueful with the team, disillusioning to find out crucial information later.
- Make sure people are compatible.
- Show work in increments, but avoid prototypes which only perpetuate an illusion of completed work.
- Modifications to baseline requirements should be made public for all to see.
- Don't introduce new processes to a death march project.

At some point the death march is likely to reach an "ugly crisis" where it is shown that the project will not be completed on time, and the project manager is fired and replaced with a new project manager who is supposed to "get it out on time". The work-in-progress created by the project team before the "ugly crisis" occurs usually ends with the sad result of being thrown away: "The real reason why all of this partially-completed work ends up being wasted inventory is that no one will ever have time to come back to it. Assuming that the project team members (now under the control of a new manager, whom they may or may not respect) is able to deliver the "bare minimum" of critical functionality, they're usually so exhausted that half of them quit. And the users are so disgusted with the project that they never bother asking for the rest of the unfinished functionality; or conversely, they're so satisfied with the minimal functionality that they never bother asking for the rest of the system".

Even though everyone understands the issues intellectually, the political battles surrounding death march projects makes it almost impossible to reach a consensus on a reasonable triage. It's only when the "ugly crisis" occurs that the various parties finally agree on something that they should have agreed upon when the project began.

Try to focus on what works, not the process or methodology, or buracracy. Not to say not to have a process, since that can be a significant process, but be reflective of what works and what doesn't. Minimize number of tools needed, like a mountain climber, just bring the essentials.

Finally, Yourdon recommends quitting or leaving if it is a viable option, learning something new for less pay will make you a happier person. If any of these succeed, what is to say that they won't try it again? Some companies need to fail to see what they are capable of, hopefully it doesn't ruin the company. It is important to not measure the success of a project by the number of divorces, broken relationships and ulcers.

I have been part of a few death marches, and while a few can be bearable for a little while, in the long run you will almost always regret it. Avoid these types of projects if at all possible, everyone needs balance in their lives. If you find yourself on this type of project, the most important thing to remember is this: Life > Job

Best of luck,
Michael Hubbard
http://michaelhubbard.ca

P.S. Or if you prefer Life > Work (Life is greater than Work, for my non-programming friends), I should make it a t-shirt :P