This is a blog about the people, processes, and thoughts about technology previews from Autodesk.

July 15, 2016

How a Garlic Press Revealed that this Software Guy should stick to Software

The year was 1975. I was a junior at an all-boys Catholic high school in New Orleans. Mr. Hebert, one of our math teachers, decided to offer computer programming as an elective. I decided to take it. Computer programming was done by typing on a teletype and saving programs to paper tape. My first BASIC program answered the question, "Given 3 numbers, can they be the sides of a triangle?"

I was hooked. I decided to be a software kind of guy right there and then. I haven't seen Mr. Hebert since high school, and I do not know if he has passed on, but I certainly wish to thank him for changing my life.

My brother and sister attended Louisiana State University (LSU). Growing up, I thought would also attend. I had the football jersey and pennant on my childhood bedroom wall. When I decided to be a software kind of guy, my high school guidance counselor insisted that I check out a smaller school, what is now the University of Louisiana at Lafayette, because it had a better computer science program. As it turned out, he was right.

At LSU, students used punched cards. Computer programming consisted of punching out a set of program statements, one per card, on a non-interactive device, handing that set of cards to a guy at a window, waiting an hour, and then receiving a printout and your set of cards back from that guy at the window. You then examined your printout to see if your program had run correctly. If you had a syntax error or made a logic error, you would punch replacement cards as necessary and visit the guy at the window again. This was not very exciting.

At the school in Lafayette, students used an interactive Multics system on a computer terminal where you edited your program statements using a text editor, ran the program yourself, and could even step through your code one statement at a time using a debugger. The gratification was immediate, and the process was totally captivating.

With its superior program, computer science was popular at the University of Louisiana at Lafayette. There were about 60 terminals available at the computer science center. Even with that many, demand was high. Students would write their names on a white board and when the next terminal became available, the student would cross out his name, and sit down at the terminal. Sometimes students would have to wait up to 45 minutes to get a terminal. That was a downside, but it beat punching cards.

After one year of college, I got a summer job at a software company writing programs for doctors' offices and a hospital. At the end of the summer, I explained how I would sometimes have to wait to use one of the terminals at school. This company had an extra computer terminal, so they let me borrow it and take it to school. I had a terminal in my dorm room! No more waiting in line. There was only one problem. I needed a modem to connect the terminal to the school's computer system.

The year was 1980. Modems were about $500. I didn't have $500. My roommate, Tim Barrios, was also a computer science major. In fact, he also worked at the software company that loaned us the terminal. The company recognized that they were helping out two students with the loan of one terminal. Tim found a modem for sale in the back of a catalog. It was only about $100. We were saved. So we each put up $50 and ordered it. About 4 to 6 weeks later, our modem arrived. There was only one problem. It was modem parts. It had to be assembled. Tim and I were software kinds of guys. We didn't mess with soldering irons. Tim found an electrical engineering student who assembled the modem for us in exchange for a case of beer. Now we really were saved. Actually, the mechanical engineering student did the minimum necessary. In other words, he didn't use all the parts. Our modem worked reasonably well but sometimes had trouble connecting when it rained. True story.

As I mentioned in other blog posts, I have four interns (Ali Ahmed, Brittany Presten, Connor Freeman, Eni Asebiomo) working with me this summer. Since I cook with garlic, and garlic presses are hard to clean, I asked them to use Fusion 360 to design and 3D print a part that I could attach to my press so I could clean it using a can of compressed air. The thinking was that I could blow out the tiny garlic remnants that remain after using the press — just like how I clean my laptop keyboard. So they did:

Let's just say my idea didn't work. I am indeed a software kind of guy. One of our mechanical engineer employees from Stanford (Lucas Prokopiak) took one look at the part and noted. "This will never work. As soon as the first little remnant is blown out, all of the remaining air will pass through that hole leaving all of the other holes still clogged." And there you have it. I am indeed a software kind of guy who had no business designing hardware. My training is in developing cleanly-written bits of code that have functional strength and share data via a logical set of parameters. I should stick to that.

Actually to mitigate this somewhat, I have leveraged the Autodesk Pier 9 office to complete a few projects in my off-hours and projects around the house:

Comments

How a Garlic Press Revealed that this Software Guy should stick to Software

The year was 1975. I was a junior at an all-boys Catholic high school in New Orleans. Mr. Hebert, one of our math teachers, decided to offer computer programming as an elective. I decided to take it. Computer programming was done by typing on a teletype and saving programs to paper tape. My first BASIC program answered the question, "Given 3 numbers, can they be the sides of a triangle?"

I was hooked. I decided to be a software kind of guy right there and then. I haven't seen Mr. Hebert since high school, and I do not know if he has passed on, but I certainly wish to thank him for changing my life.

My brother and sister attended Louisiana State University (LSU). Growing up, I thought would also attend. I had the football jersey and pennant on my childhood bedroom wall. When I decided to be a software kind of guy, my high school guidance counselor insisted that I check out a smaller school, what is now the University of Louisiana at Lafayette, because it had a better computer science program. As it turned out, he was right.

At LSU, students used punched cards. Computer programming consisted of punching out a set of program statements, one per card, on a non-interactive device, handing that set of cards to a guy at a window, waiting an hour, and then receiving a printout and your set of cards back from that guy at the window. You then examined your printout to see if your program had run correctly. If you had a syntax error or made a logic error, you would punch replacement cards as necessary and visit the guy at the window again. This was not very exciting.

At the school in Lafayette, students used an interactive Multics system on a computer terminal where you edited your program statements using a text editor, ran the program yourself, and could even step through your code one statement at a time using a debugger. The gratification was immediate, and the process was totally captivating.

With its superior program, computer science was popular at the University of Louisiana at Lafayette. There were about 60 terminals available at the computer science center. Even with that many, demand was high. Students would write their names on a white board and when the next terminal became available, the student would cross out his name, and sit down at the terminal. Sometimes students would have to wait up to 45 minutes to get a terminal. That was a downside, but it beat punching cards.

After one year of college, I got a summer job at a software company writing programs for doctors' offices and a hospital. At the end of the summer, I explained how I would sometimes have to wait to use one of the terminals at school. This company had an extra computer terminal, so they let me borrow it and take it to school. I had a terminal in my dorm room! No more waiting in line. There was only one problem. I needed a modem to connect the terminal to the school's computer system.

The year was 1980. Modems were about $500. I didn't have $500. My roommate, Tim Barrios, was also a computer science major. In fact, he also worked at the software company that loaned us the terminal. The company recognized that they were helping out two students with the loan of one terminal. Tim found a modem for sale in the back of a catalog. It was only about $100. We were saved. So we each put up $50 and ordered it. About 4 to 6 weeks later, our modem arrived. There was only one problem. It was modem parts. It had to be assembled. Tim and I were software kinds of guys. We didn't mess with soldering irons. Tim found an electrical engineering student who assembled the modem for us in exchange for a case of beer. Now we really were saved. Actually, the mechanical engineering student did the minimum necessary. In other words, he didn't use all the parts. Our modem worked reasonably well but sometimes had trouble connecting when it rained. True story.

As I mentioned in other blog posts, I have four interns (Ali Ahmed, Brittany Presten, Connor Freeman, Eni Asebiomo) working with me this summer. Since I cook with garlic, and garlic presses are hard to clean, I asked them to use Fusion 360 to design and 3D print a part that I could attach to my press so I could clean it using a can of compressed air. The thinking was that I could blow out the tiny garlic remnants that remain after using the press — just like how I clean my laptop keyboard. So they did:

Let's just say my idea didn't work. I am indeed a software kind of guy. One of our mechanical engineer employees from Stanford (Lucas Prokopiak) took one look at the part and noted. "This will never work. As soon as the first little remnant is blown out, all of the remaining air will pass through that hole leaving all of the other holes still clogged." And there you have it. I am indeed a software kind of guy who had no business designing hardware. My training is in developing cleanly-written bits of code that have functional strength and share data via a logical set of parameters. I should stick to that.

Actually to mitigate this somewhat, I have leveraged the Autodesk Pier 9 office to complete a few projects in my off-hours and projects around the house: