Category Archives: learning

When a talk goes badly…and a lesson from the Space Station…

A month or so ago, I gave a talk at the ACCU Oxford user group on unit testing threaded code. And a long story short, it didn’t go all that well. Initially, I was quite disappointed, and frankly felt like an idiot. The drive home in the car was quite a solemn affair, my friends who’d come with me were being supportive, but that didn’t change the fact that I’d basically delivered a turkey.

I’ve been mulling this over for the last month, and one of the books that helped me a lot was Chris Hadfield’s An Astronaut’s Guide to Life on Earth. And one of the points he makes in the book is to view negative things as an opportunity to learn.

Until recently, I didn’t cope will with negativity. My friends will agree that I’m very harsh on myself and I take things to heart far too easily. So having read Chris Hadfield’s book, I was sufficiently challenged, and decided to take a different approach to this. 

So whereas before, I’d have not quite imploded but being glum about it, I decided to view this as a chance to learn. So here we go.

Lesson 1 – Know your subject matter inside out.

Sounds like a no-brainer doesn’t it?  But I’d chosen a very complex topic. Probably too complex if I’m completely honest with myself, and what’s worse is that I said it in jest and all of a sudden I was committed to doing it.  So lesson 1a, is don’t jest Winking smile 

But I digress.  I’m passionate about writing unit tests for code, I think it’s something we should do as developers, no matter what the language we’re coding in. For example at this moment, I’m researching using a PHP unit testing framework. 

But unit testing threaded code is hard.  VERY hard as a matter of fact. And there was a perfectly good reason Google didn’t return much results, and that’s because it’s not something a lot of people do. 

But worse than that, I wasn’t all that familiar with threads either. Sure I have a rudimentary understanding of them, and know enough to be dangerous.  And frankly when presenting to a room full of experts, that’s not good enough. It’s bordering on disrespect, so to those who did attend and read this, I’m sorry.

But if you’re going to give a talk on something, make sure that you are fully versed and confident in what you’re going to say. I wasn’t and it showed. Badly.

Lesson 2 – Don’t use an IDE.

Another mistake I made was to have my code in an editor. Not so bad maybe, but unless you plan on doing live coding demo’s then put it on a slide. That way you’re facing your code, rather than craning your neck around to see what you’re doing on the projector.

I found I was doing this a lot, and lost my place a few times because of it. It also involved me dropping out of the presentation software, and in to the code window, which meant a lot of fiddling and faffing about.

So put your code on the slides unless you are doing a live coding demo, or doing a practical workshop or something like that.

Lesson 3 – Keep it simple

We all like to look cool don’t we with our snazzy slides and clickers. But having chatted with Hubert who is a veteran speaker and trainer. He advised that I simply put my slides in PDF. 

And that’s good advice. Imagine, you turn up to give your talk, and your laptop goes bang. What if the laptop you borrow doesn’t have PowerPoint?  That’s when a PDF is damn handy, especially when you have it on a USB stick.  You can give the talk on virtually any computer with a PDF file.

Also Hubert advised that rather than use expensive clickers, I should use my mouse to travel through the slides which is just as effective.

Basically keep it as simple as possible so that nothing overly complicated won’t break things.

Lesson 4 – Seek feedback, the good the bad and the ugly…

After the talk, I felt quite embarrassed, but I knew that if I wanted to get better, I needed to hear the feedback, no matter how bad it was. And I was given it. (Hence this blog post)

Sometimes the feedback you get isn’t what you want to hear. And I’d argue that sort of feedback is the best type.  But it’s VITAL that you don’t take that personally. It’s not a personal attack! It’s an observation, and after all if you’ve asked for feedback whether good or bad, then you’ve got to have the stones to be willing to receive the bad as well as the good.

And it’s vital you act on it. Otherwise you’ve wasted the time of the person who was kind enough to give you that feedback. The further consequences then would be that they’ll notice you didn’t act on it, and they’ll refuse to give you feedback in future.  And in doing so you’ve cut yourself off from a chance of improving.

Lesson 5 – It happens…

Sometimes, talks just don’t seem to go that well. You could have an off day or something which caused you to lose focus when giving the talk.

And sometimes, that’s how it is. A thousand and one things can cause a talk to nose-dive. The important thing is to recognise this, and not let it get you down.

Lesson 6 – There’s always next time.

You’ve delivered one bad talk. In the grand scheme of things, so what? It’s not life and death.

When Chris Hadfield went up to install the CanadaArm2 to the International Space Station in 1995, he had an irritation in his eye while he was carrying out a space walk to install the arm. His eye starting watering and stinging pretty badly, and in space there’s no gravity for the tears to run away from the eye, it just stays there building up. Right up until it goes over the bridge of your nose and starts messing around with your other eye.  On earth that’s no big deal, but in space that’s pretty serious.  You can’t exactly open the visor and give your eyes a rub as that’ll end badly for you.  Eventually his eyes cleared up, and he finished his work.

But my point is, that one bad talk doesn’t mean the end of your career or anything that dramatic. Sometimes it just doesn’t work out the way you’d hoped.  And that’s ok. 

As long as you learn where you went wrong, then you can smack it out of the park at the next talk you give.

Lesson 7 – Attitude…

Something Chris mentions in his book (I’m not on commission, honest, but it is a great book!!).  When the Soyuz is in orbit, or any solar panelled space vehicle for that matter, it has to turn it’s solar panels towards the sun.  This is known as the vehicle’s attitude.

And the same is true for us too. Our attitude dictates how we respond to certain events.

I’ll admit my confidence did take a knock after this talk.  But that was a matter of attitude on my part. I could chose to let this crush me, which is what usually happens, or I could decide to use this as a learning experience. 

That gave me a fresher perspective and the chance to learn from my errors, rather than risk repeating them again. I can’t recall who said it, but “those who fail to learn from the mistakes of the past, are doomed to repeat them.”

Lesson 8 – There are positives in there somewhere too..

So my talk bombed, badly frankly. But what it did do, was spark an interesting discussion on how we could go about writing unit tests for threaded code, and the techniques that could be utilised.

So even if the talk doesn’t go well, some good can come out of it. And we should remember that as well.


So there we go. I’ve learned a lot from things going wrong, and often times that’s when we learn the most. I have to say that the people at the meeting were very kind and supportive in their feedback, even if it wasn’t what I wanted to hear.  (They were far too nice!!) But they were also willing to give support and encouragement.

Initially I wasn’t going to do another talk this year after that one bombed so badly, but I’ve since been encouraged to do another lightning talk, so we’ll see if I’ve really learned my lessons.  So watch this space.


ACCU Conference Retrospective

I did plan to write a series of blog posts at the end of each day of the ACCU Conference in Bristol, but between having far too much fun learning, and having zero energy by the time I got home, never mind zero brain power, I thought I’d do a write up in one big posts with some “Match of the Day” style highlights.

Day 2 (Tutorial was day 1 for me…)

Day 2 kicked off with the ever energetic and lime-green nail coloured Pete Goodliffe bouncing around the stage giving a talk on how to become a better programmer. He covered various aspects of becoming a better programmer, but the main point I think he made was attitude. Our approach to becoming better. This challenged me (yet again! Thanks Pete (: ) because while I’d been moving forwards to becoming better, my attitude at times sucked!  Frankly.

Pete also issued a challenge to us all.  We were dared NOT to go to the stuff we’d be comfortable with, but to stretch ourselves and head off for talks that were way outside our comfort zones, and attend as novices. (Wasn’t hard for me, I was a novice at most talks!)  That way everyone would leave the conference having learned something they didn’t know before.

After being filled with coffee and all sorts of pastries and such, it was on to Seb Rose’s talk on Low fidelity approaches to software development. He spoke about how we tend to bite off more than we can chew, working on something that’s almost ready and will stay like that, and never get delivered.  He made a quick point on the waterfall and the biggest issue with it, was that everything feels ok until all of a sudden bang!

Seb also made the point that feedback is a very important thing to make use of, because it allows us to see where we’re at at the moment. It also gives us a chance to take stock of what we’ve done, and what our customers think. And pointed out that the Military use the Plan – Do- Check – Act which gives feedback that allows us to change the next part of the plan.

He quoted Father Ted, the scene involving Ted explaining perspective to Dougal making use of a toy cow to explain that this one was close, but the ones outside were far away.  And it’s the same with software projects.  Until we start working on something, we can’t understand the full scope of the problem we’re working on.

From there it was on to Mike Long’s talk on How To Talk To Suits, where I learned a great deal about speaking to business managers. And I thought I already did this pretty well, as I don’t like bamboozling people with technical jargon. This also included a practical workshop to work through which was good fun.

Mike spoke excellently on this, and talked us through a bunch of business clichés, such as a Business Case, where we need to present to someone for an allocation of resources for the stuff we want to do. Time is money, Mike pointed out that from a business perspective, Time matters more than money, indeed, I’ve often come across this in my career up to a point, “we don’t care how much it costs (within reason) but we must have it by tomorrow”.

Mike also used real world examples to explain that money comes in many flavours.  That is to say that if we wanted a new server for example, and our hardware budget was fully allocated, then we could STILL get the money but from another budget, such as an innovation budget for example.  Hence the term that money comes in many flavours.

There were some great lightning talks as well, and Chris Oldwood did some stand up which was great fun, and it’s a shame it wasn’t recorded, as there were some belters, who knows he may pop them on Twitter.

Day 3

Day three kicked off with frankly an amazing keynote talk from Axel Naumann on how CERN use C++. And it was awesome to hear how C++ was used to process data from the Large Hadron Collider. But what was epic for me, was to see some of the stuff that the LHC produced, and the fact that it was all completely open.  Axel also spoke about an experiment they’d carried out where they fired neutrons at nuclear waste that shortened it’s half-life but also generated energy!

Then there was an interesting talk from Kate Gregory and James McNellis on Modernising Legacy C++ in which they raised some excellent points. They made the point that we should compile C code as C++ as we’ll get better type checking.  They also made an excellent point that the warning you ignore isn’t a warning.  So Kate and James suggested that what we can do to modernise legacy C++ code is to do the following:

  • Increase the warning level and compile as C++
  • Rid yourself of the pre-processor.
  • Learn to love RAII (Resource Acquisition Is Initialisation)
  • Introduce Exceptions but carefull.
  • Embrace Const
  • Cast correctly

After that, there was an excellent talk by Chris Smith and Mark Upton from Redgate on what’s wrong with sprint retrospectives and how to fix them. This was a very practical talk, where we there was a fair bit of user interaction where we shared our experiences of working using retrospectives. They shared their experiences at Redgate in improving their retrospectives and had a lot of good ideas I plan to put in place at work.

Day 4

We were treated to a great opening talk where Alison Lloyd went through some case studies of various mistakes made in industry and what we could learn from them. I was scared that there’d be photos of Therac 25 victims initially, however there wasn’t anything like that.  Alison started her talk with a sobering discussion about diarrhea and how it caused so many deaths. It was quite educational and challenging to hear the devastating effect that this had on humans, and HOW it caused so many deaths as well.

This talk was running through my mind for most of the day if I’m honest, and I’m pretty sure I’m not the only one who was challenged and moved by what I heard in those opening 15 minutes.

Day 5

I had the unfortunate experience of turning up to a talk, and needing the loo, popped out for a second or two.  When I came back the door magnet engaged, so I couldn’t get back in. I didn’t want to knock either as I didn’t want to disturb the chap giving the talk.

However, Anthony Williams’ talk on C++ Atomics was very good.  I didn’t understand all of it, but I certainly got the gist of what was being said.  Essentially, don’t use atomics unless you have to.  You should only use them if you REALLY need the performance gains it will give you, and even then you should only use the memory_order_seq_cs (Sequential Constant) as the others are horribly complex, and you should only use them if you REALLY know what you’re doing.

There was a spare slot on the Saturday, so I volunteered to fill half of it with another chap, the only issue was, Roger and Kevlin were also speaking, so I knew that most if not everyone would be at one of those two talks, so I expected nobody to turn up to the talk I gave. But two guys who’d turned up to the previous talk stayed.  So rather than me stand up and do a talk, I made it more informal and turned it in to a chat with slides which I think quite well. I’ll be honest, I knew there wasn’t going to be many folks at this one, but it was a good way to see if I could do this conference talking thing.

The End-note was Chandler Carruth from Google talking about how they’ve made C++ safer, easier and faster with their use of Clang. It was a great talk with some live code demoes as well. He told us how Google had a completely unified codebase which allows for a single unified build system.  Chandler also spoke of the things that made C++ safe and quicker as well but I wasn’t quick enough to grab these as notes, the slides should be available though.


I’m not sure if it was me or not, but this conference felt different to me. It felt like I connected more with the material and the topics, and that could well be due to the fact that I’ve developed as a programmer since the last conference. But there was a pleasing and friendly atmosphere this year, not that there wasn’t one before but it felt more tangible this year at least for me.

I also had the chance to make new connections as well as catch up with those I made connections with last year, and a lot of people came up expressing an interest to be interviewed for the CVu magazine, and those I approached to ask were equally as nice.

I was sad to hear that Jon Jagger who’d been conference chair for the last four years had stepped down. I’m certain that I’m not alone in saying that Jon’s arranged an amazing conference this year as he has done for the last four years, and the fact he got a full minute of applauds and cheers speaks volumes for how good a job he’s done. I do look forward to hearing him speak next year though (:

However Russel Winder is the new conference chair, and I know that the conference is in safe hands.  So I’m excited to hear of what’s going to come in 2016, I may even put in a paper this time Winking smile

If you want to see what went on and who said what, the slides are available at the ACCU website, which can be found at and if you like what you see, then consider becoming a member 🙂

Overloading functions

I was chatting with a friend of mine the other night, and I must confess, I was in a bit of bother about whether to blog this or not.  For a while now I’ve been aware that I take a lot of the language features of C++ for granted.  I know how to use an awful lot, but I don’t really get in to the guts of it. So while I know a lot of surface stuff, I don’t think the likes of Herb Sutter and Scott Meyers have anything to worry about just yet.

But as I was chatting with Craig, I was worried that what I was going to blog on would be career limiting, after all I’ve been coding in C++ for three years now, so surely I should know more right?  Well, as ever Craig had some very sage advice, so here goes.

I came across an interesting issue a few years back in a legacy system I was working on and at the time, I just ignored it as one of those things.  I’d been coding in C++ for a few months, and the developer in question told me, “don’t worry, I’ll fix it.”  And off he went, and I went on and did something else.

Now hands up who can tell me what mistake I made there?  That’s right, I should have asked the developer if I could pair program with him as he explained what the problem was and how to fix it if it ever happened again.

So the problem was there was a pair of overloaded functions, where one took a char* and the other took a string.  And this was causing some unexpected behaviour in the code.

So this struck me again as I was walking home from work one night, and I realised I never did find out what happens in that case.  So I decided to find out.  Albeit three years later.

So, let’s suppose we have the following code:

void printNum(int num) 
    cout << "Print num taking an int" << endl;

void printNum(double num)
    cout << "Print num taking a double" << endl;


And we call printNum and pass it a number like say 100.  How does the compiler know which version to call?  After all it could be either an int or a double.  Well, when I ran this code and passing it 100, it printed: “Print num taking an int.”  But why?

Well when faced with this, the compiler goes through an internal sequence to work out which one to call.

  1. It gets all the functions in the current scope that has the same name as the function we’re trying to call.  It ignores the ones that don’t have the same number of arguments.
  2. If there are no matches found, the compiler will return an error.
  3. If more than one is found, it selects the best match.
  4. If there’s no clear winner, then an ambiguous function call error is thrown by the compiler.

This looks quite simple, but how does the compiler then select the best match?  The compiler works on a ratings system for the way the types are passed in the call, and the competing lists match up in decreasing order of goodness.  The list is as follows.

  1. An exact match.
  2. A promotion, so for example if you have a function that takes an int, and you pass it a char, then the char is promoted to an int.
  3. A standard type conversion. So a conversion between a double and a float for example.
  4. A constructor or user defined conversions.

So in this instance, as we’ve passed the printNum an int, we’ll get the int version back, the same way if we passed it a double like say 46.5 we’ll get the double version back. 

But what if we have something like this?

void doSomething(char* something)
    cout << "Something with char*" << endl;

void doSomething(string something)
    cout << "Something with string" << endl;

And we call it thus: doSomething(“this is a test”);

Then what version does it call?  Well, for a start, the compiler gives me a warning when I compile this.  The warning is:


So any bets on which one’s called when we run it?


It’s the char* one.  But why?  I’m not entirely sure yet, but from what I’ve read,  there is a default conversion rule to convert String literals to char *.  I am still looking in to this one, if I’m wrong then please please feel free to comment so I know.

So if we wanted the string version, then we’d need to cast our little test string to a string. 

Well hope all that helps, feel free to comment.

Happy coding.

Bits and pieces…

It’s been a while since I’ve posted, and for that I am sorry.  Life suddenly got busy, but here’s a post that’s been bubbling away the last few weeks.

One of the things I’ve always been blessed with (in some sense at least) is the knowledge of my weaknesses.  I’d argue that it’s a very important skill in a Software Engineer to know where their weaknesses lie.  I’m not talking about putting oneself down and making out that you know nothing.  Not at all, I’m talking about having sober judgement about your skills as a programmer.

So recently, I had cause to come across an area I’d never dabbled with as a programmer.  I’ve been doing some experimentation work on something that required me to have knowledge of bit-shifting and masking.

For those who were brought up in C, this is probably second nature to you, and you can safely switch off now.  I won’t be offended.  For the rest of you who are still with me, the inability to understand bit-shifting and masking is not something you should be ashamed of.  It wasn’t something I was taught at University (I did an Internet Computing degree).  It’s something I’ve had to learn fairly recently.

But before I get to some code (yes I know! actual code!!) I think it’s a good idea to go over bit-wise operators VERY quickly.

So you have a bitwise AND operator (&), a bitwise OR operator (|), a bitwise Complement opearator (~) which is also known as an inverse operator.  The AND and OR truth tables are shown below.


The complement operator (~) essentially flips the bits, or inverses them, so you if you had:

000000001 in Binary, and put it through the (~) operator you’d get returned 11111110.

So now we know what the truth table looks like, let’s discuss bit-mapping.  This is generally used to check whether a certain bit is set or not.  It’s commonly used with uint8_t in C++ from what I’ve seen, however it can be used with other unsigned integer types as well.

So let’s say we want to simulate an 8 switch DIP switch.  I’m sure you’ve seen them underneath various electrical appliances.  In case you haven’t, here’s an example below.

As you can see, it has eight switches on it, which allows you to configure your hardware in a certain way.  It’s often seen in remote door bells etc.

So lets say you want to check that bit 1 is set, that is the left switch.  To do that you need to use a bitmask.  So a quick word is needed on binary numbers.  They start at 1, and go up by 2 each time, and you generally write the larger number on the left, and the lowest number on the right.  So for example, for an 8 bit number, the binary values are thus:

128, 64, 32, 16, 8, 4, 2,1 which all add up to 255.

So if we wanted to check that the 1st bit was set, we’d need to check that the bit furthest to the left was set, which in this case is the 128 value.  Bit masks tend to be written in Hex.  So using my Windows Calculator in programmer mode (no shame in that either by the way!!) The hex of 128 is 80.  But we also need to decide what sort of mask we’re going to use.

So if we want to check that the first bit is set in our switch, what sort of bitmask do we need?  An OR based one?  Or an AND based one?  In this instance we need to use an AND based mask.  So the mask in binary would look something like this:

10000000 so for example:

10000001 – Original value
10000000 – Our mask:
10000000 – Result

The mask ONLY checks the bit or bits we’re interested in.  It ignores everything else.

So how do we represent that in code?

Well, like this:

bool checkBit(uint8_t value)
	bool returnValue = false;

	if((val & 0x80) == 0x80)
		returnValue = true;

	return returnValue;

So what’s going on here?  Well it’s a very simplistic program that simply tests that a bit is set using the bitmask.  So the if statement places a mask over the value, and compares it against the expected result.

So that’s a simple example.  Let’s say we want to print out a number in binary.  There isn’t an easy way to do this in C++, so we have to roll our own.  This brings bit shifting in to the mix.

Bit shifting is basically shifting a bit one way or the other.  There are two bitwise shift operators in C++, >> for a right bitwise shift, and a << for a left bitwise shift.  So to print a binary number from a normal number, we need to shift a bit, and using a mask, check if it’s a zero or a one.  Then based on that, add it to an output stream.  It sounds complicated, but it’s not that hard once you get the hang of it.

In code it looks a little something like this:

#include <iostream>
#include <sstream> // for stringstream

using namespace std;

// For now we print 8 bit numbers.
string printBinary(uint8_t val)
	stringstream outputStream;
	//uint8_t lastBit = 0x80;
	for(int i = 1 ; i <= 8; ++i)
		// Check what we have in the first bit.
        if((val & 0x80) == 0x80)
			outputStream << 1;
			outputStream << 0;
		// Now shift everything 1 to the left.
		val = val << 1;
	return outputStream.str();

int main(int argc, char* argv[])
	if(argc != 2)
		cout << "Usage: ./binPrint <number between 1 and 255>" << endl;
		return (1);
	// We don't put an endl here as we want it on the same line.
	cout << "Printing out binary value of " << argv[1] << " : ";

	// Convert the char to a uint8_t
	uint8_t value = atoi(argv[1]);
	cout << printBinary(value) << endl;
	return (0);

So what does this code do?

Well, it loops over an 8 bit number checking what the first bit is.  Based on the result of the mask, it appends it to the end of a stringstream so that a formatted binary string is outputted.  So for example if I want to print out the number 8 in binary, it would come out as: 00001000.

Another thing to note is that we grab the value BEFORE we do the bit-wise shift.  And we’ve got to be careful when shifting to the left, becuase if we’re checking the first bit like we’re doing in the code here, then we could shift things off the end, so we’ve got to make sure we nab the bit we want and THEN dot he bitshift.

Please do feel free to play and have a go.  It’s honestly the best way to learn.  I’m in the process of re-writing my binary printer now to cope with any bit number from uint8_t to uint64_t which is quite a challenge.  I may post that up here once I’m done.

Compact SQL Databases….

I’m in the process of developing my first app for the Windows phone platform.  I won’t say more than that for now, but it requires the use of a database at the back end to hold user account details.

Now, sadly Windows Phone on it’s own, or Visual Studio (from what I could see so far) didn’t have a mechanism for me to check what’s going on in the database that’s sat on the Virtual Windows Phone. 

I’d recently made changes to my app so that the user could select the account type they wanted to store for the app as can be seen in the screenshot below:
 screenshot of app

And so I wanted to see that what I was doing was actually adding stuff to the data base, and therefore would allow me to start doing more clever things with my app such as firing off requests and the like.  But I digress.

So how did I do it? 

So Windows Phone stores the data base as an SQL Server Compact database, which stores everything in an sdf format.  So the first trick was to get that off the phone.  The tool I used for this was the Windows Phone Power Tools, which can be found here.

So I fired that up and you get the above screen initially.  So we need to select which Virtual Device (or actual device, I’ve not tested this with my actual Lumia yet) we want to connect to.

Once we’ve done that, we’re in, and can get about downloading the file.  The first thing I learned is that if I’m on the screen that’s interact with the database, it won’t download the file.  So do all the Database stuff you want to do, then close down the app, BUT NOT THE DEVICE! 

Once you’re ready to get the file, navigate to the .sdf you’re interested in.

You will need to click on it, and select GET and it will transfer the file from the device to the location of your choice.

The biggest problem I had then, was what to use to read the .sdf file.  There’s a load of great utilities out there I’m sure but most of them didn’t work for me.  What actually did work was CompactView.  Sure it looks a bit basic, but it opened the .sdf file for me, which allowed me to check that the data I’m looking at was accurate.  It also allows you to have a context menu option as well.

So to view the file, select CompactView, and you’ll then be faced with the following screen:


It may not look like much, but at least it told me that my code worked correctly.

So happy coding 🙂

Dead trees are useful too….

One of the most important pieces of advice I’ve been given, was to read at least four technical books a year.  This was mentioned in The Pragmatic Programmer, and in an effort to follow the excellent advice given in this book. I’ve made some time to read a technical book as often as I can. I try and make it one every two months . Sometimes I manage it, sometimes I don’t.

So what have I learned from what I’ve read?

  • That I should invest in my skills portfolio just like an investor would add to his investment portfolio.  (Pragmatic Programmer)
  • I should learn to use different tool for specific tasks.  So this lead me to use the debugging tools that we have at work, whereas before I would have just sat at my desk and try to figure it out.
  • I learned that by depending on an IDE, I’ve become a lazy programmer, so I’ve moved from using IDE’s when coding C++ all together, as it forces me to think a lot more about my code.  (I confess I still use an IDE when doing C# stuff though as I don’t like hand writing GUI’s)
  • I no longer listen to music as I code, as I find it actually reduces my productivity and constantly distracts me. (The Clean Coder)
  • I’ve also adopted the art of deliberate practice.  So before I start coding, I’ll do some sort of warm up first.  (The Clean Coder)
  • I’ve altered my coffee drinking practice.  Yes, I can hear the gasps, but I now drink one strong cup in the morning, then have a soft drink in the afternoon.  This actually helps me to write better code.
  • I’ve become a huge fan of test driven development.  This has caused a few giggles at work, but nowadays, I’ll write the unit test first, before I write any sort of production code.  I must confess I’ve not done that with home projects yet.  But I’m working on that too.
  • I’m learning another programming language, so at work I code in C++, whereas at home I code in C# as I’m interested in the Windows Phone platform.   I’ve developed an app for the Android Phone as well.
  • I should look at improving my GUI skills. It’s not rocket science, with a little more effort, I can produce something that will look good. (The Developers Code)

So what are the books I’ve read so far this year?

So far this year I have read:

Granted, these aren’t language specific books. When it comes to that, I tend to dip in and out of those as I need to. If I were to list what I’m currently reading, then the list is as follows:

So how about yourself?  What are the books you’ve found helpful or would recommend?  Other readers would love to know what you’d recommend to read, or what you’re currently reading as well.

It’s been a while….

First of all, allow me to apologise for the delay between posts.  If I’m honest, I’m finding it difficult knowing what to put in these blog posts, because I am well aware that the stuff that’s new to me, is not new to a lot of people.  But then again, that was the whole idea behind this blog.  So I’m going to stop second guessing everyone and carry on.

So how have I been learning since my previous post then?

Well, I’ve been reading Bob Martin’s The Clean Coder which discusses a code of conduct for professional programmers.  I won’t go in to detail as to what I’ve got out of it so far, but one of the things that stood out was how he does deliberate practice.

So Uncle Bob explains how he uses a code kata to kick off his day, sort of like a warm up for programming before he start writing production code.  And it’s something I’ve been looking at doing myself.

So to that end, I’ve been using Jon Jagger’s excellent Cyber Dojo to do exactly that.  The idea is that I complete a puzzle, and then eventually I’ll do it again, but slightly differently using a different technique.

The cool thing about Jon’s site, is that you can try the kata in a variety of programming languages, and it’s a completely safe environment to learn and improve as a developer.  There is no competition with others, and nobody’s keeping track of your code except you.

Now if you want to do something a bit more competitive, then there’s always Top Coder which runs various competitions at various times, but I’m nowhere near the standard to take part in this yet as I simply can’t think on my feet quick enough in my chosen language.

The other thing I’ve been doing is reading, and I’ve started reading The C++ Standard Library by Nicolai Josuttis, as I want to get my head around the new C++ 11 standard.  It’s a pretty good read so far, but I’ve not got to the meat of it yet.

I’ve also set myself a few new challenges this month as well.  So I plan to learn one data structure a month, and learn it inside out.  So hopefully in a month’s time there will be a blog post with code samples, on a data structure within the C++ STL.  Now that I’ve said it, I’ve got to get on with it I suppose, so I’d best do that now.