I didn't think they'd take our absence at the design meetings so personally.

Unless you're actually a developer, it's easy to forget that code is still written by people, well some of it anyway, and that means social, political, and cultural forces of the individuals and organizations who involved inevitably have an impact on software design. That's what Conway's Law to say about it, anyhow.

Do you think that means you could predict was someone's code will look like based on their personality traits?  I wonder what INTJ code looks like, for example?

Got any guesses?


Title: I didn't think they'd take our absence at the design meetings so personally.
Snarky: All the methods on this API take no parameters and return no values.

I can't seem to remember my name...

Transparent Authentication is one of those pieces of code - or at least setup - that developers run into over and over again.  Seems like you can't go more than two projects without having someone worry about whether customers can get to all their products via the same signon, even if those products are completely unrelated.  It sometimes feels like it's the business unit version of precautionary programming - e.g. "But we might need to let those customers cross products some day."  Follow agile and leave it until that happens - there might be a much better way to do it by then.  Maybe even a way to do it for free.

Speaking of code you write over and over, this is a very good article about the concerns developers face when confronted with any API or code that has to concern itself with dates and times...Noah Sussman on Infinite Undo: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

"I have repeatedly been confounded to discover just how many mistakes in both test and application code stem from misunderstandings or misconceptions about time."

Title: I can't seem to remember my name...
Snarky: What? Oh, I'm coding up the transparent authentication work item.