Learning to Teach

I’ve been teaching web development for a few weeks at a local web dev boot camp. It has been, in a single phrase, awesome. Not only does this reflect well on my resume, I also get to grow a very different set of soft skills while still retaining my connection to the software development world. The cherry on top is the satisfaction of helping individuals learn and move toward more fulfilling careers themselves. After a long day, it’s that satisfaction that keeps me smiling.

I went to college with the intention of becoming a high school math teacher. I had had some great and some terrible teachers who both influenced me to be a positive force in others’ educations. (Perhaps if I had attended a city school with a modern curriculum, I would have known that software development was a far better career for me, but I went to a rural school that only went so far as to teach typing and Microsoft Word.) But because of my slow start I felt forced to abandon the Bachelor’s curriculum in mathematics. At the same time, the siren song of money was drawing me to a more lucrative career. I abandoned the idea of becoming a professional teacher and pursued programming, but my desire to be a great educator never disappeared. And now my teaching job marries those two paths: the career that was and the career that could have been.

Read More

Deletin' Makes Me Feel Good

The following idea isn’t new. It’s been repeated many, many, many times, and that’s without digging through Twitter. It’s practically a truism.

Every line of code is a liability.

I learned from the excellent book The Goal that companies used to consider inventory as a positive item on a balance sheet, but that it is now considered negative because until sold, it is only capital loss. Inventory has non-zero cost and zero benefit.

The same is true of code. The primary stakeholder of any software project does not care in the least how much code was used to deliver the solution, or even whether code was used to deliver a solution. Only the benefit is valued; all else may be necessary costs to achieve the benefit, but they’re still costs.

I learned this lesson early in my career. Inheriting an old, decrepit application gave me plenty of opportunities to refactor and delete. It became a regular source of joy to delete lines, methods, files, and even whole projects from that application. I’d semi-seriously joke with my coworkers that I started every workday by deleting a few lines of code.

It also put me in the strange position of having removed more code than I had written. If we’re counting by lines, I added more value to the company by deleting code than by writing it.


By the way, the final link in the list above leads to a fairly old website/blog that’s nevertheless full of really insightful wisdom.

Anxiety over the Unknown

Do you ever feel anxiety over large, ill-defined projects or goals? I do, and often. How would you feel if I told you that you had to accomplish the following:

  • learn Chinese
  • buy a house
  • learn [some JS framework]
  • give a 90-minute presentation on your area of expertise
  • actually become an expert first
  • understand blockchain technology

I’ve tackled all of those in my life. Each one caused multiple occurrenses of irritation and anxiety that usually manifested in tense, shallow breathing and a knot in my stomach. This happened just by thinking about those goals. For me, the agony of not knowing was far greater than any fear of failure. Each challenge was so big that I couldn’t think about it all at once and didn’t immediately know how to solve it, therefore I feel incapable of solving it, thus the despair and anxiety.

I’ve actually accomplished almost all of those, and I can promise that the level of difficulty was never as great as the intensity of my negative feelings. As far as emotions are concerned, just sitting down and **doing*** something was all it took to transform a monstrous beast into a not-insignificant-but-manageable challenge. I’m not saying that they were suddenly easy, but that my emotional state was a lot more cooperative. Buying my first house really was daunting and exhausting, but walking through each step sequentially by my agent is what kept my head from exploding from anxiety, and an unexploded head is crucial in any endeavor.

The art of writing is the art of applying the seat of the pants to the seat of the chair.

It seems to me that this popular advice for writers is a simple, actionable strategy for any problem that falls into the category of anxiety-inducing immensity. Not necessarily because you will breeze through your tasks—you probably won’t. But I promise that once you start moving even a tiny bit toward the end-goal, you will start building momentum that will dispel the unrealistic emotions of inadequacy, which in turn will replace your negative feelings holding you back with positive ones that motivate you to success.

TL;DR: “I care about your feelings” is basically all I’m saying ♡

P.S.
*For the final goal, I plan to learn how blockchain works and build my own in less than an hour using this tutorial from FreeCodeCamp. I love FreeCodeCamp!

Hungarian Notation is just Namespacing

There are two kinds of Hungarian Notation. “Systems” Hungarian ascribes a type to a variable, typically in a language that does not have strong typing, and “Apps” Hungarian appends to the variable name a dimension of intent. In a nutshell, one is to be avoided and the other lives on as namespacing.

If you’ve ever had to muck about with very old code, you may have seen variables such as strFirstName or intProductCount. I first ran across this when I was first discovering programming in VBA (yuck). It sort of made sense to my newbie mind. When I later learned Java in a college course, System Hungarian became worse than useless. The type is already enforced by the language, so int intProductCount is obviously redundant and creates manual work during refactoring. It is largely accepted throughout the programming community that Systems Hungarian notation is an antipattern, but it is slightly less widely known that this “bad” implementation of Hungarian notation is not what the creator envisioned at all!

Apps Hungarian, on the other hand, is the “real” Hungarian notation, and it’s very good! It attempts to communicate something about the purpose of the variable. Where Apps Hungarian was meant for programming languages, it applies anywhere you need to name something. The principle applies to HTML/CSS classes, too. Consider the following code:

1
2
3
<div class="search field space">
<input ...>
</div>

You can take a guess at what those classes mean, but you probably won’t be very confident! What if the classes were named like this:

1
2
3
<div class="js-search c-field, u-space">
<input ...>
</div>

With just a little knowledge of your project’s conventions, you now know that js-search is a hook for javascript, c-field is the root of the “field” component, and u-space is a utility class for slapping on additional styles, probably just margin and/or padding. That’s the benefit of Apps Hungarian. To me, Hungarian notation is nothing more than the first implementation of today’s concept of namespacing, which is one high-impact method for promoting good CSS architecture. Perhaps there’s a distinction between the two terms, but indisputably the aim of both is to communicate intent.

Here’s a twelve-year-old post from Joel Spolsky that is both amusing and more informational than my own li’l blog post.