Hello World!

Hello World!

In the tradition of all programmers everywhere, I thought I’d start off my first foray into blogging with a suitably experimental post. Now that’s out of the way, a brief welcome and then we’ll get stuck in…

So why, after several years of avoiding blogs (and the immensely irritating plethora of buzz words  that goes with them – I’m looking at you ‘blogosphere’!) am I suddenly deciding to add my thoughts to the clamour?

Well, the truth is, I’m not. This blog is for a few people I know who have similar interests to mine, in the hopes that what I find useful will benefit them as well. If you’re one of those people, welcome! If you’re not, welcome anyway and I hope that my ramblings are at least vaguely what you were looking for when you stumbled onto this. Feel free to leave whenever you like. I won’t be offended, I promise!

What am I hoping to cover here?

This blog is for me to set myself goals, document my progress and jot down interesting and useful pearls of wisdom that I find as I trawl through the vast ocean of misinformation, conflicting advice and (occasionally) brilliant ideas that is the world wide web. Along the way I’ll probably read a few books and attend a few talks and lectures as well. I may or may not tell you what I thought of them, but I’ll probably note down their names and the key points I took away.

What are my general goals?

I have always believed that any engineering discipline starts of as a science, and as we improve, moves closer to art. We begin by rigidly following the rules, learning the forms and grasping the fundamentals of our discipline. Then we start to question why those rules exist, and we begin to grapple with understanding the underlying principles. Finally, with our complete understanding of every decision we make, we are free to play and create something both functional and beautiful. We know when the rules must apply, and when we can break them to achieve a more pleasing outcome.

Of course, the beauty I’m referring to may not necessarily be the obvious definition. It may be a machine with a wonderfully complex, yet perfectly cooperating structure (Last Christmas, my girlfriend’s father showed me a video of a man constructing a working model engine which fit in the palm of his hand. I didn’t understand a word of it, but I was impressed by the incredible level of craftsmanship involved), or it may be a piece of code which screams its intent from the moment you begin reading. Any programmer has encountered both ends of the spectrum at one time or another – From the joy (possibly relief?) of an intuitive, obvious description of a task right down to the horror of a convoluted, hellish spaghetti mess of badly named variables, recursive functions and the dreaded GOTO. In my opinion, art is about evoking emotion and thought in the observer. If my code can make a programmer feel relaxed, confident and able to tackle the task he has been given, isn’t that a form of art?

The concept of this omniscient, omnipotent, master programmer is, of course, a pipe dream. No-one can know all the consequences of their actions (that’s why we spend so much time writing tests!), and no-one can be right all the time. That doesn’t mean we shouldn’t strive for it.

I am in the midway stage I described above. I understand the fundamentals of computer science. I understand the specifics of the languages I use, the syntactical differences and the odd quirks. Now I’m starting to question those decisions and processes. Why are design patterns a good thing? What constitutes a well written test? How do I write code that can withstand changing requirements, multiple programmers with differing opinions and understandings and still work efficiently?

In this blog, my aim is to record the baby steps I take towards becoming the ethereal master programmer. Hopefully, the things I find will help others do the same.

What are my specific goals?

I started this with a number of specific areas that I feel I need to improve. I’ll be maintaining this list and adding/removing items as necessary:

  1. Learn C# – My development experience has mostly been in Java so far. C# looks like a nice language, with many of Java’s advantages and some very powerful additional features that I wish Java had
  2. Explore and understand the SOLID principles.
  3. Understand the reasons behind the ‘Tell, don’t ask’ principle – and why getters and setters may be a bad thing
  4. Code smells – what are they? how do I recognise them? More importantly, how can I avoid making them?
  5. Design patterns – I have a basic grasp of most of the common ones. Now I need to find concrete examples of them to understand why they’re a good thing
  6. Code katas – Lets start doing them and watching more experienced programmers, to see what I do wrong
  7. Test Driven Development – I tend to still think too big. I need to cut down the size of the steps I take until I’m comfortable with thinking in tiny increases in functionality
  8. Continuous Delivery/Integration – I have some experience in continuous integration, but how can I use these effectively?
  9. Agile development processes – Scrum, Retrospectives, Changing Requirements – what is standard practice here?

9 points is enough to be going on with. Especially considering the size of #1…

Learning, begin!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s