· software-development

University coding

We went to do some university recruitment recently and pairing with some of the students reminded me of some things that I’ve started doing better since I started working professionally.

I wanted to note them down so that I’m more aware that these might be common areas to improve on for university graduates that I work with in the future.

It seemed the same for the students I paired with and I therefore found it quite difficult to understand some of the code that they’d written.

A typical example would be a method which had variables ‘x’, ‘y’, ‘num’ and ‘a’ and was named in a way which suggested it was a command when in fact it was a query.

A couple of colleagues I paired with at the end of 2007/beginning of 2008 showed me the value of naming things expressively in terms of how much easier it makes a program to read.

Sometimes there’s a bit of a tendency to try and shorten variable names which tends not to work that well from my experience.

If we can use the same language in our code as we do when speaking about a problem then we’re doing reasonably well.

At university on the other hand I had the tendency to try and write the whole solution to a problem in one go without ever actually running it until I thought I’d finished.

As you might imagine those programs never worked first time around and resulted in hours of debugging to try and work out what had gone wrong.

Incremental development certainly seems to work out much better for me these days.

Google seems to work well if you’ve narrowed in a bit on what it is you want to know how to do.

I think the development of that ‘skill’ comes through practice but it’s certainly something that I used to struggle with a few years ago as well.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket