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:
 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.
 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.
 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.
 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.
 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.
One of my favorite projects so far has been this little snake game.
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…
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…
For now, I just hope you enjoy killing time with my little snake game.
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?  Move to a bigger city hoping to find work in a cubicle somewhere, or  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.
So you might be wondering, who is this “Sunfire” chick? Where’d she come from? And why should I trust her to build my website? I think I can answer the first two questions fairly easily. I will leave the third one for another post, though.
In case the About section on my main website doesn’t give you enough detail, here’s a better breakout:
- My real name is Connie Hill, but I have been known as Sunfire since high school (10th grade, to be exact). It was a nickname I chose for myself that everyone agreed was particularly appropriate. The name fit so well, some people never even knew my real name.
- After graduating high school, I served 5 years in the US Navy working on computers in rooms with no windows in buildings underground. The travel with free room and board was nice, and I learned a lot of valuable skills.
- I left the Navy in 2006, and by 2008, I had established an online hobby business selling my pyrography (wood burnings) under the name Breath of the Dragon. First on Etsy, then moving to Zibbet in 2010.
- At the same time, I was working nearly full-time at a local grocery store. I have done a lot of different things for that company, including cooking in the deli, stocking grocery freight, changing price tags, even running my own department a couple different times.
- Oh yea, also in 2006, I decided to take my GI Bill from the Navy and head to college. I signed up with DeVry University Online, originally for a Business Administration degree. It didn’t take long for me to drop that in favor of something I actually enjoyed: Web Development.
I finally graduated with my Bachelor’s degree in Computer Information Systems with a concentration in Web Development and Administration in July 2014. Sure, it took a while. The thing about the GI Bill is that it only covers so much of the cost. Every time I owed too much, I had to stop taking classes until the previous ones were paid in full. So I had to take breaks in my learning.
But I did it. And I’m looking to take that degree and make real use of it. If I was willing to move to Seattle or another major tech hub, I would probably already be working for some major firm. But I really like living here in Wenatchee, WA. And so does my husband. We don’t want to move, so we’re doing what we can to find (or create) work both in town and through the Internet. I have a good feeling that once I get the hang of full-fledged eCommerce sites, I will be able to make strong sites for all of my crafting buddies from Zibbet and Etsy.
For now, though, I just keep practicing, learning, and exploring. Always looking for new projects to test my skills and knowledge. But we’ll talk about those later…