Ed Weissman's Blog

Good CTO: Understands that developers are on the critical path: nothing "is" until someone writes some code.
Bad CTO: Thinks that developers are no different than business analysts, admins, or envelope stuffers, and treats them that way.

Good CTO:  Understands that formal process, while invaluable, is not infallible and must be augmented by the performance of excellent people.
Bad CTO: Forces creativity and determination to take a back seat to process.

Good CTO: Wants people to be "intrapreneurs", to feel as if they're running their own little "business within a business".
Bad CTO: Thinks that being "part of the team" is more important that getting work done, no matter what it takes.

Good CTO1: Listens.
Bad CTO: Talks.

Good CTO: Strives to understand customer issues deeply as a basis for all technology decisions.
Bad CTO: Forces customers to fit into his vision of technology.

Good CTO: Prototypes and iterates in order to learn "what".
Bad CTO: The specs are the Bible, at least until Version 2.0.

Good CTO: Ready, Aim, Fire. Or when super speed is needed: Ready, Fire, Aim.
Bad CTO: Fire. Fix. Fire. Fix. Fire. Fix.

Good CTO: Prioritizes "why"; facilities "what"; accepts "how".
Bad CTO: Dictates "how". Blames when "what" doesn't match "why".

Good CTO: Daily interaction.
Bad CTO: He works here?

Good CTO: Leader.
Bad CTO: Politician.

Good CTO: Encourages customers to provide input and feedback.
Bad CTO: Depends upon training and documentation when customers don't "get it".

Good CTO: Encourages developers to identify their needs and is eager to satisfy them.
Bad CTO: Blames developers for missing deadlines when they lack the resources they need.

Good CTO: Offices or war rooms.
Bad CTO: Cubicles.

Good CTO: Intense interaction as needed.
Bad CTO: Meetings.

Good CTO: Has finger on the pulse of the organization.
Bad CTO: Needs town hall meetings and web conferences.

Good CTO: To foster moral, always strives to do the right thing.
Bad CTO: To foster moral, cheerleading and gimmicks.

Good CTO: Developers love coming to work.
Bad CTO: Developers love their work in spite of their company.

Good CTO: Googles you.
Bad CTO: Wants you go Google him.

Good CTO: Watches the project plans and schedules.
Bad CTO: Watches the clock.

Good CTO: Stays for years until our baby grows up.
Bad CTO: Moves on just before the smoke and mirrors clear up.

Good CTO: Worries about 2 things: Getting our work done and keeping our people.
Bad CTO: Worries about 2 things: How he looks and how he feels.

Follow me: http://twitter.com/#!/edw519

Permalink

| Leave a comment  »

Bad: Cubicle
Better: Office
Best: Whatever works best for you.

Bad: Meetings without agendas.
Better: Meetings with agendas.
Best: Meetings whose need is so obvious to everyone that no agenda is needed.

Bad: Specs, waterfall, Systems Development Life Cycle.
Better: Prototyping, agile, scrum.
Best: Developers with enough domain knowledge to just build it.

Bad: No documentation.
Better: Documentation.
Best: No documentation needed.

Bad: No formal process.
Better: Formal process.
Best: People so much bigger than their jobs so that process is rarely
relied upon.

Bad: Theory without experience
Better: Experience without theory
Best: Both

Bad: Help desk without programmers.
Better: Programmers available to customers.
Best: Code that just works.

Bad: Phone calls
Better: Emails
Best: Application software that encapsulates required communication

Bad: Code with early exits.
Better: Code without early exits.
Best: Code so simple because of the underlying data structure that the
early exit debate is moot.

Bad: Bugs
Better: Fixes
Best: Enough 9's to never notice.

Bad: programmer error
Better: user error
Best: What's an error?

Bad: Missing deadlines
Better: Hitting deadlines
Best: A track record so good that deadlines are never given

Bad: Complex org chart
Better: Simple org chart
Best: Technology so sophisticated, less people are needed

Bad: Non-technical boss
Better: Technical boss
Best: No boss

Bad: Management
Better: Leadership
Best: Self-motivation

Bad: Best practices, with a Capital "B" (industry standards)
Better: best practices, with a small "b" (what we figured out)
Best: Just do your fucking job.

Follow me: http://twitter.com/#!/edw519

Permalink

| Leave a comment  »

I get a lot of emails these days from fellow hackers with [ distress | concern | depression ]. They're not looking for technical solutions or advice (which is good because I have neither), they're just not where they thought they'd be and are reaching out for *something*.

I try to make a point to answer all of them because, frankly, they're my most important emails. To me, the ones and zeroes inside my fellow humans heads are far more important than those on any computer.

If I built a Venn diagram of all of my responses, the intersection is significant. There are some things I end up telling almost everyone, regardless of their situation.

This is not(Advice). Just a bunch of observations from a fellow hacker who has also suffered and learned...

1. You don't have a time machine.

So many fellow hackers say, "If only I hadn't..." with "quit my job" being the top instance.

You can't "should have". You can only "do". You don't have to forget what happened in the past, but you don't have to overemphasize the importance of its input into your future.

My favorite example:

2 people are travelling from New York to San Francisco. One drives directly from New York to Chicago. The other drives to Florida, Texas, Tennesee, and then Chicago. They are now both in Chicago, well fed, rested, and ready to go. How should their plans differ? (Hint: Except for rare exceptions, they shouldn't.)

It doesn't matter how you got where you're at. It only matters where you're at, who you are, and what you've got.

2. You can't read others' minds.

I often hear things like, "If I only knew what she wanted, I would do it." You don't know. So ask. We humans are not connected via USB 3.0 (yet). Until then, we must talk to each other without fear. That usually improves our chances of success significantly.

3. There are no rewards or punishments, only consequences.

Life's not fair. With software, unknown input + known process = predictable result. In life, known input + unknown process = consequences. We spend a lifetime learning the processes, so we should get better predicting the consequences. When you were 16 are wrote that cool software that nobody wanted, you were disappointed. Now you should either adjust the input or stop being disappointed. You'll never be perfect, but with continuous learning, you should get pretty good knowing what will work and what won't.

It's not about luck. It's about adjusting the controls to maximize the possibility of desirable consequences. You didn't do that as well as you would have liked this last time. You'll do better next time.

4. Don't order a taco at a Chinese restaurant.

Many hackers are disappointed in the responses of others in their lives. "If only more people clicked that button." "If only my cofounder worked harder." "If only that angel got it."

Sometimes we expect things from others that they are incapable of giving. It's hard for we hackers to believe that it's so difficult (or impossible) for to do or understand . We might as well order a taco at a Chinese restaurant. (Hint: They don't have any.)

When others don't respond the way you expected, maybe it's because they couldn't or didn't know how. Don't blame them. Just order what they've got.

5. You are a Chinese restaurant that doesn't serve tacos.

Sometimes a friend or loved one says something like, "You had it all! You made more money than anyone I know and you threw it away for a silly dream. You could have had and done anything you wanted with a salary like that."

Whenever they do, they're ordering a taco from *your* Chinese restaurant. They think you're something you're not and they want something from you that you don't have to give them.

In general, most normals get a greater percentage of their satisfaction from mainstream thinking, good times, and "stuff". They don't understand the hacker mindset of getting satisfaction from building and achieving.

That's OK. Being different isn't the problem. Forgetting that we are is.

6. They love you. They want to help. They're always right. Pick two out of three. (Hint: It's the first two.)

I often hear things like, "My father criticizes me for and I feel awful." You can only feel awful if you believe him. You only believe him if you think he's right. But as hard as it is to believe, sometimes he's actually wrong. This is probably one of those times. Get used to it.

7. It's all in your head.

It may sound like some enlightened Zen kind of thing, but it really is true. But knowing it and living it are two entirely different things.

It's easy to say things like, "I will manifest in my life," especially for us hackers because we are used to making something seemingly out of nothing. But when we appear to not succeed at building something right out of our head, it's easy to dismiss our our responsibility and blame something external (time, money, support, luck, etc.)

It really is all in your head. You may not be ready right now, but eventually you will be. Then you'll try again.

8. I care. And I have a feeling I'm not the only one.

The single biggest response I ever get is something like, "Thank you. It's not what you said, but the fact that you responded that means so much to me."

Feel free to email me any time. Any feel free to engage others, too. But don't get concerned if they don't respond. Their Chinese restaurant doesn't serve tacos yet.

 

Follow me: http://twitter.com/#!/edw519

Permalink

| Leave a comment  »

[image error]

On my birthday, May 19, 1997, we went to the Hillsborough Humane Society to adopt a companion for my cat Sarah. I was thinking a male, about 2 months old. She was female, 3 months old, and had other ideas. The moment we walked into the kitten room, she called me and made me pay attention to her. It was love at first sight.

We took her home and named her Shana. Sarah never liked her, but it didn't matter. She was my baby. For the next 15 years, she slept on my chest every night, and sat on my lap or on her towel next to my computer every day. She was my angel and my constant companion. I spent more "quality" time with Sarah and Shana than any human I've ever known.

With Shana, signal / (signal + noise) = 100%. Every nanosecond with her was pure joy. I can't remember a single instance otherwise. I went to the humane society to save a life; little did I know that it was my life that would be saved.

In her routine annual checkup in 2008, Shana went through a series of increasing invasive tests until she was finally diagnosed with 3 separate terminal diseases. She had shown no symptoms. Her doctor gave her weeks to live. We were devastated.

But Shana didn't know. She continued to be her same joyful self, showing no symptoms until 6 months ago. We had tried quite a few interventions, but nothing worked, so we just let her be.

Even though she had lost over half her weight, she continued to eat well and keep me company every day and night. On Saturday morning at 2:25 a.m. she woke me with her breathing to let me say goodbye. She was gone 10 minutes later.

I have had many experiences and people in my life, but to tell you the truth, I don't think I've ever been lonelier than I am right now. My heart is broken and my life seems empty. In 10 minutes, I will try to write the first code without her since 1997. I don't know how I'll do it, but I imagine I'll manage.

This may sound strange to many, but this morning it occured to me one of the main reasons for religion: never seeing her again seems incomprehensible so we have to invent a scenario where being with her is once again possible. I don't know about any of that, but I sure hope it's true.

Shana, I've loved you forever and I will love you forever, but now with a broken heart. Please visit me in my dreams,

I love you.

Eddie

Permalink

| Leave a comment  »

Apologies to Hans Christian Andersen

Once upon a time there lived a vain CEO whose only worry in life was to get eyeballs and press. He changed webpages almost every hour and loved to show off his A/B tests to his users.

Word of the CEO's refined habits spread over the internet and beyond. Two hackers who had heard of the startup's vanity decided to take advantage of it. They introduced themselves at the gates of Silicon Valley with a scheme in mind.

"We are two very good hackers and after many years of research we have invented an extraordinary method to build software so light and portable that it looks invisible. As a matter of fact it is invisible to anyone who is too stupid and incompetent to appreciate its quality."

The chief of the developers heard the hacker's strange story and sent for the project lead. The project lead notified the CTO, who ran to the CEO and disclosed the incredible news. The CEO's curiosity got the better of him and he decided to see the two hackers.

"Besides being invisible, your Highness, this software will be refactored in colors and patterns created especially for you." The CEO gave the two men most of his Series A proceeds in exchange for their promise to begin working on the software immediately.

"Just tell us what you need to get started and we'll give it to you." The two hackers asked for 2 Macbook Pros, 2 32" monitors, a broadband connection and then pretended to begin working. The CEO thought he had spent his money quite well: in addition to getting new extraordinary software, he would discover which of his users were ignorant and incompetent. A few days later, he called the old and wise CTO, who was considered by everyone as a man with common sense.

"Go and see how the work is proceeding," the CEO told him, "and come back to let me know."

The CTO was welcomed by the two hackers.

"We're almost finished, but we need a lot more runway. Here, Excellency! Admire the colors, feel the user interface!" The old salt bent over the Macbook Pro and tried to see the website that was not there. He felt cold sweat on his forehead.

"I can't see anything," he thought. "If I see nothing, that means I'm stupid! Or, worse, incompetent!" If the CTO admitted that he didn't see anything, he would be discharged from his office before his options vested.

"What marvelous software," he said then. "I'll certainly tell the CEO." The two hackers rubbed their hands gleefully. They had almost made it. More funding was requested to finish the work.

Finally, the CEO received the announcement that the two hackers had come to collect all the specifications needed to build his new site.

"Come in," the CEO ordered. Even as they bowed, the two hackers pretended to be demoing a brand new framework.

"Here it is your Highness, the result of our labor," the hackers said. "We have worked night and day but, at last, the most beautiful framework in the world is ready for you. Look at the code and see how fine it is." Of course the Emperor did not see any code and could not find any framework on his hard drive. He panicked and felt like fainting. But luckily the Aeron chair was right behind him and he sat down. But when he realized that no one could know that he did not see the software, he felt better. Nobody could find out he was stupid and incompetent. And the CEO didn't know that everybody else around him thought and did the very same thing.

The farce continued as the two hackers had foreseen it. Once they had collected the specifications, the two began typing and mousing while inputting parameters into their invisible framework.

"Your Highness, you'll have to clear your cache to load your new website." The two hackers loaded the new software onto his site then opened the browser. The CEO was embarrassed but since none of his bystanders were, he felt relieved.

"Yes, this is a beautiful website and it looks very good," the CEO said trying to look comfortable. "You've done a fine job."

"Your Majesty," the CTO said, "we have a request for you. The users have found out about this extraordinary software and they are anxious to see it on the website." The CEO was doubtful showing his website naked to the users, but then he abandoned his fears. After all, no one would know about it except the ignorant and the incompetent.

"All right," he said. "I will grant the users this privilege." He summoned his PR person and the ceremonial press release was done. A group of Sand Hill Road dignitaries logged in to the dashboard and anxiously scrutinized the cookies of the users on the internet. All the users had gathered at 127.0.0.1, resetting and reloading to get a better look. An applause welcomed the regal soft launch. Everyone wanted to know how stupid or incompetent his or her neighbor was but, as the CEO promoted the new website, a strange murmur rose from cyberspace.

Everyone tweeted, followed enough for the others to see: "Look at the startup's new website. It's beautiful!"

"What a marvelous user interface!"

"And the colors! The colors of that beautiful theme! I have never seen anything like it in my life!" They all tried to conceal their disappointment at not being able to see the website, and since nobody was willing to admit his own stupidity and incompetence, they all behaved as the two hackers had predicted.

A blogger, however, who had no Facebook or twitter and could only see things as his eyes showed them to him, logged into the website.

"The website is naked," he said.

"Fool!" his publisher reprimanded, running after him. "Don't talk nonsense!" He grabbed the blogger's credentials and took them away. But the blogger's remark, which had been heard by the blogosphere, was repeated over and over again until everyone cried:

"The blogger is right! The website is naked! It's true!"

The CEO realized that the users were right but could not admit to that. He thought it better to continue the launch under the illusion that anyone who couldn't see his website was either stupid or incompetent. And he stood stiffly on his About Page, while behind him a CFO held his imaginary revenue.

Follow me: http://twitter.com/#!/edw519

Permalink

| Leave a comment  »

I worked at McDonald's in high school. It was high volume, fast paced, hard work, low pay, and there were 10 other kids ready to take your job if you didn't like it.

I'm now a software developer. I've worked hard all my life, but I still think that McDonald's was the toughest and best job I've ever had. I learned lessons there that have helped me many times since.

Just a few of those lessons:

1. In order to do heavy volume, you have to be set up for heavy volume.

When we hung out with our friends who worked at Burger King or Wendy's, they'd tell us about their record hours and record days (in dollars). We were amazed.  What they called records, we did every day. Our records were 4 or 5 times as much. In restaurants that appeared the same.

The difference was always that McDonald's was set up for volume. We ran five lines where they ran one. We made 12 hamburgers at a time when them made one at a time. We had food cooking before people even ordered it.

If a bus pulled in, we fed everyone in 10 minutes. They took at hour. When 6 buses pulled in, we fed them all in an hour. 6 buses never pulled into Burger King or Wendy's.  They knew they wouldn't eat.

The same thing holds true for commercial software. Want to write lots of software?  You better have everything you need in place first. People. Hardware. Environments for development, testing, and production. Source control. Frameworks. Tools. And most importantly, a mindset and the experience to do a lot of work. Anything less and you'll end up with vaporburgers.

2. If you're not prepared to serve customers before they arrive, it's already too late.

If a customer arrived and ordered a sandwich that was not already cooked or a special order, no problem. We just made it. Just as long as the grill was hot, the freezer was full, the buns were laid out, and everything else was where it needed to be. If anything wasn't, we couldn't give good service to anyone.

There's a common misconception in software development that you don't really need much software before you meet your customer; they'll tell you what they need and you'll develop it. Wrong. You better have at least half of it already written, or you'll never deliver anything in a timely manner. You may not know their exact requirements, but a form is a form, a data base is a data base, a web page is a web page, and a process is a process.  You better have all your building blocks built before your customer arrives. No one wants to wait for your grill to warm up in order to make your sandwich and no one wants to wait for you to write your framework to make their app.

3. When you're operating on the razor's edge, every detail is critical.

Saturday night from 5 to 8 was always the busiest time of the week. So Saturday from 4 to 5 pm was the most important hour of the week. Everything had to be ready and everything had to be perfect. Four large stacks of buns were positioned perfectly along the wall.  The meat freezer had 300 pounds of beef patties with the boxes already dropped to break them apart. All condiments and paper goods were fully stocked; bags were even "fanned" to be easier to grab. There were no cabinet doors or drawers because there was simply no time to open and close them when you got busy. And the kitchen had to be spotless; there would be no time for sweeping, mopping, or cleaning when you'll be running 72 sandwiches at a time for 3 hours. We knew what was coming, so we got very good at eyeballing the kitchen at 4:45 to make sure everything was perfect.

The only difference in developing and deploying software is that your "crunch time" can come anytime, not just during rush hour. And you better be ready. You better know exactly where your code is and what it does. Your data better be in order. Hard copies of source code and specs have to be handy and ready to use. But most of all, the programmer has to be ready for the "burst". That means taking care of yourself and being prepared to work something through until it's right. So get enough sleep, exercise, and clear your mind.  And don't eat at McDonald's :-)

4. 1 + 1 = 3.  1 + 1 + 1 = 6

   In order to make 12 hamburgers, you'd have to:
    a. Put 12 bun crowns in the crown toaster.
    b. Put 12 meat patties on the grill.
    c. Sear the 12 meat patties.
    d. Season the 12 meat patties.
    e. Turn the 12 meat patties.
    f. Put 12 bun heals in the heal toaster.
    g. Remove the 12 bun crowns from the crown toaster and put them on the dressing table.
    h. Put ketchup on the 12 bun crowns.
    i. Put mustard on the 12 bun crowns.
    j. Put pickle slices on the 12 bun crowns.
    k. Move the dressed bun crowns next to the grill.
    l. Drain the 12 meat patties put them on the 12 bun crowns.
    m. Remove the 12 bun heels from the heel toaster and put them on the 12 meat patties.
    n. Wrap the 12 hamburgers.

One grill can hold 36 hamburgers. It takes 3 minutes to cook a hamburger patty. When I was stuck in the kitchen by myself late at night, I was able to make one set of 12 hamburgers in 5 minutes. Two of us could make 3 sets in 5 minutes by starting Set 1 at time 0, Set 2 in 1 minute and Set 3 in 2 minutes. Three of us could make 6 sets in 5 minutes by using 2 grills and helping each other with the dressing.

I have found that these multipliers work about the same for developing and deploying business software, with one, two, or three people working together as a team. Beyond that, the "kitchen" gets a little too crowded. 

5. Ideally, managers can do and doers can manage.

There were about 50 tasks that needed to be done all the time in these categories:
 - waiting on customers
 - cooking
 - cleaning
 - restocking

If you had 12 people, you specialized and divided up the work. If you had 6 people, everyone did multiple jobs at the same time. If you had two or three people, each had to be able to do anything, do it very well, and do it fast. If you had one person, they were called a manager and could run the restaurant alone if they had to. Imagine how much better the enterprise world would run if its managers were as versatile as McDonald's managers.

On the other hand, some doers were high school students preparing for college and had no plans to go into McDonald's management. But they were super-doers. They knew everything that had to be done and the best ways to get it done. They naturally gravitated to the top and started directing their peers. Eventually, McDonald's gave them the title of "swing manager" (someone who did everything a manager did but didn't get paid as much). It reached the point where swing managers were better than managers at day-to-day operations.  Funny, the best technicians anywhere are often the same ones who self-manage.

6. The difference between mediocre and good is small. The difference between good and great is large.

For us super-doers. Tuesday night was the most interesting time of the week. That's when the weekly schedule was made up. There were about 60 of us high schoolers on the payroll, and you better believe that it was critical who we were scheduled to work with. About 40 were mediocre, 15 were good, and 5 of us were great.

Monday night? Not busy, no big deal, put Martin on porter and Mike G. on the counter.  It won't make much difference. Friday night, we'll be pretty busy. If you don't have either Mark or Jay on grill, you'll never keep up. Saturday night, forget it, we'll get slammed.  It's me, Jay, and Wally in the kitchen. Have Mark on standby, but whatever you do, keep Jimmy and and Fred out of our kitchen! George and Patty better be on counter that night; we won't have any time for mistakes.

You kinda get the picture. Five Jimmys couldn't keep up with one Wally, and even if they did, you wouldn't want to eat their product.

I'd like to comment on how this applies to programming, but Joel Spolsky already has far better than I could in, "Hitting the High Notes": http://www.joelonsoftware.com/articles/HighNotes.html. My favorite line: "Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years." What was true in music was true at McDonald's. And is still true in our software offices. Go figure.

7. Good work habits are like antibodies; once you get them, you have them for life.

There were 2 kinds of workers at McDonald's, those who got the work done properly and completely, no matter what, and everyone else. It only took about 5 minutes to tell who was who. And it never changed. Both groups were equally smart, equally capable, and equally personable. What was the critical difference? Work habits. Good workers refused to work in dirty work areas. They refused to release deficient product. They refused to put off what could be done later because they knew it would grow to twice as much work later and screw everything else up in the interim. And most of all, they hated working with those who didn't have the same good habits. Why should I get the product out hot, mop the floor, wipe the counters, stock the freezer, and prepare for closing while Jimmy has a smoke and hangs out in the back. Get him off my shift!

Years later, it's still the same. Got a critical project with a tough deadline?  Need to put out great product quickly and efficiently? Who you gonna call, the brilliant guy who sits and pontificates all night or the one who understands what it takes and won't quit until he's done. Work habits separate the good from the great and show you the way to success. Once you have that taste, it's awfully hard to become a slacker.

Follow me: http://twitter.com/#!/edw519

Permalink

| Leave a comment  »

My brother and I worked at McDonald's 40 years ago. It was nothing like today: high volume, fast paced, brutal hard work, low pay, and 10 other kids ready to take your job if you didn't like it.

I am now a software developer and he's in the energy business. We have both worked hard all of our lives, but we both say that McDonald's was the toughest and best job we ever had. We learned lessons there that have helped each of us many times since.

Just a few of those lessons:

1. In order to do heavy volume, you have to be set up for heavy volume.

When we hung out with our friends who worked at Burger King or Wendy's, they'd tell us about their record hours and record days (in dollars). We were amazed.  What they called records, we did every day. Our records were 4 or 5 times as much. In restaurants that appeared the same.

The difference was always that McDonald's was set up for volume. We ran five lines where they ran one. We made 12 hamburgers at a time when them made one at a time. We had food cooking before people even ordered it.

If a bus pulled in, we fed everyone in 10 minutes. They took at hour. When 6 buses pulled in, we fed them all in an hour. 6 buses never pulled into Burger King or Wendy's.  They knew they wouldn't eat.

The same thing holds true for commercial software. Want to write lots of software?  You better have everything you need in place first. People. Hardware. Environments for development, testing, and production. Source control. Frameworks. Tools. And most importantly, a mindset and the experience to do a lot of work. Anything less and you'll end up with vaporburgers.

2. If you're not prepared to serve customers before they arrive, it's already too late.

If a customer arrived and ordered a sandwich that was not already cooked or a special order, no problem. We just made it. Just as long as the grill was hot, the freezer was full, the buns were laid out, and everything else was where it needed to be. If anything wasn't, we couldn't give good service to anyone.

There's a common misconception in software development that you don't really need much software before you meet your customer; they'll tell you what they need and you'll develop it. Wrong. You better have at least half of it already written, or you'll never deliver anything in a timely manner. You may not know their exact requirements, but a form is a form, a data base is a data base, a web page is a web page, and a process is a process.  You better have all your building blocks built before your customer arrives. No one wants to wait for your grill to warm up in order to make your sandwich and no one wants to wait for you to write your framework to make their app.

3. When you're operating on the razor's edge, every detail is critical.

Saturday night from 5 to 8 was always the busiest time of the week. So Saturday from 4 to 5 pm was the most important hour of the week. Everything had to be ready and everything had to be perfect. Four large stacks of buns were positioned perfectly along the wall.  The meat freezer had 300 pounds of beef patties with the boxes already dropped to break them apart. All condiments and paper goods were fully stocked; bags were even "fanned" to be easier to grab. There were no cabinet doors or drawers because there was simply no time to open and close them when you got busy. And the kitchen had to be spotless; there would be no time for sweeping, mopping, or cleaning when you'll be running 72 sandwiches at a time for 3 hours. We knew what was coming, so we got very good at eyeballing the kitchen at 4:45 to make sure everything was perfect.

The only difference in developing and deploying software is that your "crunch time" can come anytime, not just during rush hour. And you better be ready. You better know exactly where your code is and what it does. Your data better be in order. Hard copies of source code and specs have to be handy and ready to use. But most of all, the programmer has to be ready for the "burst". That means taking care of yourself and being prepared to work something through until it's right. So get enough sleep, exercise, and clear your mind.  And don't eat at McDonald's :-)

4. 1 + 1 = 3.  1 + 1 + 1 = 6

   In order to make 12 hamburgers, you'd have to:
    a. Put 12 bun crowns in the crown toaster.
    b. Put 12 meat patties on the grill.
    c. Sear the 12 meat patties.
    d. Season the 12 meat patties.
    e. Turn the 12 meat patties.
    f. Put 12 bun heals in the heal toaster.
    g. Remove the 12 bun crowns from the crown toaster and put them on the dressing table.
    h. Put ketchup on the 12 bun crowns.
    i. Put mustard on the 12 bun crowns.
    j. Put pickle slices on the 12 bun crowns.
    k. Move the dressed bun crowns next to the grill.
    l. Drain the 12 meat patties put them on the 12 bun crowns.
    m. Remove the 12 bun heels from the heel toaster and put them on the 12 meat patties.
    n. Wrap the 12 hamburgers.

One grill can hold 36 hamburgers. It takes 3 minutes to cook a hamburger patty. When I was stuck in the kitchen by myself late at night, I was able to make one set of 12 hamburgers in 5 minutes. Two of us could make 3 sets in 5 minutes by starting Set 1 at time 0, Set 2 in 1 minute and Set 3 in 2 minutes. Three of us could make 6 sets in 5 minutes by using 2 grills and helping each other with the dressing.

I have found that these multipliers work about the same for developing and deploying business software, with one, two, or three people working together as a team. Beyond that, the "kitchen" gets a little too crowded. 

5. Ideally, managers can do and doers can manage.

There were about 50 tasks that needed to be done all the time in these categories:
 - waiting on customers
 - cooking
 - cleaning
 - restocking

If you had 12 people, you specialized and divided up the work. If you had 6 people, everyone did multiple jobs at the same time. If you had two or three people, each had to be able to do anything, do it very well, and do it fast. If you had one person, they were called a manager and could run the restaurant alone if they had to. Imagine how much better the enterprise world would run if its managers were as versatile as McDonald's managers.

On the other hand, some doers were high school students preparing for college and had no plans to go into McDonald's management. But they were super-doers. They knew everything that had to be done and the best ways to get it done. They naturally gravitated to the top and started directing their peers. Eventually, McDonald's gave them the title of "swing manager" (someone who did everything a manager did but didn't get paid as much). It reached the point where swing managers were better than managers at day-to-day operations.  Funny, the best technicians anywhere are often the same ones who self-manage.

6. The difference between mediocre and good is small. The difference between good and great is large.

For us super-doers. Tuesday night was the most interesting time of the week. That's when the weekly schedule was made up. There were about 60 of us high schoolers on the payroll, and you better believe that it was critical who we were scheduled to work with. About 40 were mediocre, 15 were good, and 5 of us were great.

Monday night? Not busy, no big deal, put Martin on porter and Mike G. on the counter.  It won't make much difference. Friday night, we'll be pretty busy. If you don't have either Mark or Jay on grill, you'll never keep up. Saturday night, forget it, we'll get slammed.  It's me, Jay, and Wally in the kitchen. Have Mark on standby, but whatever you do, keep Jimmy and and Fred out of our kitchen! George and Patty better be on counter that night; we won't have any time for mistakes.

You kinda get the picture. Five Jimmys couldn't keep up with one Wally, and even if they did, you wouldn't want to eat their product.

I'd like to comment on how this applies to programming, but Joel already has far better than I can in, "Hitting the High Notes": http://www.joelonsoftware.com/articles/HighNotes.html. My favorite line: "Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years." What was true in music was true at McDonald's. And is still true in our software offices. Go figure.

7. Good work habits are like antibodies; once you get them, you have them for life.

There were 2 kinds of workers at McDonald's, those who got the work done properly and completely, no matter what, and everyone else. It only took about 5 minutes to tell who was who. And it never changed. Both groups were equally smart, equally capable, and equally personable. What was the critical difference? Work habits. Good workers refused to work in dirty work areas. They refused to release deficient product. They refused to put off what could be done later because they knew it would grow to twice as much work later and screw everything else up in the interim. And most of all, they hated working with those who didn't have the same good habits. Why should I get the product out hot, mop the floor, wipe the counters, stock the freezer, and prepare for closing while Jimmy has a smoke and hangs out in the back. Get him off my shift!

Years later, it's still the same. Got a critical project with a tough deadline?  Need to put out great product quickly and efficiently? Who you gonna call, the brilliant guy who sits and pontificates all night or the one who understands what it takes and won't quit until he's done. Work habits separate the good from the great and show you the way to success. Once you have that taste, it's awfully hard to become a slacker.

8. Simple data + Good systems = Fast & accurate.
Don't need no stinkin' cash register.  Big Mac, fries, and a Coke: 96 cents.  Hamburger, fries, and a Coke: 59 cents.

They gave us a cash register, an order pad, and a pencil. In 7 years, I never used any of them. I handled twice as many customers as anyone else.

Typical trip to McDonald's today:
- I wait to be greeted.  I am usually not greeted, so I just proceed on my own...
- I order a Big Mac, fries, and a Coke.
- The operator presses 3 buttons on her automatic register.
- She tells me my total.
- I ask, "Where's my food?"
- She says, "You have to pay first." (When did this get started?)
- I pay.
- She gives me my change.
- She hits a button to see my order.
- She walks over to the counter to get the Big Mac.
- There aren't any Big Macs.
- She yells something to someone.
- She returns to the register.
- She hits a button to see my order.
- She walks over to the fryer and gets my fries.
- She puts a tray on the counter and puts my fries on the tray.
- She hits a button to see my order.
- She puts a cup of ice in the soda fountain and hits a button to automatically dispense my Coke.
- She hits a button to see my order.
- She goes back to pick up my Big Mac. There still aren't any.
- She hits a button to see my order.
- She picks up my Coke and puts a lid on it.
- She goes back to pick up my Big Mac. There still aren't any.
- She hits a button to see my order.
- I complain that my fries are getting cold while we're waiting for my Big Mac.
- She looks at me as if I was from Jupiter (and leaves my fries right where they're at on my tray).
- She hits a button to see my order.
- She gets my Big Mac.
- I ask for ketchup.
- She gives me one.
- I ask for 2 more ketchups.
- She give me two more.
- She doesn't thank me.
- She stares at the next customer.
- I take one bite out of my cold Big Mac and eat one cold fries and throw it all out.
- (How is it that I have to wait and the hamburger is still cold?)
- I vow to never return, but a year later I forget and return anyway.
- I remember all the lessons I learned at McDonald's and I'm glad I still use them.

Does my typical trip to McDonald's today remind you of anyone who develops software?

Follow me: http://twitter.com/#!/edw519

Permalink

| Leave a comment  »

(A true story.)

Philip (President): Our factory is underutilized by 10%. Either we start building more of our backlog or we lay people off. I'd rather keep everyone busy, build inventory, and get ahead of the curve before the busy season. How can we do that?

Lee (Operations Manager): Company policy restricts us from building more than 3 months of backlog. If you just change that to 4 months, we'll have plenty of work.

Philip: Done. Now how do we implement that?

Lee: I'm not really sure. I think we'd have to change a setting in the legacy software.

David (IT Director): No problem. It's probably one line of code in our core routine. Fill out a ticket and submit it to IT Services.

Judy (IT Admin): I'm assigning this request Ticket# 129281. But it still needs the section on Business Impact completed and Director approval.

David: It's for Philip. It we don't do this right away, we'll have to have a layoff.

Judy: OK, then I'll fill out that section myself and put this on the fast track.

2 days later.

David: What's the status of 129281?

Judy: It's the first Enhancement in the Developer Queue, after 14 Bug Reports.

David: Forget the queue. Mark it urgent and send it to Ed immediately.

1 hour later.

Ed (programmer): On line 1252 of Module ORP572, I changed the hard-coded variable MonthsOfBacklog from "3" to "4". I unit tested this successfully and ran 2 batch test runs. The Operations work queue increased 10% as expected. This is good to go. I just submitted it to Code Review and moved in to Homer for User Acceptance Testing.

Shirley (Code Review): It is now against company policy to have any hard-coded variables. You will have to make this a record in the Parameters file. Also, there are 2 old Debug commands, an unassigned variable warning message, and a hard-coded Employee ID that will all have to be fixed before this module can be moved to production.

Ed: Fuck that shit.

Shirley: That may very well be true. But since you were assigned ORP572, you are responsible for fixing preexisting errors that violate new company policy. I cannot promote this as it is.

2 hours later.

Ed: OK, done. I just resubmitted it to Code Review.

Julie (IT Testing): Homer is not available for User Acceptance Testing because Fred is running a controlled test for month-end accounting close. Use Marge instead.

Ed: I don't have access to Marge.

Julie: Then contact Joe in IT Security. He'll get you permissions.

2 hours later.

Joe (IT Security): I cannot grant you access to Marge without David's signature. He's out of town. Can this wait until Monday?

Ed: I don't think so. Philip wants this right away. Get him to grant access.

Shirley: Your new Parameters record "MonthsOfDemand" needs a better name. The offshore programmers won't understand what this means. Also, it should have an audit trail of changes.

Ed: What policy is that?

Shirley: It's not exactly written down anywhere. The offshore team is 3 months late updating the wiki, but I assure you, all new Parameter records must satisfy new naming requirements and keep audit trails.

1 day later:

Ed: I renamed the Parameters record "MonthsOfDemand" to "SelectedMonthsOfBacklogDemand" and added Module PAR634 to maintain that record and its audit trail. I have submitted it to Code Review.

Tony (IT Testing): I see 129281 on Marge, but I have no Test Plan.

Ed: Just run it the old way and the new way and note the increase in the total on the WorkOrdersHours report.

Tony: That's your test plan? No. This affects everything in the factory. I have to have user selected Test Cases, Expected Results, documented Test Runs, and user sign-off.

2 days later:

Philip: David, tell Tony to move Ed's program to production immediately.

David: Yes sir.

Total elapsed time: 6 days.
Lines of mission critical code changed: 1.
Bytes of mission critical code changed: 1.
Excedrin eaten: 24
Pissed off hours spent on Hacker News: 14.

Follow me: http://twitter.com/#!/edw519

Permalink

| Leave a comment  »

For Me, the Difference Between Hacker News and Twitter

Hacker News:

   1. Browse front page.   2. See interesting story.   3. Read comments.    4. If interesting discussion, read article.   5. Upvote good comments.   6. Commend great comments.   7. Amplify comments with which I strongly agree.   8. Respond to comments with which I strongly disagree.     9. Comment with strong thoughts regarding article.  10. Edit comments repeatedly until clean.   11. Go back to work.  12. Return to HN threads, looking for replies.  13. Respond to compelling replies.   14. Get pissed at down votes.  15. Forget about being pissed at down votes.  16. Get pissed at negative replies.  17. Forget about being pissed at negative replies.  18. Go to Step 1 (5 to 10 times per day) or shut down.

Twitter:

Thought. Textpad. Type. "View Document Properties" until < 140. Copy. Paste. Tweet. Oops. Delete. Fix. Repeat. Click @edw519. Nothing. Sigh.

Follow @edw519

Permalink

| Leave a comment  »

10:48

Boss: Hey Ed, Sue in Detroit says that sometimes, the wrong Invoice Part Number is showing up on the Product History Screen. Can you help us figure this out.

Ed: I'm busy with something else at the moment. Put the ticket in my queue.

Boss: This will only take 10 minutes.

Ed: Are you sure about that?

Boss: Yes. I'll just set up a web conference. Sue can show you right away, then you can look into it when you have time.

Ed: OK.

Boss: Great. Check your Outlook for an invite.

11:05

Got an Outlook invite for a web conference at 11:30. Accepted.

11:25

Called the web conference 800 number from my IP phone. Busy. Tried again twice. Busy both times. Called my cell phone from my IP phone. Busy. OK, the IP phone system is screwed up again. Called the web conference phone from my cell phone. First one there. On hold. Clicked the link in my browser to the web conference. First one there.

(Ed starts reading Hacker News in another tab.)

11:38

Boss enters conference call: Where's Sue?

Ed: I don't know.

Boss: Can you see my screen?

Ed: No.

Boss: OK, hold on. Let me be the host. Can you see it now?

Ed: Yes, but I thought Sue was going to demonstrate the problem.

Boss: That's right. I'll just transfer host mode to her.

(Ed continues to read Hacker News in another tab.)

11:47

Sue enters conference call: OK, why are we here?

Boss: So that you can show Ed what's wrong with the Product History Display.

Sue: What's wrong with the Product History Display?

Boss: You know, sometimes the wrong Invoice Part Number displays.

Sue: You mean for mil-spec orders?

Boss: I really don't know. You sent the ticket.

Sue: What's the ticket number?

Boss: Hold on, let me check.

(Ed continues to read Hacker News in another tab.)

11:53

Boss: It's ticket number 13827. Remember now?

Sue: How do I see tickets on my PC?

Boss: Just click on the I.T. dashboard on the intranet.

Sue: I can't. The web conference software went full screen.

Boss: Then just hit Alt-F4. Then go to the intranet.

(Ed continues to read Hacker News in another tab.)

11:57

Sue: OK, what was that ticket number again?

Boss: I should have written it down. Let me look it up again...

Boss: 13827.

Sue: OK, I see. This only happens once in a while. No one knows why. It always breaks on Part Number R27-83.

Boss: OK, show Ed.

Sue: How to I get back to the web conference.

Boss: You have to start all over. Alt-F4 killed it.

(Ed is still reading Hacker News in another tab.)

12:04

Sue: OK, the web conference is up again. Can you see my screen?

Boss: No, you have to click "Host".

Sue: Where?

Boss: In the little box in the upper right hand corner.

Sue: The "History" box?

Boss: No, the "Attendees" box.

Sue: OK. Can you see my screen now?

Boss: No. Try again.

Sue: I did. It said that you have to give up host mode.

Boss: OK. I didn't know that.

(Ed continues to read Hacker News in another tab.)

12:14

Boss: I gave up host mode. Try again.

Sue: OK, can you see my screen?

Boss: Yes.

Ed: Yes.

Sue: OK, if I go into the main menu, click "Operations", then click "Sales", then click "History" it takes me to the Sales History Menu. See?

Boss: Yes.

Ed: Yes.

Sue: Then I click on Sales History Display by Part. I enter "R27-93" and the main screen pops up. Then I click on Invoices, I hit F5, then F3, then F7, and the Invoice Part Number changes to "GT548". This should never happen. What gives?

Ed: OK, let me check it out and get back to you.

Boss: OK, bye.

Sue: OK, bye.

Ed is now stuck in host mode because the other two logged off. He can't get out. Windows locks. He reboots.

12:38

Ed logs back in and goes to the dev system. He goes to the main screen, clicks "Operations", then clicks "Sales", then clicks "History" it takes him to the Sales History Menu. Then he clicks on Sales History Display by Part. He enters "R27-93" and the main screen pops up. Then he clicks on Invoices, hits F5, then F3, then F7, and the Invoice Part Number remains "R27-93", just as it should. It works in dev perfectly.

12:46

Ed logs into production through his secret back door. He goes to the main screen, clicks "Operations", then clicks "Sales", then clicks "History" it takes him to the Sales History Menu. Then he clicks on Sales History Display by Part. He enters "R27-93" and the main screen pops up. Then he clicks on Invoices, hits F5, then F3, then F7, and the Invoice Part Number changes to "GT548". Sue was right.

12:57

Ed checks the Version Control System. The program has been checked out by Fred since November 11. He runs a diff and sees that Fred has found and fixed the problem in the 425 lines of code he has changed.

1:03

Ed calls Fred to see what he's been up to. Voice mail.

1:07

Ed emails Fred, explaining the problem.

Ed returns to Hacker News.

1:17

Fred calls back. Ed tells him to read his email.

(Ed continues to read Hacker News in another tab.)

1:28

Fred calls back: OK, I remember that. The program was broken by one of the offshore programmers who was changing the header on every program in the Operations directory. He accidently removed a line of code before he recompiled. Somehow, it made it through QA, and now Sue has found the bug.

Ed: Well then, can you promote it now?

Fred: I don't think so. There are 12 other changes in this mod. Let me check and call you back.

(Ed continues to read Hacker News in another tab.)

1:36

Fred calls back: I can't promote any of these changes until the XL500 mods go through first. They're on hold until QA approves the spec. So we just have to wait.

Ed: OK, thanks Fred. I'll just email my boss and tell him.

Ed emails Boss with the explanation.

(Ed continues to read Hacker News in another tab.)

1:48

Boss: OK, this sounds like a problem. It looks like I'll have to escalate this to the Steering Committee. I'm glad you had 10 minutes to spare. Thanks.

(Ed continues to read Hacker News in another tab.)

Permalink

| Leave a comment  »