Persons are the most important factor: one can do a thousand things; two can do ten thousand
Programmer Pyramid
Within a given population defined by a complex skill, the distribution often appears extremely skewed. In American Football, a few quarterbacks stand above the other professionals. In business, a tiny group of CEO's make far more money than others. Similar distributions occur with programmers. The typical programmer is average, and the good programmers are three times more effective. The better programmers again are three times more effective, and the best are another three times more effective. In other words, the best programmers are 27 times better than the average. The best produce more code of higher quality in a shorter time. At the bottom of the pyramid are programmers whose presence reduces the effectiveness of others.
The high level of effectiveness often defies simple comprehension. A wise person questions how such a ratio can exist. Can one programmer really produce 27 times more code than an average programmer? The answer is yes. When amazing advances occur, often a small group is responsible. The small Hewlett Packard Language Lab outperforms the the mammoth IBM Language Lab. The hiring practices influence the success. Another example: the five programmers at The Federated Group had more functional modules of higher quality than the hundreds at Circuit City or at Silo. (Price-Waterhouse was the common DP auditor of all three businesses.) example102. See Successful Teams
The history of computer science is punctuated by the extreme accomplishments of a very few
The first factor in extreme success usually stems from personal attributes and skills: The top programmers are truly the top. A few people have criticized this list because it contains physical skills as well as mental; programming is not only cerebral:
The second success factor is chemistry. More than once, a great programmer has failed the first interview. At Home Savings, Mike Moffett had read an article about retrieving the values of local variables after the function ends. (In theory, such variables disappear, but in reality, they survive temporarily on the top of the stack.) Mike asked the author to apply for a position. Then Mike had a heart attack, and the interviewer who took over did not understand the author or his methods. So, the interviewer declined to hire and the author went elsewhere. When Mike returned, he was frustrated that his replacement was technically incapable and failed to hire the author.
Another great programmer simply lacked verbal skills; he relied on referrals because he interviewed poorly.
The interplay of ego can greatly affect chemistry, and thus success. Ron McMichael was ever so humble and very successful. Vlinki, too.
The exact chemistry is hard to define or to predict; more than once, I have seen a great programmer fail in one company and thrive in another. More than once, a great programmer has moved on after becoming weary of arguments. Poor designs, hypocritical policies, testing practices or lack thereof, or lack of visible philosophical progress have all been deal breakers. The best programmers might seem like perfectionists, but often arguments against programmers arise out of pride rather than logic. We the managers listened to the buss words of the sales rep....
Similarly, groups might vote on policies, but do the members of the truly know what is best. When adopting a new data base, one shop voted for Ingres because supposedly Ingress had data tables of unlimited size; Oracle only allowed 2 billion records per data table. The business had 20,000 customers and a couple million transactions. Those voting for Ingres could not describe the addressing algorithm, but unlimited must be better than 2 billion, or so they said. Some shops are doomed to repeated cycles of failure.
The third success factor is collaboration. Once collaboration begins effectiveness further increases. Where each solo programmer might produce a unit of work per day, collaborators might produce 2.4 units of work per day together. At one shop with thirty some programmers, four when asked to write a report took less than twelve hours spread across three days; others took more than six entire days per report. The fast programmers co-operated with each other and the users out of respect quickly fulfilled requests for clarification. The users liked working with the fast programmers but not with the others. This begs the issue of the definition of a unit of work. Among the best programmers in good shops, the weekly output dwarfs the output of poor shops. If poor programmers have too much sway, the shop suffers; cleaning up the shop poses big challenges.
Whether it be chemistry or collaboration is hard to tell. A shop of about twenty people had a new director appointed from outside. He quickly hired three assistants; two were greatly not favored by the staff. The four mandated that each programmer do his own work; talking was minimized. From about month six and for the next three years, about one programmer left each month starting near the best. Hiring did not keep up with leaving. Finally, the corporation decided to move the shop out of state after being in California for decades.
In another failure of management, a supplier to General Motors had several un-ethical managers; they connived to keep certain bugs in programs; they refused to adopt modern methods. Ultimately, when a good programmer left, GM called the programmer and asked why, Subsequent research revealed how that one version of a program might fix a bug and the next version would restore the bug. The contract with GM was not renewed and many lost jobs. Lisa Perichelli was an excellent contact at GM.
Sometimes the collaborators have similar skills, like ingenuity. Other times, one collaborator has ingenuity and the other has precision; the latter reduces the errors of the former and gives the former a sense of safety. Often an average manager fails to understand the daily success of the collaborating top performers; he asks "why do those guys talk so much; they act like they are having fun."
The fourth success factor is superior design. Top programmers choose excellent first versions, and which enable re-work and maintenance. These version follow pre-defined. shop paradigms. The best programmers are not renegades, though they often write the rules. Jack Howard wrote several thousand lines of Pascal in a short time; his superior algorithms caused wonderful changes in COBOL, BASIC, and SPL programs.
The fifth success factor is prolific production. Their speed of typing, their good first guesses, their organizational skills and memory, and their low error rates combine to create quickly large amounts of good source code. Demonstrations occur sooner. Tests occur sooner. Errors are corrected early in the process. This factor might seem to raise a circular argument. Munson Management was not sure that they should hire Gavin Scott; why he did not even drive a car; what could he do? A senior mentor suggested scanning the source code to look for author=GS. Surprisingly, as a student trainee, Gavin had written code in several important programs. He went to become one of Munson's technical gurus.
Another oddity about such precocious performers is the inability of average managers to identify and hire the best programmers. Even when a manager by luck hires a top level programmer, the manager may fail to understand the top performer and the top performer moves on. In shops that emphasize democratic principles more than wisdom, the majority may outvote the top performer, and the top performer can become isolated.
The high level of effectiveness often defies simple comprehension. A wise person questions how such a ratio can exist. Can one programmer really produce 27 times more code than an average programmer? The answer is yes. When amazing advances occur, often a small group is responsible. The small Hewlett Packard Language Lab outperforms the the mammoth IBM Language Lab. The hiring practices influence the success. Another example: the five programmers at The Federated Group had more functional modules of higher quality than the hundreds at Circuit City or at Silo. (Price-Waterhouse was the common DP auditor of all three businesses.) example102. See Successful Teams
The history of computer science is punctuated by the extreme accomplishments of a very few
The first factor in extreme success usually stems from personal attributes and skills: The top programmers are truly the top. A few people have criticized this list because it contains physical skills as well as mental; programming is not only cerebral:
- good typing skills
- either excellent memories or good organization
- focus and persistence
- fewer re-writes
- good first guesses and excellent second guesses
- abstract thinking
- thinking by analogy
- prototyping
- minimal or hidden ego
- energy and focus
- reasonable physical fitness
The second success factor is chemistry. More than once, a great programmer has failed the first interview. At Home Savings, Mike Moffett had read an article about retrieving the values of local variables after the function ends. (In theory, such variables disappear, but in reality, they survive temporarily on the top of the stack.) Mike asked the author to apply for a position. Then Mike had a heart attack, and the interviewer who took over did not understand the author or his methods. So, the interviewer declined to hire and the author went elsewhere. When Mike returned, he was frustrated that his replacement was technically incapable and failed to hire the author.
Another great programmer simply lacked verbal skills; he relied on referrals because he interviewed poorly.
The interplay of ego can greatly affect chemistry, and thus success. Ron McMichael was ever so humble and very successful. Vlinki, too.
The exact chemistry is hard to define or to predict; more than once, I have seen a great programmer fail in one company and thrive in another. More than once, a great programmer has moved on after becoming weary of arguments. Poor designs, hypocritical policies, testing practices or lack thereof, or lack of visible philosophical progress have all been deal breakers. The best programmers might seem like perfectionists, but often arguments against programmers arise out of pride rather than logic. We the managers listened to the buss words of the sales rep....
Similarly, groups might vote on policies, but do the members of the truly know what is best. When adopting a new data base, one shop voted for Ingres because supposedly Ingress had data tables of unlimited size; Oracle only allowed 2 billion records per data table. The business had 20,000 customers and a couple million transactions. Those voting for Ingres could not describe the addressing algorithm, but unlimited must be better than 2 billion, or so they said. Some shops are doomed to repeated cycles of failure.
The third success factor is collaboration. Once collaboration begins effectiveness further increases. Where each solo programmer might produce a unit of work per day, collaborators might produce 2.4 units of work per day together. At one shop with thirty some programmers, four when asked to write a report took less than twelve hours spread across three days; others took more than six entire days per report. The fast programmers co-operated with each other and the users out of respect quickly fulfilled requests for clarification. The users liked working with the fast programmers but not with the others. This begs the issue of the definition of a unit of work. Among the best programmers in good shops, the weekly output dwarfs the output of poor shops. If poor programmers have too much sway, the shop suffers; cleaning up the shop poses big challenges.
Whether it be chemistry or collaboration is hard to tell. A shop of about twenty people had a new director appointed from outside. He quickly hired three assistants; two were greatly not favored by the staff. The four mandated that each programmer do his own work; talking was minimized. From about month six and for the next three years, about one programmer left each month starting near the best. Hiring did not keep up with leaving. Finally, the corporation decided to move the shop out of state after being in California for decades.
In another failure of management, a supplier to General Motors had several un-ethical managers; they connived to keep certain bugs in programs; they refused to adopt modern methods. Ultimately, when a good programmer left, GM called the programmer and asked why, Subsequent research revealed how that one version of a program might fix a bug and the next version would restore the bug. The contract with GM was not renewed and many lost jobs. Lisa Perichelli was an excellent contact at GM.
Sometimes the collaborators have similar skills, like ingenuity. Other times, one collaborator has ingenuity and the other has precision; the latter reduces the errors of the former and gives the former a sense of safety. Often an average manager fails to understand the daily success of the collaborating top performers; he asks "why do those guys talk so much; they act like they are having fun."
The fourth success factor is superior design. Top programmers choose excellent first versions, and which enable re-work and maintenance. These version follow pre-defined. shop paradigms. The best programmers are not renegades, though they often write the rules. Jack Howard wrote several thousand lines of Pascal in a short time; his superior algorithms caused wonderful changes in COBOL, BASIC, and SPL programs.
The fifth success factor is prolific production. Their speed of typing, their good first guesses, their organizational skills and memory, and their low error rates combine to create quickly large amounts of good source code. Demonstrations occur sooner. Tests occur sooner. Errors are corrected early in the process. This factor might seem to raise a circular argument. Munson Management was not sure that they should hire Gavin Scott; why he did not even drive a car; what could he do? A senior mentor suggested scanning the source code to look for author=GS. Surprisingly, as a student trainee, Gavin had written code in several important programs. He went to become one of Munson's technical gurus.
Another oddity about such precocious performers is the inability of average managers to identify and hire the best programmers. Even when a manager by luck hires a top level programmer, the manager may fail to understand the top performer and the top performer moves on. In shops that emphasize democratic principles more than wisdom, the majority may outvote the top performer, and the top performer can become isolated.
The following programmers excelled in productivity or ingenuity or precision.
Ira Baxter -- ingenious and theoretical
Curtis Stevens -- prolific and persuasive
Gavin Scott -- precise and quick
Doug Larson -- 'perfect' code and thoroughness on-time
David Doyle -- started Quest Software: what more need be said
Bruce Tobak -- highly skilled and detailed
Robert Green -- Suprtool Founder and insightful
Ron McMichael -- conscientious compulsive completer; a great teammate
Bruce Jaranek -- librarian and QA
Jack Howard -- Mr Perfect wrote pretty, error-free code promptly
Mike Tedford -- I just did it; I did not know it was difficult
Bob Guhl -- Well, I don't know. I will get back to you tomorrow, and he always had a good answer
Steve Sternitzski -- the original librarian and teammate with Ira and me
Success is the Best Teacher
Thomas Edison learned a lot of ways not to make a light bulb, but his success brought him profits, which paved the way to further successes. Great scientists learn more from each other's successes than from failures. The programmers in the list above are known for successes and not known for their failures. Repeating the steps of a success has hope of repeating the success. Success belongs to a narrow path; in programming, a statement has many wrong variations and few correct variations. Successes make money and money greases the machinery. Failures consume and destroy. The power of successful techniques rapidly improves a shop, but poor techniques rob in secret. See Semi-Interpretive
Praise and Promote
When a programmer succeeds, praise the programmer. When a programmer performs well, promote the behavior. If you are a manager, then you likely have good people skills and good organization. When a programmer exhibits good skills, encourage more of the skills. A lot of good cooking might help a programmer flourish, but a tiny dose of cyanide is deadly. Natural competition among low level programmers seems more prevalent and destructive than among better programmers. Sometimes, the manager must alter bad behaviors. Excessively loud music by definition is excessive. When the manager expects rancor, the manager should consider limiting the kinds of criticism. For example, in a code review, the manager might declare that a few kinds comments are appropriate for that day.
The 15 Minute Rule
When I have managed groups of programmers, during normal circumstances, I assigned at least three tasks to each programmer. One task was primary and the others were less important. If the programmer happened to stall for more than 15 minutes on the first project, then I expected the programmer to switch to one of the lesser tasks. If the programmer became stalled on all three tasks, then the program was expected to find me or the project leader. We usually would resolve all the stalls and progress resumed. Sometimes I had to work along side the programmer because I realized that there was a lack of understanding; sometimes I had made an error in the spec. Concurrently with the 15 Minute Rule, I checked in with each programmer at least once each day.
Fruitless Labor
When a programmer is stalled, hours of fruitless effort are a waste; there is no heroism in fruitless labor. On a manufacturing task, the programmer should never spend more the fifteen minutes going down rabbit trails. If some aspect of his assignment is not familiar, the programmer must ask the team. If the team does not know, then something is very wrong. Maybe a bad spec. In some cases, there is menial, boring, repetitious, even failure filled work. More than one good programmer has told me something like "one of these 32 combinations is the answer." And, each combination took part of an hour. Finding the correct configuration for hardware can bring about this situation. But that work is finite and rare. If the effort fails, then the team must scramble or abandon; or the manager must authorize the purchase of a solution.
Handling New Ideas
Inventing during manufacturing can cause confusion and leads to inferior products. The specs should contain correct solutions. As the task continues, the programmer might envision a new or better method to satisfy some functional need. The programmer should bring such ideas up during design reviews. A beneficial new idea might lead to a change in the project, but only after mutual approval, and then the actual changes should occur within maintenance tasks of the retrofit variety. These retrofits contribute to the list of secondary and tertiary tasks. A really good new idea might lead to a change to a paradigm or a shared library, and that change would occur during a research project.
Manufacturing is Profitable
Contrary to some popular notions, general programming is not creative. General programming should be like manufacturing, and it should produce rapidly and on-spec and on-time. Shops make money thru improved sales or thru reduced costs in other departments. Cute code is not necessarily profitable. The typical shop only needs a small number of paradigms. The shop might have hundreds of programs, and they should fall into only a few categories or paradigms. The manager must teach the programmers or at least expose them to good influences, which might be another programmer who has certain skills. In the market of 2015, some would argue correctly that no one person can know every fact.
Splitting the Project in Two
In theory, there should be no significant reasons for the stalls because we thought we had removed all of the black holes. If ever we discovered a black hole after we started programming, we stopped and re-grouped. Sometimes a programmer has to conduct simple experiments. For example, when formatting HTML, the different browsers render the same code differently. The programmer might need to make a few guesses. However, there comes a point when the guesses yield no uniform results. At such points, the stall becomes a black hole and should be removed from the project. The first implementation might render correctly on only one browser. The programmer should be working on a research project or a manufacturing task. After the research yields a result, the manager can insert the result into the specs for the manufacturing project or trim the project if the research fails. The programmer needs success, and that might mean splitting the project intelligently after the project begins.
The Good Manager Knows
When I was the manager, I still did significant portion of the programming. I learned the technology; I learned the business.
Programmers are People
The personalities and skills of programmers vary. Yes, I try to hire the best, but usually some programmers already work for the company. Some excel at research; some at coding; some at testing or documenting; some at implementation. While it might be noble to train all the programmers in each facet of the shop, it is much more pragmatic to let programmers work on the tasks which match their skills and efficiencies. Ron McMichael and Bruce Juranek were the QA kings at their respective jobs. Virtually all the software flowed thru them.
People Need Friendly Reminders
There is so much to know in a typical IT shop that no one knows everything. Even the sharpest programmers need reminders. We lesser programmers forget some of the details, especially when there is a large array of tools and when daily decisions are not yet written. So programmers ask questions of each other. A two minute question and answer that eliminates a stall is worthwhile. Most programmers reach a good balance between solo work and team work. For certain tasks, some programmers find collaboration more productive than solo work.
Thursday Deadlines at Noon
Mondays can be hectic. I preferred Tuesday noon for deadlines of small projects and Thursdays for large projects. Most of the time, the final deadline was anti-climatic because we had already made many intermediate deliveries. On the rare occasion of a mistake at noon Thursday, we had a long time before the week end to make adjustments.
Friday Fun Days
When we were successful as a group on Thursday, I let each programmer choose a small task to work on during Friday afternoons. The task should entail no more than 12 hours, which is three afternoons. Sometimes a programmer chose a research task. Yes, good programmers like being rewarded with more work. Other Fridays, having suffered a setback, we would gang up on a roadblock. We wanted to eliminate stressful thoughts over the week end. Sometimes the 'best' programmer had to help the 'worst' programmer. We overcame.
The Wiki
We know that certain principles prosper; we need to discuss them and agree to them in word and in deed. Use the wiki to publish those principles. We spent several hours discovering a configuration for a device; publish it. We lost two hours because we chose a bad sequence of steps within the IDE; publish. We want standard patterns; publish. A program crashed and displayed an unusual error message; we published.
The wiki should display information about all major strategies, about techniques, and about important but seldom executed tasks.
The wiki should have common spaces and personal spaces.
Flexible Hours
Hours do not flex; time marches on, but this euphemism describes the practice of allowing workers to have variable starting and stopping times. Many years when I had two jobs, one started early in the morning and the other started during the mid-afternoon. When I worked on the far side of Los Angeles, the work day started about 10 am and finished about 7 pm. When on a role, I sometimes worked thirty hours straight. For Ken Williams at APU, we worked 43 or 45 hours per work, and he allowed us great flexibility. We dealt with funerals, sick kids, and car repairs, and then worked compensating hours; if a sports team was in a championship game, we followed him to the field.
Curtis Stevens -- prolific and persuasive
Gavin Scott -- precise and quick
Doug Larson -- 'perfect' code and thoroughness on-time
David Doyle -- started Quest Software: what more need be said
Bruce Tobak -- highly skilled and detailed
Robert Green -- Suprtool Founder and insightful
Ron McMichael -- conscientious compulsive completer; a great teammate
Bruce Jaranek -- librarian and QA
Jack Howard -- Mr Perfect wrote pretty, error-free code promptly
Mike Tedford -- I just did it; I did not know it was difficult
Bob Guhl -- Well, I don't know. I will get back to you tomorrow, and he always had a good answer
Steve Sternitzski -- the original librarian and teammate with Ira and me
Success is the Best Teacher
Thomas Edison learned a lot of ways not to make a light bulb, but his success brought him profits, which paved the way to further successes. Great scientists learn more from each other's successes than from failures. The programmers in the list above are known for successes and not known for their failures. Repeating the steps of a success has hope of repeating the success. Success belongs to a narrow path; in programming, a statement has many wrong variations and few correct variations. Successes make money and money greases the machinery. Failures consume and destroy. The power of successful techniques rapidly improves a shop, but poor techniques rob in secret. See Semi-Interpretive
Praise and Promote
When a programmer succeeds, praise the programmer. When a programmer performs well, promote the behavior. If you are a manager, then you likely have good people skills and good organization. When a programmer exhibits good skills, encourage more of the skills. A lot of good cooking might help a programmer flourish, but a tiny dose of cyanide is deadly. Natural competition among low level programmers seems more prevalent and destructive than among better programmers. Sometimes, the manager must alter bad behaviors. Excessively loud music by definition is excessive. When the manager expects rancor, the manager should consider limiting the kinds of criticism. For example, in a code review, the manager might declare that a few kinds comments are appropriate for that day.
The 15 Minute Rule
When I have managed groups of programmers, during normal circumstances, I assigned at least three tasks to each programmer. One task was primary and the others were less important. If the programmer happened to stall for more than 15 minutes on the first project, then I expected the programmer to switch to one of the lesser tasks. If the programmer became stalled on all three tasks, then the program was expected to find me or the project leader. We usually would resolve all the stalls and progress resumed. Sometimes I had to work along side the programmer because I realized that there was a lack of understanding; sometimes I had made an error in the spec. Concurrently with the 15 Minute Rule, I checked in with each programmer at least once each day.
Fruitless Labor
When a programmer is stalled, hours of fruitless effort are a waste; there is no heroism in fruitless labor. On a manufacturing task, the programmer should never spend more the fifteen minutes going down rabbit trails. If some aspect of his assignment is not familiar, the programmer must ask the team. If the team does not know, then something is very wrong. Maybe a bad spec. In some cases, there is menial, boring, repetitious, even failure filled work. More than one good programmer has told me something like "one of these 32 combinations is the answer." And, each combination took part of an hour. Finding the correct configuration for hardware can bring about this situation. But that work is finite and rare. If the effort fails, then the team must scramble or abandon; or the manager must authorize the purchase of a solution.
Handling New Ideas
Inventing during manufacturing can cause confusion and leads to inferior products. The specs should contain correct solutions. As the task continues, the programmer might envision a new or better method to satisfy some functional need. The programmer should bring such ideas up during design reviews. A beneficial new idea might lead to a change in the project, but only after mutual approval, and then the actual changes should occur within maintenance tasks of the retrofit variety. These retrofits contribute to the list of secondary and tertiary tasks. A really good new idea might lead to a change to a paradigm or a shared library, and that change would occur during a research project.
Manufacturing is Profitable
Contrary to some popular notions, general programming is not creative. General programming should be like manufacturing, and it should produce rapidly and on-spec and on-time. Shops make money thru improved sales or thru reduced costs in other departments. Cute code is not necessarily profitable. The typical shop only needs a small number of paradigms. The shop might have hundreds of programs, and they should fall into only a few categories or paradigms. The manager must teach the programmers or at least expose them to good influences, which might be another programmer who has certain skills. In the market of 2015, some would argue correctly that no one person can know every fact.
Splitting the Project in Two
In theory, there should be no significant reasons for the stalls because we thought we had removed all of the black holes. If ever we discovered a black hole after we started programming, we stopped and re-grouped. Sometimes a programmer has to conduct simple experiments. For example, when formatting HTML, the different browsers render the same code differently. The programmer might need to make a few guesses. However, there comes a point when the guesses yield no uniform results. At such points, the stall becomes a black hole and should be removed from the project. The first implementation might render correctly on only one browser. The programmer should be working on a research project or a manufacturing task. After the research yields a result, the manager can insert the result into the specs for the manufacturing project or trim the project if the research fails. The programmer needs success, and that might mean splitting the project intelligently after the project begins.
The Good Manager Knows
When I was the manager, I still did significant portion of the programming. I learned the technology; I learned the business.
Programmers are People
The personalities and skills of programmers vary. Yes, I try to hire the best, but usually some programmers already work for the company. Some excel at research; some at coding; some at testing or documenting; some at implementation. While it might be noble to train all the programmers in each facet of the shop, it is much more pragmatic to let programmers work on the tasks which match their skills and efficiencies. Ron McMichael and Bruce Juranek were the QA kings at their respective jobs. Virtually all the software flowed thru them.
People Need Friendly Reminders
There is so much to know in a typical IT shop that no one knows everything. Even the sharpest programmers need reminders. We lesser programmers forget some of the details, especially when there is a large array of tools and when daily decisions are not yet written. So programmers ask questions of each other. A two minute question and answer that eliminates a stall is worthwhile. Most programmers reach a good balance between solo work and team work. For certain tasks, some programmers find collaboration more productive than solo work.
Thursday Deadlines at Noon
Mondays can be hectic. I preferred Tuesday noon for deadlines of small projects and Thursdays for large projects. Most of the time, the final deadline was anti-climatic because we had already made many intermediate deliveries. On the rare occasion of a mistake at noon Thursday, we had a long time before the week end to make adjustments.
Friday Fun Days
When we were successful as a group on Thursday, I let each programmer choose a small task to work on during Friday afternoons. The task should entail no more than 12 hours, which is three afternoons. Sometimes a programmer chose a research task. Yes, good programmers like being rewarded with more work. Other Fridays, having suffered a setback, we would gang up on a roadblock. We wanted to eliminate stressful thoughts over the week end. Sometimes the 'best' programmer had to help the 'worst' programmer. We overcame.
The Wiki
We know that certain principles prosper; we need to discuss them and agree to them in word and in deed. Use the wiki to publish those principles. We spent several hours discovering a configuration for a device; publish it. We lost two hours because we chose a bad sequence of steps within the IDE; publish. We want standard patterns; publish. A program crashed and displayed an unusual error message; we published.
The wiki should display information about all major strategies, about techniques, and about important but seldom executed tasks.
The wiki should have common spaces and personal spaces.
Flexible Hours
Hours do not flex; time marches on, but this euphemism describes the practice of allowing workers to have variable starting and stopping times. Many years when I had two jobs, one started early in the morning and the other started during the mid-afternoon. When I worked on the far side of Los Angeles, the work day started about 10 am and finished about 7 pm. When on a role, I sometimes worked thirty hours straight. For Ken Williams at APU, we worked 43 or 45 hours per work, and he allowed us great flexibility. We dealt with funerals, sick kids, and car repairs, and then worked compensating hours; if a sports team was in a championship game, we followed him to the field.