Joel Spolsky

Biography

Spolsky grew up in Albuquerque, New Mexico, and lived there until he was 15. He then moved with his family to Israel, where he attended high school and completed his military service in the Paratroopers Brigade. He was one of the founders of the kibbutz Hanaton in Lower Galilee. In 1987, he returned to the United States to attend college. He studied at the University of Pennsylvania for a year before transferring to Yale University, where he was a member of Pierson College and graduated in 1991 with a BS summa cum laude in Computer Science.

Spolsky started working at Microsoft in 1991 as a Program Manager on the Microsoft Excel team, where he designed Excel Basic and drove Microsoft's Visual Basic for Applications strategy. He moved to New York City in 1995 where he worked for Viacom and Juno Online Services. In 2000, he founded Fog Creek Software and created the Joel on Software blog. Joel on Software was "one of the first blogs set up by a business owner".

In 2005, Spolsky co-produced and appeared in Aardvark'd: 12 Weeks with Geeks, a documentary documenting Fog Creek's development of Project Aardvark, a remote assistance tool.

Spolsky also co-founded Stack Overflow, a question and answer community website for software developers, with Jeff Atwood. He is now CEO of the resulting Stack Overflow and the Stack Exchange Network.

In 2011, Spolsky launched Trello, an online project management tool inspired by Kanban methodology.

In 2016, Spolsky announced the appointment of Anil Dash as Fog Creek Software's new CEO, with Spolsky continuing as Stack Overflow's CEO and as a Fog Creek Software board member.

He is the author of five books, including User Interface Design for Programmers and Smart and Gets Things Done. He is also the creator of "The Joel Test".

Spolsky coined the term fix it twice for a process improvement method. It implies a quick, immediate solution for fixing an incident and a second, slower fix for preventing the same problem from occurring again by targeting the root cause. His use of the term Shlemiel the painter's algorithm, referring to an algorithm that is not scalable due to performing too many redundant actions, was described by salon.com's Scott Rosenberg as an example of good writing "about their insular world in a way that wins the respect of their colleagues and the attention of outsiders."

Spolsky recently made an appearance at the WeAreDevelopers Conference 2017, stating how developers are writing the script for the future. In his speech, Spolsky talks about how software is eating the world, how it is becoming more evident in everyday life as people interact with more software on a day to day basis, and how developers are helping to shape how the world will work as technology keeps evolving. He uses the metaphor "we are just little vegetables floating in software soup", referring to our constant use of software for the most mundane activities, including work, social networking, and even taking a cab.

Personal life

Spolsky announced his marriage to his husband, Jared, on social media and his blog. He lives on the Upper West Side of Manhattan.

Schlemiel the Painter's algorithm

In software development, a Shlemiel the painter's algorithm (sometimes, Shlemiel the painter algorithm) is a method that is inefficient because the programmer has overlooked some fundamental issues at the very lowest levels of software design. The term was coined in 2001 by Spolsky. The term is not to be confused with the Painter's algorithm (used in image compositing), as the two are entirely unrelated.

Analogy

Spolsky used a Yiddish joke to illustrate a certain poor programming practice. In the joke, Schlemiel (also rendered Shlemiel) has a job painting the dotted lines down the middle of a road. Each day, Schlemiel paints less than he painted the day before. When he is asked why, Schlemiel complains that it is because each day he gets farther away from the paint can, and it takes him longer to go back and put paint on his brush each time.

The inefficiency to which Spolsky was drawing an analogy was the poor programming practice of repeated concatenation of C-style null-terminated character arrays (that is, strings) in which the position of the destination string has to be recomputed from the beginning of the string each time because it is not carried over from a previous concatenation.

Spolsky condemned such inefficiencies as typical for programmers who had not been taught basic programming techniques before they began programming using higher level languages: "Generations of graduates are descending on us and creating Schlemiel The Painter algorithms right and left and they don't even realize it, since they fundamentally have no idea that strings are, at a very deep level, difficult."

Example

The programming practice that Spolsky used to make his point was repeated concatenation of null-terminated character arrays ("strings").

The first step in every implementation of the standard C library function for concatenating strings is determining the length of the first string by checking each character in the array, starting from the beginning, to see if it is the terminating null character. Next, the second string is copied to the end of the first, effectively concatenating the two. At the end of the concatenation, the length of the combined string is discarded upon return to the calling code.

In Spolsky's example, the "Schlemiels" occur when multiple strings are concatenated together:

After "Paul" has been appended to "John", the length of "JohnPaul" (or, more precisely, the position of the terminating null character) is known within the scope of strcat() but is discarded upon its return to the point after Paul and before George. Afterwards, when strcat() is told to append "George" to "JohnPaul", strcat() starts at the very first character of the array ("J") all over again just to find the terminating null character. Each subsequent call to strcat() has to compute the length again before concatenating another name to the buffer.

Analogous to Schlemiel not carrying the paint-bucket (or the string's length) with him, all the subsequent strcat()s have to "walk" the length of the string again to determine where the second string should be copied. As more data is added to buffer with each call to strcat(), that terminating null character also gets farther away from the beginning, meaning subsequent calls are increasingly slow—just as Schlemiel's path to his bucket keeps getting longer.

The problems illustrated by Spolsky's example are not noticed by a programmer who is using a high-level language and has little or no knowledge of its underlying principles and functions. "Some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels."

Publications