To plugin or to code?


This seems to be my question as of late – Should I search for a plugin? Or just figure out the code myself?

I’m sure I’m not the only one who, when looking at a problem, thinks “I could probably do that myself…” But then suddenly, things add up, and there’s now a mountain of “I could do it…”s on the to-do list. There comes a point where we must take a step back from ourselves, and honestly evaluate what needs to stay on our own plate, and where we can include others, to get everything done in the end.

For me, this question has arose in regards to a personal project, one that does not generate income, but rather increases the connectedness of our local veteran community. Still, I am torn. So let’s examine both sides…

Option A: Find a plugin

The thing about WordPress is that it is open source, meaning anyone can and does create useful tools, for a variety of purposes. In fact, there are so many plugins out there — big ones, little ones, ones I didn’t even know I needed but suddenly I want — that it is easy to get lost in the pool of options. While I was searching for possible plugins to serve one purpose, I came across another, somewhat unrelated, that I’m highly considering adding to the resource pool…

But remember, just as there are plenty of plugins out there, they are not all created equal. While you are exploring your options, be sure to review the plugin information. Check to see that it gets updated fairly regularly (once in 2 years is probably not a good sign – who knows what security weaknesses lurk in there!). Make sure it’s not something new – a large number of downloads, with plenty of positive reviews, is usually a good thing. However, be scrupulous – How many of those reviews are fake? How often to problems get resolved? When was the last time it was updated?

One last thing – don’t settle for a plugin just because you think you need it. Really keep in mind what it was you originally wanted from a plugin – if you can’t have that feature with limited extras that may only distract you or lower your site’s security wall, then you can probably skip it.


Option B: Write the code myself

On the other hand, I know exactly what needs to be done. I know I can do it (because I’ve done it before). And I’m not afraid to do it.

In fact, I’m already part of the way there – running a child theme allows for a lot of flexibility and creativity. I’ve learned a lot about templates, WordPress hooks and function calls, even plugin themes.

But time. It takes time to write the code yourself, especially if you want to be meticulous with it, like I can’t help but do. And I don’t know about you, but time seems to be at a premium lately. Paying Job 1 has a set schedule, so everything else has to fit in around that. Paying Job 2 is pretty awesome, and super flexible, so that helps break up the monotony while still allowing me to pursue things on my own time.

Outside of that, one of two things happens: [1] everything I want to do suddenly overlaps with each other, or [2] my motivation is completely gone, and I’m so easily distracted that nothing gets done. The constant battle of my life!



I think it really is up to each site owner/manager or web developer, to decide which option is best for their situation. In my case, I’m probably going to end up writing the code myself, when I can find make the time to do it. That way I know I am getting exactly, and only, what I want. And if I do it right, there should be little security flaws to worry about.

Bringing Clarity to Debugging


Many years ago, during my time in the military, I learned an invaluable process: how to troubleshoot an issue. It is all based on understanding the flow, from start to (expected) finish. Knowing the system you work with aids tremendously in being able to fix it when it breaks.

The sorts of things I had to troubleshoot back then were usually power-based. The power comes from the wall, into the plug, through the converter, and out to the various components. Sometimes it was more about the computer system as a whole: I’d see an error on the screen and have to figure out which component in the flow might have caused the problem.

I never thought I’d keep using that skill even after I left that environment. But I did, and still do.

In fact, just the other day, I found myself going back to the basics of troubleshooting. One step at a time. The whole thing doesn’t work? Then move through the process one step at a time to find out where it stops working. As I was working on the PHP code for a current project, I had to do that. With the help of some strategically placed comment tags, I was able to step through the process, one part at a time, to discover where the issue stemmed from. After that, it was a more focused level of testing, carefully analyzing each character of code I had written to find a typo, or a missed semi-colon, or an incorrectly-placed closing bracket.

Usually, debugging code is nerve-wracking and frustrating, but not this time. As I worked to isolate the issue to a single component, I was reminded and reassured that this was logic at work.

So, how do we translate the troubleshooting process to debugging code?

Well, break it down into the 5 steps of the process:

[1] Verify that a problem actually exists.

Here, we need to remember, just because we saw it happen once doesn’t mean it’s definitely a problem. Try to recreate the event to make sure it is an actual issue. During this step of the process, we often start narrowing down some of the causes. For instance – if an input box doesn’t display as desired, check a different browser or device. If those alternatives display correctly, this gives you a head start by signaling that the error stems from a certain browser’s default display settings.

[2] Isolate the cause of the problem.

This is the big part I used recently. Start with a blank slate (or in my case, mostly-commented-out code), and one at a time, include a component, then test to verify that there are no issues with that piece. Ensure you are getting the expected output at this point, so that the correct data is being moved into the next step. Once you are sure that first component is not at fault for your issue, move on to the next one.

[3] Correct the cause of the problem.

After the process of elimination leads you to the part of your code that isn’t working as intended, now you can focus your vision and nitpick. Did you open and close all brackets as needed? Do you have the correct stop character at the end of each line? Did you misspell a variable or method name? This is also a good point at which to review the logic of your code. Sometimes I get so swept up in the tiny details, I miss the fact that my initial logic wasn’t sound as written, and it never actually produced the output I expected. You may also find that a fresh set of eyes at this point will help. As coders, we get tunnel vision when we spend too much time with our own code, so much so that we can subconsciously ignore otherwise-blatant mistakes. Having someone else review the component in question may help narrow it down.

[4] Verify that the problem has been corrected.

Now that you’ve pinpointed the problem code, and corrected your mistake, check to make sure your fix actually produces the expected result. If not, return to step 2 and continue the process. Think of it as working within nested If() statements… Just keep going until all errors have been corrected and validated.

[5] Follow up to prevent future problems.

This step I use the least, but it shouldn’t be ignored or neglected. Often, when creating with code, after deploy or launch, the developer moves on to other things. We rarely return to old code for improvements, unless the client comes to us with worries. But that’s now how the bad guys work. They are constantly pounding on sites and programs, looking for the weaknesses. It is up to us developers to repair those weaknesses as soon as they are found, not only when someone becomes victim to it. That’s why updates come out so often!


I hope that helps next time your code doesn’t perform as expected.

Feed the Snake Game


One of my favorite projects so far has been this little snake game.

Screenshot of the game in its original format

Getting started

Back in 2015, I took a course on Udemy titled “Projects in HTML5” by Eduonix. It included a variety of small projects using some of the new features added to the most recent release of HTML. Anyone who works with HTML knows, however, that it’s not just the markup you need to know – there’s plenty of CSS(3) as well as JavaScript.

The snake game was an exploration of using the newly-added <canvas> element, and using JavaScript to draw on that canvas based on user input.

When I first published my creation, it was nearly the same code as presented in the course. But me being the person that I am, I had already made a few tweaks of my own. As time went on and I played my game, I kept thinking about little ways I could improve the game. I also shared it with some friends who also offered suggestions. Some of those changes were pretty easy to implement; others required a bit more attention (and even some learning on my behalf). Even now, there are still things I want to change about it.

Making it Mine

The most prominent change I’ve made from the original is that I’ve added the ability to start/pause the game. Originally, it would simply start as soon as the page finished loading. Now, once it is loaded, you need to press the spacebar to start the game. And, you can pause the game at any time by hitting the spacebar again…

Updated version of the snake game includes pause functionality

What’s Next?

In the future, the big thing I want to implement is a global scoreboard (probably just for the top 10 scores). I’ve started doing some research on how to do it, but I have a feeling it is going to take a lot of adjustment from it’s original form to make it really work. Not to mention, being married to a security professional, I’m going to want to implement it in a way that won’t be easy to cheat. I know nothing is ever truly hacker-proof, but the hardier my program, the less likely anyone will spend too much time trying to dominate the scoreboard…

If you have any suggestions on how to implement as-small-as-possible of a database, or what steps I should take to keep my PHP and JavaScript code as clean and secure as possible, please let me know. I’m always looking for things to learn.

For now, I just hope you enjoy killing time with my little snake game.

Becoming Known in Wenatchee


Something I’ve learned about my personality, is that no matter what job I am doing, I tend to give it my all and do my best. Whether it be scrubbing chrome in the Navy, or slicing meat in the grocery store deli, or just making copies for someone else in the office….

Once I get my foot in the door with a company, I’m golden. It’s that first step that I have a hard time with.

So when I finished up college, and my husband was asking me what I was going to do next, I started hitting the street. Looking for jobs in the tech industry that weren’t just techs. Learning who the big companies around here are, so I can apply for positions with them, if they ever come open. Within a year, it was easy to see that [a] these companies were rarely looking to hire developers, and [b] the best way to get hired is to already be doing they job they’d want to hire you for… Both kinda tough when you are new to the industry.

What does that leave for me? [1] Move to a bigger city hoping to find work in a cubicle somewhere, or [2] stick it out in Wenatchee, creating a company with my husband, and work for ourselves.

Thankfully, I was able to pick up some small projects from Renee, my mentor of sorts. I interviewed her for an assignment in my last class, to learn about the industry and the opportunities in this area. At the same time, she was secretly interviewing me. While she was not able to offer me a position as an employee (she runs her company with her husband as a partnership), she did see my potential. She was able to pass along some of the ‘entry level’ work that came into her office. That way, she was freed up to focus on the more complex stuff, and I was able to learn more about web development as a profession, while still making some money.

Between the work she sent my way and the grocery store income, money was good. I also learned about networking and making connections in this community. Nearly 2 years later, and we are really getting to know people. Little things like attending a luncheon and sitting next to the mayor as we listen to the Economic Development team talking about ways to make our city better. Or having drinks with the owners of establishments we frequent, without realizing who we have been talking to the whole time. Or showing up at a professional holiday party, and being instantly recognized and complimented on our coordinating garments.

I have gone from a hermit who likes to blend into the background, to reading the business news journal and recognizing half of the people or businesses featured inside. Walking down the street, I smile and nod in response to a knowing smile, to a passerby who I then realize is the publisher of the local newspaper. We attend a networking meeting, and we a greeted with “I saw you out walking the other day” [we are pedestrians – we walk everywhere – but at least this person recognized us, and made it a point to mention it]. Slowly but surely, we are becoming known…. and that’s how it starts. ©2015-17 Connie Hill