At the old Cray Research campus in Minnesota the building floors were numbered campus-wide, rather than per-building. My first office was one floor above ground level within that building, but was considered 5th floor, as that building was built on the highest ground on campus.

This was more than just a geek thing though -- all the buildings were connected by skyways and the like, so it would have been confusing (particularly to visitors) to exit the third floor of one building, walk through a skyway, and end up on the first floor of another building.

Legend has it that the decorative colored patches of carpeting near the entrances and exits to buildings (or subsections thereof) would also guide you around the campus, if you knew the secret to decoding them. Unfortunately I didn't know how it worked, so I spent my first several months there making sure I followed coworkers to and from the cafeteria, lest I leave for lunch and never find my way back. I was never eaten by a grue, so I guess I passed the test.

Fed to hungry wolves in a zoo might be good. That is, if my cats don't do the job first...

What we really need everyone to practice, and thus could use education in, is critical thinking. Being able to listen to arguments put forth, be they politics, coding conventions, automaker press releases, software reviews, terms of a mortgage, environmental science, economic stimulus plans, or why we really need to get a puppy, then apply brainpower to analyzing the risks, benefits, drawbacks, and shortcomings of said argument is vital.

People need to learn to think for themselves instead of accepting what others say without further reflection.

It's simple really -- the same way you build up relationships with people outside the office -- around food and drink.

Things that have worked very successfully at my workplace (not all in place at the same time over the years):

- Friday Beer Bash. 3PM on Fridays (or most Fridays) have a self-sponsored beer bash. A few volunteers buy beer, some non-alcoholic beverages, and some chips/cookies etc. Everyone is invited to come, sit, and visit. Everyone is expected to chip in a couple bucks toward the food.

- Donuts. A set of people gets together at the same time in the morning once a week (Friday at 8AM when we did it) for donuts in the conference room. This isn't a "come grab a donut and go back to your office/cube" thing, but sit around the conference room and talk about anything and everything (work related or not). The participants are on a rotation to bring donuts, milk, and juice, paying out of their own pocket whenever their rotation comes around.

- Grilling. Pitch in together to buy a grill (or get one donated by someone, or the company). During months where the weather is nice enough, grill lunch outside, everyone bringing their own items to grill that day. Probably do this once a week. Organize payment for propane/charcoal however makes sense (chip in a buck once a week/etc).

- Cooking contests. An annual brownie contest, chili and cornbread contest, etc. A panel of employee judges gets to judge the contest, or everyone in attendance votes for their favorites. Have some sort of small prizes for the top three (e.g. small gift cards), funded however makes sense (company, entrance fee, proceeds from employees chipping in at the door to cover extras like beverages).

- Often the "self-sponsored" events above (beer bash, grilling, donuts if you choose to do it that way) end up generating more cash than actual costs. Whenever the amount builds up to a sufficient level, have a "free" pizza/whatever lunch paid out of the proceeds.

- Not quite a food thing, more of a beer thing, but start up a bowling league, company softball team, or something like that that gets people from different departments to join up around a common interest.

There's at least one notable substance that shares this property: Water. That's why it forms ice on the top surface rather than along the bottom/sides of the container (be that container a bucket, a river, or a lake). This very fact is instrumental to life on our little globe.

You answered your own question -- it's a "relatively simple tool". The tool has relatively little value-add or innovation compared to their other work. They'd rather spend their employees' time on developing software more core to their business.

The fact that this particular utility isn't particularly core to their business or seen as critically valueable or innovative is evidenced by the quick turnaround in releasing the source code. It's so far from their core business that it's just not worth their developers' and lawyers' time to rewrite/relicense/etc. the code to avoid the GPL entanglement, so the least expensive route to their objectives was to release the code.

If only I could mod the parent +1 Insightful and post... but I'll choose posting.

Most of the commenters do not realize that Joel is, at the heart of things, railing against over-complicated design more than praising lazy programming practices. Unfortunately that's not how he titled the article, and the reaction is thus predictable. I sincerely doubt he'd advocate sloppiness of code or design.

Unfortunately there are very non-junior designers who never make transition #3 (or maybe they regressed). As a result of their seniority and presumed competence, they are placed in a position to over-engineer solutions, miss market opportunities, and starve less elegant but competing solutions of the manpower and attention which bring the 50% solution up to a 95% solution. And unfortunately when their supervisor is too busy with other business concerns and a bit out of date with their technical knowledge, the necessary checks on over-engineering don't get applied. Couple that with politics/turf/etc typical of many businesses, and the non-over-engineered solution loses out. The entire organization suffers as a result, missing deadlines, solutions that aren't, and eventually it impacts the bottom line.

Personally I haven't made transition #4, however I'm starting to glimpse what it means. I'm not yet convinced that I care enough to make that transition, but I think that's a normal part of the process of growing.

Forget a mouse, forget wireless unless you're using a laptop.

The best dang "mouse" I've ever found is a Microsoft Trackball Explorer. Five buttons plus scrollwheel. I've used xmodmap to remap the buttons to help alleviate some nascent carpal tunnel symptoms. I own two of them, using one at work, and one at home. It does tend to get a bit gummed up on the trackball bearings, but about once a week I just swab around them with whatever pointy object is handy (paper clip, pen, thumbtack), and all is well. It'd probably help if I didn't eat junk food while working on the computer, and thus get all that goo on the trackball itself.

Unfortunately they stopped making it a few years ago. And when I say "unfortunately", know full well that I refuse to give Microsoft a dime for anything other than Trackball Explorers and keyboards, so you know the Trackball Explorer has to be awesome to overcome my loathing of Redmond.

I pretty much agree with the parent.

When I was fairly new to my company code reviews were reasonably helpful, as I was certainly not an expert in the areas I was fixing bugs, and there was a lot of undocumented knowledge of how various components interacted with eachother. As time went on and I became more proficient in these areas, code reviews began to be less useful.

I then moved on to taking primary responsibility for an important system library whose original developer left years earlier, and the current maintainer had been layed off. A year into that effort I was effectively the only person in the company who understood how the library worked, and as such was the sole expert on it. Code reviews for checkins were still mandatory, but about the only thing any other reviewer would ever find were minor stylistic issues -- the real bugs went undetected because the expertise required to detect them just wasn't reasonable to expect of anyone else.

Today I find myself working on deep close-to-the-metal code. Due to economic conditions it's just not feasible to have any overlap between engineers in the areas they're deeply familiar with (yes, that's a management issue -- city bus syndrome is a very real risk). For all but the smallest changes, others cannot fully understand the implications of my changes when they review my code, and I cannot understand the implications of the changes when I review their code. We still keep at it, but the effort rarely catches real problems.

Alongside those issues, I have been with this company for more than ten years, yet in my particular group I'm the youngest person with the least experience. With such a mature and historied team, significant mistakes are exceedingly rare, and even minor mistakes are uncommon. The most common thing we catch is someone forgetting to update the current copyright date in a file's comment block.

For the stated reasons, I currently view code reviews as generally just an extra hoop to jump through in the checkin process. If I should ever change jobs, I'm sure I'd once again appreciate having more experienced developers double-checking my efforts.

I know that some of the water comes up from the ground on Progress vehicles, so you are correct on that front. However I've watched the NASA TV channel quite a bit over the past year, and during the recent missions where the urine processing system was installed and fixed, it was definitely stated that water generated from the Shuttle engines is transferred to the ISS. The other poster is correct as well, in that NASA TV stated that the end of shuttle flights was part of the motivation behind installing the water recycling system.

I don't believe water transfer is done via a umbilical, instead bags of water are filled on the Shuttle and transferred oto the ISS. However, I could well be wrong regarding this point.

> Everyone drinks recycled urine and sweat every day.

While a good point, this may not be quite as true in the case of the astronauts aboard ISS.

A large portion of the water delivered to ISS comes from the Space Shuttle as it combusts liquid hydrogen to power itself while docked. Depending on the source of the liquid hydrogen and oxygen fuel (i.e. Is it generated from electrolysis of water? Condensed directly from the atmosphere? etc), it's possible a significant portion of their water supply has never been urine or sweat before.

And even if the liquid hydrogen and oxygen was water previously, do water molecules generated from hydrogen combustion really count as "recycled"?

-- CdM