aussie coder . com

Just to document some things I’d like to achieve this year, unless I completely forget or other priorities take over

1. After having listened to the last couple of Hanselminutes episodes I’d like to study a bit more on the current architecture standards coming through the .NET community.  The shows I am referring to are:

• Show 140 – Rob Conery on Domain Driven Design
• Show 145 – SOLID Principles with Robert C. Martin
• Show 146 – Test Driven Development with Scott Bellware

Basically, all these three shows have got me back into being interested in hearing more Hanselminutes (I chose the shows to listen while driving for a trip), but more than that they resonated with what we’re already trying to do, or to achieve at work.

For instance, although we probably don’t really follow DDD, we do have a pretty tight cohesion to the companies domain, terminology, and processes.  A lot of what Rob Conery said actually applies to how we try to go about our software development, with the planning and dialogue we open with our users.

So the interest there would be to study a bit more of the practice of DDD, and maybe not taking the practice to heart and keeping to every principle, or pattern – but see what we’re already doing that works similar to the framework and what practices related to that we could adopt that would make sense.

Similarly, listening to Scott Bellware on Test Driven Development, although we are writing tests semi-first (I tend to unless I am having a hard time wrapping my head around some code, in which case I spike then wrap tests), I came to realise I’m probably under-thinking TDD/BDD.

My methods are coming out much like they would if I didn’t test, with overly complex tests – not simplified enough for it to be proper TDD.

Now that is kind of the way the boss wants it and the way we adopted it, but I don’t know if I’d call us a TDD shop (and I don’t think he would either, even if we are a testing shop – we work for a private company and are efficient and producing quality code anyway, so it’s kind of semantics for us).

The thing I don’t think I do enough of is considering the behaviour, or the aspect of what a method is trying to achieve before I code it up.  I mean, I understand I want to get from A-to-B with this method, I want it to achieve X reason for existing – but I don’t frame that in “for this unit of work, this is how the guys on the floor are using this, and this is the process it would go through, so the method should behave accordingly.

I honestly don’t think it’s that far of a leap from where I am now with my thought patterns, but it’s about taking that time to work that flow instead of thinking of it as purely code that achieves a function and tests that will prove that code does that function.

2. Become basically familiar with another language, either Ruby or probably Python.  This isn’t learning something so I can use it on a daily basis to a high degree – but just learning it for readability, become familiar enough so I understand what other developers are talking about, and just learn the basics for interest.

3. Read more code.  I’m pretty insular or isolated with the code that I am doing, and I do things my way and it works, but I think I need to get back to listening to podcasts, watching the rest of Rob Conery’s MVC Storefront series, and just get a better idea to improve my own development.

4. Prepare for meetings better.  Hopefully I won’t be attending that many meetings in the future, but I had the thought the other day that I walk into a lot of meetings with not much idea of what to say, and I end up being in a situation where I can be caught unprepared or put on the spot, or am just reacting.

So the idea here is to push more for an agenda for any meeting I’m attending, to come with some idea of what I’m going to say, some planned points on paper, and to try and stick to the topic – there’s nothing more that I hate than a meeting that is just all general business of whatever anyone can think of at the time, and I find a lot of the “Monday morning scheduled meetings” that occur weekly for everyone to catch up, generally, just meander unprepared and anyone will bring up whatever is on their minds at the time.

5. Self-manage better.  We have Fogbugz at work, but it’s a personal productivity tool, and if you don’t use it, it’s not really enforced.  That’s fair, but I do know I work better when I have a list of tasks in front of me, when I can cross things off and feel like I’m achieving things.

The past year while I had a project that kept my interest I’d find that I’d do the next two-four weeks scheduled work within the first few days, because I was driven, interested, and had a plan of what I had to achieve.

I have to find a good balance of spending time setting up and managing myself, so I am more productive in the other times, rather than spending all my time trying to just work and get through things, and either be caught out by things I haven’t done, things that I haven’t done timely enough, or finding myself with time that I just don’t have enough to do because I haven’t scheduled enough into my time.

There’s probably more I should be doing, but those things came to the top of my mind while driving home from my trip and I think they’re a good start!