How my High School Job Prepared me for Building Software

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.

Product/Market Strategies

Not so Good: Build it and they will come. 

Good: Make something people want. 

Better: Make something people need. 

Even better: Make something people need and know that they need. If they don’t already know, someone will have to help them know. That someone might be you and helping them will take sales and marketing, a significant consideration. 

Even better: Make something people need, know they need, and are willing to pay for now. Competing against “we’re not ready, maybe next year” is tougher that competing against any competitor. 

Best: Make something people need, know they need, are willing to pay for now, and has their hair on fire. 

Leapfrogging to “let’s just solve this problem now” is often the best (and most fun) way to deploy. 

[EDIT: This is “not” about “guessing what people need”, worrying about competition, or assuming “if I need it, others must too”. This is about getting up off your butt, talking to people, finding out what they must have, and building it for them. There are people everywhere desperate for solutions to their problems, and I promise you, they’re not finding them. Sure, you may scratch your own itch and hope that someone else needs it, but this is a lottery approach. Most start-ups fail because they built something no one else wanted or was willing to pay for. 

There is absolutely no better way to find out what to build than finding customers first. Please don’t be like me and learn that the hard way. There are great apps everywhere that nobody uses while people suffer because no one is building what they want.] 

What went wrong in your first start-up?

In my first failed start-up, I did what is now considered standard advice and it was an utter failure (which might explain why I still question all advice, no matter how standard). 

The software was a small business system for manufacturers and distributors. I was the technical person, my co-founder was the business person. 

How we did things:


- We determined the customers' most critical requirements. 

- We built what they needed from those requirements. 

- We installed the hardware and software. 

- We got them up and running in test mode. 

- We adjusted, reworked, and went live.

 

What ended up happening:


- Critical features were invariably missed. I had to add them. 

- There was always some scaling issue we missed. Always. 

- Architecture had to be reworked with every install.

- My co-founder was able to sell far faster than I could build. 

- My co-founder was unable to help me build. 

- Customers became disillusioned. 

- I collapsed, vowing never to go through this again. 


What I now believe:


- Make sure your MVP is enough. 

- Beware being consumed by customer service. 

- The first two founders must be technical. 

- Your architecture must scale, even if your app doesn't. 

- Always be brutally honest with each other at all times. 

- Make sure all your failures are recoverable ones. 

- Plan for 40 hours/week. Stop working at 80. 

- Never quit. Start over, but never quit. 

What do small business owners care about?

Small business owners are always concerned about revenue. Always. They know there are 2 ways to solve almost any small business problem: (a) Work like hell on 42 different things, or (b) Add sales. Find a way to show them new orders and you will get their attention. 

Small business owners often feel like they must defeat someone else in order to win (whether it’s true or not). 

Always leave a little wiggle room in price or terms so that they can enjoy the feeling of a victorious negotiation. 

Small business owners appreciate simplicity. Confuse them with technology or jargon and they will move on to something they understand better. 

Small business owners understand the importance of other people in their business. Show them that you do too and that will go a long way toward your credibility. 

Every small business owner has a few pet peeves that drive them nuts. It might be the outrageous cost of something or how difficult it is to get something done. Discover and solve these things and you could go far. 

Small business owners are especially sensitive to bullshit. If you’re a poser, save yourself the trouble and move along. 

Small business owners often have a bigger “real mission” for being in business. Find out what that is and help them achieve it. They will really appreciate you for that.

What’s your favorite start-up book?

Do More Faster by Techstars founders Brad Feld and David Cohen 

(Apologies to OP’s request for brevity; there’s just a lot of good stuff that I’d like to share.) 

A must read for anyone here who is serious about their startup.

I read it on the flight to Startup School to “get in the mood”. I couldn’t put it down. 

It’s easy to read for 2 reasons: every chapter is a short essay by a different person (including many Techstars alumni) and it’s very well written, almost like pg essays but by lots of different people. It covers lots of ground, much of which has been covered here at hn many times, but then again, some of this stuff can’t be covered too often. Also, sometimes someone says the same thing a little differently, and that’s the one that actually reaches you. 

My 300 page copy has 50 or 60 dog-earred pages and hundreds of red marks; it’s that full of gems. (For that reason, I highly suggest buying a hard copy and keeping it on your bookshelf for future reference.) I think that yc should come out with a similar book. I’d love to read essays from yc alumni, their advisors, and of course the yc principals themselves about what they thought was important. I realize much of this is on-line already, but there’s nothing like a great hard copy too. 

A few of my favorite quotes from Do More Faster

“I realized that I had two options. I could quit buying comics or I could quit my job and build the iTunes of comics.” - Kevin Mann 

“Getting feedback and new ideas is the lifeblood of any startup. There is no point in living in fear of someone stealing your idea.” - Nate Abbott and Natty Zola 

“That means every moment you’re working on something without it being in the public arena, it’s actually dying, deprived of the oxygen of the real world.” - Matt Mullenweb 

“Focus on the smallest possible problem you could solve that would potentially be useful” - David Cohen 

“You know you’re on to something when the community starts donating money to make sure it stays alive.” - Darren Crystal 

“In companies that rely on having a large user base as ours does, it is very unlikely that you will offend enough people quickly enough to dampen your future growth.” - Sean Corbett 

“We learned that very few people care how you accomplish something. Instead, these people care more about whether you create value for your end user.” - Colin Angle 

“We knew that the high-level concept of our first site still really inspired us.” - Alex White 

“They stepped back from what they had created and thought about what they could do better than anyone else in the world.” - editors 

“During the first few days of every TechStars cycle, we tell the 10 bright-eyed new teams that one of them will not be together at the end of the program. Unfortunately, we have not been wrong yet.” - editors 

“If you can’t quit no matter how hard you try, then you have a chance to succeed.” - Laura Fitton 

“When you ask CEOs of major companies what they’re most worried about, one common answer is ‘a couple of guys in a garage somewhere.’” - David Cohen 

“Companies that work just always seem to move at lightning pace.” - David Cohen 

“It turns out that giving up your one obvious competitive advantage often proves to be deadly. If a startup can’t do more faster, it usually just gets dead faster.” - David Cohen 

“There is an enormous difference between exciting technology and an exciting business.” - Howard Diamond 

“Changes come daily, weekly, and monthly - not once a quarter or once a year.” - Ari Newman 

“While it was only a detour of a week, that’s a lot in TechStars time.” - Bill Warner

“Only hope instead is to listen to their head and their heart and follow a path that they believe in, keeping some of the feedback and discarding other thoughts and ideas.” - Bill Warner

“…when presented with exponential growth, remember that people tend to drastically overestimate what will happen in the short term, but will profoundly underestimate what happens over longer time spans.” - Ryan McIntyre 

“…consider life as a founder of a startup to be one big intelligence test.” - Ryan McIntyre 

“Remember that human nature has a tendency to admire complexity, but to reward simplicity.” - Ben Huh

“If you are innovating, you actually don’t know what your product needs to be. Furthermore, your customers don’t either. No one does.” - Ajay Kulkarni and Andy Cheung

“Nearly every startup must find ways to differentiate itself from competitors.” - Raj Aggarwai 

“What is the thing that matters most to making progress right now?” - Dick Costolo

“…you cannot create the need.” - Michael Zeissner 

“Opportunity cost can kill a startup.” - Michael Zeissner 

“It’s easy to feel trapped by these handcuffs but if you change your perspective just a little, you might find that you hands are bound by nothing more than air, and the future is yours to create.” - Eric Marcoullier 

“There is one thing that the hundred of founders I meet each year have in common, and that is that their plan is wrong. Sometimes it’s the big things, sometimes it’s the little things, but the plan is always wrong.” - Rob Hayes 

“…we have to strike while the iron is hot! My experience is that this is rarely true.” - David Brown 

“Take the time to get it right and you’ll find that those competitors might not be as close as you think.” - David Brown 

“Seeking the perfect combo: ‘a smart-ass team with a kick-ass product in a big-ass market.’” - Jeff Clavier 

“The moral of the story is easy: When you follow your heart, good things usually happen. We have a very short stay on this spinning orb and I believe life is way too short to be stuck in a career that doesn’t fulfill you.” - Mark Solon 


Why would you not launch?

0. You’re truly not ready. 

A recurring meme is the equivalent of “Just Do It”. Excellent advice, almost all the time. Almost. Except when it’s terrible advice. 

Yes, as someone who has suffered after launching too soon, I will go against prevailing wisdom and suggest the unthinkable, “Maybe you’re really not ready and can do more harm than good by launching prematurely.” 

Just a few of the bad things that can happen: 

1. People will visit once, see that it’s crap and never come back again, no matter what you do. 

2. You will be overwhelmed by support requirements to the extent that all development stops. 

3. You will be overwhelmed by support requirements to the extent that much support never gets addressed. 

4. Your calendar becomes science fiction; everything has changed and it’s a whole new ballgame. 

5. The stress level will become so overwhelming for some of your people that you will simply lose them. Forever. 

6. If you have taken people’s money and not delivered, the guilt can become so overwhelming that it cripples you. 

7. Your marathon has turned into a sprint you cannot finish. You have launched and lost. I love the idea of pushing the envelope and launching sooner rather than later. You must have real world feedback and launching is best way to get it. But launching too early early is just as bad as launching too late. So how do you know when the time is right? I don’t have a definitive answer, but I do know that your gut is a critical input. Sooner or later, you just have to go with it. 


Why should you fire bad customers?

Wanting it fast, good, and cheap is also a red flag for lots of other little bonuses, such as:


- You will constantly wait for them to make a decision. 

- It will be your fault they took so long to make a decision. 

- They will have emergencies of their own making. 

- It will be your fault they have emergencies. 

- They will commit to little or nothing on paper. 

- It's not their fault because they never committed to that. 

- You think you have specs; they think you're prototyping, so... 

- You will do much work 2 or 3 times. 

- They will constantly change priorities. 

- They will forget they changed priorities, so... 

- They will complain when a lower priority isn't done. 

- You won't get paid on time. 

- You will spend lots of time trying to get paid. 

- They will always find some excuse to not pay. 

- You may never get paid. 

- If it's good, it's because they thought of it. 

- If it's bad, it's because you suck. 

- You can't win. 


Honestly, I wish we could tattoo these people to save the next developer all the heartache. As soon as you realize they want it fast, good, and cheap, “run” the other way. 

Where can I get help starting a business?

I would ask for help from my current employer. 

This, of course, requires you to be completely open and honest about your desires and that they’re not jerks. 

They already think you’re a superstar, so it really won’t be that much of a surprise when you say something like, “I had so much fun ‘liberating our data’ that I’d like to start my own service business doing the same thing for others.” 

Smart business people like helping others, especially helping others get started. They seem so sense that the karma will eventually come back to them (and I believe they’re right). They also understand (even better than you) the business benefits of your work and can really help you focus your new business. 

Ask them (starting with the top person, of course) for guidance on how to get started. You may be surprised how much you learn from them and how willing they are to help. You may think you know how much your work has helped them, but I bet they have more to share that you don’t already know. 

They probably can be the source for great leads, their vendors, their customers, other companies in the boss’s CEO or Tech circle, golf buddies, who knows. For example, if your owner/president/CEO has an associate who would benefit from your services, “everyone” wins when he recommends you. 

As long as they don’t feel their core business threatened by your service business (helping their competitors), your own employer may be the best source for ideas and leads to starting your own service business. Give it a shot. 

I’m sooo confused…

Release early and often. 

Get eyeballs, then monetize. 

Bootstrap. 

Get basic version working, then add features. 

Get basic version working, then scale. 

Get basic version working, then license the technology. 

Get basic version working, then sell to enterprises. 

Get free version working, then upgrade them to premium.

Get free version working, then sell support. 

Get free version working, then sell services. 

Get free version working, then put it on your resume. 

Raise money, hire wisely. 

Be first to market. 

Be second to market. 

Wait for market to clear, then enter with second wave. 

Find your niche. 

Have the lowest price. 

Have the highest price. 

Use technology as a barrier to competition. 

Win a business plan competition. 

Get into an incubator. 

Get into a seed accelerator. 

Find an angel. 

Find a mentor. 

Crowd source fund raising. 

Get press to raise money. 

Raise money to get press. 


I think I’ll just fall back on the only thing I know:


Build something people will pay for. 

When do you say “yes”?

“So here it is, the most plain, powerful, single word you have to know, and use when managing a project: NO” 

If you aspire to mediocracy in an enterprise, then this “may” help you survive. Otherwise, it’s horrible advice.

If you have serious competitors, then you have to find YES.

If you are attempting to do something extraordinary or for the first time ever, then you have to find YES. 

If you are building a startup, then you most certainly have to find YES. 

I am not saying that all things are possible. I am saying that you need to find YES.

Once you get into the habit of saying NO, you forget how to find YES. 

A simple (and timeless) example. Your customer wants Deliverable X in Time Y using Resource Z. You know it’s too much and will disappoint. So instead of saying NO as OP recommends, you find a way to do what can be done. It may have a few less features, may need an extra resource, or may take a little more time. 

Or better yet, you analyze the constraints long enough to find methods or tools you hadn’t considered to say 

YES to all of it. (We never would have found Framework ABC if the customer hadn’t forced us.)

I have often been to only person finding YES when I was surrounded by others pre-programmed to saying NO. 

That’s how they survived. Usually in an enterprise or institution. That same thinking is a disaster in an achievement oriented environment. 

Finding YES forces you to stretch beyond your previously perceived limits. Settling for NO dooms you to mediocracy forever.

Some may call this a semantic argument. I call it state of mind. How badly do you want it? Find YES.