Bob Congdon

Within our daily lives, which we go about without thinking much about the many mysteries, archetypes, themes and more varied ways of thought. For example, have you ever thought why waffles are always the same shape? Behind it all is concept of "having a shape". There [are] all sorts of these archetypes/shapes: in print, in mass-produced goods and whatnot. Understanding these these "shapes" let's you grasp how these things work.

"Pythagoras Switch" wants to help kids have that moment of A-HA! We want to raise thinking about thinking, to flip that epiphany switch in every child.

In general, I recommend you avoid symbolic debuggers of the type that have become standard in many IDEs. Debuggers tend to produce a very fragile debugging process. How often does it happen that you spend an extended period of time carefully stepping through a piece of code, statement by statement, only to find at the critical moment that you accidentally "step over" rather than "step into" some method call, and miss the point where a significant change in program state occurs? In contrast, when you progressively add trace statements to the code, you are building up a picture of the code in execution that cannot be suddenly lost or corrupted. This repeatability is highly valuable - you're monotonically progressing towards your goal.

I've noticed that habitual use of symbolic debuggers also tends to discourage serious reflection on the problem. It becomes a knee-jerk response to fire up the debugger the instant a bug is encountered and start stepping through code, waiting for the debugger to reveal where the fault is.

Most companies have it all wrong. They don't have to motivate their employees. They have to stop demotivating them.

• Equity: To be respected and to be treated fairly in areas such as pay, benefits, and job security.
  
  
• Achievement: To be proud of one's job, accomplishments, and employer.
  
  
• Camaraderie: To have good, productive relationships with fellow employees.

1. Start with working code and good tests or you are doomed
   
2. Rest assured, you don't know where the problem is
   
3. There is always a long pole in the tent, but it is not always the same pole
   
4. If it doesn't help, take it out
   
5. You need to know when to stop

The server cannot use the error page specified for your application to handle the Original Exception printed below. Please see the Error Page Exception below for a description of the problem with the specified error page.

Today's example was actually submitted by a few different people over a span of a couple months and is from the data-access layer of an enterprise .NET application. For you non-enterprise developers, here's an easy way to make your applications more enterprisey: add lots and lots of constants.

If IBM is hiring Ruby skills then Ruby is enterprise. That may seem like circular logic, but the reality is that IBM, more than any other individual or organisation, still defines what is and what is not "enterprise". If IBM is investing in an area, you can be pretty sure its going to be used in enterprise contexts.

If IBM supports it, its enterprisey.

DOLIST is similar to Perl's foreach or Python's for. Java added a similar kind of loop construct with the "enhanced" for loop in Java 1.5, as part of JSR-201. Notice what a difference macros make. A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language. Then Sun has to publish a JSR and convene an industry-wide "expert group" to hash everything out. That process--according to Sun--takes an average of 18 months. After that, the compiler writers all have to go upgrade their compilers to support the new feature. And even once the Java programmer's favorite compiler supports the new version of Java, they probably still can't use the new feature until they're allowed to break source compatibility with older versions of Java. So an annoyance that Common Lisp programmers can resolve for themselves within five minutes plagues Java programmers for years.

The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs.

Software is a conversation, between the software developer and the user. But for that conversation to happen requires a lot of work beyond the software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

But what do software developers do? They design and write code, they layout screens, they debug, they integrate, and they check things into the source code control repository.

The level a programmer works at (say, Emacs) is too abstract to support a business. Developers working at the developer abstraction layer need an implementation layer -- an organization that takes their code and turns it into products. Dolly Parton, working at the "singing a nice song" layer, needs a huge implementation layer too, to make the records and book the concert halls and take the tickets and set up the audio gear and promote the records and collect the royalties.

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market. Which gets me to the most important point of this essay:

Your first priority as the manager of a software team is building the development abstraction layer.

At Apple, we only have one rule:
Rules are made to be broken.
Take "Thou shalt be compatible with IBM?" for instance.
We decided there was something more important than building a computer that's compatible with another computer.
Namely, building a computer that's compatible with people.