Category: Programming

The answer is always in the code.  Or is it?

Yes.  And no.

The code depends on the data being a certain way.  If the data is different, the code will fail.

This is the lesson that I learn (again) after an almost perfect experience of writing a test-driven solution.

I say “perfect” in that, test driven development is sold as a better way to program.  In an ideal world, it’s a better way to develop because you write the tests first, which saves you time because the code works the first time.  It’s the programmer’s equivalent of the construction worker’s statement “Measure twice. Cut once.”

Figure out the specifications first, before you write any code.  You can’t write good tests for uncertain specifications, so the very act of writing the tests will lead you to find out the right information.  This, in the end, should make it easy for you to build software that works the first time.

The time saving promise of writing unit tests is that they will save you from wasting your effort.

Does this pattern seem familiar: Write some code, then realize that you did it wrong, write some more code, then realize that you’re not sure about this other part, wait, go ask some questions, come back, re-read what you’ve written… and maybe write some more (buggy?) code… run some data through your code to see if it works… fix something… test it again… and so forth.

So recently, I wrote some tests, wrote some code that passed the tests, and my code worked the first time, on my local sandbox.  Yay for me!  I did it right, or so I thought.  I then tested it on our development server.  It didn’t work.  What could it be?  I start thinking about the differences between the environments.

It puzzled me for about a half hour.  Then I took a break, participated in my favorite activities, and then had an ah-ha moment.  I realized that the answer to my bug could be in the data.  Sure enough, I returned to my desk and found that the real data was missing an array key that I had assumed would be there.

Lesson learned: Use real data for your unit tests.

[ @todo: Insert photos of bugs and fun stuff.]

It’s not always important to solve bugs with great speed.  In fact, “slow down” is a tip I give myself regularly.  BUT, it’s true that I’ve figured out some favorite techniques that help me solve software development bugs in a timely manner, and I hope you find something helpful here!

#1 Read the bug report carefully and ask questions.

Most initial bug reports don’t have all of the important details.  Ask questions so that you don’t lose time going down the wrong road.  Well thought out questions show that you are working on the issue, which is good news to anyone who cares about it getting fixed.

#2 Reproduce the bug, ideally on your local development sandbox.

You’re going to have to set up the bug locally anyway, in order to test your fix, and my advice is to make reproducing it locally something you do very early on in the debugging process.

The process of trying to reproduce it may shed some light on the situation, which helps with knowing what questions to ask (see point #1).

I have an approximately 2000x greater chance in fixing a bug I can reproduce than in fixing a bug that I can’t reproduce.

#3 Ask for Help

If the importance is on the speed on which the bug gets solved, then the more brains, the better!  How soon you should ask for help probably depends on the seriousness of the issue, and your likelihood of solving the issue on your own.  Be honest, do you have the technical knowledge here?   Have you solved other similar bugs before?

There is no shame in not knowing something.  Often it is just a matter of experience, which you will gain in time.

#4 Watch out for the Wild Guesses

The reason not to ask for help, is that sometimes people will help by giving suggestions that could not possibly be correct.  Be careful!

I only consider answers which “could not possibly be correct” after I’ve already checked out the technically most likely causes.  Don’t go down a rabbit hole that’s a 1 in a million chance.  (On the other hand, don’t assume that you have superior knowledge, and be careful to not dismiss a suggestion just because you don’t understand it.  Ask questions.)

#5 Define the scope

Software systems are HUGE!  Let’s make the haystack smaller…

If this is a website bug, does it still happen with Javascript disabled?  That’s a good way to tell if it’s a backend or frontend issue.

If you disable a plugin/module/theme or otherwise remove some included files, does the bug go away?

Another way to define scope, is to use a debugger and put a break point before and after where the bug exists.  Examine what happens to the relevant variable values until you can be certain of the code block where the error happens.

#6 Assume it’s a recent change.

Did you do something recently?   Look at your recent commits, software updates, etc.  If this is a huge problem that did not exist before, something must have changed to cause it.  You can also check out previous git commits/other git branches and see if the bug existed in them.

#7 Stay Focused; Put the “Emotions” aside.

Has this bug caused your adrenaline to shoot up?

Or, has it caused others to stress?

Try to put all of your feelings aside, and follow a process driven by logic instead.

I find that understanding emotion is very helpful when interacting with people, but computers don’t care how I’m feeling.

YOUR emotions, as well as the emotions of OTHERS can interfere with your ability to use reason to solve an issue that’s logic based.

Do what you need to do in order to stay focused on solving the issue.  I (try to) banish my emotions to the other room.

Is working remotely important to you?  Do you want to work from home?  Or do you want to live the digital nomad lifestyle?  A good programmer may be an introvert or a traveler, and more companies are figuring out that it doesn’t matter if their employees don’t live near each other — what matters is finding talent.  Wherever it is.

Remote software developer jobs definitely exist.  You’ve got your pick — you can find remote jobs that are full-time salaried positions, part-time, contract work (or contract-to-hire) or freelance work.  Freelance is what most people probably think of when they hear about someone working from home.  But it’s certainly not the only option any longer.  You can work for a small or large company as a remote employee.  Some big name companies that work in this way include Github, Trello, and Automattic.

Are you a WordPress theme or plugin developer?  Or skilled in PHP, Javascript, and CSS?  You may be able to get a remote programming job at Alley Interactive, where I work.  Tell them that I referred you.  If you are a UI or UX developer, you might also want to check out Alley Interactive, because sometimes there are job openings for those positions as well.

Tip #1: Use Google to find Jobs

Search for “distributed team” and your skill or other keyword.  For example, I often search for the name of a particular programming language, or for the job title, like Software Engineer, Software Developer, etc.  I just did a google search for “php distributed team” and found TeamSnap, who’s hiring a Ruby on Rails Developer and an  iOS Developer.  Yeah, that’s not PHP, so this method is not perfect nor fast, but you will find so-called “unadvertised jobs.”

You can also use Google’s Advanced Search options to search for new results, or sign up to Google Alerts.  This might send you an email alert when a start-up company creates an “about us” page when they decide that they need to start hiring.  There are lots of tech start-ups out there, so you never know what you might find!

Make an effort to really dig through the search results.  Don’t stop on page 1 or 2!  While “distributed team” is a big buzzword these days, you can also search for the words “remote” and “telecommute.”

Many companies don’t advertise positions outside of their website.  This means that these job openings don’t appear on job listing sites, so you have to actually go digging to find them.  Look at the bottom of company websites for a “Careers” page.  Also look at all “About us” and “Partners” sites.  I found my current job from following a link from one of those “Our Partner” pages.  So, be curious, follow links and dig around.

Tip #2: Use these Websites to Find Remote Programming Jobs

 

Stack Overflow – Remote Jobs

The above link will take you to the Stack Overflow Careers website search with “Allows Remote” selected.  You can toggle this option on and off by hovering your cursor over the location box.  They currently have 246 remote jobs.  The nice thing about Stack Overflow jobs are that the job listings are almost all really high quality.  Companies have to pay to list their job opening on that site (the fee starts at $699), so you can be pretty sure that the companies are actively hiring.  And it is a great site for job hunters because Stack Overflow gives you the ability to build a pretty comprehensive profile, so you can really show off your skills and link to your code samples and projects.

We Work Remotely – Programming Jobs

We Work Remotely is a job listings website that’s 100% focused on remote jobs.  They don’t have a ton of listings, but they do have a separate category for programming gigs, and you can subscribe to the RSS Feed, so that you can be the first one to know when jobs are added.  This isn’t a free site for companies (it costs them $200 for 30 days), which is good for you because it means no spam!

Skip the Drive

Skip the Drive is all about remote and telecommuting jobs.  The people over there seem to be quite friendly (despite a very annoying splash screen), and you can sign up for daily new job emails.  They are an aggregator, so if you’re looking at the other sites on this list, you might run into a lot of repeats.  But, they might find something you didn’t see.  Right now, they have 120 remote software development jobs, web related jobs, and a dozen WordPress related remote jobs.

Indeed (Put in the keyword “remote” and leave the location field blank)

Probably one of the more popular job sites, I did use Indeed to look for remote jobs, but it was annoying because there were lots of “No Remote!” jobs that came up in the search results.  I still found it worth my time to sift through their listings.  They will send you an email every day with new search results, and when I was job hunting, I would often start my day by going through their email.  Every once in awhile, there was a real gem.

Tip #3: Show off Your Greatness!

There is a reason they call it “Human resources.”  Talented employees are resources.  Companies go shopping for more resources.   You need to sell yourself.

Remote workers have to have:

1. Skill.  No one is going to hire someone remotely who can’t do the job.  Prove that you can do the job by having code samples.  Or showcase your previous projects.  Or write some technical articles.  If the company you want to work for has some open-source projects, try to contribute to them.  It’s a sure way to make your application stand-out.
2. Excellent written communication skills.  Prove that you know how to communicate well.  Show it off in your cover letter (ALWAYS write a cover letter!), thank you letter, in your social media profiles, Stack Overflow questions/answers, or on your personal blog.  Great communication is critical for interacting with clients and also important for getting things done.  Unclear communication is a time waster.
3. Self-Direction and Time management.  You must be able to prioritize and juggle tasks.  The freedom of working remotely also comes with great responsibility.

Think about your life history and think about what things you’ve done that make you a great fit for the position you’re interested in.  And then at the interview, tell them why you would be a great fit.  Remember, they want you to be the one for the position.  (Otherwise, they wouldn’t have arranged the interview.)  You just have to sell yourself.

Do research about their company and honestly tell them how your skills are a good match.  Honesty goes a long way.  If you don’t know something, tell them that you don’t know, but explain how you could go about finding out the answer.  Remember that no one knows everything, but if you know how to get the answer, that’s good enough 80% of the time.

This got to be a bit of a ramble, but I hope that the above links help.  My final thoughts are, don’t give up, and yes, remote programming jobs exist.

Related ~ Links

How to Hire a Remote Team