Lately I’ve been fascinated by language, and this led me to ask one big question: why is there so much religion in swear words?

On one of my favorite self-rambling drives, it struck me how so many popular expletives have a touch of religious language:

  • Holy crap!
  • What the hell!
  • God damn it!
  • Jesus Christ! (I’m counting this one)

I have a hard time believing these became swears naturally, since a few make no sense to me. Why is “Holy Crap” an expletive? A swear is normally used when we feel extremely good or bad. Yet “holy” is positive while “crap” is negative. The two cancel each other out and we have a neutral phrase unsuited for swearing. I must’ve missed the memo.

I don’t think it’s some kind of brainwashing, but I do think it’s affected people. It’d be hard for our swears not to affect our thinking. We use them when our emotions are highest, which makes those memories have a powerful effect on us. So would using subtly religious words during these moments subtly push us to religious belief?

Maybe it’s a stretch to think mere words could sway us this much, but language shouldn’t be underestimated. When it comes to our beliefs, if our thoughts are the most important part of them, our language is right after it. We can’t have thoughts without the language to form them, so the words we use directly affect the kinds of thoughts we have. It’s why in 1984, the Party was removing words related to rebellion - it would make rebellious thoughts impossible, thus rebellion itself impossible. It’s also why politicians are trained to pick their words extremely carefully, since the emotional effect of different words can greatly influence how we view an issue.

I like to wonder, if these types of curse words weren’t used, how much would the world’s religious views change? Would people today be more or less religious than they are now? My own guess is people would be less so, although I don’t know how much. As much as language affects the world’s religions, it’s only one factor.

Think about it: if some subtly referenced the zoo whenever they swore, the zoo would be much more important to them. They’d likely visit the zoo regularly, give money to their local zoos, ask their zoo for forgiveness after making mistakes, protest against businesses they think are anti-zoo, and say people who don’t go to the zoo are bound for eternal suffering.

It sounds crazy, but remember: don’t underestimate the power of language. A few different words and, in a few decades, everyone could be part of the Sacred Church of Zoology.

September 26, 2016

Are we too Comfortable?

People today have lots of entertainment - streaming television, online games, extravagant video games, social media feeds, eye-catching news, endless music, and more.

Most often we hear these are good. They make us laugh. They inform us. They exhilarate us. They give us enjoyable memories.

But are they the best use of our time?

With so much entertainment at our fingertips, are we fulfilled or just comfortable?

I don’t mean comfortable as in “relaxing in a big chair,” I mean as in “comfortable with not doing something productive or meaningful.”

My biggest issue with all this entertainment is it gives us the illusion of meaning. Reading fluff news made for clicks makes us more informed than we aren’t. Interacting on social networks makes us feel more connected than we are. Watching dumbed-down or simplified television makes us feel more mature and rational than we really are.

These all feel nice but give a false feeling of moving forward. They make us feel like we’re fulfilling our potential when they’re just making us comfortable where we are.

But my logic raises this issue: do we need feelings like anxiety for a meaningful life? Would this meaningful life than be less enjoyable?

How does someone feel when they’re motivated to learn a new skill? Pick up an unfamiliar instrument? Write out their inner thoughts and feelings? Make something creative with only a slim chance of success?

Are they satisfied with life or just unconcerned with it?

For me, the motivation for coding in my spare time has been rooted in different anxieties. I’d make something new out of fear I’d need it in the future. Out of sadness that I’d never be as intuitive as characters I enjoy. Out of frustration that, no matter how cool I may make something, someone else will make something better.

See the Pen Hypnotic Spiral by Maxwell Antonucci (@max1128) on CodePen.

This is only me - I don’t know if everyone else needs to suffer, at least a little, to feel fulfilled or productive.

But I know there’s a big difference between feeling fulfilled and feeling comfortable. And the more comfortable we are, the less likely we are to feel fulfilled.

Please remember that before you watch that new series on Hulu.


I’ve never been scared of death itself, only the times where it’s on the horizon.

To me it never made sense to fear death. A book I read in middle school described death as “a wall on a road that goes up for eternity, left for eternity, right for eternity, down for eternity, and is as thick as eternity.” No matter what we do, it will be there. That makes fear pretty pointless, since it’s meant to help people avoid danger. With a danger that can’t be avoided, fear won’t change much.

Whether or not there’s pain doesn’t affect this. The amount of pain I’d feel during death is equal to the amount of relief I’d feel from it. Plus pain isn’t exclusive to death - I imagine I’ve got as much pain in my future as I do pleasure. And that’s fine. If we didn’t have pain, pleasure wouldn’t exist. Likewise if we didn’t have death, life wouldn’t exist. The worse I’d feel about one, the better I’d feel about their counterpoint. It all equals a calm acceptance of death when it arrives.

So I don’t fear death. I fear when death is creeping into view but isn’t quite there. When you can measure the final distance between you and death. A rush to do the things we now don’t have time for. It throws questions of how we should act, how we should feel, if we did enough things right, if we did too many things wrong.

We have no time to answer any of those questions that need an answer when the distance is so short. The panic and realization of death without the peace of mind and acceptance. All the pointless fear before the acceptance. A clawing uncertainty.

All those feelings sum up my last week. The last week we had with Jasper.

He was getting slower and weaker. Eating less and always laying outside. Needed help just to walk across tiled floors. Every moment I was feeling that clawing uncertainty. Had I done something to cause this? What can I do now? What more could we have done to make him happy? What if this isn’t the end? Even worse, what if it is?

Painful as it was to think about, I could see something just over the horizon. The remaining distance now visible and getting shorter.

It lasted all the way until this morning. The vet said it was internal bleeding caused by a large tumor. He only had a few months at most. The best decision would be to peacefully put him down. Like a candle the uncertainty was blown out and I was left full of shadows.

I could only ask myself: now what? There’s no uncertainty or fear, so how do I feel?

All I knew was I didn’t want to feel the same as last time.

This “last time” was when our other dog, Maya, passed away. It was several years ago. I was at school in Upstate New York, studying in the library. There was a phone call, the news, and an empty line. Then a stale feeling in my chest.

No collapse. No tearing up in public. No rush of good memories. Just a stale feeling as my mind unjammed itself and went back to studying. It nudged me for the attention it needed but I didn’t give.

I hate the short distance between life and death in these times. But I hate something even more: the huge distance between my feelings and Maya’s death. A distance I never managed to close.

I didn’t want to feel that kind of distance again. So I held Jasper close, told him I loved him, kissed his forehead and let him lick my face one more time. The tears were coming but I couldn’t break yet. We drove home, cleaned some things up, and I called some family with the news. Then I went into my room and broke. The collapse. The tears. The rush of memories. A lot more.

There was no longer any fear, uncertainty, or distance. There were lots of feelings now. They were all bittersweet. I knew I was only so sad because I’d been so happy before, for so long. It took a while to balance out, but I eventually got to that calm acceptance. It slips in and out, but it will stay with time. Then I’ll be able to think about Jasper with a smile instead of more tears.

Being a short distance from death is terrible, but a huge distance is worse. There’s no terrible feelings, but no good ones either. When it comes to death, we shouldn’t regret having to close that distance with others or with ourselves.

Because avoiding death forever means avoiding life forever. Like a life with a loyal, quirky, and lovable dog that you will miss immensely but will have no regrets about.

June 12, 2016

Have a Second Blade

I rediscovered an important career lesson in a manga where high schoolers try to kill their tentacle-alien teacher. An unlikely place, but I swear it’s worth it.

The important lesson is to have a second blade. That’s an edgier way of saying “have a backup plan.” Not a small one though. A backup plan for one’s entire career.

What’s this Weird Manga?

First off, the manga “Assassination Classroom” is a great read for many reasons: a great anti-hero teacher, surprising depth, and making me cry at least twice. But let’s focus on one chapter.

In this chapter, the teacher Koro-Sensei duplicates himself to tutor each student for exams (stick with me here). But the students say if they can assassinate him for the reward money, they’ll be set for life. Knowing this, their grades don’t matter. As long as they kill him, things will work out.

Koro-Sensei then, for some reason while making a tornado, gives an important lesson: the success of their primary goal isn’t assured. They may fail the assassination before the year is over. Someone outside the class may kill him. He could leave the classroom and avoid their future attempts. Most of these possibilities are totally outside their control.

In short, what they built their futures on is fragile. So they need at least one backup plan for their lives, or as he calls it, a second blade. Otherwise they’re not qualified to call themselves assassins.

How’s this Relate to my Career?

Having a second blade doesn’t just apply to killing an alien teacher. It has more relatable, less absurd applications, such as every career ever.

Take front-end web development. I could pour all my time and energy into it. Coding visible web components and creating new websites. I already do that a good amount now, so why change?

Like with the assassination classroom, most or all of this effort could be for nothing. It doesn’t take much searching to see why in my case. What if tools like The Grid go mainstream and automate everything? Too many businesses stick to social platforms like Facebook and Twitter instead of official websites? People only make sites with premade components or templates, like WordPress themes or frameworks? Businesses focus more on native apps instead of websites? These are already issues, and could do all the above someday.

Planning a second and third strike is important in case the first misses.

If I pour all my time and energy into that first blade, it’d go to waste. Then where would I be?

Having a second blade helps avoid this. If I assumed all the above happened, what skills would I fall back on? What would I wield instead? But the digital field has plenty of related options:

  • UX Design
  • Branding
  • Accessibility
  • Web privacy
  • Writing and content management
  • Expanding into back-end languages
  • Likely many more I don’t know

Get Your Second Blade

Thinking ahead is one thing, but thinking far ahead and for the worst is another. A second blade is more than a backup plan, it’s a backup plan for one’s entire career or life.

This is vital to assassinations since without a good backup plan, you can get killed. In real life, it’s so all your work doesn’t go to waste. Something beyond your control could shake things up, or destroy them, at any point. Without a second blade, you can’t fight back.

So whether you’re worried about your career, or trying to kill your tentacle alien teacher, a second blade is a worthwhile investment.


The good and bad about web projects is they can get complex. It’s good because one can make incredible things limited only by imagination, free time, and lack of social life. It’s bad because overly-complex projects are hard to maintain, slowly break down, and eventually self-destruct.

For the sake of work and insurance premiums, complexity must be kept at bay. Not removed altogether, as we then couldn’t savor others’ bemused expressions when showing off our work. Coders just need to control and manage their project’s complexity so it scales without breaking.

This isn’t new info. The fun part comes when coders talk about how they control it. There’s no set in stone rules. Some are common, some are rare, all depend on the person.

In my case, I have eight general yet firm rules for my code. They keep it modular, editable, and easier to manage. I won’t scream them from the rooftops as the token to our salvation. But I’ll share them for other front-end coders looking to write or improve their own rules.

Plus my megaphone is broken and there’s no tall rooftops in my neighborhood. So let’s begin!

Thou Shalt Write Lots of Inline Comments

Informative comments in code seem like a chore. One that takes too much time, especially for projects with deadlines. This does not matter. For the love of a supposed God, write lots of comments.

I’ve learned their importance first-hand. At the start of the year I finished up a prototype. Earlier this month I had to make some changes. Looking through it was like going through a familiar maze after being spun around, blindfolded, and all signs were written in German.

No matter how obvious the code was to me before, enough time will take that away. Inline comments are the simplest, most effective way I’ve found to avoid this. For me, inline comments should be for:

  • Each page’s basic function - put at the very top.
  • Variables - what they’re used for and their unit of value.
  • Loops or functions - use, output, arguments, and examples.
  • Any complex chunks of code - to avoid future “look at it weep” situations.

Thou Shalt not Style Components Through Parent Elements

Modular CSS is written it can easily go from one project to another. Elements’ styles must be totally independent, or at least easily editable. A common way I’ve broken this rule is making important styles reliant on containers.

CSS Components must have styles completely independent of elements around them.

For example, let’s say I had a slider full of pirate ship pictures called a Pirate Slider. Normally the Pirate Slider is full width, but I made it half-width inside an article container. That’s convenient for this code, but now using it’s harder to use my Pirate Slider in other projects. That’s because code outside the component is effecting it so much. The component becomes more of a hassle to use.

Simple lesson from our Pirate Slider: don’t have any styles rely on container or parent elements. Especially widths, floats, padding, or margins, as they’re the most noticeable and volatile ones.

Thou Shalt Always Use Scoped Variables in Component Style Sheets

A common issue I’ve faced moving components from one project to another: it’s full of variables and values unique to that project. Restyling means going through the sheet several times replacing them, checking if I’ve missed any, finding some, and repeating at least three times. Imagine doing this every time a component is used elsewhere and don’t feel frustrated. I’ll wait.

The makers behind Bourbon’s Refills knew about this when making web components designed to be dropped into projects. All important values are held in unique, local scope variables atop the page. Changing the core styles is as easy as changing the variables.

.accordion-tabs {
  $base-border-color: #dcdcdc !default;
  $base-border-radius: 3px !default;
  $base-background-color: #fff !default;
  $base-spacing: 1.5em !default;
  $action-color: #477dca !default;
  $dark-gray: #333 !default;
  $light-gray: #ddd !default;
  $medium-screen: 40em !default;
  $tab-border: 1px solid $base-border-color;
  $tab-content-background: lighten($light-gray, 10);
  $tab-active-background: $tab-content-background;
  $tab-inactive-color: $base-background-color;
  $tab-inactive-hover-color: darken($light-gray, 5);
  $tab-mode: $medium-screen;

// Rest of styles and selectors go here


I don’t do this for every component’s styles, since it’s too much work. It has to meet these criteria:

  • It’s separate from the project’s base styling, like typography or colors.
  • It’s styled mainly with unique classes. At the very least, all first-level selectors should be classes.
  • It’s something likely to be used in other projects. A general-purpose menu? Sure! A menu built specifically for vegetarian pizza websites? Congrats on designing something with such an odd specification. Likely not needed elsewhere.

Thou Shalt Use the BEM Naming Convention

The previous commandment has one flaw: with all those class names, there’s a higher risk of some being the same. It also has a footing flaw during its tennis backhand, but that’s its own problem.

Anyway, my preferred way to avoid this is the BEM (block, element, modifier) naming convention. I won’t explain it here, as lately there’s been tons of articles doing just that. But I will say it’s very useful keep classes specific and organized, especially for components.

Thou Shalt Use Sass Maps for Global Variables

Before I used basic Sass variables to define global variables for major elements like typography, colors, breakpoints, and containers. But there’s lots of risks with this:

  • Naming things is tough, and so is remembering those names. The more global variables, the more different names you need, the harder using them gets.
  • There’s always the small, but still dangerous, risk of overlapping variable names.
  • The relationships between the variables can get complex, such as different colors or font-sizes. Capturing these in variable names makes them long and unmanageable.

I’d just accepted all this, but a BigEng article showed another approach: Sass Maps for global variables.

Now instead of a big, confusing list, they’re organized to clearly show their values and relationships:

$g-color-main: #00F;
$g-color-action: #F00;

$color-map: (
  main: (
    lightest: tint($g-color-main, 85%),
    lighter: tint($g-color-main, 50%),
    light: tint($g-color-main, 15%),
    base: $g-color-main,
    dark: shade($g-color-main, 15%),
    darker: shade($g-color-main, 50%),
    darkest: shade($g-color-main, 85%)

  action: (
    base: $g-color-action,
    hover: shade($g-color-action, 15%)

  mono: (
    white: #fffefc,
    black: #111

Referencing them is also more straightforward and flexible with functions.

button {
  color: color(main);
  background-color: color: color(main, lightest);

  a { color: color(action); }

While every map needs it’s own function, it’s worth it for easier use and scalable management.

Thou Shalt Only Nest Classes, and Never More than One

Aside from reading too much manga on weekends, my only serious bad habit is too much Sass nesting. It starts simple: nesting one element in another. But the more changes I make, the deeper that nesting gets. Before I know it an element’s CSS is a nested clusterf**k with impossible maintenance.

.first-selector {
    color: black;
    font-size: 3em;

    background-color: red;

    .second-selector {
        border: 1px solid purple;
        .element {
            @include position(absolute, 0 null null 0);
            padding-bottom: 2em;

        .element-two {

            .some-text {
                font-size: 0.83em;
                text-underline: underline;

                .that-one-element-you-need-to-change { //Good luck finding this
                    margin: 1em;
                    float: right;

This rule cuts this behavior off before it gets ugly: if you’re about to nest something inside something already nested, STOP. Take the extra minute to add a class and extra selector. It’s shorter than the extra ten minutes of tracking the element down in the aforementioned “nested clusterf**k” each change.

Thou Shalt only Bind JS to Data Attributes

A small yet important step to separate style and function is not linking JavaScript to classes. This keeps two scenarios from ruining a project’s code:

Function and style should always be separate, especially with classes

  1. A component’s class, or multiple classes, change. If the JavaScript is linked to those classes, it means going through all the related code and making changes. Repeat every time a class changes and tell me how fun that is.

  2. Two or more different components need the same JS functionality. If the class linking the JavaScript has lots of styles, it can lead to painful patches and workarounds to get the same effect without those styles. Example: Foundation 5.5.3’s modals are closed by clicking a .close-reveal-modal element. However, it also affects an element’s size, type, and positions it in the top right. Want a close button at the bottom of the modal? Not much fun either, I’ll tell you.

To avoid all this “fun,” link all JS code to attributes separate from styles. A simple rule is using attributes with a “data-*” name. But anything guaranteed not to overlap with CSS works fine.

Thou Shalt Put Tags and Their Content on Different Lines

This rule iss simple, easy to explain, and more of a personal preference. In a nutshell:

<!-- Write this in HTML -->

    Lorem ipsum dolor sit amet, consectetur adipisicing elit.

<!-- Don't write this in HTML -->
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit.</p>

Viola! With this little rule the content’s more organized and maintainable. The fewer large, hard-to-read blocks of code, the better.

General Rules for All Projects

These rules are meant to be specific but not too specific so they can work for any project. I won’t change each past project to follow them, but I will follow them as much as possible moving forward.

For any developer who hasn’t made similar rules for themselves yet, I encourage it as soon as possible. The sooner it’s done, the easier and more effective they’ll be. Setting your principles and standards up for yourself early means more improvement now and much better quality in the long run. Although don’t go as far as carving them into stone in your office - there’s always a chance some will change later.

Plus white boards are much cheaper and quieter.


Let me begin by typing that while I once loved front-end frameworks like Bootstrap and Foundation, most of my excitement has faded.

I was a big fan while learning the front-end basics. But there comes a time in every front-end developer’s life when they need to lose their training wheels and build their site architecture from the bottom-up. One that meets their specific needs, and they understand enough to use flexibly. Ever since I got Plately together, I’ve been building on that and hardly use third-party frameworks.

But that’s no reason to dismiss them entirely. There’s still times where they’d come in handy for me or anyone else.

I like to compare front-end frameworks to religions. There’s a lot of options out there, with passionate and sometimes scary disagreement. Some people are ardent followers of one framework or a few, some don’t believe in any at all, and others chose the best parts of some without committing. What you ultimately choose comes down to your preferences, needs, and how comfortable you are with silk robes and animal sacrifice.

Lost track of that metaphor, but I have seven situations where I’d accept using front-end frameworks, for work or side projects. If it doesn’t match any of them, I recommend going with something totally custom.

1. You’re in a Hurry

This one’s a given. If a project has a strict deadline, using a framework with the basics built in may be the only way to save enough time.

You may ask: how much of a hurry do I need to be in? Simple: take the amount of time you’d have for a project that’d put you in a horrid panic fearing for your job. Then take off a few days. If you have less time than that, go for it!

2. You use Most of it

The biggest issue with frameworks is code bloat. Lots of elements and patterns are included that, if you don’t use, weigh your site down.

If you actually need that many components, then that issue’s gone. There’s no unneeded bloat since you’re working on a larger site that naturally has a larger codebase. But this means having a clear idea of what the site needs from the start…which isn’t always the case.

But what if you can code all those components yourself with less code? In that case, a framework may not work after all. If you have the time to pull that off.

3. You Cut out Everything you don’t use

Related to the above issue: if you’re not using most or all of a framework, but can remove the bloat of what’s not used, that works too. Many have Sass versions that let you add and remove components as needed.

However, if you’re using a remote CDN to pull all the styles and functionality at once, you’re out of luck.

4. You Customize it. A Lot.

Personally my biggest issue with frameworks is they give sites an “out of the box,” rushed feel. I know that’s more of a pet peeve, but is still worth mentioning. If visitors see the site’s had little effort put into making it, it risks hurting their impression of it. I acknowledge it’s not a huge risk, but it’s there nonetheless.

It’s why I prefer frameworks that are either bare bones or built on Sass - they’re easier to customize consistently. To me, a site uses a framework best when you can’t easily tell which one was used.

5. You’re New to the Front-end

As some back-end programmers discussed about front-end frameworks, they’re very helpful if front-end isn’t your thing. It helps them focus on the product and content without fretting over the CSS and UI.

I don’t think that should be the case for every site, but it’ll be the case for many. Not everyone wanting to make a site can add custom styles. Plus many developers with varying experience could be collaborating and need a common starting point. Those are good moments for frameworks to shine.

6. You need a Reliable UI

Many frameworks are built with user experience already in mind. Elements like navigation, carousels, buttons, and forms are made to be responsive and easy to understand. UI can be surprisingly tricky, as I routinely learn, so having this handled beforehand is a big help.

7. Your Client Already uses it

I don’t need to explain much. Inheriting a major project with the framework already built in? Unless you have a big, compelling reason to migrate away from it and justify all that work, you’ll be using it. And even then, it may be too much work to be worth it.

In Conclusion

I’ll wrap up this post with some frameworks I recommend based on past experience:

  • Bourbon is my top choice despite not technically being a singular framework. It’s four tools you can mix or match to build out a site: the Bourbon mixin library, the Neat grid system, the Bitters scaffolding styles, and the Refills component library. It’s very scalable and you can use select pieces on other projects. My own framework uses Bourbon and parts of Bitters, so they’re very useful.
  • Foundation is the only “mainstream” one I like. It has advanced functions, is scalable, and gives many options for setup and customization. I use it frequently in my work for a big client and, while it can be more confusing than others, is still reliable.
  • MaterializeCSS takes Google’s Materialize styling and turns it into a useable, enjoyable framework. I’ve used it mainly since I love the look and feel of Materialize, and others who do too should give this one a try.
  • Want more? I’ve got a whole Pinterest board of frameworks to browse through.

While I still feel that a personal, tailored framework made on their own should be an ultimate goal for front-end developers, the ones already out there are great starting points. Plus, who says we won’t be using one in some future projects?