On Setting My 2019 Goals

I’m the sentimental type that takes a new year very seriously. There is something about the natural pause at the holidays that makes goal-setting, planning, and otherwise organizing seem so natural.

I did not make goals for 2018. As 2017 turned into 2018 I was preoccupied with recovering from the trauma associated with a life-threatening medical complication during my pregnancy only to have my February due date child born just a few days into 2018. On a day when I had no less than seven meetings scheduled!

The biggest thing I learned from not setting goals is that when you don’t have goals established, you don’t have guideposts to help you systematically evaluate your situation in order to make changes. It’s impossible to tell whether you’ve succeeded or failed and all too easy to assume that you must be a failure.

And I did. In my mind I was one big massive failure.

For the first time in my life I wasn’t able to put all of my extra time into making sure everything I did professionally was absolutely perfect. To me, every little flaw was magnified, compliments were ignored, anything that might be an accomplishment wasn’t recognizable. I lost my confidence. I was a failure, or so I felt.

By any other year’s standards, professionally, I was a failure. In 2018 I built fewer websites than I have since I began working professionally as a web developer, I spoke in public only once – a repeat talk at my local meetup, I had a hard time keeping up with the developments around CSS grid, Gutenberg, the GDPR, and JavaScript. I became isolated: I went to only two meetings of the WordPress team that I’d led through the end of 2017 and my attendance at conferences or other meetups and trainings was at an all time low.

The thing is though… I wasn’t a failure. Not even close.

I very suddenly became the parent of a late-preterm baby who needed extra special care in the NICU and then, just when things were starting to seem “normal”, that pesky life-threatening issue I’d had during pregnancy came back and I needed to have surgery again.

2018 was an exceptional year. In spite of the fact that I was learning how to be a parent, that I was in a significant amount of pain for a large portions of time, and that I was recovering from trauma, my business and my skills didn’t die. I let go of my unpaid commitments and I maintained my skillset through the work I was doing. It wasn’t until recently that I could see it: in spite of very difficult life circumstances I remained committed to my existing clients, I worked hard on their behalf, I added a few new clients, and I made enough money to stay self-employed.

Did I spend lots of time volunteering on open-source projects? Did I build new skills in my free time? Did I push myself professionally? No, I absolutely did not. And that is OK. My life demanded other things from me in 2018. Sometimes life happens instead of ambition. Health and loved ones, those key components of life, are always going to be more important.

I am not preoccupying myself with all of the hard things that happened: they happened and they are over. It’s my job to live and dream now, both personally and professionally. For 2019, I am making goals again. They are across a range of categories:

  • environmental
  • family
  • financial
  • health
  • personal
  • professional
  • relational

One of my most important learnings from this last year is that ambition shouldn’t be confined just to professional, public pursuits. I’ve always made goals in other categories, but the professional goals tended to push out goals like “read x number of books” or “exercise 3-4 times per week.” In the moment, I’d prioritize hitting a client deadline over reading before bed. While this can make sense in certain situations, this choice became my default.

The flight attendants are right though: you need to put on your own oxygen mask before putting masks on others. I know that if I don’t fuel myself up with good food, exercise, time with my family, and time to relax, I won’t be of much use to my friends, clients, and family. That recharge is important. If I’ve got it, I can be efficient with my work. If I’m not coming from a place of healthfulness and calm, I won’t work as well.

And so, in 2019, I’ll have benchmarks established to be able to see if I am moving forward in the way I’d like to in ALL aspects of my life. This way, in six months I’ll be able to tell if I’m making progress towards these benchmarks or not. I’ll be completely happy with unmet goals if I can see why they couldn’t or shouldn’t have happened. The goals aren’t there to be achieved, they are there to establish a path that very well may change along the way. In the end, it’s the path that is important, I just need to make sure that the path is leading somewhere.




2016 Year in Review

Early in 2016, I left my job, became self employed, and never actually announced that fact to the world. Here’s why: It’s scary. Terrifying, in fact.

At first, I didn’t share because I was adjusting in the same way anyone with a new job adjusts. I had left my full time job as a senior web developer at an agency to work part-time rebuilding the technical infrastructure of a non-profit I am passionate about. They had been repeatedly targeted by hackers, and so those first few weeks were spent full-time fixing the biggest security holes. At first, it felt like I just had a new job.

I became preoccupied with setting up a business, which, turns out, is confusing to do in the District of Columbia. Then, I started taking on other clients while setting up administrative structures for myself. All of these logistical parts that have nothing to do with my skillset overwhelmed me. I wondered if I could figure out small business administration, if I could make enough money to make this adventure sustainable, if I could really do everything I wanted to do on my own.

I had a lot of self-doubt (imposter syndrome is real!) and the part of me that is really shy encouraged me to keep to myself while I got used to what I was doing. At the same time, I appeared on WP RoundTable, which was the first public indication that I was self-employed.

Meanwhile, I realized something really important: I loved my clients. Big love. Unicorns jumping on rainbows love.

I was happier than I’d been in years.

It was feeding my soul to work on projects that are focused on making the world a better place. Every day, I was delighted to work with my talented, passionate, amazing clients.

I traveled a lot to attend conferences and spoke quite a bit (WordCamps Lancaster, Northeast Ohio, New York City, Pittsburgh, Baltimore, and US). The total quantity was perhaps too much for my homebody self, but I absolutely love teaching through public speaking and enjoyed every second of these trips.

WordCamps have been a constant in my life for years now, as have the WordPress Training Team, the WordPress DC Meetup, and DCFemTech. I can not explain how much I adore the people in these communities. For me, 2016 highlights from these areas of my life include the training team building out their first full workshop, speaking at the DC meetup about one of my favorite topics: color, leading a workshop for the Women’s Information Network on getting into WordPress, helping organize DCFemTech’s very first Inspire event, and helping organize DCFemTech’s second annual Hack for Good. Dear friends in these communities also connected me with opportunities to my very first guest blog post for Design TLC and do an AMA for ManageWP.

The support of these communities, friends, and family buoyed my spirits in the times when my confidence dipped. And it did dip: there is nothing like being totally on your own to cause self-doubt. In spite of this, not once did I feel lonely in 2016, even though I spent most of my time working by myself. When I felt discouraged, tired, or otherwise doubted myself, I’ve been so thankful to have people in my life who help pull me back into a productive place.

I worked more in WordPress and less in Drupal. I ended the year with an 80% WordPress/20% Drupal split in work, which is exactly the opposite of what this distribution looked like in 2015. In doing so, my skills as a WordPress developer grew tremendously, which was a larger goal I’d had for the year.

Consciously leaving the security of full-time employment is easily the biggest professional risk I’ve ever made, but is also perhaps the best thing I’ve ever done. In 2016 I worked with many of my favorite people from all parts of my life and career. I worked with designers who pushed me technically and projects that presented new problems. I am a better developer, project manager, and all around problem solver than I was a year ago.

I got over being afraid of being self-employed and started to revel in the possibilities of it.

So what’s next?

In 2017 I want to focus on expanding past client work. Don’t get me wrong, I am still doe-eyed in love with my clients and intend to keep supporting them and working as a developer. It’s just that I also want to spend more time writing, speaking, and teaching. My clients and others I’ve met this past year have helped crystallize something I already knew: web development and the internet spark a lot of anxiety in people who are trying to learn to code or who are trying to manage their websites. I love working with these people so that they are empowered with the tools and skills they need and I want to do more of that work outside of my one-on-one client engagements.

With that, stay tuned! I’ll be blogging regularly in 2017 and also have a few other projects sitting in the wings. I’d love to have you along for the ride, so please consider being one of the first to join my brand spanking new email list!

What are your plans for 2017? Let me know in the comments!

I am Writing a Book this November

Last year I failed to write a novel. I had every intent of writing a book and I even had an idea (think the results of apocalyptic consumerism encouraged by a greedy and controlling government). So, I signed up for National Novel Writing Month (NaNoWriMo) and gave it a go: I lasted two days.

I failed because I was trying to write a book that is fundamentally outside of what I read. The only novel of any kind I can think of that I have read in the last five years is Louise Penny’s Still Life, which I read because I was on vacation with my sister, who has read every single one of Penny’s mysteries. It was a great book and the perfect thing for me to read at the beach, but the reality is that when left to my own devices I read massive quantities of non-fiction.

This year, I signed up again, but I am going to defy NaNoWriMo convention and write a non-fiction book. My years of aspiring to write a novel have taught me that the goal of NaNoWriMo is overarchingly to get a first draft (at least 50,000 words) on paper in the month of November, so that is exactly what I am aiming for.

I have an outline of the book I am envisioning, but I have not done any research beyond sharing the outline with a few people to get their feedback. I have lots of questions. Will the amount of research that I’ll need to do be more or less labor intensive than my fiction-writing counterparts? Will the 1600+ words that I need to write per day to reach the goal be doable with my subject matter? Is 50,000 words a reasonable target length for my book or will it be shorter/longer? Will I have time to do this given all of the other personal and professional commitments I have in November?

NaNoWriMo also tells you to publicly commit to writing a book so that you’re holding yourself accountable to those you know. Last year I am pretty sure I told two people and that was it. This year, I am writing this post to force myself to be accountable. Writing this book is something I really want to do and so I’m sharing the goal with the world. I am not aiming for a complete, perfect, publishable book this month, but a first draft of something that I could polish and expand after November. I’ll report back in a month and report on how it went. I am determined to make sure that at that point, something of unknown quality and word count exists.

On the Death of Websites

When most people think of a website dying they think of sites that are temporarily pushed off the face of the internet by denial of service attacks or sites that are maimed and manipulated by hackers. Though these two things certainly do cause websites to “die” temporarily, there are so many other ways websites can go to the other side for a little bit… or for good. And however they go, there are always so many feelings.

There is that “oh shit, I killed it!” moment that happens to developers everywhere. Maybe you forgot a semicolon in your PHP and got a white screen of death in return. Maybe you updated your plugins and were inexplicably gifted the same result. Maybe you just did something ridiculous in a moment of temporary insanity like drag one folder into another folder on your server. In most of these cases revival is pretty quick and the dominant emotion is probably fleeting panic followed by the thought that no one probably noticed anyway. After all, you only killed it for thirty seconds, right?

Then there is the surprise takeover. Have you ever gone to a website that you built and maybe even thought you maintained only to find that your website is gone and an imposter has taken it’s place? Did the powers that be really rebuild and repoint their domain on their own?!

Most takeovers are deliberate and mutually agreed upon transfers of power though. Sometimes downloading your files, exporting your database, and packaging it all up to send into the ether is enough to make you feel ill. What will the new keepers do with your files? Will they even use them or are they going to go into a deep dark archive only to be forgotten forever? If you’re the receiver of the package, then what will you find? Will the code be clean? Is this going to be a nightmare to maintain? Maybe it will be easier to just rebuild it…

Then there is the launch surprise. You are responsible for pointing the domain away from the website you’ve maintained and into the unknown. What will be there? Sometimes what is there is beautiful and makes you feel awful inside. Why didn’t you build something as awesome before? Could you, if you wanted to? Self doubt will win every time. Other times what is there is arguably a step back from what you’d built. Why would anyone want this new monstrosity instead?

Sometimes you are replacing your own work. Most of the time this results in genuine relief – thank goodness this old, horrific code of mine is leaving the internet forever. I know it was cutting edge at the time it was built, but it is positively embarrassing today. And doesn’t it look so much better now anyway?

Three Common Visual Mistakes in Web Design

I can not browse the internet like a normal person because I build websites for a living. I constantly critique the websites I find and open up my code inspector to see how a particular effect was achieved. With surprising frequency I have come across websites (including quite a few for huge companies) that are generally beautifully constructed, but that have a glaring visual error that somehow made it past quality control testing. The following mistakes are the offenders that make me cringe the most.

1. Formatting that Forces a Horizontal Scroll Bar

Horizontal scroll bars are expected on websites that were built with a fixed width. However, when a horizontal scroll bar appears on a responsive website, it is symptomatic of an element on the page overflowing beyond that page’s 100% width container.

In a lot of cases I’ve noticed that this phenomenon is specific to only one page or type of page on a website, which helps explain how this issue could have been missed during testing. Elements introduced by content managers into a blog post, for example, can cause this issue on single pages. Often, this issue is not a problem on all widths, but may impact just some screen widths.

A few things that can cause overflow to happen are:

  • fixed width elements that are wider than the current viewport width
  • elements where overflow should be, but is not set to “hidden”
  • when a percentage width is combined with a fixed width and therefore “outgrows” the available screen real estate
  • iframes
  • images or videos that are not responsive

Fixing this particular problem can be tricky and typically involves some detective work. The key element of fixing the problem is identifying which element or elements on the page are causing the overflow. From there, one can make a decision about how to approach fixing that particular issue.

When I run across this issue on a website I am building, I typically will look for the source of the problem by hiding entire sections of the DOM one at a time to see if the scroll bar disappears once a particular element is hidden. Usually I add display: none; to elements using my code inspector to remove them one at a time. In particularly persnickety cases I may comment out entire sections of code that I have identified are NOT the problem so that I can more easily continue to inspect other parts of the page.

2. Favicons from Software or Frameworks

Building a website on top of an open source content management system like WordPress or Drupal is an awesome thing, but leaving the WordPress or Drupal logos as the favicon for your website is not. I also frequently see websites that still have the favicon from the Genesis Framework, which is a popular theme framework for WordPress.

The fix for this problem is simple: create your own favicon that utilizes the logo or branding of the client. Though I don’t recommend it, another option is removing the favicon entirely: no favicon is better than someone else’s favicon.

3. Very Wide Blocks of Text

There are a whole host of typographic sins that are committed constantly on the internet, but this particular problem can be very subtle, which is why I think it is often overlooked.

Wide blocks of text are a problem for readability of content. It is difficult for the human eye to focus on a line of text much beyond 100 characters. Historically, this is part of why newspapers have generally been typeset using narrow column widths.

Typically, if a website was designed with typographic best practices in mind, the comps for mobile, tablet, or desktop screen widths would not have included wide blocks of text. When this issue appears, I think wide text blocks have usually been introduced unintentionally in the development phase of the project. A developer may have failed to pay attention to what happens in between established breakpoints or they may have actively introduced wide text blocks when improvising design between or beyond established breakpoints.

Solutions to fix this particular problem are varied and heavily depend on the design of the particular site in question. Often the fix is to continue a design pattern from a different breakpoint, to establish a maximum width for a particular section, or to add a new breakpoint to address this specific issue.


I’m a stickler for visual details and it drives me nuts when I see these mistakes in the wild. Are there other visual mistakes you’ve noticed that consistently appear on websites you visit? Let me know in the comments.

What Developers Mean when they say “Don’t Hack Core”

In both the WordPress and Drupal communities you’ll frequently hear the refrain “don’t hack core.” What does that mean though? Often I see this phrase used out of context or without explanation. When I was first learning to code, I certainly didn’t know what it meant, I just knew that one time my mentor pointed to most of the files in WordPress and very seriously told me that touching them or changing them was very very bad.

What is core?

In order to not hack core, we first must be able to identify what core is. In general, “core” refers to the basic set of core files that make up a content management system. When you download WordPress or Drupal, the core files are what you download.

WordPress Core File Structure
WordPress Core File Structure
Drupal Core File Structure
Drupal Core File Structure

What does “hacking” core mean?

In the context of the phrase “don’t hack core” the word “hack” simply means “to change.” This means that you should not make any changes to core.

It’s that simple: do not change the core files. Changing the core files in any way is hacking the core files. Do not hack the core files.

Where am I allowed to make changes?

Of course, in order to customize WordPress or Drupal you will need to add theme and plugin or module files. There are very specific places where these files belong within the core file structure. In WordPress, custom theme files should be located under wp-content/themes and plugin files should be located under wp-content/plugins. In Drupal, your custom theme files should be located under sites/all/themes and module files should be located under sites/all/modules.

There is also a file that you may need to edit in order to make sure that your database is connected to your website (wp-config.php in WordPress and settings.php in Drupal). You’ll notice though that these files are not included when you initially download either CMS’s software. They are created as part of the installation process. In WordPress, wp-config.php is located at the root level and in Drupal, settings.php is located under sites/default.

Some developers will argue that they need to change core because they discovered a problem with it. If you find a bug in core and have a patch for the problem, then submit a bug report to the core development team for the software you are using. In the meantime, don’t hack core.

Why is hacking core bad?

In the most general sense, hacking core is bad because of the security, maintenance, and compatibility problems that making changes to core files can cause with your site. It can cause unforeseen and bizarre problems with the display of a website and can also be a root cause of issues that can bring down a website entirely.

There are also very specific reasons why hacking core is a bad idea. They are:

1. Inability to Easily Update Core

WordPress and Drupal frequently release updates to their core software. These updates include security updates, bug fixes, and new features. It is recommended that you upgrade your software as new versions become available so that your website is protected from any known security vulnerabilities and that it remains compatible with the most current versions of plugins and themes.

When you update either WordPress or Drupal, you are functionally replacing the old core files with new versions of the files. Therefore, when you “hack” core by making a modification to the core files, you are guaranteeing that you’ll need to redo these hacks with every update released for your software. Since the core software is changing with every update it is certainly possible that the hack you originally implemented will not be exactly replicable with a new version of the software.

2. Security Vulnerabilities

When a security vulnerability impacts WordPress or Drupal core, the core developers and community for each project will release an update that patches the vulnerability. If you create your own independent version of open source software, which is what you are doing when you change core even a little bit, you may create vulnerabilities and not even know it. You run the risk of having your site compromised and then having no one who can help you troubleshoot because your underlying software is unique.

3. Maintenance Problems

Most websites are maintained by multiple people over time. This can be due to staff or agency changes or simply due to the primary site maintainer going on vacation. If another person is trying to fix a problem on the website where you hacked core, you can not assume that this new person will look for changes within the core files because it is best practice to NOT change these files. This hypothetical person will instead look first in all of the places where changes should be made, like in child theme and custom plugin or module files.

4. Compatibility Problems with Plugins/Modules and Themes

In both WordPress and Drupal themes are used to modify the appearance and styling of a website and plugins or modules are used to modify how the software works. Some parts of themes and plugins/modules interact with pieces of code found in the core software. If you hack core, it is possible that you could modify something that interacts with a theme or plugin/module you are using and that this could cause unforeseen incompatibility issues. Again, troubleshooting these issues will be extremely difficult because your configuration will be 100% unique.

When it comes to core, there is no benefit in being your own unique snowflake.

5. That’s What Plugins and Modules Are For

Most of the time when people make changes to core, they are doing so because they want to change or add functionality to the software. This goal of modifying and extending the functionality of your content management system is exactly why plugins exist for WordPress and why modules exist for Drupal. Chances are you may be able to find an existing plugin or module that will add the functionality you’re looking for to your site. If you can’t find exactly what you want in an existing plugin or module, then best practices are to code your own custom plugin or module.

What about themes, plugins, and modules?

As with core, best practice is to not make changes to theme or plugin/module files. The underlying reasons for this are basically the same as the reasons why it is bad to hack core: updates will overwrite your changes and you may unknowingly introduce security vulnerabilities.

There are two generally accepted approaches to theme development: using a starter theme to create your own 100% customized theme or using a base theme and creating a child theme that overrides the base theme.

If you are using a plugin or module and you absolutely need to modify the code in order to get the functionality you need for your site, fork the plugin and create your own custom version. This will prevent future updates to the plugin from overriding your changes.


Hacking core is simply changing the core files for WordPress, Drupal, or any other widely used open source content management system out there. The place to make modifications to the way WordPress or Drupal looks is in your theme files. The way to make modifications to the way WordPress or Drupal works is with plugins and modules.

At the end of the day, never ever hack core. Never.