Where will I ever need this math?

For a career, you need certain skills. There are six main areas where mathematics is needed and a bunch of sub areas... ignoring math for maths sake or teaching. Most of these people are highly respected and often are paid highly.

1) Computer games, simulations, military simulators, etc. The level of math varies but usually requires at least two semesters of Calc, Linear Algebra, and some exposure to Vector Calc. I work in this area.

2) Economics, business, predictive economics, insurance. This usually finishes Calc and then goes into probability, statistics, and actuary (insurance).

3) Research, materials research, chemistry, heat transfer, nuclear plant building, solar cell creation. Most of these delve into a unique blend of statistics and differential equations.

4) Engineering, bridge building, aircraft design, process engineering, industrial design. This is almost entirely Calculus and applied physics.

5) Biological research, genetics, protein analysis, pharmaceutical research. This is applied chemistry, biological sciences, and computer simulations mixed with Abstract Algebra (protein folding), Calculus, and various fluid sciences (fluids is a very hard part of physics/maths).

6) Applied physics, nuclear research, grand unification, particle/string theorists. These are all post-graduate people and you had better study a lot of physics and have known Calculus for 20 years. Most of these people have advanced physics degrees and at least a masters in maths. This is DiffEQ, Lie Algebra, Symmetry, Geometry, and much much more.

Defining risk levels in Software Development

Risk can be defined many ways in software development. The team itself can add risk when team members do not communicate effectively or choose poor development methods. The build process can add risk when people submit changes late into the development cycle or the review process for new submissions is ill-defined. Lack-of-prioritization or poor understanding of needs can lead to integration of unnecessary changes. This blog is an attempt to address only the code-writing aspect of risk.

First of all, there is always risk any time you add or modify existing software. Many software developers make the claim "I'll just slip in this minor change and it has no risk of breaking anything." With that statement, begins the long march toward finding the bug, coding, testing, and integration. I've certainly broken many builds in my time as an engineer and giving a clear indication of risk to management is nigh impossible.
Many times, as we approach alpha or beta in a project, we are told to only include changes that are low-risk. Without any real metric, we can only use our best judgment as to what is risky or not and even very good engineers get this wrong. My goal here is to define a simple metric by which to measure risk level.
My metric here is defined in a non-TDD environment. TDD changes these numbers, dramatically lowering the risk levels in most cases. These numbers do make a few assumptions and those are:
* working with an existing code base
* multiple programmers working within this code base (more than three)
* a strong dependency on working builds by the rest of the team
The numbers here are a simple ratings system meant to rate the risk of breaking the build by any given check-in that you may be performing. These are based on my personal experience, a bit of intuition, and in a few cases, generalizing some things that vary a great deal.
Here are my risk levels:
1) Same software, modifications to constants still within range. Level one are always very minor, change no behavior, change no loading, does not include additional data, no new constants, variables, etc. Removing dead code (commented out).
2) Same software but actual lines of code modified. This means the rework of one or two functions to add clarity, reveal a latent bug, or to optimize. Removing unused code, unused member variables, and general cleanup.
3) Same software, but major refactor. Consolidation of some common code into a common function called from different places. Adding another function invocation from another location. Changing of a basic type from int to float or something similar.
4) Minor structural changes. Adding files to a project. Changing a project's settings, adding support for additional platforms, etc. Adding enumerations that will be used. Changing ifs to switches or vice versa. Supporting new conditions in an if-else statement. Adding validation code on startup.
5) New basic behaviors with no large changes to existing behavior. New messages added. New queries added. These new behaviors are not coupled to existing functionality. Integrating new files into a project. Moving functionality into or from a base-class. New GUIs inevitably fall into this category.
6) Behavioral changes. Any concurrency changes. Refactoring a class or a major section of code. Callbacks added when a file-write completes, when a db query finishes, etc. Adding or removing coupling between classes, functions, or some hybrid. Adding virtual function overrides. Replacing existing functions with template functions to support cross-platform or cross-build behaviors. Updating a third-party library (this can vary wildly depending on the vendor).
7) Removing existing functionality that is in use or major new behavior. Refactoring classes into a new hierarchy. Introducing polymorphism where it did not exist before.
8) Rewriting a system. New concurrency model. New DB model. Complete rewrite of existing system. The breaking apart of an existing system into small subsystems. Introducing concurrency or removing it, adding callback or signaling, making software work on a new platform, integrating a new third-party library, introducing a new asset system, removing a legacy coupling from existing systems.
As a simple guideline, you can call anything less than level four low-risk, 4-5 medium, 6-7 high, and 8 very high. Each of these ratings simply speak to the likelyhood of unintended breakage or behaviors including side-effects, knock-ons, and misunderstood requirements.
Low risk items here have almost no chance of breaking the build. Medium items are possible to break the build and usually adding a code review is enough to prevent any serious damage. High risk items are those on which no code review can gauge the probable outcome and even unit testing is likely to miss many bugs. Level 8 risk is guaranteed to break something. In fact level 8 risk rarely can be done without some down time while the project recovers from all of the new bugs introduced.
When giving your final assessment, always consider consider CRI:
Composite Risk Index = Impact of Risk event x Probability of Occurrence
C = l * p. This can mean modifying the above numbers. It is best to consider both Impact which is what my system attempts to gauge, and PoO separately so that others can judge the real risk.

Animal displacement pressures

Animals are often being driven from areas that humans find habitable or in some cases, those that humans make habitable. Still the mountains around LA, in spite of tremendous human population pressures, remain relatively devoid of human habitation. But all other land nearby that is even remotely flat is occupied by humans and the occasional possum. Most other complex life forms have been forced into the surrounding mountains, become extinct, or been moved out by ASPCA.

The animals who have survived are now in a new environment. Few of them are naturally hill-climbers, and none of them naturally manage the pollution well. This type of animal displacement can be found in a huge number of urban centers affecting a large number of large mammals and reptiles. Fish have been depopulated to extinction and forced into new climates that are harsher or less accessible to humans. Many prominent scientists and environmentalists are concerned about the large open areas of the oceans devoid of life and how few mountain-lions survive. Yet these examples open up opportunities for other life and complex life living in new areas simply means that life will need to adapt.

The three-eyed frog from the Simpsons is one possible outcome from this animal displacement, but more likely, the mutations and adaptations will be more mundane and prepare these animals for hillsides (not the fish of course), mountains, and deep forests. When the inevitable flooding comes from polar melting and the more flooding on coasts, these animals may be more adapted to dealing with space and land pressures.

Of course, a bunny rabbit that can climb montains like a goat seems odd, but if that works for the bunnies....

Working from home - a game-programmer's perspective

What does it take to work from home?
The first thing you need is to know C++. Don't even bother if all you know is VB. Some other languages are becoming popular like PHP, Python, and even C#, but these are more of an exception than the rule.

Obviously you need a PC and unfortunately a Mac won't do. Rarely will Linux work either so you are normally stuck with Windows. Then you need a compiler: often compilers come with your specialized hardware. Then you need the hardware that it takes for test like an XBox360, a Wii, or whatever. These boxes are not the commercial ones, but specialized hardware that usually have their own compiler and libraries. Your employer will have to give you one.

Discipline
Are you disciplined enough to work from home? This is the main problem with working from home that many programmers cannot grasp. It seems as though when you do program something at home, it goes so smoothly. This strikes at the crux of the problem which is the integration and testing aspects of game programming.

Most employers rightfully assume that programmers have a hard enough time getting out of bed and rolling into work by 10, that relying on them to get out of bed and do more than turn on their computers and log onto the network is nigh impossible. This is because most gamers come from university of in some cases high-school and when they arrive at work, they are little more than their parents "little boy."

Why can't I work from home? It's all just twiddling bits, right?
It is true that at some level, all you are doing is twiddling bits. Still, the act of engineering a game is a lot more than that and involves bouncing ideas off other people, white board sessions, some form of XP, and working with other people. Working alone is only possible on small indie titles anymore like Tower Defense and a mod of Breakout.

This is because the current complexity of most games makes game programing best done as a group exercise. People working alone on games is a rarity these days given what people have come to expect from interactive entertainment. You would be special indeed to be able to create the tools, audio, graphics, animation, gui, networking, gameplay, user interaction, and so on required for modern games.

Theft of IP?
Another major consideration is theft. Large companies, in particular, are worried about employees stealing their code. The comedy of this situation is that all code is basically just text and many solutions are commonly available on the internet as freeware or just part of a blog. That doesn't stop the paranoia nor this strawman argument from pervading the internets and employer consciousness.

Manufacturer Hardware Requirements
Often the manufacturer of a particular piece of hardware (PS3 for example) demand a strict control over hardware. This means that a game programmer probably can't work from home in these cases.

So what can you do?
Sign an NDA with your employer to address the theft issue.
Come into work a few days per week.
Conference calls are available.
Talk to your IT staff and get yourself on remote login because you need to respond to email and be able to checkin code.
Collaborate through good communication mechanisms like design docs, Freemind, and other ways of sharing docs and Ideas. Google docs isn't bad for this sort of thing.
Hardware control can be maintained by showing up at work with your XBox or PS3 once per week and provided that your employer can obtain a hardware control exception, you should be able to move back and forth between your job and home. Unfortunately, this hardware is usually heavy and may be a bigger pain than it's worth.

The decision-maker/team-lead

There is little in life, as an employee, that is more frustrating than management indecision. Have you ever posed one of the following interrogatives? "Why can't the team make decisions and why is my boss not making hard choices?" "We know what has to be done; why can't we get started?"

Making decisions about team direction is never trivial, but it can be made a lot easier by sticking to a few simple principles. When you set up a 'framework' for decision-making and team path discussions, you eliminate most of the possibility of postponement, indecision, and general lack of direction.

Postholes
Our first topic is approval. Getting management approval for your team's activities can be a pain and extrememly time-consuming. Rather than asking about everything that you do and receiving approval on every hour spent and every dollar spent, try to obtain generic approval. Approach your upper management and agree upon the three or four basics for things that are the responsibility for your team. You should be clear about what your team should be doing, but also you should make these definitions as broad as your manager will let you. Be careful taking on too much responsibility.

Once you have this in hand, then you don't need to go to your manager for every task or project than you need to tackle. Don't rely on your manager to set this list of responsibilities for you because he will make them as narrow as possible if you let him. You probably want enough responsibilities to keep you challenged but not be overwhelmed. Your boss, on the other hand, is probably only considering you for a narrow set of responsibilities. Push yourself a little and obtain permission to stretch a little.

Fenceposts
Our second topic is specialization. Why are you on a team and why does that team exist? What differentiates your team from all of the others? What is you team's raison d'etre. Once you have a clear picture of that, making decisions becomes easier. Very few teams exist for one reason so make sure that you have a complete list. If you have more than five or six, you may need to found a new team.

Some suggested specializations could be:

1. Deliver tools to the rendering team.
2. Setup and maintain a pipeline for game assets.
3. Build good repore with all clients.
4. Follow up with all clients on software delivery.
5. Automate everything that interferes with artist workflow.
   

From a list like this, you can easily set priorities, tasks, and decide what comes first. It also makes clear that any extra tasks that are unrelated, but that are requested, are unlikely to be fulfilled.

Slats
Our next topic is ownership. How do you involve people on the team in such a way that promotes high quality, dedication, and ownership? This is very basic: using the principle of specialization (above), hold quarterly meetings with your team to focus on what your team should be doing. Make a whiteboard list and treat this like a brainstorming session. Once you have spent 45 minutes to an hour, start pruning that list with your team right there with you.

You are asking for their involvement and effectively obtaining their permission. You want your team to succeed, so don't take on massive projects. If they are very large, then break those into smaller projects and deliver pieces. This makes it easy to show progress and prove out whatever you are delivering.

Once you have a clear picture of what needs to be done, you should talk it over with your boss to be sure tht these are reasonable goals or if s/he has some surprise project that needs to be done instead or on top of your list.

Nails
Pulling together all of this and making the final choices is your next piece. This involves stewardship. You want the team to succeed. You have all of the people you need supporting you and the last piece of the equation is making choices. The major part of this decision making process is being flexible.

• When starting on a team or at a company, focus on quick wins. This also works well for problem employees.
• Focus on testable or provable deliverables. Being halfway done never counts for anything.
  
• Break all tasks into smaller tasks until you can deliver something in two weeks.
• If a task is taking too long, ask your employee to deliver something smaller.
  
• Be flexible enough to recognize when someone is floundering and help him/her, either directly, or by having that person work with someone else. If it is still not working, give that person a related task to help him/her "work it out" in his/her head.

Stewardship also means following all tasks to completion. You can't just leave things unfinished. Quality is another issue in stewardship, so making sure that the thing delivered is above normal company-quality helps.

Paint
The promotion of your tasks and the accomplishments of the team are the last piece. This is a bit of politicking, but mostly involves promoting the team's accomplishments. There are only a few things to keep in mind when doing this.

• Don't over-promote. When describing accomplishments, avoid words like 'incredible', 'amazing', and 'unbelievable' which undermine the perception of your judgement.
• Don't take credit for other people's work done. This is usually trransparent and pisses off your employees and your bosses. It never does you any credit. You are managing the team's success which is more than enough.
• Eliminate too much detail and simplify any progress report to bullet-points. Only provide detail when requested. I suggest preparing a full report, and then preparing a bullet-point list to match that. The full report is for you; the bullet-point list is for your boss.

Summary
The decision making process can be hard, or it can be easy. By following this methodology, you can ensure that your team succeeds, that your people are happy, that your boss is happy, and that your team is perceived as successful.

Aligning teams

In recent years, I've come to understand the concept of alignment which I now realize is the cornerstone of any productive enterprise. Certainly in engineering efforts, alignment of company ideals, team management, and individuals should mean that everyone is working toward the same team goals. This factor is naturally assumed at all companies because "everyone is on the same page" but the fact is that even well-aligned companies rarely have everyone "on the same page." Alignment comes from communicating ideas, goals, ideals, and needs from top to bottom and back to the top again. The top-down communication is generally assumed at all companies, but the bottom-up rarely is. Basically, fomenting a company philosophy of open-dialog between parties leads to better products, easier work life, and a happier staff.

My intent here is to define alignment in more certain terms and to provide a framework for discussion and analysis.

Alignment
There are several great articles and books on this subject [Strategic Alignment: Leveraging Information Technology for transforming organisations] and these have more to do with "straightening out" IT such that it more tightly meets the business objectives. This involves governance and defining key organizational objectives and filtering those down into the organization such that the IT is transformed. Quoting Wikipedia: Business/IT alignment is an ongoing process that will optimize the relational mechanisms between the business and IT organization by working on the IT effectiveness of the organization in order to maximise the business value from IT.

Clearly this is a little myopic. More and more organizations rely on IT to perform larger slices of their businesses and many companies are built around IT delivering new products, especially IT-based companies (e.g. Microsoft, IBM, Qualcomm). In addition, this concept can be defined more broadly to include other engineering sciences and how they bring value to a company.

Team
A team is loosely defined as a set of people working in an organization separated by a few levels of management from the executive staff. Their objectives are often that of engineering and creative enterprises that indirectly add to the earnings potential of the company.

How do businesses view engineering
Engineering is the lifeblood of most companies shipping products these days and business is beginning to realize that these people are some of the most important people to a company's product-line and long-term growth.

For many engineers in the trenches, they feel saddled with the dogma that IT or Engineering is an expense. Basically, they feel that they exist to suck money out of the company. Few companies would explicitly recognize this fact, but at its basest level, this is the view. This can make engineers feel petty and makes their lives feel futile unless they realize that nearly all employees are viewed in the same light, except perhaps for the CEO and the executive management depending on who you ask. Basically, human capital is an expense and it is generally the most largest part of any company's business expenses.

So, on the topic of alignment, we can already see that an engineer's view of his place in an organization is probably misaligned with that of the leadership team of that organization, the extent to which is defined by that management. There is a lot to be said for companies that respect individuals who pore over tomes of technical specifications attempting to meet some product description or bridge requirement. This leads to better alignment at the onset of a relationship and fosters a mood of "partnership" which we'll discuss in some detail later.

Aligning the goals of the engineers with those of the company can mean that the engineer feels more able to approach management with technical "concerns" helping management to align better with clients. This cycle of communication leads to adjustments to contracts, money changing hands, and better client relationships meaning more future contracts.

Unaligned engineering goals can mean fewer interactions between engineers and management. This often leads to missed deadlines with little or no explanation, products that are poorly designed or don't meet requirements, and broken promises with clients. This nearly always leads to fewer future contracts and less capital.

Incidentally, these concepts apply to a lot more than just engineering.

How engineering views management
This point of view is often fraught with misconceptions. Engineers rarely think of the CEO or the executive staff as idiots, but they often do feel very disconnected with the goals that the executive staff set for the company. Some of the reasons lie with the fact that company execs often view the world in margins and bottom lines while responding to investor concerns. This set of business-related objectives rarely maps well to engineering objectives. In addition, engineering is all about process and planning and what engineers fail to realize is that business is generally all about that too. This leads engineers to believe that they are following more 'noble' principles or at least different ones on a daily basis when in fact, the principles are the same.

In most cases, engineers simply view management as too unconcerned with the engineering concerns to rely on management to help them solve problems. In other words, if managers don't understand, then an engineer often feels too busy to explain it to them. This is part of where misalignment is perpetuated. This is not where misalignment begins however.

Partnership
Making people feel engaged and involved with the decision-making of any company is quite a difficult task. By involving people in multiple discussions, many meetings, and feedback systems allowing them to feedback to management all costs money and does not ship a product any faster.

Let me say this: companies who have put partnership programs in place tend to outperform competitors by large margins. These companies include Apple, Rockwell, Hewlett Packard, and Microsoft just to name a few. Many of these programs aren't great, but their attempts to engage the employees in quality, ideas for improving the business, and money making opportunities all serve to build a sense of partnership. Partnership is one of the many tools for keeping teams aligned and here are a few of those strategies.

• Open team discussions that are brain-storming sessions and everyone must offer something.
• One-on-one discussions every few weeks between team-lead and employee to see what is happening on the shop floor.
• Product improvement incentives.
• Employee rewards programs.

Vision statements
Setting the course for your company is all about providing a "thought framework" allowing people a basis for discussion and a mantra to rally around. Ones that you may have heard are "Quality is job one", "We focus on the customer's needs", and "Why go anywhere else." It also makes clear the company's self view which helps employees align with where they stand within an organization.

A vision statement is the bedrock of a company's beliefs and can be a good set up for planning meetings and other discussions. Having multiple statements is often a bad idea but having one or two company ideals helps keep people aligned with overarching company views and smooths many discussions when employees lose focus on the needs of the company.

In spite of their ability to be trite, many of the motivation posters are positive reinforcement for the expectations that any company has when it comes to setting goals and teamwork. Companies that post a few of these posters around the office in most major rooms build morale and foster collaboration, depending on the posters chosen. Companies should consider which traits that they care to foster and find appropriate posters, mantras, and vision statements to help their teams focus.

Each team should also have a distinct flavor or character from other teams. This may mean another mantra on top of that provided by the company, differently colored jerseys, or even a team name. In any case, most employees fight with the constant personal battle to be part of something larger than themselves, but also to be distinct and team differentiation is one way to make people much more comfortable within an organization.

Engagement
An employee who sees some of his own personal goals as being the same as the company's goals is engaged. This means that the employee has aligned himself to the goals of the company. This is a fairly common occurrence at most companies and certainly worth considering. The majority of employees when starting a new job take a wait and see approach to seeing how the company behaves and whether or not s/he can see himself working there long term. Fostering a sense of engaging the employee and encouraging employee ideas will build better team members, better teams, a better company, and ultimately better products. Not too surprisingly, many engineers find themselves engaged in such a way that they are often thinking about engineering issues outside of work.

The overwhelming majority of employees do not enter into a working contract with any sense of insubordination or malice. Disengagement is one area that breeds feelings of distrust and malice. When employees feel that they are not aligned with the company, even ethically misaligned, the employee can become disengaged and recovery from this mental state is often difficult or even hopeless. If an employee begins to see the company as not serving customer needs, disingenuous in their claims or mantras, dishonest in their dealings, or capricious in their dealings with employees, the employee most often becomes disengaged. These areas fall into a business ethics discussion and are not really part of an alignment strategy, but these kinds of company 'misdeeds' will sabotage any efforts a company may make regarding alignment and "keeping employees on board with the company vision."

Another area that leads to disengagement is fear. Most employees have a certain level of fear built in which usually manifests as respect for superiors and working well with others. Few employees run amok in a company out of this sense, at least at some level. But fear works on even stout minds and eventually creates a fear-engagement. This is a "watch your back" mentality which courses through the company and undermines individuals and entire teams. People lose the ability to create, being too focused on keeping their jobs to do their jobs effectively. The causes of this type of disengagement are corporate bullying, financial losses at the company, the announcement of job cuts, and other factors which affect the welfare of he employee. Often, just seeing a good coworker be fired is enough to disengage the employee.

Defining goals
General goals are easy to define but hard to maintain. Keeping the company's mantra foremost in the employee's minds is never easy and falls along the lines of constant reminding. The basic rule of management is to be prepared to repeat everything you say at least 5 times. With that in mind, there are a few strategies for making sure that the company-wide goals are well understood by all.

Quarterly reviews of employee status is fairly common and this is a great time to repeat the basic company tenets and mantras. This is also a good way to make sure that the employee is attempting to hit that mark and if s/he is aligned with the company goals.

Most business theorists agree that the CEO sets the tone for the company and should speak periodically to remind everyone what the goals of the organization are. These company meetings serve to be a sound board for filtering information down to employees and keeping the company aware of recent developments, recent promotions, cash flow issues, strategies for the company, and the overall goals for the period.

However, an added step that works is to involve employees in these meetings. Home Depot employs this strategy to great effect by a once-monthly meeting called "Breakfast with Bernie". Bernie is one of the founding partners of the company and they utilize a network broadcast to all stores in the company on a Sunday morning. Part of the meeting is dedicated to feeding down status to the entire company. Another part is a Q&A with employees at different stores. A person is chosen from a few stores (usually 2) and a live question is posed to Bernie. This illustrates open lines of communication between upper mgmt and the employee. It also involves the employees creating lines of trust.

Nearly all people know what a goal is. But a goal loosely defined is a goal misinterpreted, particularly in engineering. All engineers are smart individuals, but they cannot know exactly what the intent of management, customers, marketing, and others desire. They will do their best, and they will naturally assume that once they hear the request/requirement as it is handed to them, they understand it. They are usually wrong, of course. The best way to keep everyone working toward the same goals is periodic review and this is where SCRUM can aid us. Keeping clients and engineers talking helps greatly.

Safe to fail
When things don't go well, people can easily fall into the blame game. In fact, this is so common, it is basically an expected human failing. To help keep focused on company goals, discourage the blaming of others for minor mistakes, the harsh criticism of poorly worded emails, and the acrimony that may come from a strangely worded question during a team meeting. We all do these things from time-to-time and while some level of criticism is appropriate, any openly public display of ridicule is likely to shut future doors of communication for all who witness it.

Missed deadlines are a constant source of aggravation for management as they try to mitigate disaster with their clients, yet making this a major source of concern or ridiculing engineers for under estimates will cause them to push away and not offer to do any extra work. Part of being an engineer is dreaming about what can be and making it happen, but engineers often become mired down in the minitue of the integration that they forgot to estimate. Often, effort is underestimated and this is the nature of engineering, but a correct strategy of biweekly deliverables, or partial SCRUM, means that any overages are caught early, that the work is more easily estimated, and that everyone understands what is at stake. This creates alignment upward promoting communication that can easily be managed by team leads, sales staff, and even the executive staff reporting to the board of directors.

Managers who understand the engineering process of requirements capture, architecture, design, implementation, integration, debugging, and maintenance can become a serious partner in the relationship between marketing, executive staff, and engineering. Making a safe-to-fail policy also means not jeopardizing anyone's job due to a missed deadline or failed attempt at a task. Most big gains in the world in engineering come with many failed attempts. This does not mean allowing a bridge to collapse is acceptable, but if early prototypes collapse and computer simulations fail to work, this should be considered part of the process, not the end of an engineer's job.

Flat management structure.
Too many layers: this is the bane of many an engineer. How does s/he communicate with the management staff and feel connected to the goals of the executive staff with so many layers of management? This is a huge problem at most larger companies where at least 3 layers exist between the CEO and the engineer. There are a few strategies for dealing with this issue.

The once a month (or once per quarter) meeting of the CEO to the entire company helps to keep people's minds on the company's goals. Team-related goals that are discussed every few weeks helps to keep employees "on board" with the monthly mention of company goals. The suggestion box can help, but this level of effort is so trivial most people ignore it unless the company is over a certain size.

Letting people approach their boss's boss without question and without retribution is the surest way to guarantee that people can feel that the layers of management are less important to the overall importance of communication within the company. This is a true "open door" policy and allows the sharing of ideas, reevaluation of a review that seems unfair, and even discussions about the communication within the company. Allowing people to leap-frog at least one level of management and encouraging that from time-to-time means that managers are slightly more busy, but that's why they become managers.

Conclusion
There is plenty to say about creating an atmosphere of alignment in your company, but this blog should provide a framework for getting started.

I'll go into fixing your company's broken alignment in my next blog.

Basics of motivating your engineering staff

You're a manager of a small development team. You begin to pose the question: what do I do with these guys? How do I get things done? They are the experts of their respective domains. Who am I to tell them what to do?

Well, one of your major responsibilities is making things happen, but you can't do it all yourself so motivating others is the key to your success. Your objective is three-fold: keep your people coming back to work, have your people get to work and finish things on their own, improve the quality of the product.

There are hundreds of books on management. The styles vary from the mean boss to parenting examples, but the basics can be boiled down to just a few basic principles. These are so easy to do, that it's almost silly, but it'll make your employees happy and make your life easy. It will also make you very effective. I am going to recommend two first steps and then the day to day steps are below.

Pick a mantra. It must align with management so make sure that you vet this mantra with your clients and boss. It may sound silly and it may sound petty to have a mantra, but it really works. Some ones that tend to work are "Service first" or "Our code is tested". If you must pick more than one of these, never pick more than three. Now you have a means to build an organization. Concentrate on fulfilling this mantra and building up the team toward achieving this goal and all of the subgoals that accompany it.

Software is a service. This is easy to forget as a software developer but as long as you are adding value to a company by doing things that other people can't or don't want to do, you are providing a service. Keep service foremost in your team's mind and discussions.

Now the day to day is a bit different: these are the things that will help you build your team into a super team that will make you and them very happy.

• Set the standard. Show people what good looks like. Present acceptable examples of well-tested code that meets the coding standards and is easy to read and maintain. Once people understand the minimum requirements which you've made clear, it makes their lives easy. This also comes down to defining what a design doc looks like, a systems plan, a deployment plan and so on. Beyond code, this can be extended to behavior: never be petty, always be helpful, think about customer service that you like and mimic that, give your people your attention and so on. If you are a good example, they will admire and respect you. If you are asking for quality work, it’s a given that you also would do the same.
  
• Planning. Involve your team in planning. You have a list of tasks and some of them are critical, but many are not so have your team work with you in deciding the direction of the team. They are professionals and so you should respect their ideas and opinions.
  
• Options. Give them some choices. The choices should be as big as possible, but even small choices make people much happier. You have a list of things that should be done, so while you are doing team planning for the next delivery cycle, ask each of them what they would like to work on and assign tasks appropriately. Invariably, you will have someone who may be a bottleneck, so explain to the others that you will need to better balance the tasks so that they all get done. People do understand. If the list of tasks is fixed, maybe you can allow your employees to pick the order in which things are done. Even this small amount of control gives people a better sense of control over their lives and they are way happier. It also gives them a sense of ownership and thus improves quality.
  
• Listen. Listen to your employees. Think of it this way: you are paying these people good money and why? They are professionals. Treat them like professionals and they will act like it. This is where you build your team into a monster of productivity. It will make a huge difference. This means one-on-one meeting for at least one hour every two weeks. This also means a 1/2 hour meeting at least three times per week with your entire team to talk about whatever engineering thing that you think is important. This meeting is critical: you must have it. It forces the team to communicate and everyone hates it, but is solves far too many problems to be avoided. You can talk about team interaction, coding standards, schedules, company politics, or whatever. Also, allow other people on your team to conduct the meetings to talk about what they they are working on or to ask design decisions. Everyone should actively participate. Hand the markers and whiteboard to others.
  
• Focused work. This is a reminder to keep people on tasks and try to avoid too many distractions. You must be a team player and always strive for the betterment of the team and still balance that with finishing important tasks set out a few weeks prior. Your company will want to pull your people into other teams or keep your people busy with other tasks. Just add the latest requests to your task list and tell other people or teams that you will do it as soon as you can. You have a list of tasks and you should be prioritizing these tasks along with your team members. Everything in the world will seem to be a higher priority than what you are currently working on. Sometimes those things are more important but usually, they are just another task that you can put off for a little while. If you are doing SCRUM, then any new tasks will be started within a few days anyway. Allow your people to interact with other teams because this is a necessary part of work and it makes them feel better connected anyway. You aren't trying to hide your people from the company. But avoid the expansion of scope during a sprint (strongly discourage this), and no new tasks - if it can be avoided at all. While this may seem like too much process to some development managers, this is the bare minimum of process that you should enforce. If there is anywhere you can go wrong as a manager, it is most likely to be here. Some of my best programming experiences have been when a manager allows me to finish something before moving on to the next high-priority task. Definitely pay attention to priorities set by other teams but this is up to you so make your best judgment and be prepared to defend your prioritization. Make sure to have time in the schedule for maintenance.
  
• Scheduling. Once someone has picked a task, let him/her pick the schedule. If it will take too long, then break the task up into subtasks and this may reduce the length. Also, remind everyone that this is engineering and that engineering takes time. It isn't up to you as the manager to define how long something takes because you will miss some details in the scheduling meeting. Also, consider the cost of building a test suite for this new functionality and cost of integrating that new code and test suite. There are lots of hidden costs in any engineering exercise. If your people start to take too long, this is where your expertise comes in and you can do some XP and more hands-on. In fact a feature that is taking too long is a great opportunity to get deep into the code yourself. Enjoy it. One more thing: make sure that any task has short-term deliverables (this is a sprint idea); this guarantees that if something is running behind schedule, you catch it early.
  
• Professionalism. Use the word engineering often. This removes a lot of the emotion from discussions and focuses on the tasks at hand. It also adds a level of professionalism. But you've also got to mean it. If you have any doubts about what engineering is, think process and testing. People can tell you how they feel during a regular meeting or in a group, but if you are conducting regular one-on-ones, then they feel no need or they are likely to only talk about professional stuff in a public forum. When you conduct regular one-on-ones and people feel that you are really listening, professionalism just happens automagically.
  
• Task list. Always have other tasks laying around that people can do. Often, someone will get stuck on a particular problem and be looking for a solution. Tell that person to take a break from it and work on one of these lower-priority tasks for a few days and s/he will feel a lot more refreshed having accomplished something. You will also have banged out another task, and only put a small delay on that other deliverable. If s/he is still stuck... you are the manager, help him/her. XP or working together on it is always a great exercise socially and from an engineering standpoint. This list of tasks can also become your plans for future development so that you never sit idle. Maybe, you can work on these when you have time.
• Early behavior correction. Tell people when they make mistakes: do not wait. If it is a minor mess up, you can tell people in front of the team. If it is a medium or serious mistake, pull him/her aside and tell him/her. If you wait more than 24 hours, you are asking for trouble because people forget what they said or why they said it. Good managers course correct their employees immediately. This helps them, you, and all of the other people with whom they interact. Never, never, never berate an employee in front of others and be extremely careful telling your manager about bad behavior of your engineering staff: it could undermine his/her career and make you look bad too. Only tell your manager when attempts at fixing behavior fail.
  
• Give recognition. Never take credit for work done by others. Always give it to the team and to individuals. Everyone knows that you are facilitating the success so you don't need to take credit for anyone else's success. If you do, you disrespect the employee and you are transparent to your managers who will see you as petty. The occasional reward for excellence helps too: tickets to the game, a trophy, an airsoft gun, or whatever.
  

That's it. If you can do these and stick to it, stay consistent, and be respectful, all of your worries about management will magically disappear (well, almost). Your employees will keep coming back to work because people listen to them, respect them, and they feel more professional at work. The work getting done just happens because they have ownership over their tasks and they respect the work being done. The professionalism aspects improve quality.

Good luck.

Why insects fly around a light at night

I figured this out by watching their behavior under unusual circumstances, but is goes like this: insects move toward a light source attempting to "find the way out". They most often don't know the difference between day and night (some insects clearly do) except for the amount of light available. When in a garage that has the door closing, they will fly toward the available light for a way out of the garage. The same is true of a cupboard, a closet, or what have you.

In the case of a light bulb, they are simply doing the same thing that a buzzing fly attempts to do as s/he busily bounces off of the glass of your indoor window: s/he is repeatedly trying to get outside to where the light and warmth are. It's kind of funny really, but they just want outside and if they can just find a way through that little crack in the glass of the lightbulb, they can make it outside.

Just my 2¢.

Why women are better at communications and social skills and why men are better at math and sciences

First let's dispense with the idea that women and men are all that different at anything. There is a much bigger gap between an average male and a below average male in mathematics than there is between an average male and an average female. The same goes for science and the opposite is true for communication and social skills.

Secondly, let's look at what the difference is. A few studies show that men are, on average, around 3% better than women at math and science, and that women are better, on average, by the same amount in communications and social sciences. These differences are small (almost minute) and simply do not account for the differences in the number of science and math papers published by men or the psychology papers published by women. Also, this does not account for the differences in other areas like linguistics, a very technical area, chemistry, and biology.

While the number of graduates from university now favor women (around 70% of graduates from post secondary education are female in 2006), the record shows that women are poorly represented in papers, journals, and in the sheer number of major discoveries in math and sciences. So why is it that more women are now graduating from university than men and yet they aren't surpassing men in these areas which usually require higher education.

The biggest thing that we need to consider is disposition. Men are more interested in cars, computers, and non-human things: usually things of a mechanical nature. Women are more interested in people, social hobbies, and things that are social. Secondly, a socialization that more women have to sitting around talking about personal matters is part of this equation. People are interesting and women definitely gravitate toward the study of people. Men gravitate toward things that could be considered anti-social or things that prove their manhood (sports, fishing, and so on). Obviously, these generalizations are somewhat silly, but sadly, there is a lot of truth to them. In the grand scheme of things, the mad male scientist hiding away in his lab is a more acceptable stereotype to us than the mad female one. This is the cultural side that also influences how women view the world. Here is a recent article from New Scientist discussing this aspect: Link

One more note about disposition: many of these traits are linked to needs of the species. The male, in order to prove his manhood, must stand out from others and is thus competitive with his peers far more often than females. We find this type of behavior strongly favored across the spectrum of animals. Most Western and Far Eastern societies discourage these behaviors and we are slowly seeing the diminishing of males in scholarly pursuits. This has been widely documented in recent decades. This competitive behavior leads men to pursue simple things like chess far more often than women (see previous link). It also leads to Math leagues, Physics competitions, and so on. There are few, if any, French competitions, History leagues, or Economics debate clubs in Western Education. The result is that boys shy away from these fields, Economics being excepted. There is no better way to interest a male in a subject than to make it competitive.

Females, by contrast, favor teamwork and group success over self pursuits. The result is obvious. They build stronger families, by contrast, and they often have larger circles of friends. They are often the nucleus of any community and they maintain strong bonds of friendship throughout life. Recent studies say that this is a major factor in female longevity and another reason that widows live well for many years while widowers most often die within a year or their spouse's demise.

We'll continue to examine the differences in men and women from a lot of different directions, but I will argue that we need look no further than the corpus callosum. The reader may reference this brain structure definition here: http://en.wikipedia.org/wiki/Corpus_callosum. Let me offer this simple metaphor: the corpus callosum is the network allowing both sides of the brain to communicate. In men, this network is overall larger than in women, but the splenium (part of this network) is larger in women. We are neglecting individual differences because given any male, his corpus callosum may or may not be larger than any given female. Still, the averages persistently show differences in size of these two regions. Let me emphasize that these differences in size are very small. Keep in mind that disposition is just as important as any physical differences may be.

Before I go off the deep end, and earn the ire of millions of women everywhere, keep in mind that in the hind portion of the corpus callosum (the splenium) is larger in females. This area is not necessarily related to communications of any particular type, but because it is the thickest portion of the corpus callosum, it has the "densest layer of communication" between the brain hemispheres. So, in a way, women have a larger corpus callosum, but not overall. Another thing to consider, albeit with little empirical evidence, is the physical location of the splenium in relation to the brain structures normally associated with math, science, music, and linguistics: the left temporal lobe. The splenium is not close to the left temporal lobe and may not facilitate any communications between the left and the right hemisphere; this seems unlikely, but at the very least, communication through this brain structure is not as great as through other parts of the corpus callosum.

For the sake of science, let us ignore overall brain size. The brain size in males is slightly larger than females but many studies have concluded that brain size makes no significant difference as to the overall cognitive abilities of anyone. The quality of the connections has long been recognized as the major contributing factor to the quality of cognition and/or thought. With this handy knowledge in tow, we can march toward our goal: with the corpus callosum as the major network of cells and dendrites allowing the brain hemispheres to communicate, is it any wonder that at the highest levels of math and science intelligence, we find men. Toward the midbrain and hind brain, we tend to find socialization and thus women are clearly leaders when it comes to social skills like psychology, teaching, and salesmanship (ask any automart who their best sales people are). This is no way implies that either men or women are superior... in fact I might argue that women have the most social advantages in life while men make the best mad scientists (comedy is intentional here).

A recent book called Outliers discusses the effects of a small advantage given to someone over time. It discusses financial advantages, birthdates, and other matters which seem to provide no clear advantage to anyone, but in the year-after-year way that life works, these accumulate to be huge advantages. It discusses how people born before certain dates have more chance of succeeding at university because those date are close to 'cut off" dates that are required for children entering school at the ages of 5. The small advantage given to children early on accumulate over time to make major differences in adulthood.

The physical argument goes something like this: while the differences in math and science intelligence are very small, the long-term effects are gargantuan. The other factors of disposition and social pressure contribute to this and provide men an enormous advantage in maths and sciences at the highest levels over the very best women. This same advantage is afforded women in sociability, salesmanship, and teaching where the very best women are far superior in these areas of life than the very best men.

So, in conclusion, let me say this: a boy locked in room playing with his computer (more likely a video game) is common and a girl playing dress-up with her dolls and barbies is common. We can try to change the nature of humans, but I believe that it all comes down to the corpus callosum.

This blog is more food-for-thought than anything else. I don't prove very much of this but most of it is widely available information and long-since proven. I’d love to hear your feedback, positive or negative (of which I expect plenty).