Let's Learn Java - setting our rules

As I mentioned last time, I'm going to focus on the core features of Java over this series, to help those of you less experience to build up a familiarity with the language and some of it's features.

As such, this series will provide an introduction to core features of the language, but it's not in any way expected this will be all you need.  Much as I talked about in the automation series, this series will introduce core concepts with examples to you.  It's goal is to illustrate a framework for you to develop your own mastery.

How do you do that?

Practice

It's one thing for me to show you how to do something.  But the best way to learn is for you to do it yourself, change a few things, and see what happens.  Try and expand beyond what I've done.

I recently spent a couple of days in a Buddhist monastery, where there was a poster that said "I practice every day to become better".  That's exactly how I feel about testing, and it's also the method I learned to program.

Nothing throws what you've learned into such sharp focus as trying to do.  If you're a great success at it, try and be more daring.

If you find a problem, explore - read the error message.  Try Googling your problem and reading around.  Try different things.

My advice is to try and make discrete changed, and run your program regularly to see what happens.  That should help you catch problems as early as possible.

Read

I worked for 10 years as a C++ developer.  I've worked in the IT world for 20 years.  I have 3 higher education qualifications, and none of them is in computing.

I learned to program C++ by finding a really good introduction I could work through.  Key was it had to have a lot of examples - for me the book was Software Engineering in C++ by Michael J. Pont.

But reading "a book" doesn't make you an expert.  Combined with my experimental practice, I also read a couple of other sources to refine and fix what I'd learned.

As a teacher, we're taught the importance of "the rule of three" when learning something new.  You had to be told something three times, in three different ways for you to learn best, reinforce and sink in.

Likewise in programming - reading allows you to get some familiarity, the best way to test that is to try and write something that uses this.  This in turn will lead you to Google and read up more stuff, as a kind of cycle.  Repeat this enough, and you're learning.

Yes - the two things form some kind for infinite feedback look - and that folks is the path of mastery.

Most books I've come across are giant tomes - whilst that's great to be authoritative, I'm always intimidated by the idea of reading a 1000 page book.  Although, unlike Game Of Thrones, it's not likely anyone will die in this [brace yourself ... a meme is coming].

One book I heartily recommend as a companion to this series is Alan Richardson's Java For Testers - it has some nice explanations, and plenty of practical examples

This series will be designed to complement that book, I'll be working with my own descriptions and examples.

Competition Time

I've never ran a competition before?  Well I am now!

I'll be giving away an electronic copy of Java For Testers to one lucky winner.*

To enter - just comment below including your Twitter ID.  On Wednesday 31st August (NZ time) I'll chose one person at random (I might even write a program for this), who'll be the winner.

You have no obligation to do anything beyond that.  However to make sure the book is going to a relevant home, when I look at your profile on Twitter, I'm hoping to see the word "testing" (at a stretch "QA") somewhere.  Good luck!


* Just to be very clear - we're testers, and clarification is everything.  I won't be "giving away" as much as "buying as a gift".  Just in case you were wondering if I'm shafting Alan on his royalties.