“Being a Productive Geek”

Last night at my local NxtGenUG meeting, unfortunately our speaker couldn’t make it, so we ended up just having an informal “open space” session. I ended up at a table with some great geeks talking shop and discussing what helps us boost productivity.

My “crazy sleep thing” sparked some real interest, but we also covered some great topics, and I think we missed some – so I wanted to put my thoughts down here in the hope that you can find at least one thing to help you get more out of your day.

“The Crazy Sleep Thing” (Biphasic Sleep)

I don’t want to go to much in to this, since quite frankly it’s more than a tip, it’s a lifestyle choice. Besides, I have blogged about this a-plenty in the past. In short, I sleep less than most other people, and in two phases. If your interested, definitely check out my previous posts.

Binaural “Beats”

These came up when discussing biphasic sleep, but I feel they deserve a special mention because I have found them so useful. Binaural beats are basically the result of the collision of two different frequencies of sound in the brain. If the resultant frequency is of a certain type, it influences brain activity in a certain way (e.g. inducing sleep, increasing focus etc.).
Be sure to check out this site for some great free mp3s. If you are a Spotify user, I have found this artist to have some great tracks also (I use these all the time).

We also discussed how just having the white noise (binaural beat aside) on our ears can simply remove distracting background ambient noise. Also, noise-cancelling headphones are a great addition to your aural arsenal.

The Pomodoro Technique

I can’t remember when I came across this technique, but I remember it changed my working life! The Pomodoro technique is a simple technique to get your time under control. Check out the official site, and this great book for pointers on how to do it. I also put together a little WPF app, but unfortunately that has been benched for now. For me, personally:

Pro’s

• It increases focus by focusing on one task at a time.
• It improves estimation skills by getting used to timeboxing tasks into 25m iterations.
• It’s productive, since each iteration should complete a (or a definitive part of) a task, you can tick something off the list and know it is “done done”.
• It’s flexible – if people keep trying to interrupt you, you can tell them to wait and any time under 25m is normally acceptable (even if they make out it is not).
• It’s informative – Logging interruptions and reasons why tasks are taking longer than expected can really be an eye-opener. Some things will surprise you, others no-so-much. For example, I found I kept losing a lot of time prepping certain tasks, so I made document templates and automated parts of the process. I was oblivious to this before because it “only took 5 mins” – actually it took 10-15 and I got it down to about 30 seconds.
• It has character – this might sound odd, but things are likely to become more successful with you if you give them character and treat them like a “thing”. As an example, one of the rules of Pomodoro is “protect the pomodoro”. This gives the pomodoro identity in my mind and makes me want to protect it.
• It’s a metric worth tracking – since the pomodoro is a fixed unit (they are always 25m, no more, no less) they can actually be measured with accuracy. This is one of the reasons why I used it as a measure of productivity while doing my biphasic sleep trial.

Cons

• You have to say “no” – not really a con in my mind, but some people don’t like doing it, and others don’t like hearing it.
• It’s disheartening (at first) – when you first start, you will realise that your awesome productivity might have largely been a dream. I did. Being honest with yourself can be difficult.
• You will “lose” time - Don’t think that 8hrs/day = 16 tomatoes. You will NOT get that – focused work is hard and it will tire you out. However, you will actually be crossing more off the list. But I can tell you I had some interesting conversations with an old boss because he didn’t like the fact that I was “saying no because of some silly tomato” and then not having the “full 16 tomatoes” to show for it. Don’t try and account for every 30m block. You will need a rest, you will need the bathroom, you will get caught at the watercooler in a great conversation. Don’t beat yourself up, even if you are hitting just 6 tomatoes a day while starting, you will find you are probably getting more done than before. An important part of working hard is knowing when to take a break.

ORM’s

We had a short discussion on how Object-Relational Mappers help us remain more productive by allowing us to focus more on the domain problem rather than boilerplate data-access code. We talked about some of the different ORM’s available (NHibernate, EF4, ActiveRecord) and how those that embrace ORM’s get more done and deliver quicker.
We also talked about trying to integrate ORM’s into legacy code (by isolating the “new” code and replacing/refactoring the existing code piecemeal).

Learning & Study

The software industry moves at a tremendous rate. There are always new tools, frameworks, languages, patterns and practices being released/becoming the “latest trend”. This makes it really hard to stay on top of it all. Here are some pointers:

• Don’t generalise, specialise – pick a field that you enjoy (or find lucrative) and specialise. There is simply too much for one brain to handle.
• What you don’t know – find someone (or somewhere) that does. Since we are specialists, we may get caught off-guard and need to know something that isn’t in our core skill set. This is where the power of networking and good Google-fu come in. Build up a collection of good sources of information and use them.
• Use SRS systems – I came across SRS sometime last year and I tell you this now. IT WORKS. In short, SRS uses simple Q&A flash cards to test you. If you get questions right, they don’t get asked for a while, if you get them wrong, they do. I personally love Anki but there are others out there.
• Find the best learning style for you – different people have different brains. Different brains absorb and retain information in different ways (e.g. reading, visual, audio, doing). Do a test and find what works for you.

Know Your IDE/Toolset

I often get comments at work about how I flurry over the keyboard and things happen, classes are generated, code is moved, things deleted, snippets inserted, browser windows opened, commands executed, etc.
Spend time learning keyboard shortcuts (or making them) for actions you perform all the time. It really pays HUGE dividends. For example, I use the Sticky Notes application in Windows 7 a lot for getting thoughts that pop up out of my head and written down. So, I pinned it to the taskbar (right click it in taskbar), and moved it to the first item (next to the orb). Now, to create a note it is simply WIN+1, CTRL+N away. I can do that in under a second. Now time how long it takes to open it from the start menu..
Also, use tools like Resharper (my personal fave) and CodeRush and learn the features they offer. These really will make a huge difference in how much code you can crank out and make it much more flexible to refactor (refactoring is critical to clean code and should be easy).

Improve Your Base Skills

This is something I have started to work on actively recently. As a geek, I think these are:

• Raw problem-solving. Grab Brain Workshop. It’s awesome.
• Typing. Grab Stamina.
• Design. Buy a notebook and a pencil.
• Communication. Collaborate. Admit when you are wrong or don’t understand.
• Coding. Hack, then hack some more. Hack until you have nothing but stubs for fingers.

Obvious Ones:

These have been (and still are still being) done to death on productivity blogs, so I will cut the crap and just give them as a one-liner:

• Close Twitter, IM, Facebook and any other thing that pretends to add value to your life.
• Close email - your manager can actually wait for that spreadsheet that actually adds no business value.
• Stick to the plan – protect the pomodoro from the greatest threat – you.
• Remove distractions – wear headphones, turn off the TV, close the door.

And lastly – celebrate getting more done. Reward yourself for getting it all done. Leave early, take a long lunch and meet a friend. If work is funny about it, get a new job. Work should be fun. If it’s not, MAKE IT. Yes, I am one of those annoying people that enjoy Monday mornings because I look forward to work.
Recently, I have begun thinking my old “work hard, play hard” motto is broken..
Work smart. Work less. Play more.

Getting Started with DDD

What is DDD?

DDD is Domain Driven Design. It is a design paradigm that focuses on the language used in software and it’s alignment with the business domain. It uses binding context’s to create business-centric models which solve problems as they are modelled, described and discussed by the business/industry.

Why Do I Care?

Software is about translation – we developers take the business problems and translate it into a solution (provided by code). We not only have the problem of finding a solution (often with tight constraints) but also having to translate all the business lingo into geekspeak. But why? Why do we need to translate? Modern development languages have very rich support for integrating your own language into the code. Why do we add a problem that no longer needs to exist? We should focus our core efforts on finding the solution and not the translation in the middle.

Perhaps oddly enough – a great way to do this is by focusing on integrating the language into the solution from the outset. There should be no translation, the software is the translation. This “integrated” language is the common language, the ubiquitous language.

What Will DDD NOT Do?

• Dictate/define a new testing format/practice (you do have a testing practice, right?). TDD’ers can work fine, although BDD’ers naturally have a better fit since they are already a step towards using the ubiquitous language in their behaviour definitions.
• Change the way you work overnight. The DDD concept is relatively simple. But implementing is hard, we need to change the way we work. Namely, us geeks need to get our social skills sorted, talk to the business and perhaps more importantly - truly understand the business. This may mean dropping the horrible “I’m more intehwigent than you” complex that (sadly) many geeks seem to have. Be bold. Don’t be afraid to say “I don’t know” and ask for clarification. The business will thank you when they actually have working, useful software. A good BA can help here in facilitating these talks.
• Give you the solution. DDD is no silver bullet and goes no way to actually helping you solve the solution (we have to get paid to do something right?). However, DDD will get you so much closer to the problem that it will make it easier to solve in the most elegant way possible.
• Get it right, first time. Due to the fact that us geeks spend a lot of time studying/learning to stay just on top of the software industry, we unfortunately have little knowledge of other business domains. This means we need to learn a lot. And we will get it wrong. Our first few designs will be totally out of whack with what the business is actually trying to communicate. That’s fine. Do it again. DDD will force you to rethink and work on your prototyping skills. Rapid prototyping and spike solutions will become a much larger part of your arsenal because we are going to get it wrong. Get it wrong while it’s cheap!
• Prevent good technical design. Some geeks have aired concerns that all these classes with “jumped-up business terms” are polluting their awesome, technically perfect and soundly-engineered code. Well, I am a straight-shooter, so: Grow up. If your design skills are that good you should have no problem isolating the (internal) technical design requirements from the language used. For example, there is nothing to stop a “TPSReportData” inheriting from the “XmlDataSource<T>”. The point is, when we have code being called in our domain model, we are talking about TPS Reports, not XML.

What WILL DDD Do?

• Get you much closer to the business. Both the people and the problem. This is rewarding on two levels: firstly, it’s great working with people - building relationships, trust and knowing you are genuinely helping them out. Secondly, being closer to the problem means you are more likely to find what people actually want and need. There are many times when you actually get to the crux of the problem (after several iterations) and discover it can be solved VERY easily. As opposed to the up-front (complex) design originally envisioned.
• Make you more employable. Increasing domain knowledge will also have the side effect of you developing some great industry knowledge making you more employable within that sector (ask any DDD’er that has worked a lot in the finance or medical industry).
• Make you VERY aware of the language used in code and tests. The language becomes critical to everything. I have found a real plus of this being that I have ditched a lot of confusing code. If I can’t articulate tests/code in the business language (when working on the domain model) then I question why? Often, it is because I have either misunderstood something, or I am trying to make the “thing” do too much and this responsibility lies in the “other thing”.
• Make you focus on the model rather than worrying about technical nuances/design. Now I know some of you are probably jumping around saying “the technical design is important!” – yes, I agree. But put simply, it is not as important as the domain model. Why? Because the biggest (but often neglected) constraint on the technical design IS the domain model! Get the model right first, then you can produce the cleanest, technical design to implement that model.
• Cause you to create classes with similar/identical names for different contexts. I thought I would mention this one in particular since it is one that people often have problems with. Let’s say we have a “Customer” object. We are modelling the base customer details which includes name, telephone number etc. All good. We then head over to focus on the billing section of the application. Oh, Customers need a payment method (e.g. credit card) so on goes the “PaymentMethods” property to the Customer object we created earlier right? WRONG. We have two different domain concerns here and they should be isolated from one another. Most modern development languages support namespacing, which is a nice solution to this problem. A “User.Customer” is not the same as a “Billing.Customer”, treat them as such.
• Require loosely-coupled “modules” which seem to add work. Think of modules as the “areas of concern” (e.g. the user of the application above is not the same area of concerns as billing). These modules need to be in isolation and loosely-coupled from other modules (e.g. we don’t use a “User.Customer” in the billing department. People can view the creation of these classes as overhead. Much like other principles/practices (such as automated testing) this cost is far outweighed by the benefit. The time spent on ensuring your model is right will pay huge dividends when that old chestnut CHANGE rears it’s ugly head. Changes are likely to be to a single “module” which is isolated so doesn’t cause ripple effects. Good practices are all-too-often dismissed for time-wasting. I say to these people this:

“Next time you go for surgery at the hospital, tell the surgeon to not worry about scrubbing up since most people don’t get infections during surgery.”

Would you? Of course not! Why? Because we know that if surgeons didn’t follow good practice then more problems would occur. Why is software any different? Yes we are still a relatively young industry (compared to medicine and other forms of engineering) but it doesn’t mean we can’t TRY to instil good practices now.

Getting Started

Like I said, you can’t “go DDD” overnight. But you can start right now. Grab a pen and paper, map your current software architecture with namespaces and sample class names. Think about how data is stored/retrieved – do you have monolithic “Customer” objects? Are there tables/objects that have data that is actually something else? Do you have geekspeak bubbling up into your domain layer? Do you even have a domain layer? (I am not kidding, I have seen many solutions with a “domain” class that has nothing to do with the domain model).

Now on a different piece of paper, map the business units, the terms they use and how they interoperate with each other. Now compare the two drawings, different much? Mine were! Now think about how you could develop the codebase into something more like the business model. Then do it. Rinse and repeat.

Focus on what the business wants and needs. Ditch the rest. This process is much easier when you are all talking the same language.

Links/Resources

• “Domain Driven Design” by Eric Evans. The “big blue book” – THE book for DDD. I personally found this a hard read since I don’t cope well with narrative books. However, solid knowledge and very informative.
• Domain Driven Design on Wikipedia.
• DDD Community Site
• “An Introduction to DDD” by David Laribee on MSDN
• “ThinkDDD” by @JakCharlton
• Rob Conery and James Avery discuss DDD on the ALT.NET Podcast
• Eric Evans DDD Talk at SkillsMatter.

To Close…

DDD is still very new to me, I have yet to do a project with it in the workplace, but some changes (for both me and the workplace) are required before I can do this (me first, lead by example). However, the concept is simple, and solid. I feel the same way about DDD as I did when I first started getting into TDD. It felt right. Almost like I have woken up some long-forgotten natural geek instinct.

I am now focusing a lot more on prototyping and understanding my domain. I will be honest, I am finding it hard – there are a lot of new terms to digest and understand (not just smiling and nodding). However, the more questions I ask, the more I learn and the more I am simplifying the model in my mind – which I can then apply in code. To be honest, I find it energising since it is enabling me to focus on what is REALLY required. And we all know how much of a fan I am for getting things done.. :)

Onwards and upwards!