Developer must reads

I had mentioned this a couple of times to people about how a book would fit into my must reads or where it would fit in. I figured I would try to dump that list here while trying to list them in a suggested order.

• Code Complete: 
• gets you thinking about how you structure and write code on the line or function level.
• talks about developing good coding habits (comments, naming) and skills (debugging)
• Pragmatic Programmer:
• starts talking about basic principles such as DRY, goes a step further then Code Complete
• talks about learning your tools and introducing some ideas of craftmanship
• Apprenticeship Patterns:
• establishes some ideas of how you can attack your pursuit of mastering your craft
• some ideas of how to stay organized and on track as well
• Refactoring:
• how to make your code better when you start to see the pitfalls of your approach
• can make it easier to know how to tackle or see/smell the possible problems and code smells
• Mythical Man Month:
• start introducing you to some on going issues with managing software teams and projects
• contains some timeless papers that introduce Brook's Law and No Silver Bullet
• Design Patterns:
• now getting up to lower system interactions and design
• starts to develop some common design terminology
• help you understand categories of problems and possible solutions
• Applying Domain Driven Design:
• takes design and development approach a step further
• ties in some design patterns, test driven development, and refactoring together
• starts to introduce you to architecture patterns
• you get to see the workflow and thought process of how a system comes together
• Patterns of Enterprise Application Architecture:
• now we get to how to establish components and layers of a system
• getting to applying the same ideas of Design Patterns but to a higher level of design

Now I need to finish a couple of those books and figure out new books to read (probably something on XP or Agile, TDD, continuous delivery, and DSLs), but that is a series of books that should probably be stretched out over the beginnings of your career (say first 2 or 3 years) because some of them will require a mentor or experience to start to grok (I'm still trying). 

It's probably debatable about where some of them appear (maybe Applying DDD before Design Patterns?), but these are all books that help regardless of technology. You'll probably enjoy having them on your self after your done as well (for reference or the reminder). 

Besides these books you should strive to master your primary programming language and dig into core technologies you use. After that you should also try to explore other languages and technologies even if they don't apply directly to your work.

I'm still trying to accomplish some of those last points but I imagine I'll always be going after something.

To learn is to abuse

I know sort of a strange title but I feel like there is some order of operations I'm following in my growth as a developer.

Learn thing -> abuse use of thing -> actually start to understand thing (hopefully) -> use thing appropriately -> learn new thing -> ...

My thoughts are interfaces are starting to change...mature? I think the .NET convention of an 'I' (ex: IEncryptionAlgorithm) prefixed defeats part of the point. I think that encourages us to see it as an interface code construct and not the required object description that your module/class/method wants. Perhaps Java's '*able' (ex: Runnable) is a better one. I hope that makes sense but I'm starting to think a lot of developers have focused on "this is a class" or "this is an interface" when both are actually an object description and when you take that in as a parameter you are saying I require these members. When I start thinking that way I start thinking that class methods should be virtual by default and that in general we probably don't use interfaces correctly (hell a lot of people don't use them at all I'm sure). Just having a class by default have virtual methods means we could mock a class the same as an interface. This does mean that you couldn't rely on a class's implementation at runtime but you shouldn't be programming against the implementation anyway.

Of course then I think about how it's easier to reason about a class if it's sealed up nicely. It's also easier to reason about code interactions if types are explicit, but then again it's easier to write tightly coupled code if types are explicit. Perhaps since class members are by default non-virtual, proper use of things like TypeMock should be encouraged. 

My biggest objection is if it allows you to open up the class and mock out a hidden internal dependency. If you needed to mock an internal dependency to properly test a class then perhaps it should be an explicit dependency instead (pass in through a parameter). 

Beyond mocking, interfaces should be encouraged as well since they are what provide real modular and reusable code. Type hierarchies only project shared/related implementation reuse which I don't think helps an application on a whole, just a piece of a subsystem or layer. They are best at describing related types, perhaps that's all they should be used for and not for passing around or interacting between subsystems.

I think this has been influenced by my interest in dynamic and message passing style languages. I also think this is just my understanding of object-oriented design hopefully increasing (you never can judge your own aptitude). So I'm thinking I'm leaving behind a phase of my understanding where I probably overly used classes and probably about to enter one where I overly use interfaces. Of course this only really matters in static languages where you have to worry about types. Maybe I'm over thinking things...or maybe I should just go back to Ruby or Python.

The Times, They Are A-Changin'

Ya, I've been pretty quiet lately.  Turns out I've been pretty busy lately.  See, I started this blog when I started a new job and a new phase in my career.  I just figured it was time to write some stuff and generally cultivate the idea of writing as an important part of my overall career.

Well, I've recently started at a new new job.  We don't need to get into all of the ugly details about how the old new job ended, suffice it to say that it was a career learning experience.  But we can all readily agree that I definitely wasn't happy there, and everybody knew it.  There was friction.  A lot of friction.  I wish them well and all, but it's just better for everybody that I'm not there.

So here I am at a new job.  This one is kind of an interesting mash-up of the industries of my last two jobs, but leaning more towards the former than the latter.  But the overall culture of this place is definitely a far cry from either of the previous two jobs at every level of the organization.

Anyway, being the new guy at a busy place, and trying to pick up various psychological pieces that have fallen over the past few years, you can imagine that I'm quite busy these days and that would explain the lack of recent posts.  (The 3 hours per day of driving doesn't help either, but that should change at some point.)  I was hoping originally that there would be more active contributors here by now, but it is what it is.

I can, however, take a moment to jot down some initial impressions of the new job.  A pros and cons list, if you will...

Pros:

1. It pays more.  That's always a plus.
2. Casual day every day.  Shorts and flip-flops are even acceptable.  (Though I despise flip-flops and would never be caught wearing such things, but shorts are a nice option on hot days.)  I'm enjoying sporting the t-shirts on my first week, but I imagine I'll mix it up with some polo shirts just so I'm not always wearing t-shirts.  Besides, why would I want to wear out my best t-shirts?
3. Software best practices.  None of this "we're a Microsoft shop" nonsense, but rather a corporate culture from the top down to use what works for good long-term reasons.
4. Good talent pool.  I especially hear great things about the lead architect here.  Basically, I enjoy working with peers from whom I can learn things and refine my craft.  This seems to be the kind of place where they focus on building a good team and let the team figure out how to handle the projects, rather than tightly defining individual roles and ending up with vaguely qualified people who don't actually work well together.
5. Great corporate culture and environment.  The people who work here seem to genuinely enjoy working here.  I don't hear any complaining, I don't see anybody slacking off or taking breaks to vent, none of that.  Everybody's busily working away at things they enjoy doing.
6. Venturing outside of my comfort zone.  One of my main reasons for leaving my previous previous job was because I was becoming too settled into my role.  I didn't want to build a career on being the guy who supports one legacy product.  Furthering that, I continue to not want to build a career based on one technology or one platform.  I love .NET, and I enjoy furthering my skills as a .NET developer, but at this job I'm currently doing a good bit of PHP (which we'll be converting over to .NET eventually, but for now changes to the existing PHP product need to be made).
7. Working with a friend again.  I've really missed daily interactions with the friends I made at my previous previous job, and it's good to be working with one of them again.
8. Change of scenery.  For one thing, I like working in a proper office park again (the variety of lunch choices alone is a welcome change).  But this is also 90+ miles from home.  It's in a whole new market.  If it works out, we can relocate here permanently (so far this is a 3-month contract gig with a possible hire, but if that doesn't happen I can just slip into another contract gig or something, no big deal).  But overall it's good to make contacts in another market.  If you spend your whole career in a single (especially small) market, you have to keep the bad contacts along with the good.  Old bridges are burning, and even if we didn't start all of the fires it's still best to avoid trying to cross them.
9. Individual accountability.  As Tony puts it, "giving you enough rope to hang yourself."  Basically, initiative and project ownership are welcome here.  If you want to do something that will be good for the company, then do it.  Just make sure you do it.  With initiative comes responsibility.  They don't expect us to be perfect, so some room for mistakes is acceptable.  But overall I like the idea that it's not all surrounded with a vast sea of red tape, nor are we begging at heels of the on-high masters for a little bit of leeway to do our jobs.  We're allowed and expected to be leaders here.
10. No offices.  Seriously, this is kind of cool.  The cubicles are very nice and very spacious, and everybody short of the CEO is in one.  The only office is for the CEO, because he clearly needs a place where he can close the door and be on the phone or hold a private conference without having to book a room or anything like that.  And even his office is all glass with full view of everything going on.  Even his monitor is facing outward so he's not hiding anything.  But everybody else is in a nice cubicle.  Some have better window proximity than others, but there's no avoiding that.  Generally, though, I find this brings a nice sense of flattened management structure to the whole game.  We're all peers, we're all members of the same team, we're all in this together.

Cons:

1. Long commute.  90 minutes each way is pretty exhausting.  It's likely that I'll get a cheap apartment in the area, but that still feels like money down the drain.  It still comes out to a net increase, but doesn't feel right.  (Though the added sleep available in a local apartment would be more than welcome.)  Maybe I can work out some remote VPN time instead.  The lead architect suggested that, and I definitely like the idea.  But until I get fully entrenched in tasks and heads-down coding work, I need to maintain a presence in the office.
2. The lead architect is hard to read.  He's clearly a nice guy, that much is obvious.  But it's hard to tell if he's being nice or if he's upset at something or if something else is wrong.  To be fair, the guy is probably tired as hell.  It's a demanding job.  And let's also be fair on my end of this interaction... I have below average body language and situational awareness and I'm paranoid as hell.  Not a good combination when dealing with subtle interpersonal interactions.  So that's more a con for me than for the job.
3. The carpet texture is uneven.  Seriously, this bugs me on a daily basis.  It feels like the soles of my shoes are unevenly worn or that I have something in my shoe or something like that.
4. There's no secret garden.  In the building there are two communal sets of men's/ladies' rooms, that's it.  This means that, on a not-so-fresh day, I don't have a private place to poop.  I'm thinking about the greater good of the community here.  You don't want to be around when this bomb goes off.  At my previous two jobs I had sought out, found, and retained designated safe zones for accomplishing this task.  Here there simply are none.  Sorry guys.

That's about it for now.  I'm sure I'll think of more stuff later, but I think this sums up the experience so far quite well.