I’ve tried to fight it over the years, but there’s no use in denying it anymore. My name’s Andy and I am a web geek.

Since February this year, I’ve worked with Rob at Eco Web Hosting to help him find more time to work with on his Udemy courses. If you’re an Eco Web Hosting customer, you may have seen my name before.

If not, hello!

I didn’t come to The Complete Web Developer Course as a complete beginner to web development.

I’d made a few static HTML sites in my late teens and spent the last couple of years working in the hosting industry, though until now, my focus had been mostly on supporting and maintaining the platforms, rather than development on them.

My last job meant I needed to know how to read PHP to an extent, but that extent was the writing of <?php phpinfo(); ?> (this creates a diagnostic PHP page that lets you check various limits and settings in PHP).

I’d never developed a project of my own in PHP though.

Rob had always managed Eco Web Hosting through the customer control panel and directly in the back end database, but there’s only so long a business can grow without an admin system to manage all the data.

It was time for a CRM. Here’s what I’ve learnt from my challenges so far.

Challenge 1: Finding flow

I work from home. Working from home is pretty awesome in many ways, but confronts you with new challenges.

For me, before getting into the business of coding, I still had to get the basics right. I moved to Cambridge specially for this job, having spent most of my life (with the exception of a stint in Malmö) living in The Midlands.

I had to find both my feet and my flow. Luckily, I found a house within two days of sofa surfing, so that was everything sorted, right?

Work somewhere comfortable, but not too comfortable

My house is great. I have great housemates, I’m not too far from town, though my landlady keeps chickens in the back garden, and they had a tendency to escape when I first moved in.

It’s difficult to find your flow when you’re trying to catch a feathered escapee in your garden.

Fugitive foul are perhaps not an issue for everyone, but there are other pitfalls in working from home.

The appeal of being able to work without needing to move anywhere may be something you want to take to its logical conclusion — working from bed.

To those of you considering this, my advice is this: Don’t.

I have tried it, and it seems like a great idea until the novelty of it wears off. At that point, you’re not really doing much, and you end up working in a slight malaise. Get up, eat and do the things that make you feel part of society.

You’ll feel better for it, and you’ll think more clearly.

Of course, working from home all the time can get a bit tiresome. Coffee shops’ WiFi can be pretty flakey though (Costa Coffee, I’m looking at you).

After some exploration of my new city though, I now have a place to work that has great WiFi, great coffee, and has been providing me with what might be an unhealthy amount of paninis. Balzano’s Deli, I thank you.

Create a routine

The perils of working from home strike again. You’re the master of your own destiny. So long as you get the work done, it’ll all be fine. Kind of. Well, no.

Without setting yourself deadlines, your productivity will start to crumble. You’ll do the essential tasks, but not the things that help you develop, and help you develop the business.

Structure your own routines, and adjust them to work for you. Just make sure you have one, else the hours will disappear before your very eyes.

Make time for yourself

Developers don’t have typically have a reputation as health freaks, based on a perhaps slightly unfair stereotype.

A healthy body leads to a clear mind though, and a clear mind is better at developing solving than a foggy one.

At the risk of this starting to sound like a self-help blog post, there are a few important things you can do to keep you at your sharpest.

1. Sleep well.
2. Eat well.
3. Walk every day.
4. Take regular breaks.
5. Don’t berate yourself for not understanding something — just give it more time.

If you succeed in doing this consistently, tell me how.

Challenge 2: Stopping spaghetti

I studied journalism at university because I’m interested in interesting people doing interesting things.

After graduation, I found that in addition to the memories of merriment, becoming a societally aware adult and, you know, the actual degree, I’d also found I was more able to structure ideas in a way that let me think and communicate more clearly.

Practicing what you preach isn’t always as easy as it seems when it comes to programming though, especially if you’re relatively new to it.

There is a term thrown about to describe an ugly mess of impenetrable code that’s had little consideration as to the structure.

It’s known as spaghetti code, or, if it’s particularly monstrous, a big ball of mud.

“Hah!” I scoffed. You wouldn’t catch me doing that.

After about a day of starting the CRM, I found myself wading through a meals worth of spaghetti that was missing only the bolognese sauce.

It seems that complacency isn’t a friend of the developer. Being the stereotypical Brit I am, I stood up, made myself a cup of tea and sat down to see what I could do to make it right.

Here are my tips to turn your tangled spaghetti code into nicely layered lasagne.

Comment all the things

Comments allow you to document your code. Though you can make sense of PHP with a serious left-to-right scan of the screen and a furrowed brow, for the sake of yourself and any others that need to read your code, it’s best to explain what things do in more human terms.

In PHP, you can comment your code in two ways.

Single line comments

// These start with two forward slashes.

// They're useful for brief comments on lines, such as "Test".

// You can also use them to disable a line of code you intend to return to later.

Multi-line comments

/* A multi-line comment is started with a forward slash followed by an asterisk, and ended with an asterisk followed by a forward slash.
These are useful for if you want to write a brief description, for example of what the function of the file you've created is, or what a routine within it does. */

Keep it modular

Say you’re writing some code that pulls a list of product names from a database table for specific customer based on a search for their e-mail address.

Then, you realise you’d like to include a direct search, that allows you to search by a product name, find the customer, then display a table containing all the products of that customer.

The tempting thing to do would be to write an if statement that says:

If the customer’s e-mail address is being searched, create the table of all that customer’s products.

Otherwise, if a product name is being searched, find the customer, then find the product based on that.

This example doesn’t look like such a terrible crime at first, but it’s inefficient, and spaghetti code comes from an accumulation of small inefficiencies.

What you should do though is find the customer’s e-mail address before looking up the database at all and store it in a variable.

That variable can then be used to look up the customer’s details, and can be used later on by other routines too, meaning you don’t need to repeat the same code.

Having modular routines like this means you can then transplant them in their own file. You can then just call this file using the PHP include or require functions when you want to run that routine, rather than needing to write them out each time.

Take a break

It seems obvious, but when you’re tired, you make mistakes. There’s no merit to be found in draining yourself of energy.

If your eyes hurt, you’re getting frustrated, your code makes no sense any more and you’ve forgotten to eat in several hours, it’s probably time to step away from the screen and do some real world activities.

Challenge 3: Battling bugs

Bugs are a part of developing. Even the most seasoned developer will write code that contains bugs.

The bigger a project gets, the more logical caveats there are. What is important is knowing how to keep them to a minimum, and how to handle them when they arise.

Here are three things you can do to give you the best shot at squeaky clean code.

Get the structure right first

Some bugs can be avoided in the first place by getting the structure of your data right.

If you have a database table containing a list of user logins, and that database allows duplicate usernames, time spent on changing the code to deal with duplicate usernames is time wasted, and means more lines of code for bugs to be found.

Time well spent would be to get rid of any duplicates, then alter the database so it doesn’t allow duplicates to be saved in the first place.

Echo and print_r everything

When something doesn’t do what you expect it to do, it is almost always because the wrong (or no) data is being sent somewhere else in your code.

If a process you’ve written doesn’t do what you expect, start by echoing each piece of data you give it, such as each variable that code uses.

This lets you check that each variable contains what you expect it to.

Remember that arrays are collections of variables, and so if you want to find the contents of an array, echo by itself won’t do the job.

The quickest way to check the contents of an array is the print_r function.

In human terms, take baby steps. If something doesn’t work, you can find out why by checking each stage of the process.

Test it, then test it again, then get someone else to test it

Awesome. So now you’ve wrapped up the project!

You’ve tested every possible way the program could be used under the sun, and everything works, so you offer it to your workmate to test.

“Everything works perfectly,” you beam at them, full of beans.

“Except that bit. Don’t click that bit. But everything else works.

“Okay, not if you type that either, but it you don’t type that it works. Well, it did work. You must have broke it.”

After a gruelling day/week/year/decade of getting your project to work, it can be disheartening to realise that there are still flaws you need to iron out.

Some developers enter a state of denial, where they’ll blame the user.

Others will just curl up into a ball and rock back and forth.

However you choose to deal with your first bug report, it’s important not to take it to heart.

It’s equally important to give your work to a second (or third, or forth, or moreth) party to test, because fresh pairs of eyes will find things you could not.

I’ve not yet reached this stage, as the my lovely little CRM is still in its young days.

Wish me luck!

---

 

I’d love to hear your experiences of developing so far. Have any of you run into any hurdles on the road to being a pro developer?