May 24, 2020
Once a year, I go back to the skills that I feel I am proficient in and take a 101 course to see what of the basics have begun to slip.
Practical Test-Driven Development for Java Programmers by Matt Greencroft does have potential, as the creator does have valuable insights to share. However, this course was rushed in its creation and came across as lazily put together.
When teaching others, especially a beginner level course like this, your content needs to be very consistent. Creators should aim for immaculate content and be cautious of how they communicate their own bias, especially when they are the first point of contact to many on the subject matter their course covers. In my experience of mentoring indigenous soldiers in the Middle-East to teaching newcomers to the software development world, your students mimic your actions. New learners are like sponges, and they absorb all of your actions, not just to what you are trying to draw their attention.
The introduction and pacing are decent for most of the content.
The pacing is quite refreshing; the author does bring a practical aspect to most of the theory quite well and is one of the more unambiguous indications of their experience.
The course does cover essential topics and ties most of the practicals to the theory well.
With little effort, the author could revamp this course to negate most of the cons.
I did enjoy the author’s presence in the course, and that the cons I am about to list are due the proper time not given to the creation of this course.
The creator is inconsistent in how they act and how they instruct the student to act.
At times the practical content includes concepts that do not tie in well with the level of theory, and bad practice is used by the creator to negate the divide.
The author describes how in a test they would initially be leaving an ISBN as an integer as there is currently no need to use the slightly more complex data structure of a String. In the next moment, they see that they cannot have an integer with a leading zero. This problem does not fit with the narrative; the author then proceeds to alter the data of the test by removing the leading zero. Altering the required structure of that data, instead of the data type in the test is the most transparent moment when the author chooses convenience over discipline.
Another example is where the author uses a demo Spring Boot application, where Spring Boot is not a topic of this course. The problem is that the legacy code then requires setters to be added purely for the sake of the tests and compensating for the @Autowired annotations that we are not covering in the course. Earlier in the course dependencies are injected by using setters where the author really should have done something more meaningful for novice learners.
Example files do not appear to be on GitHub/ VCS, and one gets a Forbidden error when downloading them from LinkedIn.
This, unfortunately, leans towards the rushed/ lazy nature of the course and that it might be abandoned. I will message the author and ask about the course files not being available on LinkedIn.
The code created by the author is quite lazy, under the guise of refactoring to a better state during the refactor step.
If you do not maintain the same standards of coding as you apply when refactoring then you add tedium to a very iterative process; you introduce a compounding problem. You can still write good code while writing the bare minimum to make the test pass.
Your code while teaching must be to a higher standard than what you code in your day-to-day projects. Train hard, fight easier. How you practice becomes what you do, if you teach students at a low level, then that is what they will practice. Teach your students as close to the ideal standard as possible, so that they practice to that standard. When the pressure is on and those students have to revert to their instinctive level of coding, then you have set them up for success.