Stolen LEGO: Two weeks later, now with a $1200 reward

LEGO in grass and bushes

The past two weeks have been a blur. This is, by far, the strangest thing that has happened in my life to date. I sincerely hope it goes down as the strangest thing ever, because I don’t think I’m prepared for anything weirder than this.

Here’s a quick high-level summary and you can find more detail below:

  • Our LEGO collection is still missing after the LEGO theft on August 28th. We did find a small pile of LEGO outside (photo above); it looks like one set of drawers tipped over after being set down and these are the pieces that were left behind.
  • Today I’m announcing a $1200 reward for the successful return of our collection and helpful information on finding the person(s) responsible.
  • Our home owner’s insurance policy has us covered and will (eventually) pay for all replacement costs in full (less our $1200 deductible).
  • In spite of the above, several friends and family members have been amazingly generous and purchased gifts to help us start replacing our collection more quickly. We couldn’t be more thankful or grateful. Y’all are amazing!
  • We have installed $1000-worth of surveillance and security equipment to help us sleep again… which is finally starting to work.
  • We still need your help keeping eyes on the many different marketplaces and reporting leads.
  • Lastly, I’m bothered a lot by how inward facing all of this has been – my world view has had been too much about me these last two weeks. I’m looking forward to getting back to thinking about and investing in the rest of you.

$1200 Cash Reward!

Pile of Money
Photographic illustration. I promise I won’t pay you entirely in ones.

Yes, we can replace our collection 100% thanks to our home owner’s insurance policy (more details below). This will take time and will still cost us $1200 for our deductible. I’d like to speed that process up and just get the original collection back, so I’m putting up $1200 towards the successful return of our collection and apprehension of the person(s) responsible for the theft.

If you can help us get our collection back, or if you can help us find the person(s) responsible for the theft, we want to personally pay you $1200 for the information.

If you know anything about who did this, where to find them, or where to find our missing LEGO collection, I urge you to please contact the Grandville Police Department or me personally.

Thank you to our generous friends and family!

Despite being clear that our insurance will cover us, many of you saw fit to bless us anyway. Some of you sent LEGO, some of you offered to send LEGO, some offered money and time. I shouldn’t be surprised, knowing all of you like I do, yet here we are. It is so encouraging to know you and be related to you. You’re a wonderful reminder to be more generous myself.

Our insurance has us covered

This section was originally 1,000 words all by itself. I’ve pulled that out into a separate post that I’ll share later. For now I’ll give you a truncated version.

This week getting a $1200 check from the insurance company, against a $7500 loss. We’ll get the rest too, but it’s not a huge windfall that everyone expects and assumes when they say “they’re just doing it for the insurance money”.

Before I go any further, I need to say this: we love and recommend State Farm insurance (and have for years before this incident, too). They have been easy to work with on all fronts: vehicle insurance, renter’s insurance, home owner’s insurance, life insurance, etc. Every time we’ve needed to call them about anything, on any front, we were able to talk to a real human almost immediately. Every. Time.

In short, the process for restoring our collection will be based on reimbursement. As we are able to buy the lost sets we will submit receipts to State Farm. After that they will cut us a check for money spent.

But what if we get the original collection back?

I asked the detective in charge of our case the very same question. There is a restitution process for just such a thing. If we’re able to recover any original parts of our collection that will come off the insurance claim. If we were already paid for a replacement then either the replacement or original will become the insurer’s property. As it turns out, this is both a straight-forward and common occurrence.


Increasing our home security

Security camera
Photo by Serge Kutuzov on

The most frustrating part of all of this for me is that someone was in our home, while we slept, and got away without us noticing anything. This is the only known break-in at this address since the home was built 60 years ago. And it will probably be the only one ever. But we can’t be sure of that, of course. And sleeping has become quite difficult now because every bump and creak puts us on high alert, tense dreams startle us awake, and so on.

So, beyond the $1200 deductible we need to pay for replacing our collection, we’ve spent another $1,000 on surveillance and security equipment for our home. We’ve also paid out far more in hours of attention and wasted anxiety.

I’m not going to give up any details about what we bought, though, as that would defeat the purpose of getting the security system in the first place. I can tell you what we’ve done in general, though, and what you might want to consider for your own home (where we both know a break-in will never happen because you live in a safe neighborhood and lead a private life and keep everything worth stealing either locked up or secret, naturally).

We purchased a combination of cameras and sensors from different providers. This mixture allows us to monitor all doors, floors, and windows. I intentionally picked parts from multiple systems to ensure redundancy. If one layer fails or is compromised another can still secure the area. Everything we’ve installed is connected wirelessly and has battery backups. Outbound signals for the security system will utilize its own 3G antenna if WiFi is unavailable. Our modem and router have their own battery backup as well.

If someone opens a door, or enters through a window, we will be notified immediately. If someone bypasses those security measures and makes it into any room in our house, the secondary system will still notify us immediately. And if someone can cut our power or our internet we will still be notified immediately.

If this sounds like overkill, that’s because it is. Now that the integrity of our home has been compromised, though, I don’t expect we’ll ever live without it. As a rational, thinking human being this bothers me to no end. This is a totally emotional response to a statistical uncertainty. But my rational thoughts aren’t what keep me awake at night.

A quick side-note on counting on other people’s security cameras

Many people asked us if any neighbors may have had security cameras pointing at our home. I was polite and brief in all of my answers about that: no they don’t. Do your neighbors have cameras pointed at your home? Would that make you more or less comfortable?

The more elaborate answer is: even if they did, most cameras have a usable line of sight of about 30 feet, and that’s reduced to about 15 feet in darkness. Even HD cameras still capture barely-useful footage in that full range, which reduces the truly useful distance even further. I could go into a lot more detail about the limitations of the optics and sensors themselves but I think that much detail is useless and will sound condescending. I’ll just sign off as an authority who is both a technophile and a person who has studied camera equipment for more than a decade now.

Casting a wide net

Fishing net
Photo by Jonas Jacobsson on

There are so many digital marketplaces for LEGO. Holy smokes! I knew about a lot of places, but then people reached out and pointed out so many more. Now I’m watching all of them. If you can help watch any of them, too, I would greatly appreciate that.

Here’s a non-exhaustive list of sales outlets to get you started:

And you can find the list of stolen goods and photos of the collection in my previous post.

I’ve also reached out to a number of resellers, advertised buyers, and Lego User Groups (LUGs) to make them aware of the theft and keep eyes peeled for our stolen goods.

As you can imagine, keeping tabs on each of these sites is a serious chore. That’s why I’m looking for help to keep tabs on all the listings and why I’ve offered the $1200 reward.

Reporting leads

If you have any promising leads or information to share, please do! You can reach the Grandville Police Department through the non-emergency line at (616) 538-6110 or email Our case number is 17-6191.

You can contact me via email using my first name at this domain. I’m on twitter as @rzen. I’m also on Facebook and am usually absent there, but will make an exception for discussing this.

Thank you!

Help! My entire LEGO collection was stolen!

Did you take my entire LEGO collection? Because somebody did.

If it wasn’t you, can you help me find the thief?

A list of sets, some photos of the collection, and media coverage appear at the very end of this post.

Read the follow-up post, with details on a $1200 reward

When did this happen?

Sometime after 12:00am ET on Aug 28 (when I got into bed) and 9:00am ET on Aug 28 (when I returned to my basement office) some person(s) invaded my home and relieved our basement of practically every piece of LEGO. And that’s it. Nothing else in our locked home, or unlocked garage, was touched. None of our expensive electronics (computers, monitors, microphones, etc.), none of my expensive camera equipment (body, lenses, lighting, etc.), none of my woodworking tools (table saw, mitre saw, drill press, router table, etc), or any other things of any kind.

It sure sounds like a prank. A very ill-conceived and poorly timed prank. That’s the explanation that makes the most sense of this situation. But nobody has stepped forward or returned anything.

[Minor addendum, after thinking more critically: most of the computer equipment, except for desk-mounted monitors and microphone, were on the main floor of the house with us; the camera equipment was hidden from sight; and the tools would have been very difficult to remove due to their size]

How did this happen?

I honestly can’t say. My family was home the entire day on Sunday, Aug 27. We had a few close friends over for lunch that day – people we’ve known for years and who depend on their credible reputation for their careers (and, before you ask, everybody is on the suspect list, including me). My boys and I played downstairs throughout the afternoon. The LEGO was fully present and accounted for throughout all of that. I was personally up and about the house until midnight, and then awake and out of bed again by 6:30am on Monday, Aug 28. Our house was locked when I went to bed, and again when I left for breakfast at 7am. My family was awake throughout the house from the time I left (7am) until 9am when I returned home and went downstairs. That means the break-in most likely occurred between 12:00am and 6:00am on Monday, Aug 28.

Someone came into my home. While we were sleeping. And removed nothing except thousands of dollars of LEGO. Small, rattly pieces of plastic. Either with a crew that should be large enough to be noticed, or with many trips up and down the stairs.

I want it all back, of course, but almost more than that I want to know how they did it. How did they get all of the drawers, parts, and sets out of our house without any of us hearing?

How much did they take?

Table with 9 bins and 316 drawers of sorted LEGO
The sorted collection. 316 bins of pieces separated by part type.

We’re still working on the total volume, but I know it was generally in the realm of “a lot”. Enough to fill two 18Gal storage bins, at least. The good news is, I have a good idea of which pieces and which sets went missing.

You see, I spent some time last summer sorting my childhood LEGO collection and putting it into small-parts drawers (see above). I had quite a few misc sets and figures that I then put on display across the top of those drawers. I also happened to take copious amount of photos of the process and some of the cooler sets that are now (that is, were) in our collection.

Back when I was still a teenager, my mother had the bright idea to round up all of my LEGO instruction booklets and put them into a folder, which eventually expanded to fill a full box. And the thief just so happened to leave ALL of the manual in the box on the floor.

Box of LEGO instruction booklets
My fine collection of un-stolen LEGO manuals

The real kicker, though, is that they took the sets that Katie and I were actively building! Rather large gifts that we had gotten each other recently. They took these partially-assembled sets and all of the pieces that I had just finished laying out and organizing into plastic dishes across a table in our basement.

Here’s what the table looked like yesterday:

Katie, building the LEGO Disney Castle
Katie, building the LEGO Disney Castle

And here’s what things look like now:

My office, stripped of LEGO
The space formerly known as “the LEGO table”
Table with just a few empty containers
Our stripped and barren table

Those vile rats even took all of the tupperware and an ice  tray that the pieces were sorted into! I mean, just look at all this tupperware!

Tupperware and such
All of our glorious containers, now AWOL along with the LEGO that was in them

How can someone help?

First, theft is covered under our home owner’s insurance policy, and we’re working through the proper channels to sort that out. We are actively working with the local police department on this active case.

Our collective hunch is that the sets are being sold off individually and the rest of the pieces sold in one or many bulk lots. The best way you can help is to keep your eyes peeled for used LEGO that’s up for sale. Maybe via Craigslist, maybe via Facebook, maybe via ebay, or pawn shops, or elsewhere. The seller is probably going to list them within a couple hundred miles of Grandville, MI (49418).

Which sets are missing?

We’re working on a list of that and I’ll update this post accordingly as more info becomes available. Until then, below is a short list of the assembled sets and loose minifigs that we know were taken.

Any leads?

Please either contact the Grandville Police directly via 616-538-6110 or or email me privately. My email address is my first name at this domain.


How about some more photos?

Sure thing, here’s a partial gallery documenting some of the sets and parts!

Media Coverage

So far this story has been covered by Inside the Magic, the Miami Herald, and Fox 17 news (WXMI) in Grand Rapids.

Conditionally change JetPack Infinite Scroll trigger to “click” or “scroll”

Earlier today I was trying to change the “type” for JetPack’s Infinite Scroll behavior to use “click” only for the front page. For all other archives I wanted JetPack to use the standard “scroll” type (you know, the namesake for Infinite Scrolling).

(In a hurry? The solution is at the very bottom of the post.)

JetPack has a bunch of filters available, and the developers even had the foresight to provide a conditional to toggle this behavior based on whether or not the site footer is displaying widgets. Each of the JetPack Infinite Scroll Settings is explained extremely well in the documentation. The setting designed for what I wanted to do is called footer_widgets.

This setting expects a boolean and, if true (footer widgets are present), JetPack will automatically convert the event trigger to “click” in order to allow visitors to see the footer. My first thought was that I could throw is_front_page() right here in the settings definition. My immediate second thought was, “no, that won’t work.”

You see, when the theme support for infinite scroll is registered we’re on the after_setup_theme hook, which is much too early for WordPress to know which template is being loaded.

Digging in, I found a filter mentioned in the documentation named infinite_scroll_has_footer_widgets designed expressly for more complex logic. This is perfect, I thought. Surely this could be as easy as hooking the is_front_page() callback to the filter (i.e. add_filter( 'infinite_scroll_has_footer_widgets', 'is_front_page' )). Nope; this filter is also evaluated before the template conditionals know where we are on the site. Foiled again!

Ah ha! There’s a filter named infinite_scroll_settings we can override! Nope, this is run too early, too.

Finally, Ben Gillbanks (@BinaryMoon) came to my rescue:

He was exactly right. The filter infinite_scroll_js_settings, designed for altering the settings just before they’re passed into JavaScript, works because its parent function is hooked to wp_footer.

Thanks Ben!

If you’ve got a more appropriate filter or an even better solution, I’d love to hear it!

Serve Missing Media from a Production Server via Apache/Nginx

When working on a website locally, it can become quite tedious to pull down all media from a production environment – particularly if you just need to spot-check one or two key areas. In some cases, the production sites I work with have media folders that are more than 1GB (!!) in size. In fact, it’s not entirely uncommon for a large site with a lot of history.

Several months ago I saw someone tweet a simple solution to this, but I didn’t take note of the URL anywhere and it quickly slipped into the ether. Googling for phrases like “apache redirect missing images to production server” or “serve missing images from remote server using apache” or “display live site images on development site” yielded unproductive results.

Then, today, while wishing once again for a solution to my dilemma, I found it!

To save others (and my future self) the struggle of trying to find this solution, I’m documenting it here.

In both of my examples below, make sure you swap for your production server’s URL. And note that these snippets expect the URL structure to be the same between servers (they should be, if you’re working with a true staging copy of a production environment).

Here’s how to tell Apache to serve missing files via remote server:


Note: If you’re working with WordPress, make sure this directive appears before the WordPress-generated rewrite rules in your .htaccess file. Otherwise, WP will catch the missing file URL and route it to a 404 internally.

And, here’s how to tell nginx the same thing:


How about as a WordPress plugin?

You’re in luck! If you’re using WordPress and you’d prefer to slurp up those missing images (so you’re not always dependent on a remote server), you can use the plugin Uploads By Proxy. This plugin will fetch each missing image from the remote server and load it into your local uploads directory for future use. For my use cases, though, I just wanted to see the images on my staging site, not actually copy them and eat disk space.


Becoming a Better Developer: Week 1 Review

This past week has been absolutely packed with new knowledge. I’ve distilled it as best I can for now. I hope future travellers will benefit from this as much as I have.

Getting Started

This past week I read the first four chapters of Clean Code and several relevant blog articles:

Then, on Saturday, I attended the WordPress and Backbone.js session at

I’ll talk about each of these in turn below.

Clean Code, Chapter 1 – Clean Code

Honesty in small things is not a small thing.

This is the omen that kicks off the book, actually belonging to the foreword rather than the first chapter. I really appreciate this quote, much as the author does, because I value the small, the finite, the detailed. Small things matter, and they make all the difference. It reminds me of another quote I greatly enjoy…

It’s always the difference that makes the difference.

Ponder, for a moment, your favorite brands and your favorite experiences. What makes them special? What makes them memorable? I guarantee it’s not their broad generalities. Indeed, it’s their details – their uniqueness from other similar, but different things – that make them special and memorable to you. And, I argue, it is for these very same reasons that the details in your code matter.

It is through practice in the small that professionals gain proficiency and trust for practice in the large.

Attentiveness to detail matters when programming. It means the difference between code that functions properly, and code that brings an entire production site to a halt due to a misspelled variable or missing semi-colon.

A fascinating statistic that the author presents very early in the book is that studies have found “consistent indentation style was one of the most statistically significant indicators of low bug density.”  If you’re lackadaisical about how you’re indenting your code, you’re probably less specific about a lot of other things, too.

Making your code readable is as important as making it executable.

This point, I feel, is paramount to everything else that this book covers. Humans will read your code often – maybe not that one small module tucked away in the recesses of the codebase, or that one-off function you had to hammer out at the end of the day specifically, but by-and-large code that you write will be read again by humans. It will either be read by someone else, or by future-you (which, if time has elapsed more than two weeks, makes future-you as good as a total stranger). What will they think when they read this code? Can they read this code? How frustrated do you feel when you cannot read or understand code that someone else has written?

Have you ever been significantly impeded by bad code?

Where does bad code come from? We run into it often, but why is that? I wager that improper planning, poor time management, and unrealistic expectations are the three most common factors of bad code.

Perhaps you felt that you didn’t have time to do a good job; that your boss would be angry with you if you took the time to clean up your code. Perhaps you were just tired of working on this program and wanted it to be over.

The best way to combat writing bad code is to remember that small things matter and that, ultimately, going slow will lead to working fast.

Working Fast = Working Clean

The only way to make the deadline— the only way to go fast— is to keep the code as clean as possible at all times.

This is a phrase I want to have enlarged, bolded, italicised, highlighted, underlined, and framed. It should be a permanent fixture at the top of every code editor, before the signature line on every contract, and in the footnotes of every email and project communication.

Sloppy code slows everyone down. If may feel faster as you’re writing it, because you’re just flying through line after line as you scramble to complete each function. But think about the gravity of what you’re doing – you’re writing the very lining of your own tomb!

How will you extend that code going forward? How will your code interact with the code of your teammates? How will it respond to the third-party integration you now need to include as part of phase 2? What happens when you or the client uncover a bug – will you even be able to trace it and correct it?

If you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.

An inordinate amount of time is dumped into maintaining bad code. It’s an alarmingly and depressingly large statistic. Don’t burn away hours of your future because you couldn’t spare a few moments in the present.

Incremental Improvements beat No improvements

Try and leave this world a little better than you found it… — Robert Stephenson Smyth Baden-Powell

The next time you sift through a project, take some time to change code for the better. To quote the author once more, “Improve a variable name, break apart a function that is doing too much, see if you can’t eliminate one small bit of duplication…”

Clean Code, Chapter 2 – Meaningful Names

One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.

If you want your code to be understandable to strangers (and I’m including future-you, here), long after you’ve written it, you would do well to choose meaningful names for the things you write. Files, classes, functions, and variables should all be named in such a way that they are completely obvious and even pronounceable.

That last word there, pronounceable, isn’t a prerequisite for names that I had fully considered before reading this book. Now it’s a concept I haven’t been able to shake loose from my head. A function or variable that is pronounceable, say, convert_usd_to_eur(), is far, far easier to verbally reference to your coworkers than one named, say, UsdToEurCnv().

A consistent lexicon is a great boon to the programmers who must use your code.

This is a principle I’ve tried to maintain for almost my entire career as a developer. Not strictly for the sake of other developers, but for myself, too. Using a consistent, predictable naming pattern makes it very easy to correctly guess what something is likely named within a project. If you take no other tips away from this chapter, let it be this one: name things consistently!

Shorter names are generally better than longer ones, so long as they are clear. Add no more context to a name than is necessary.

A long descriptive name is better than a long descriptive comment.

Be concise, but be clear. “Post ID” is better than “The ID of the post”. However, “ID” is not better than “Post ID”. However, while striving for brevity, remember that it’s better for your function or variable name to be descriptive than it is to provide a descriptive comment.

People are afraid of renaming things for fear that some other developers will object.

Don’t be afraid to rename something in this age of “Global Find and Replace”. As the author suggests, you’ll likely surprise someone, but that is far better than the alternative of further cementing a poorly named item in your project.

Clean Code, Chapter 3 – Functions

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

I love this excerpt, and the paragraph that surrounds it. The author cannot justify his assertion that smaller functions are better, except his four decades of experience in writing functions of all shapes and sizes. The shorter a function is, the easier it is to read, and the smaller the space for bugs to hide.

Your functions should tell a story.

Every function in this program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!

The program referenced in the quote above did some pretty neat and seemingly advanced stuff, and even still it could be broken down to functions that were an average of four lines long. That’s a pretty lofty goal to aspire towards, but a goal worth achieving nevertheless.

The implications here are that any nested structures currently found in your functions (if and switch statements, iteration loops, etc) are better suited in their own separate functions.

Functions should do one thing. They should do it well. They should do it only.

Functions that do one thing cannot be reasonably divided into sections.

Break apart those large functions! Make sure every function has a single purpose, and remove everything else it’s doing until that purpose is met. It is OK if a function’s sole purpose is to call three other functions, but make sure its name clearly reflects that purpose (e.g. find_and_delete_invalid_subscriptions() – This function is clearly doing two different things because the word “and” appears in its name. If those two things are two different function calls – find_invalid_subscriptions() and delete_invalid_subscriptions() – that’s a-o-fine).

Your function promises to do one thing, but it also does other hidden things. Sometimes it will make unexpected changes to the variables of its own class.

If a function conditionally behaves in multiple different ways, or it modifies something outside of the scope of its single, solitary purpose, its doing too much. Refactor that function in such a way that it does its one obvious purpose, and put the other bits into a separate function.

Functions should either do something or answer something, but not both. Either your function should change the state of an object, or it should return some information about that object.

On Function Parameters…

The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification— and then shouldn’t be used anyway.

This is something I want to explore more in-depth, and I’d wager its worthy of a blog post all its own. I agree that fewer parameters is preferred to many (e.g. $args = array() vs $param1, $param2, $param3, ...), but I’m not so sure how I feel about “zero arguments”. That is something I’ll need more time to explore.

Clean Code, Chapter 4 – Comments

Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

While reading this chapter I found myself disagreeing with the author quite often. You see, I’ve always found code comments and inline documentation to be tremendously helpful – both while reading and writing code – and he maintains the position that comments are a crutch and too-often clutter up the codebase.

Comments are a great way to get your thoughts down on how you think a function should be written, and what generally needs to happen, in plain English. They’re also a great way to see a quick summary of what a conditional statement may be testing, or a helpful note about why a particular section is written in such an obviously non-optimal way (e.g. “This function checks for [something] in this way because [some other method] isn’t available at runtime”).

After wrestling with many of his points over the weekend, I’m starting to shift my position.

Don’t comment bad code — rewrite it. — Brian W. Kernighan and P. J. Plaugher

[W]hen you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code.

Replace the temptation to create noise with the determination to clean your code. You’ll find it makes you a better and happier programmer.

[Good] comments do not make up for bad code.

Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments.

Most of my struggles throughout this chapter came to an abrupt end when I encountered the above quotes. Prior to this I saw our author as a simple comment hater. When I read, and then re-read these lines, though, I started to evaluate the many ways in which I misused comments in my code.

Don’t waste precious minutes of your limited time on this earth adding comments to poorly-written code. Put those minutes to better use and improve the code. You won’t only be improving your own life, you’ll also be improving the lives of everyone else who will have to interact with that code in the future. You’ll be doing everyone a better favor, too, by improving the code than you will by merely describing it.

Blog Posts – Objects, Singletons, and Dependency Injection, oh my!

I don’t have much commentary to add to the blog articles I read, but I do highly recommend reading them. I’m of the mind that singletons (classes that are designed to be instantiated exactly once) are generally bad and to be avoided, for all the reasons Michael Toppa raises in his article.

I’ve personally been drawn towards using singletons across a number of projects. I liked working within a class structure because of the clean namespace it afforded me. Even as recently as this week I’ve placed code inside of a class that I only intend to instantiate once, globally. I know it’s bad – my awareness of my habitual problems is the entire reason I’ve committed to this 16-week series!

Bonus reading! This weeks serendipitous look at Object-Oriented Programming reminded me of an article I read back in August titled OOP is Not Your Hammer by John Hann.

WordPress and Backbone.js

wpsession6_thumb_pastI don’t think I can say enough good things to fully do this session justice. The three presenters, K.Adam White, Carl Danley, and Zack Tollman each did a phenomenal job in breaking down Backbone and making it approachable, even to a beginner. I’ve had a keen interest in Backbone.js for over a year now, but I just didn’t have the ambition or fortitude to take it on until after watching this session. Now I can’t wait to put it to use. I’ll probably start using it this week, in fact.

If you’re interested in adding structure to your javascript – even if you’ll never actually use Backbone.js – I highly recommend watching WordPress and Backbone.js and learning from the experts. Carl Danley, for example, does a great job guiding how to break apart a project and think about it as discrete, manageable pieces before even laying a line of code.

In Conclusion

To conclude this past week’s study, I leave you with a quote from the end of the Foreword to Clean Code:

Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail.

But never forget that your real goal is to tell the story of the system, and that the functions you write need to fit cleanly together into a clear and precise language to help you with that telling.

We are in for a long haul. This work will not be easy, but it will be worth it. Everything else builds from this foundation, so it is important that we get it right.

Next Week

Over the next week, starting today, I’ll be reading chapters 5-8 of Clean Code.

Are you keeping up? I’d love to hear your thoughts on any insight you’ve gained or any of the commentary I’ve added above. Leave some feedback in the comments!

Becoming a Better Developer: Week 1 Schedule

This week marks the beginning of my 16 week “Becoming a Better Developer” course.

Starting today I’ll be reading the first four chapters of Clean Code:

  1. Clean Code
  2. Meaningful Names
  3. Functions

I’ve looked ahead, and I’m really excited by some of the excerpts I’ve read. I’m particularly enthused by Uncle Bob’s strong emphasis on short, uni-tasking functions and using meaningful, descriptive, and pronounceable names. Just following those two pieces of advice alone can dramatically improve anyone’s code.

I’ll report back on Friday with my key take-aways and highlights.

Have you read this book? What am I in for? Please let me know in the comments!

Becoming a Better Developer

As I stated last week, for the next four months I’m putting myself through code school.

Objective and Plan

In order to do this right, I’ve outlined a 16 week plan that has me reading 5 books and recording what I’m learning. Every Monday I’ll write about the chapters I intend to read and what I expect to learn, and every Friday I’ll write about what I actually learned along with key take-aways. I think it would be great if you were to follow along every week and share your experiences in the comments. I could certainly use the encouragement, and I’m sure you can benefit by learning something new (or being reminded of something they forgot), too.

My main objective is simply to become a better developer. I realize this is largely an unquantifiable intangible, but I know that I (and anyone else following along) will become demonstrably better for putting forth the effort. I can say this with certainty because I’ve never heard of anyone getting worse – or remaining stagnant – after investing sixteen weeks of effort into a sole area of focus.

Demonstrable improvement may surface in any one of the following ways:

  • Increased expedience in solving complicated problems
  • Better solutions to existing problems
  • Cleaner, simpler, human-readable code
  • Improved architecture across the entirety of a given project
  • Code that is easier to test, debug, and extend
  • Jealous co-workers, friends, acquaintances, and arch-nemeses.

Required Reading

Below are the six books I intend to read, in order, over the next 16 weeks. I’ve linked to the kindle edition of each (not affiliate links), and have included the current price on Amazon. You’re welcome to acquire these books however you like.

  1. Clean Code [17 Chapers, 315 pages] – $21.39
  2. The Pragmatic Programmer [8 chapters, 260 pages] – $22.99
  3. Design Patterns: Elements of Reusable Object-Oriented Software [6 chapters, 360 pages] – $27.49
  4. Guide to Building Testable Applications in PHP [16 chapters, 68 pages] – $20+
  5. Refactoring: Improving the Design of Existing Code [15 chapters, 413 pages] – $29.99
  6. WordPress Coding Standards Handbooks [4 pages] – $0

Total Investment: $121.87
Total Reading Commitment: 62 chapters, 1,420 pages
Per week: 4 chapters, 88 pages

In addition to the required reading, I’ll also be participating in every session taking place at

If you want more to read, see my post on additional recommended reading for developers.

Learning Goals

My learning goals are pretty fuzzy at the moment. I’ve learned that there is so much that I don’t know that I can’t possibly know what it is I need to learn or how it will benefit me in the future. That’s a very convoluted way of saying, “I want to learn whatever is written in the books I’ll be reading, and I hope it’s all good for me.”

That said, there are a few things I hope to learn (or better understand) by the time I’m done here. Once I’ve concluded the 16 week course I’ll circle back and update this post with a nice concise list of things actually learned. Until then, here are just a few for-instances:

  • Learn and leverage the common best-practice mnemonic devices (e.g. SOLID, DRY, etc.).
  • Understand the merits and best approaches of Test-Driven Development (TDD).
  • How to efficiently refactor crufty code without destroying everything.
  • How to recognize a problem as an identified pattern with a repeatable solution.
  • Better understand the purposes and capabilities of Object Oriented Programming (OOP).
    • Specifically: when to use constants, static, public, private, or protected properties and methods.
    • How to avoid “singletons” and other the many other pitfalls OOP-beginners typically make.
  • Understand and better leverage Model-View-Controller (MVC or MV*)-style architecture.
  • Better understand and implement RESTful practices.
  • And the coding utopia: the best ways to write cleaner, efficient, and more effective code.

Course Schedule

Week 1: Clean Code, Chapters 1–4
Week 2: Clean Code, Chapters 5-8
Week 3: Clean Code, Chapters 9–12
Week 4: Clean Code, Chapters 13–17
Week 5: Pragmatic Programmer, Chapters 1–4
Week 6: Pragmatic Programmer, Chapters 5–8
Week 7: Design Patterns, Chapters 1 & 2
Week 8: Mid-Semester Reflection + WP Developer Handbook
Week 9: Design Patterns, Chapter 3
Week 10: Design Patterns, Chapter 4
Week 11: Design Patterns, Chapter 5
Week 12: Design Patterns, Chapter 6
Week 13: The Grumpy Programmer’s Guide To Building Testable PHP Applications
Week 14: Refactoring, Chapters 1-5
Week 15: Refactoring, Chapters 6-10
Week 16: Refactoring, Chapters 11-15

Join Me?

If you’re at all interested in this, I urge you to follow along. The only real financial commitment is the cost of the books – if you choose to buy them – which is far less cumbersome than a single college credit, I can tell you that much. Join the mailing list or leave a comment below and let me know you’re following along!

Becoming a Better Developer: Precursor

Here are a few posts I’ve read recently that have helped get me in the frame of mind for the semester of learning I’m designing for myself.

Be sure to check out this recommended reading for developers post I put together on Sunday, and the Back to Basics post I published on Monday. On Friday I’ll work on published the list of books I intend to read over the next 4 months and the specific topics I intend to study and write about over that course of time.

Have a great article to recommend that I missed? Leave a comment!

Back to Basics

This year, my goal is to become a better developer than I was last year. Now, that’s no different than my goal in previous years, and if you’re a developer it should be pretty high on your list of goals as well. However, this year I’m approaching the goal in a measurable, tangible way.

I’m sending my self to code school.

I’ve been building websites since 1996. I cut my teeth on rudimentary HTML on a free Tripod-hosted website that some kindred spirit from the Yahoo! Chat: Programming chatroom helped me create. From the moment I learned that every site had exposed source code that I could view, dissect and emulate, I was hooked.

In the 17 years that have passed since I crafted my first HTML tag, the web has evolved and grown in amazing and magical ways. I have learned and grown with it, but certainly not in the same order of magnitude. In fact, I don’t even think the work I’m producing adequately demonstrates SEVENTEEN YEARS of education. This is largely my fault.

For the better part of these 17 years I have snubbed formal education and conventional learning. I haven’t attended a programming class of any kind or even so much as cracked open more than one or two programming books. Everything I’ve learned has been out of curiosity or necessity from project to project. In the folly of my youth I scoffed at the notion that I could learn something of value about our fast-paced industry by reading an already out-of-date book or enrolling in a behind-the-times college program.

What a fool I was.

Now, this isn’t to say I’ve ignored collective wisdom. Certainly not! I would not know any of what I have learned without the help of minds that are both brighter and more generous than my own. I owe a great debt to those who documented their work and put out blog posts, tutorials and other instructional materials. It is in their footsteps that I hope to follow.

This year I hope to undo all the damage I created by not taking my discipline seriously.

Developer Boot Camp

For the next four months I’ll be attending a self-directed semester of education. I’ve solicited book recommendations that every good developer is expected to have read, and I’ll be completing sample projects that I believe are important to learning the principles these books will teach. By the time the semester is over, I will be a demonstrably better developer than I am today.

Thankfully, I’ve already gotten a bit of a head-start. In June of 2013 I launched WPSessions, which has brought to me the personal instruction and expertise of more than 17 WordPress experts so far. I’ll continue to lean on that throughout all of 2014 as well, but the sessions there will only help supplement the more rigorous education I’ll be documenting here.

In my next post I’ll lay out the schedule I intend to follow, the required reading I plan to complete, and the specific topics I desire to learn and master.

Join Me?

If you’re at all interested in this I urge you to follow along. The only real financial commitment will be the cost of the books – if you choose to buy them – which is far less cumbersome than a single college course, I can tell you that much. Leave a comment here, or join the mailing list below, and I’ll do my best to help hold you accountable.

Recommended Reading for Developers – Building a Better Bookshelf

This year I want to become a measurably better developer. One way I hope to improve in that regard is by reading the best books that have been written on the topic of programming and development.

Now, I would consider myself a web developer – I’ve been building websites for the better part of 17 years – but I don’t consider myself a very good one. You see, in all this time I haven’t read more than maybe a single book on the topic. Everything I’ve learned has been from the web, and has been learned quite haphazardly at that.

Please help me fix this.

Leave a comment below with your best recommendation for required reading for a competent developer. Book, blog or otherwise.

The book doesn’t need to be specific to web development. In fact, I would love to read any book that leads me down the path of being a better thinker, doer, and problem solver. I’d love to learn about design patterns and how to efficiently solve problems in ways that have been demonstrated to work. The languages I work with most regularly are PHP and JavaScript, and I predominantly build websites using WordPress, but if your recommendation will teach me principles that extol the pillars of better development practices, regardless of language, I’m for it!

Here are some suggestions I’ve already received:

So, tell me, what book (or blog) are you shocked I haven’t already read at some point in the last 17 years?