Saturday, October 8, 2016

Practice what you preach!

I think sometimes life has a weird symmetry - this week had an excellent example of this.

My son is in his first year at Victoria University in Wellington - he's done well, but not sure if he wants to do a second year without a considerable rethink.

He recently had an essay for Classics returned to him with some comments, for which he was allowed to make changes and resubmit.  He got a C-, but as he pointed out "it's still a pass", and wasn't so keen to redo it.

I had a chat with him - it's so rare to get useful feedback on something we've done.  Of course we all really want to be "done with" projects like essays or documents so we can just move on with our lives.  But applying those comments would help him think about what he's written, how to present a better argument, how to do it better.

Without feedback, we keep doing what we're currently doing, but it's unlikely to get any better.  We read through the comments together, he formed a plan of what to do, and resubmitted it yesterday.


During the week, one of our lead developers emailed me about my blog series looking at Java basics.  There were a few things I'd done which whilst not big things, would be considered bad practice in the team.  Would I be interested in the feedback?

My stomach turned - it might mean a lot of rewrites, and I'm working on my astronomy series right now.  And yet, although that series is meant only as an introduction to some key concepts, I wanted it to be as good as I can get it, without compromising the "sense of fun" I like to include in most of my writing.  [Although of course, this wasn't much "fun"]

So of course I wanted to know.  His comments were useful, because it made be think about some aspects I'd not thought about in detail,

  • Class names should be Capitalised, this makes it easier to tell them apart when declaring.
  • All code blocks should use braces "{...}" to contain statements, even if just one line.  I'd not used them in a few  DiceClass methods just to show that they're not mandatory (if you have a single line).  I changed all bar on, just to prove this, added a comment to the relevant blog, then never missed the braces afterwards
  • Some methods such as diceOnOrOver returned an integer, but should return a boolean.  I'd cheated there, because I knew I'd wanted to add the integer returned at a later date, but he was right, it should return true or false.  I know it's tempting to go "but I just need ...", but it can be a bit of a slippery slope.
  • I was using ArrayList, but I should declare them as a List not ArrayList, because ArrayList is a kind of List, and you want to keep the List interface.  StackOverflow discusses this here.


All told, with changes, retesting, committing to GitHub and blog modifications it took a few hours, but it did reinforce those points.  I don't think I'll ever forget to use a capital for a class name ever again now.

It's also a reminder to hold ourselves to the advice that we council others - and yes it's so rare to get good feedback, it's always useful to apply it so we learn from it and make the best essay/document/code we can.


Now playing: "River deep, mountain high", Ike & Tina Turner


1 comment:

  1. Writing great thesis statements shouldn't be an issue for you, in case you keep the aforementioned factors in mind. To get started writing a descriptive essay, pick the topic you are going to be describing and ask for help mastergrades. The most significant part is to choose a topic.

    ReplyDelete