I'm coming out this week to Redmond again to visit Microsoft and interview, this time for a developer gig.
That last time, I was interviewing for a PM gig that I didn't entirely understand, and the vetting process before coming out was not particularly rich. I was an awful fit for that job, I think, and in retrospect, I'm not even sure how they came across me because I had never applied for it. But it was still a good experience, because it gave me a peek into the culture that I would never have had otherwise.
When I lost my job in April, the day after my honeymoon no less, my game plan became pretty obvious after a few days. I had to broaden the search and think more nationally in terms of the kinds of places I wanted to work. I also wanted to use the time I wasn't working (which has been a lot longer than I expected) to try new things, learn new things and develop my side business (mostly CoasterBuzz) into something that could sustain me for the duration. I feel like I did most of that.
Locally, in Northeast Ohio, the work potential is the worst it has been since 2001. The smaller short-term contract stuff kept leading me to the "over-qualified" response (seriously, for three months, doesn't that make me a low-risk bargain?), and the three really solid gigs I encountered after long interview processes ended up in two "we can't spend that money right now" endings and one that went to one of my mentors from two jobs ago, who also got let go and was clearly the better candidate, by a long shot.
We're not at all tied down here in any way other than real estate (another dismal market), so I've been targeting a number of well-known companies and watching their job postings, mostly in the Pacific Northwest and Central Florida. Good choices, too, as Forbes recently named Seattle as the best place for tech jobs, and Orlando was third place. I never forgot the trip to Microsoft, and going to conferences and what not just made me want to be a part of what goes on there even more. It's a far cry from the start-ups I've been working at, but internally, there are a lot of people taking initiative to better their product areas. Who wouldn't want to be a part of that? I've been watching the boards for start-ups and small companies as well, but the number that are hiring in these regions seems to be nearly zero.
This trip feels much different already. I had two brutal phone screens that were far more intense than most face-to-face interviews. The vetting process was solid and I go in feeling like I understand the gig, they understand me and flying me out there is a good decision for everyone. I'm really psyched for the trip. Plus there are bonus points because I'll have a short window to visit family out there.
I'll share more about the process after I get back, and hopefully have good news to share as well!
I've been thinking a lot about all of the frameworks we have now to use with our, uh, frameworks. There's a framework to solve every problem. Dependency injection frameworks are of particular interest to a lot of people because they make unit testing ridiculously easy. They're also well suited to something like ASP.NET MVC, where you're trying to make as few dependencies as possible between the various concerns.
But I was chatting with someone the other day about all of the frameworks for DI, and he expressed concern that he wasn't comfortable depending on a lot of external libraries for some things. His view (pun intended) was that you start to junk up a relatively simple framework like MVC by putting all kinds of other stuff into it to support another framework, and that introduces different kinds of risks. For example...
- You're decorating everything with attributes.
- There are all kinds of configuration files or classes to do the hookup.
- You'll replace the standard controller factories, perhaps giving new devs one more thing to learn about for your project.
- Global.asax becomes even more of a dumping ground (more because of the placement of routing there plus DI framework init).
- It just feels dirty to some to be using another library you don't own.
I think these are all valid concerns, though the scope of them depends a lot on your specific scenario. The funny thing about using frameworks that are named after design patterns is that everything becomes an academic debate about where and how you do this and that. And if you're a junior developer wanting to impress your peers, or a senior developer not wanting to set a precedent for the "wrong" thing, you want to get it "right."
Many of the examples published on the Web and in books suggest simply using different constructors on MVC controllers to handle DI in a rational way that doesn't require an additional framework. That allows you to keep the default controller factory and let your unit tests instantiate them with your mock objects. I read a lengthy discussion forum thread that suggested this wasn't proper either because you aren't testing the way that the objects are created in the real production environment. I thought that was a pretty thin argument, but I do see the point.
I got to thinking about how the provider model introduced in ASP.NET 2.0 worked pretty well for a lot of things, and it was used effectively before that in wiring up swappable data access layers on various apps. Creating a lightweight container to do that wire-up would be pretty straight forward, even if it did reinvent some wheels.
I don't really have a point that I'm after here. I guess these are things I'd like to hear people talk more about. What are you doing in the real world to keep things testable and maintainable?