Showing posts with label Teaching. Show all posts
Showing posts with label Teaching. Show all posts

Saturday, March 5, 2016

Teaching programming related skills to my kids

As mentioned in a different post, I'm not a teacher but I do enjoy teaching my kids things.  Often this is computer related stuff.  Since my son is learning Java at school, I will use that as the initial basis for some teaching opportunities.  He still hasn't learned a number of key items yet but he will hopefully be ready for this by the end of the year. My idea for teaching is not the standard read a book and write some tiny bit of code to learn basic syntax/idea. Instead, I am going to write some relatively small (probably < 2000 lines of code) programs which are highly commented.  The comments will consist of application specific comments but more importantly will include "talk points" about why I did something or how I could do it different/better.  We can then walk through the program itself together and discuss how/why it works.

Items which we may be able to weave into the conversations include:
  • Analyzing options; trade-offs between viable solutions to problems and parts of problems.  
  • Architecture/design/implementation choices.  
  • Evaluation criteria for various choices
    • readability / maintainability
    • ease of expressing a solution
    • performance 
    • cost
I will also try to convey various good/best practices and various things that should be avoided. I am hopeful that he will take the opportunity to try experimenting with the examples as well. 

Even it it doesn't pan out to my fullest desire, I hope that one or both of my kids might learn something useful and enjoy some "geek time" with me.

The initial program I thought of is a Sudoku puzzle solver. A number of us in the family like to work the puzzles at times (some of us more than others).

Here is a link to my initial stab at the well commented Sudoku solver program.
https://drive.google.com/file/d/0B0GbWl6CZQ6lQlZ4S0NHNWpVWVk/view?usp=sharing
This link is to a zip file on my Google Drive containing a Eclipse 4.5.1 project.  You can extract it and import it into an Eclipse workspace. There is a README with some hopefully helpful setup info if needed.

[2016/3/15] Below is a stack based solution with some changes for clarity (in many cases compared to the prior recursive version) and has heavy use of JDK 8 functionality including use of "default" in interface definitions and more stream/lambda examples. I'm sure some of my lambda related code could still be cleaned up - probably with use of method references in some places.
https://drive.google.com/file/d/0B0GbWl6CZQ6lZzh4TVl4a3dUOUU/view?usp=sharing

For this particular program, I think some of the conversations might include:
  • mutable versus immutable data
  • data structure selection
  • object orientation design
  • serial versus concurrent/parallel processing
  • Java 8 "functional programming" features
  • solution strategies
    • brute force
    • backtracking
  • recursion versus stack based implementation 
From a longer term perspective, I might try to create or discuss implementations in other languages/technologies. This might provide me an opportunity to learn some new things at the same time or brush up on some rusty skills. Some initial thoughts on this include: C, C++, Scala/Akka,Erlang, Scheme/Lisp/Clojure, JavaScipt/CoffeeScript/TypeScript.

**
[2016/05/29] As a side note, simply replacing regular streams with parallel streams had a substantial negative impact on the performance.  This was on on a 4 core i5 based system running at 1.70 GHz with Windows 7 x64. Maybe an improvement could be made with some effort but it will take a bit more work than just adding "parallel" in a few places.
**
I'm starting to think about what type of programs might be fun to work on next.  Maybe a web application could be interesting but I think the focus would be more on the supporting technology (i.e. container and frameworks).  Maybe we will make that decision together.

[2016/04/03] Somethings to note, code reviews are a good thing - would have caught a number of my own documentation mistakes in this code which I need to fix.  A code review involves one or more other developers who read the code while looking for errors in logic, code documentation or deviations from some coding standards.  Finding the logic/documentation errors is the best code review usage and has a better chance of working if the developers have some artifact the the logic was created from which can be referenced - probably a design document, use case or diagram of some sort.  Deviation from coding standards is better identified with other software which can be integrated into appropriate places in the chain of software development events.  One of those events might be checking the files/changes into a source control system - something that is important but I am not discussing here.  Creating unit tests are another possible way to catch logic errors if the tests are created based upon the desired true outcome (requirement) versus the actual code/logic which was implemented.  Do some research into Test Driven Development (TDD) for more info in this area.  From a pragmatic standpoint, taking a break from a long coding session and coming back to it after a couple hours to carefully review it again can go a long way to catching your own mistakes (of all types) before others find them.

 Deuteronomy 32:2New International Version (NIV)
Let my teaching fall like rain
    and my words descend like dew,
like showers on new grass,
    like abundant rain on tender plants.

Thanks for reading!
Scott

Wednesday, December 30, 2015

Thoughts on teaching Java at home

My son is taking his first Java programming course in high school (an Advanced Placement [AP] course).  Since I am primarily doing Java work most of the time now, I figured some father-son bonding would be fun to do while teaching him some Java stuff.  The result so far has been fun at times and I think he has learned a bit but also causes me to pause to think about the timing and process a bit along with other items. 

Some thoughts/considerations/findings are:
  1. I question how much I should try teaching him in this situation.  Part of my reasoning revolves around the fact that his class is moving pretty slow (maybe the memory of how slow my first Pascal course was has faded) and the content is somewhat limited with focus mainly around the requirements of the final AP test.  I don't want to distract him too much from his teachers plans due to the chance he may not focus enough on the exam requirements.
  2.  I've never taught anything formal before and have no training as a teacher.  This in and of itself makes things difficult but I find it even harder when combined with how long I have been programming (using Java and other languages).  All my knowledge and experience helps me in day to day work but I find it hard to identify material at an appropriate knowledge level for someone just starting out. It seems that teaching someone that already knows the language fundamentals should be easier than starting from a nearly blank slate. There are three major areas where I run into this.
    1. Language features/syntax
      1. Try explaining functional aspects of Java (lambda functions) to someone that is just finishing talking about 'for' loops in class.  If you come up with enough examples you might get past the initial glassy-eyed stare but it will take a while.  I am thinking that after his current class, many of the more interesting ideas should be easier to grasp or at least provide an easier basis to start explaining things.
    2. Data structures
      1.  I work with reasonably complex problems and utilize many of the of common collection classes constantly. In examples for my son, I am finding it hard to limit myself to simple arrays.  I keep getting drawn into explaining the fundamentals of data structures along with the various collection classes.  Unfortunately, my main goals usually are not about data structure fundamentals.  It is almost funny as I pondered how to explain Java references and I keep wanting to utilize C/assembler/machine details to contrast them [aka pointer, memory address].  This may work if someone already knows C or understands the underlying hardware (things like Von Neumann or Harvard architectures) but I found myself on a slippery (but fun/interesting) slope trying to find the appropriate wording.
    3. Examples and Design considerations
      1. Coming up with an extensible example that starts like "Hello World" and gradually includes new language features/syntax while demonstrating (reasonable) design skills is likely harder than my day job.  While I may cringe on occasion at examples my son has from class, I am starting to understand why they are needed at times.  It is more effort and time to teach design skills concurrently with language syntax and usage.  I would love to come up with a really nice example program/project idea that scales from day 1 all the way through the Java 8 changes AND demonstrates a reasonable design strategy.  Maybe something like that is possible or already exists but I don't have the time to create or find it.
Another impediment which I wouldn't have anticipated as one is the use of an IDE (Integrated Development Environment).  I use Eclipse about 99.9% of the time.  In the high school class they don't use anything more than Notepad++ (and just plain notepad at times).  The impediment in this case is not their use of Notepad++ but my reliance on Eclipse.  I find that when I work on some toy ideas with my son (not using an IDE), I do miss silly mistakes now which would be obvious as you type in Eclipse.  With code completion, I don't usually have to memorize the specific order of parameters for most things, etc.  If you take away the code completion, it does slow things down and I find myself providing parameters in the wrong order at times and making other mistakes.  The problem is obvious when parameters have incompatible types but otherwise it does take extra time debugging that type of problem.  Debugging and analyzing error messages are good learning tools but it is somewhat an annoyance when that isn't part of what you are trying to demonstrate.

If I was a real teacher then there are surely many resources to help with planning a real curriculum but doing this type of thing mainly spur of the moment is not easily done.

Now that I mentioned a number of impediments, I should mention a few resources which I think have helped teach my son (and maybe my daughter later).  I think a couple old "Java in a Nutshell" books helped a little - he can thumb through them as needed and put bookmarks anywhere he desires.  I think an even better resource is my Java 6 certification book/study guide.  I don't think he has spent a lot of time with it yet but the fact that it contains oodles of correct/incorrect small code samples with descriptions of why they work or not should be a big plus.  If he starts at the beginning, with a little effort he should be able to pick up many of the individual concepts presented.  I probably won't quiz him with the sample test questions though.  It make take him a while to mentally put it all together but I think it could be a really good start.  If he digs into it more thoroughly I will document what i find.
 
The following is more of a side note related to myself.

On that note, after giving my son my Java 6 certification book/guide, I went ahead and picked up the "OCA Java 8 programmer I" and "OCP Java 8 Programmer II" study guides.  In the past, I had considered taking the tests but just never found enough time to fully prepare (cram for realistically).  There were API's that I rarely, if ever, need/use that I would need preparation (Threading comes to mind).  And my earlier comments regarding reliance upon an IDE like Eclipse resulting in a bit of laxness in reading what I write still applies.  I'm not a real fan of reading intentionally misleading and ugly code but I understand reason for it in the context of the certifications. Even so, the study guides are still really useful though because they do tend to describe things which might be uncommon but useful or items which you may have forgotten about.  I'll admit here that I had somewhat forgotten that you can specify "default:" in a "switch" at a location other than the end of it.  I, as a standard practice, always specify it at the end of the "switch" - I don't remember the last time I specified it anywhere else.  So the study guides provide good examples of valid syntax which you may not utilize due to existing organizational code standards or similar reasons.  There are also items covering new features which you may not be (highly) familiar with. 

I'm going to put more effort into actually getting the OCA certification in the near term.  I think this will be a wise choice related to employment over the next 4-6 months.  Hopefully I can find time for the OCP certification as well.  It appears to be increasingly import to differentiate oneself from others.  I just don't want to take away too much family time in the process.  Some prayers will hopefully help in setting priorities. 

Thanks for reading,
Scott