I always see this book on the shelf as I walk through the R&D department, which I'm doing a lot more again since I switched back to the team I was on 2.5 years ago. It's a recent change, only the last week, and it's been a challenge trying to transition and get things cleaned up as I move between teams. There's always a lot in the air I don't want to leave for the next person to get my role. Fortunately, the new team is in better shape now than when I was last there. Seems like that pesky 1.5 FTEs of support with a hard push down is gone (and any extenuating issues), as well as offshore coordination and one of the teams that was fun, but not a good fit (resulted in a lot of context switching).
My first task has been getting new contractors interviewed. Keeping your capacity where it should be is always right near the top of any list at work. We're still date driven despite being agile, so every time you're short a resource, it's muddling up your existing resource load (I know - demand should fit capacity within an iteration and delivery is reduced to meet capacity, in theory - but you don't need to have a debate with me about why that doesn't always hold true). One of the very few externals we brought in for a quick onsite interview couldn't even explain MVC. Another wasn't familiar with Using. And just in case you feel that's esoteric language keyword knowledge, that's just an example, not the only question. I sometimes get the impression they're pulled into consulting for a very VERY specific purpose - such as practical implementation of existing MVC, or because the actual developer left for a better job - and never make the effort to go back and learn any of the language basics, or even their framework or pattern basics. Don't believe me? Then I'll let you interview the one who couldn't differentiate between abstract and interface next time. I'd have accepted a rant about why you can have multiple interfaces but there isn't multiple inheritance in C#, despite it not being completely the point. Anything to show you were interested in your language of choice and were thinking about your craft. Particularly at contractor rates.
Back to it's happy bunny Life. Get One. I've always thought it was there for semantic analysis purposes. After all, it's in the R&D space and we do a lot of work with content. I've been to presentations by co-workers where someone talks through million by million citation grids, groupings, big data, and RDF. And happy bunny is sitting there right next to the anti patterns book and two shelves of books and academic journals with stern warnings that it's not your library; don't take the books. I pictured one of the R&D folks I know running their algorithms and big data analysis vs. a content set where happy bunny was one of a million items, and then opening the book to validate the search worked against happy bunny as an edge case (yes, the edge case is the happy bunny path in this case - my love of irony has influenced my perception about why the book is there). But given all the five star reviews on Amazon for happy bunny, I'm now of the opinion that someone in R&D probably just really likes happy bunny and it cheers them up after a day full of algorithms and comparing elastic engines.
No comments:
Post a Comment