Anthony Panozzo's Blog

The Personal MBA program founders think that you can understand the fundamentals and mechanics of business by reading a list of books that they have hand picked as the best in the business field. They conjecture you might get close to the same education level as a traditional MBA with much less time and money.

While skeptical that it will line up fully with most MBA programs, I think that this program has the right idea. The best learning comes when one is interested in something and really wants to learn more about it. I am interested in learning more about business and entrepreneurship since I feel that my strengths lead in this direction. It seems that these books will give a high return on time invested, as most of the time I see new connections or learn new skills. While the information might not be applicable right away, just knowing more gives me confidence that I will succeed when the time comes. There seems to be a lot to learn, but it's not rocket surgery either. Many concepts are similar to each other, and having a background in economics probably helps.

Matt wrote that coding is like writing. I came to the inverse, although similar, conclusion in high school. Writing words resembles writing programs for the brain. In both, to communicate your meaning correctly, you need to know your audience and signal based on your representation of the underlying system. This will allow the interpreter to understand what you are saying.

I originally felt this parallel when I constructed arguments for essays. Words and sentences must be read through sequentially and the work needs to make sense. This resembles writing a program and running through it in your head before executing. When writing a paper, I found framing arguments often corresponded to declaring variables. The introduction of a paper lines up with initialization, setting the evaluator's mind in a specific state for later communication. The conclusion is cleanup. Pronouns are abbreviations or aliases to entities. A sentence that could be ambiguous should be expanded out, much like one would use parentheses to clarify a potentially ambiguous expression.

In Weinberg on Writing: The Fieldstone Method, Gerry Weinberg (author of Are Your Lights On? and Secrets of Consulting) discusses his main writing workflow. Weinberg primarily collects ideas and words with energy behind them, which he refers to as "fieldstones". He then analogizes writing to building a wall with stones. Overall I thought this book was fantastic, with many ways of generating ideas and working with them in an original manner.

Weinberg always seeks to move writing forward, and keeps a list of things to do depending on his energy level and state of mind. If he feels high in spirit, he might develop fieldstones into new sections. If he feels drained, he might reword a section that needs fine-tuning or perhaps take a break.

Weinberg's technique seems to produce a volume of writing: he has published over forty books and numerous articles and other writings.

Getting Real: The smarter, faster, easier way to build a successful web application Author: 37signals Published: 2006 Pages: 177

This book describes the philosophy of development at 37signals when they created five successful web applications while taking no venture capital.

The biggest theme that I can see with this book is that you should do a few things exceptionally well as opposed to doing many things, only some of which are done well. I see this theme repeated in many works that I read. You don't want to be good at several things, you want to be world-class at whatever you choose to do.

I really liked the firm's approach to taking venture capital. They are big fans of bootstrapping by keeping functionality at a bare minimum to what is required. Having less features means a firm can spend time on the very most important features and ensures that they are agile enough to change plans once a page is actually out there. Every single feature that goes into your software is a liability, and users will not want it taken out. So think carefully about every feature. Be ready to say "no" a hundred times. If you keep hearing about something, you will know that users really need it. This comes back to designing something based on the actual underlying needs of users and doing continuous usability testing and getting continual feedback to ensure that designs work as desired.

I recently started a new supplementary coding technique that I have not heard about anywhere else. I'm not sure what to call it, although internally I've been calling it streaming, an abbreviation for stream of consciousness programming. It works by writing out how you are solving a problem.

Here's a real-life example that likely took place over the course of a couple of hours:

control_parsing
 Go through documents and figure out what appropriate values would be for the metadata and the control data to get it out
  Given a standard document, the ability to correctly parse out the fields
   Given a patient identifier, find the matching patient
    What API call do I use for this?
     Where is the system id of 387 coming from?  I could swear I've seen that before
      I don't think it's actually used, I think that we just use the patient identifier and the user's institution id
       Pretend we are calling the API call with the known patient identifier and user's institution id to ensure that I have the right mental model

Process

I use vim to type out my thoughts and save them a text file. I could see marking things off by putting '#' at the beginning of the line, which for me would gray the line out, but normally I just delete things when I get done. This results in a nice feeling of crossing things off of the list. If I'm in the heat of solving a problem, I often don't write or delete lines. But when I come to a stopping point or am considering what next to do, I usually write out what I am thinking. This minimizes overhead and preserves flow.