Writing Intentionally Bad Code

I’ve done my fair share of speaking; I won’t say I’ve done a lot of speaking (not at least compared to people like Laura Thomson, Chris Hartjes or Rafael Dohms), but I’ve done a bit. Every time you speak people expect to see code in your slides. And they expect to see both a wrong way and a right way to do a particular thing.

That’s all fine and good; slides aren’t big enough to write an entire application. But in preparing for my class, The Object Oriented PHP Masterclass, my task has been to write a complete application that my students can refactor using the principles they have learned. And writing code wrongly, on purpose, is hard.

Breaking carefully cultivated habits

Part of the challenge in intentionally writing bad code is the need to fight against years of habit building for writing code the right way.

After all, writing code correctly is the skill I’m hoping to impart upon my students. It’s a skill I’ve carefully cultivated. Looking at bad code, I have an instant idea of what needs to change and why. I know, for example, that duplicated code should be refactored into a function. I know that an object that has HTML in it is doing it wrong. I know that an object with more than one job should really be broken into two. I know that private methods can be bad, especially in classes from which other classes must inherit.

Yet in order to teach these topics, I must do the wrong things, on purpose. For others to learn, they must encounter carefully constructed bad code.

Bad code isn’t enough

Note that I said “carefully constructed bad code.” Simply writing bad code for my students isn’t enough. I must write carefully constructed bad code. There’s a difference.

When inexperienced developers write bad code, their code is just bad. It has few (if any) redeeming qualities. It often must be scrapped, or at a minimum refactored intensely.

I’m not trying to have my students rewrite this code completely. I want them to be able to refactor it, to make it better, to look at carefully constructed problems and say “oh, that can be improved with abstraction!” or “oh, I can write an interface for this!” I want them to see solutions in the code, based on the material I’m preparing. I want them to be able to implement the answers based on their understanding of the course.

This is a very different type of “bad coding”. It requires deliberate action.

Size matters.

Of course, there’s tons of examples of bad code all over the internet. Why not just adopt one of those for my students to work on?

Because if you’re taking my class, which is two weeks long, you don’t have the time to understand something like WordPress, let alone refactor it. The size of the code base matters a great deal in developing and cultivating understanding.

The application I’m building is essentially a Hacker News clone, with ratings, comments, submissions, and authentication. This is just large enough to provide a number of avenues for demonstrating mastery of the material, but small enough that it can be refactored in a couple of weeks.

Challenges abound – but it’s worth it

One of the best benefits of being a teacher is that I have the ability to see how what I do affects the student. And even though teaching is a challenging task, it’s one that’s well worth it!

Registration is now open for The Object Oriented PHP Masterclass. Learn to write object oriented PHP hands on and boost your career! Register today!

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Hikari wrote at 4/9/2013 8:48 pm:

Teaching is really a challenge. I’m very bad at teaching and hope to never have to rely on it for living.

A classic suggestion is to get some small business and stress it to the most. As you said, the business being used as example can’t be something too big that’d take months to read or too complex that’d take months to explain and/or understand. The teacher can’t risk the quality of the teaching on the student not understanding the business. The business is secondary, it can’t be the focus of the lesson, teacher’s objective isn’t teach the business.

But that creates a problem I see a lot in unexperienced people. During didatic work, we do things aiming to learn them. We document everything, describe everything, use all UML diagrams and models. And when these ppl go to real work they wanna do the same, wanna use everything, wanna bloat the documentation and waste a lot of time with basics!

I see you’re starting now as a teacher, you have little experience and lack materials. In general, try to be didatic, focus on what you wanna teach and don’t let tools used to help on that to shadow it.

Copyright © 2023 by Brandon Savage. All rights reserved.