I spent a considerable portion of this evening reading New Programming Jargon. The article documents software jargon such as:
- Egyptian Brackets: When the opening curly bracket is on the same line as the conditional, and the closing curly bracket is un-indented on the last line.
- Common Law Feature: A bug so old that it's now expected behavior.
- Rubber Ducking: Talking out a software problem; it could have been done with a rubber ducky instead of a co-worker. AKA potato pairing.
I would like to add one to this list:
- Collecting Underpants: Announcing profit as the end result of the project, without having identified how the finished product will generate revenue.
(See http://www.robineldred.com/2013/03/collecting-underpants.html for more information on collecting underpants.) I first heard this term a few years ago here in Seattle when a fellow glassblowing student and I were discussing our day jobs.
There are some awesome little things that I've noticed in the first week or two of using Photoshop CS6. They're super useful in my web developer workflow, and they're just little things that really add up to save me a ton of time.
- With the marquee tool, a tool-tip shows the dimensions of the currently selected area.
- Holding Shift when dragging a new guide snaps that guide to the ruler marks.
- When creating a new guide from the View Menu, it re-uses your previous orientation selection (Horizontal or Vertical).
- Control + mouse scroll will scroll the image horizontally.
- I can finally paste a hex color (with the # ) into the color picker.
- Alt + click on the Layer Styles triangle now opens (or closes) all layer styles.
These small improvements to my everyday workflow are far more important than whopping huge new features that I (the web developer) probably won't ever use.
This is a story of doggedness, of persistence, of how attempts at a task one may try before success. If you're a regular This American Life listener, you may have heard this story before.
In the middle of the 17th century, a monk and mathematician (Marin Mersenne) published a formula for discovering prime numbers. His formula found a 21 digit number - 147,573,952,589,676,412,927 - which became mathematically famous as a super-large prime number.
In 1903, Frank Nelson Cole started his presentation "On the Factorization of Large Numbers" to the American Mathematical Society. He wrote Mersenne's famous prime on the blackboard, and then worked through the long multiplication to demonstrate that it was divisible by a nine digit number (193,707,721) and a 12 digit number (761,838,257,287).
Here's the most compelling part of the story. In the early 1900s, how long did it take Cole to find these two numbers and prove that Mersenne's famous number was not a prime number?
Three years of Sundays. These three years of Sundays were probably spent solving the problem by trying every possible solution - dividing Mersenne's number, by one number and then the next number and then the next. Three years of Sundays is 156 Sundays. For 155 of them, Frank Nelson Cole failed.
This is the marvelous thing about science, and scientists. Scientists are the type of people will fail for 150 Sundays, and still keep trying.
I have heard a few tales of the shame of Internet Explorer 6, the web browser famously despised by web developers (even its own creator). Submitted for your approval, here are a couple of those tales:
- Six years passed between the release of Internet Explorer 6 (2001) and the next version, IE7 (2007). Why so long? I was told that after IE6 was released, Microsoft decided that browser wars were won. The development team disbanded. I recently mentioned this story to an actual longtime Microsoft employee, who said "that sounds about right".
- An large technical organization has some critical business applications which only work in IE6. They will be upgrading all their workstations to Windows 7, which includes Internet Explorer 8, but not IE6. The solution? Instead of upgrading the legacy web application, this organization will provide virtual WinXp machines with IE6.
The rule of cheap, quick, and good is that you can have only 2 of them. Your project can be well built, and done quickly, but will be expensive. Or it can be done quickly and cheaply, but it will be crappy. This applies to web development, and probably to all software development.