New Dell signage in the Austin airport.
Wow, check that out!
Why it matters long term? As an academic says:
“There is a very strong track record of places that attract talent becoming places of long-term success,” said Edward Glaeser, an economist at Harvard and author of Triumph of the City. “The most successful economic development policy is to attract and retain smart people and then get out of their way.”
(From Little Bird)
One of the “tricks” you learn in programming – “soft skills,” apparently they used to call them – is that you should match the style and formatting of the code you’re editing. If you’re starting with your own code from scratch, no problem, go crazy. But if you’re like most developers in the world and maintaining an existing code base with incremental improvements, you’ll more often than not be editing and adding to existing code.
To make the code easier to read and understand (a broader, high-level goal of programming) it’s best to figure out and match the style being used already in the code. In contrast, you could do things in a different stye – use closures and callbacks instead of more procedural things, or two spaces instead of two tabs, etc. Young programmers struggle with this: like skateboarders, they want to try new tricks and show them off. The code becomes more confusing, harder the understand, and thus more error prone (someone added code without fully understanding what was going on), and slower to change (it takes a long time to understand).
So, there’s that: code in the style of code you’re editing.
In the white-collar world, this same problem exists, except it’s PowerPoint and Word documents, not code. Many “young white-collar workers” I encounter don’t adapt to the existing style too well. They go off and do their own thing, often not consciously. Successful work documents typically follow a very tight pattern (sometimes called a “loop” in slides) for all the same reasons that you want your code to have a consistent style.
Once you’ve figured out and started using the style of an existing chunk of text or slides, the next stage of knowing what the fuck you’re doing (pardon the jargon, a technical term in cube-land) is to project out how that style would apply to entirely new parts of the subject at hand. Did your boss just ask you to “go fill in that those pages on AsiaPac – you know, like 4 or 5 pages”? What she means is “figure out the style and pattern we’re using in the other 20 pages of the report, and do exactly that…and if you can’t figure out the pattern…why am I paying you so much? In fact, if I’m telling you this, why am I paying you so much?”
As it goes with so much of white-collar work, your job is to ensure that your boss doesn’t have to tell you how to actually do something.
(via CA’s DevOps report.)
Scenes from the weekend.
Most of the hierarchy found in the traditional firm must be eliminated, and the walls between functional staffs must be destroyed. You can’t move fast, no matter how good the systems are, if turf fights among functions are the norm, and if even routine decisions must be processed through numerous layers of bureaucracy.
Tom Peters (via fadingcity)
Over some ribs and brisket the other days a friend of mine called this notion “management debt,” which seems right. The analogistic potential of “technical debt” is limitless!
Now you’re a zombie with bags.
I’ll put it over leftover chili! I don’t fuckin’ care.