How long can people live?

One thing that is often overlooked when considering human longevity is brain cell death. The brain loses roughly 10K neural cells per day. These neural cells do not regrow and there is at present no way to restore them.

link

Quote: "show a consistent decrease in the volume of the brain after about age 40. It is likely that this “shrinkage” derives much more from the loss of white matter,"

So, by the age of 80, the typical person has a brain mass similar to that of a young child. Even if you lived forever, your brain would eventually peter out.

There is some hope for regeneration through the hippocampus and the subventricular zone: http://en.wikipedia.org/wiki/Neurogenesis

The hippocampus is widely known to have regenerative cells but the subventricular zone was not understood until recently. Still, these have almost no impact on storing memory, so in the sense that they would prevent you from losing cognitive function, they are worthless. To use a networking analogy, the hippocampus is like a router and it is periodically replaced when it goes bad (cells die) but the network on which it resides is losing computers everyday. Eventually, the router will be around, but all of the computers will die.

"Neurogenesis is substantially reduced in the hippocampus of aged animals, raising the possibility that it may be linked to age-related declines in hippocampal function. Given that neurogenesis occurs throughout life, it might be expected that the hippocampus would steadily increase in size during adulthood, and that therefore the number of granule cells would be increased in aged animals. However, this is not the case, indicating that proliferation is balanced by cell death. Thus, it is not the addition of new neurons into the hippocampus that seems to be linked to hippocampal functions, but rather the rate of turnover of granule cells."

This is basically saying that cells regrown in the hippocampus have no function other than hippocampal function and thus aren't useful for repairing the damage caused by aging.

Regarding the SVZ, "... the SVZ can recover itself following mild injury, and potentially provide for replacement cell therapy to other affected regions of the brain." This is a great area of research, but so far as we can tell, this has very weak restorative abilities. We do have hope that these stem cells can be used in therapy.

There is hope for using stem cells and restorative techniques. But at present, brain cell death is a byproduct of living. In speaking with researchers on this matter, many estimate ~130 years for over 50% of your brain to be dead. This is a lot longer than most people live, but their cognitive abilities will have declined to a point to make the exercise dubious.

Eventually, your brain would die entirely, but I suspect in a non-linear fashion. You do need a certain 'critical mass' to do things like language and math puzzles and once you decline to ~30% remaining mass, you would probably lose all ability to do even basic problem solving.

I think that we all wish that there were a way to regenerate cells in the brain more readily.

Keys to successfully changing careers

When changing careers, there are a few keys to success. I have based this blog on a person who wanted to change his career to a producer/artist working in the games industry. These rules apply for any major career change.

1) Learn the language of the new role. Live it speak it, understand it deeply and be guaranteed that even though you thought you knew every conceivable term related to that field, that you've probably only learned about half. Be comfortable with that and you might make it through the first interview (probably not, but by the third or fourth, you'll be OK).

2) Learn about key players in that industry. You must know the names of a few movers and shakers and some details about what they've done. John Carmack - made Quake and Doom, John Romero - helped Carmack on Quake and Doom and formed IonStorm, etc.

3) Put together a portfolio and you should be able to demonstrate a basic skillset.
For producers, it's schedules, planning, Gantt charts, and deep knowledge to waterfall and scrum. Better know how to navigate politics, manage expectations, and motivate.
For artists, its pointillism, texture mapping, animation, Maya, 3DS, Poser, and ZBrush. Better know how to sketch, do environments, model a creature.

4) Tailor your resume to closely match the career you are seeking. You have done work before and if you have done anything that looks like producing or art, put that on the resume. If you do it right, you could end up looking like you've built a career on what you want to do. DO NOT BE DISHONEST. Making things up will hardly ever work and earns you a bad rap with people who will never hire you later. But be interpretive with your accomplishments and you'll probably find something in there that matches the job you want.

5) Read everything that you can on the topic. Blogs, Gamasutra, the Maya help page, management books (I recommend "Growing Great Employees" and "Good to Great")... everything you can... stay focused on the goal.

6) Stop saying "I wanna be a ..." and start saying "I am a ...". Play act the role (this is highly recommended) by yourself or with a SO or friend... this is called visualization. Imagine yourself doing this job everyday. Then try to imagine the hard parts of that role... what would really suck to be stuck with doing? (firing people, doing art for some porn game). At the end of the day, this is a job and we all live for the 10% interesting stuff where 90% of the stuff at most jobs is just stuff to do.

7) Create a linked in profile and update it regularly when you feel that you've acquired new skills.

8) Profit

Good luck

Success is all in the question

[Chicago Tribune, Sept 23, 2010, Robert Pagliarini] (I quote this here because the article is likely to disappear. I completely agree with the sentiment of this article. Now if we could only get this idea out into the world for everyone to read...)

Wondering why you can't get a job, lose weight or save money? Maybe you're asking the wrong questions.
"Why can't I get a job?" "Why am I always so broke?" "Why can't I lose weight?" These seemingly valid questions can wreak havoc on your life and your success. Whoever first said, "There are no bad questions," was dead wrong. If you want to get a job, make more money, lose weight or achieve any other worthwhile goal, it's time you start asking better questions.
The problem with these kinds of questions is that you will either find or fabricate answers to them. You'll scour your past and present to find proof for why you can't get a job, are always broke, or are overweight. Worse yet, if you can't easily discover any legitimate reasons, you'll create some. Either way one thing is certain, whatever you ask you will answer, and often your answer will lead to more problems.
Here's an example of how this works in action. Let's say you've been unemployed for six months and you just received another rejection email. "What's wrong with me?" you ask. "Why can't I get a job?" "Why is everyone else so much better and more qualified than me?" Consciously or unconsciously you will find answers to these questions. "I must be bad at interviews, have a weak resume or be a poor communicator." Often this line of questioning will not only discourage and frustrate you, but it can lead to a self-fulfilling prophecy wherein you sabotage future interviews.

A much more effective strategy is to ask solution-focused questions. Instead of, "Why can't I get a job?" the following are much better questions because they lead directly to solutions:
-- What can I do to make a positive and lasting impression during my next interview?
-- What would I have to do to get a job in the next 30 days?
-- How can I become more qualified than any of the other candidates?
-- What other skills do I have that I can emphasize to make up for my lack of experience?
-- What five things can I do to stand out from the 100 other applicants?
Can you see how asking these kinds of questions will lead to dramatically different answers and results? Asking, "What can I do to get a job?" versus, "Why can't I get a job?" isn't just a play on words or the latest pop-psychology power of positive thinking trick. It's an effective strategy to solve a problem because when you start asking solution-focused questions, you tend to start finding solutions

If you're thinking that solution-focused questions are not only effective for shifting your own focus but helping others find positive strategies instead of more problems, you get a gold star. Last week I received an email with not-so-great news. I immediately typed the reply "What's the problem? Why isn't this working?" Just before I was about to hit the Send button I realized that these were terrible questions that would focus the conversation on what wasn't working instead of what might work. I changed my reply to simply, "Wonder what we need to do ..." Guess what I received back. Yup. Some great solutions and ideas to turn things around that NEVER would have been discussed had I sent the problem-focused question.
The challenge is that most of us have been asking problem-focused questions for years or even decades. The solution is to become more conscious of your questions. The next time your automatic response is, "Why isn't this working?" become solution-focused and ask, "How can we make this work?"

If you need some added inspiration, wear a rubber band on your wrist. Every time you ask a problem-focused question, give yourself a snap and rephrase the question. It might take a few days or even weeks to break the habit, but, before long, I guarantee that you will have a bruised wrist and a lot fewer problems.

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.

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.