Tip: Have your own work space or room

In our house I am fortunate enough to have reserved the ‘box room’ bedroom for the sole purpose of serving as my office.  This gives me an opportunity to enter ‘a work environment’ and close the door on home (and vice versa at the end of each day).  This focuses the mind on work matters and keeps me from being distracted by the massive amount of DIY work that remains incomplete in our house at the moment.  I recall reading articles before I asked for this arrangement with regards to habit fields, and really am a believer in this concept.  I think I would find remote-working so much more difficult if I had to sit somewhere that also served as a relaxation area.

Tip: Set up your working environment properly

Set up your working environment as if you were in an office for a company.  By this, I mean everything; ranging from the bare bones of your work environment to your software setup.  Actually pay attention to health and safety regulations with regards to monitor and keyboard/mouse use; make sure your chair is correctly adjusted (and is adjustable at all! Don’t work on a dining chair!) – in my early days as a freelancer I used to sit on a non-adjustable chair for about 5 hours a day and ended up needing physiotherapy on my lower back as I was in utter agony.

Try not to compromise on your software setup either.  Install the same FTP client you use at work, and configure your IDE or text editor in the same way as your work, including indentation and layout settings; it’s amazing how a little effort to get the environment consistent can make your life so much easier.  My advice extends to, if possible, having a computer for work and a laptop for pleasure.  This further extends the separation of work time and play time; if this is financially not viable then a good compromise is to have two users on your desktop machine; one for work and one for personal use.  I’ll bet your bookmarks for work in your bookmarks toolbar are substantially different to the bookmarks for home in your home bookmarks toolbar!

Keep work and pleasure separate in your software environment too

Moving on from that point, I used to have all of my bookmarks for freelancing and general interests in one bookmarks toolbar folder, meaning BBC News was mixed up with the PHP Manual and a bookmark to my phpmyadmin directory.  This made it too easy to see the BBC news bookmark and check the news for 5 minutes.  5 minutes turns in to 10, in to 15, etc.  Now, I keep my bookmarks separate, by using different browsers. I use Mozilla Firefox for work; and Firefox only has my work bookmarks in it, and I use Google Chrome for pleasure; this has my personal bookmarks in it.  Largely I won’t even use my desktop PC for ‘play’ or ‘relaxation’ and try to reserve that stuff for my laptop.

Don’t get work done in your house when you’re supposed to be working

For the first two days of the remote working arrangement we had ongoing building work.  It is very difficult indeed to get good runs of concentration with the noise, and interaction with the tradesmen.  If you’re having any considerable work done to your house my advice would be, if possible, to go in office for that period.  It’s much quieter and you’ll be much more productive.

Communication

Assuming you are moving from an office environment, you will be used to being tapped on the shoulder and asked questions, and being asked for updates on the state of work on a fairly regular basis.  Though these distractions are often labelled unnecessary and irritating, they naturally lessen in frequency if you’re not in the office.  This doesn’t mean that you should make yourself completely impossible to contact!  I ensured I invested in an unlimited call plan on a home number so that I can call the office as frequently as needed to ask questions to which I need immediate answers, and so that the office have a reliable line on which they can contact me.  Thus far I have more than made good use of the phone line!

Your project manager will largely appreciate frequent, detailed updates of your progress.  There’s nothing worse than having a developer working for a solid few days with no good indication of where they are at with a project.  It’s good to say “all’s going well and we’re on time” and it’s responsible to inform if you’re having difficulties and look to be struggling to deliver for the target time.

Work Time

Something said fairly frequently to me is “oh so you can work whenever you want then”.  I’m not sure that this is entirely true, and my advice would always be to try to be at your desk between the hours that your office would normally be open (in my case 9am to 5pm).  This means:

• You are contactable via email and on the phone all day, should you be needed.
• You maintain a fairly normal working life and have similar spare time as other people (provided your friends work normal hours!)
• You are guaranteed to put in the required number of hours per week.

Quick advice for those who do freelance work alongside a full time job

• The hours of 9am – 5pm are strictly your company’s time.  Make your freelance clients aware of this. Break the rule for noone.  In my opinion, to freelance when you’re being paid to work by someone else is criminal!
• You will find it much more difficult to motivate yourself to freelance after having spent 8 hours each day working in your own house (I used to find working 12 hour days fairly easy if 8 hours were in-office and 4 hours at home).  My solution to this is to work in my office for work, and to move to the sofa on a laptop to freelance.  This does break slightly from my laptop == pleasure rule but at least gives me some separation in terms of the type of work I do!

Summary

Overall, it took me a week or two to get in to the swing of working remotely full-time, but I’ve got there now, and it feels good! I get distracted a lot less on an hour-by-hour basis and feel that I get more done in terms of pure development, and also the three segments to each working week really help me with maintaining my productivity at a high level right from Monday morning to Friday afternoon.  For any employee with the option of working remotely: give it a go, but only if you can separate work and home properly!

I thought “someone else must have had this problem”, and if they hadn’t, I was going to write a Firefox Add On to help maintain productivity by blocking distraction web sites. But, alas, someone has beaten me to it! I have found and installed the LeechBlock Firefox add on and it is fantastic. I’ve added my favourite sites to a list of sites to block at any time that isn’t a break time (so here, 9-11, 11.15-1, 1.30-3, 3.15-5) and it’s proven very effective.

On the command line interface, assuming you have wget installed, type:

wget -r ftp://USERNAME:PASSWORD@mysite.com/

Hit enter and wait while it retrieves everything for you.

I did it this way because I didn’t want to download 4gb of data to upload again, so ran this command direct from the ‘production’ server with its stupidly fast internet connection. Hours and hours saved!

Explaining and justifying your decisions

At the most very basic level, take this bit of code for example:

ksort($files);

To most PHP developers it is obvious that this bit of code sorts the $files array in key order. But it is not obvious to any PHP developer *why* I have done this. Adding a comment to say what I am doing and why would help speed up the recognition of what this code does; but more importantly, explain why this code is here.:


/**
* Sort the $files array in Key order. We want them displayed on the
* page in added order, and the $files array is not necessarily
* sorted in that order before this stage.
*/
ksort($files);


Using code comments as a tool: Autocompletion

There are other areas of an application where documentation can be even more useful. Modern Code Editors and IDEs will read what are called ‘docblocks‘ at the top of class, method or function definitions and add the information in the docblock in to your autocomplete prompts. So how do these docblocks work?

Docblocks are generally in this format (opened by /**, closed by */, with a * at the start of every line inbetween) and always apply to the next uncommented line of code. In this case, the line of code beginning with $page_posted_to = is documented by the docblock above.:


/**
* Determine if the page has been posted to with an action.
*/
$page_posted_to = (array_key_exists('action', $_POST) && !empty($_POST['action']));


Within docblocks you can contain ‘tags’. These ‘tags’ begin with an @ symbol and are often read or interpreted by documentation generation utilities or IDEs/Editors for autocompletion. A comprehensive list can be found on the Wikipedia page for Docblocks. Using these tags can encourage you to include information in your documentation that you might forget to include normally, ie the expected data type of function parameters.

At it’s most basic use, docblocks usually look something like this when describing a function or method:


/**
* This function adds two values together
* @param int $a The first value
* @param int $b The second value
* @return int The value of $a + $b
*/
function add_together($a, $b) {
return $a + $b;
}


As you can see, including these docblocks explains in plain english what the function does, what parameters it expects, and what it will return. This can save the next developer that reads your code tonnes of time and headaches, but most importantly of all, will make your code editor or IDE (if it supports autocompletion and docblock parsing) much more intelligent when it comes to helping you call your own methods or functions.

The idea of the ‘architect’ of this system was that any interaction with databases or storage of data; ie the models; would be shared in the central library.  This would mean that changes such as the one I worked on with is_deleted = 1 would be simple and made in one place, and one place only.  A true implementation of the ‘Don’t Repeat Yourself (DRY)’ principle.

The nature of this platform is that it is exactly that. A platform.  This typically means that no two implementations of the platform are identical, so to speak.  The platform is built upon and ‘extended’ to do what the individual customers want from their online shop.  This sometimes means that custom product ‘getter’ blocks of code are written.  Often, the ‘quick and easy’ approach had been taken with these , and they had simply been added as standalone functions in the individual project’s library, called things such as getAllProductsFlaggedAsSpecial()  This obviously meant that when I implemented my is_deleted changes in the central library, and wasn’t aware of the custom nature of these custom product selectors, the sites that used those custom product selectors continued to display deleted products.  Big oops!

This now means that I will need to go through the individual implementations of the platform, search for any custom product SQL that is being built, and add the AND p.is_deleted = 0 in to them.

This whole problem got my thinking about how I would approach this issue (The need to build custom product getter functions in individual implementations of the platform), and here’s how I think I’d do it.

I think I would ensure that all custom product getter functions were in fact methods in an extension of the main Model class that then called a buildWhereClause method that added any global product SQL (eg AND is_deleted = 0) in, like this:


class Model_Product extends Base_Model {
...
function buildWhereClause($sql) {
return 'WHERE p.is_deleted = 0 AND '.$sql;
}
...
}



class MyShopNameModel_Product extends Model_Product {
function getProductsFlaggedAsSpecial() {
...
$sql = "SELECT * FROM product ".$this->buildWhereClause('is_special = 1');
...
}
}

Essentially, what I learnt here was that the developer to begin with that wrote these ‘quick functions’ saved his or herself half an hour or so, but cost me (2-3 years later) a fair amount of time in debugging.  I think this is evidence that coding things the quick way and implementing a fast solution is often a false economy, and someone later in the life of the software will have to spend the time saved (and possibly more) to work around the disadvantages of the quick approach.

• HTTP requests are expensive in terms of time.  Reducing the number speeds page load time.
• Browsers can – and do – cache effectively.  Inline CSS and Javascript can’t be cached for later page requests.
• Images can be optimised on the web without any major loss in visual quality.

Javascript Files

Minify Them!

Firstly, remember that if you are including libraries such as jQuery, there are a few ways in which you can do so.  They offer a “minified” or “compressed” version, which is at least half the size in KB of the uncompressed version.  Given that you are extremely unlikely to need to ever modify the jQuery core, I don’t see any argument for including the full version of the library, and would choose to include the smaller, minified version every time.

If you have your own javascript files that are particularly hefty, you can minify those for production sites too, by using tools such as JSMin.  The only problem with doing this is you tend to need to maintain two versions of the file.  The minification process tends to be irreversible so you will need to keep a “development” copy of the javascript, just in case you need to make changes or additions in the future.

Use a Content Delivery Network for your javascript libraries!

If you want to go one step further, you can include libraries such as jQuery from “Content Delivery Networks”.  Here is what wikipedia defines a CDN as:

A content delivery network or content distribution network (CDN) is a system of computers containing copies of data, placed at various points in a network so as to maximize bandwidth for access to the data from clients throughout the network

Put simply, CDNs are probably much more capable of delivering the javascript files to the web browser accessing your page quickly and reliably than your own server.  Additionally, remember that this means that the CDN is taking some of your bandwidth costs away – at least 50kb per new visitor.  An additional strange secondary advantage is that it is possible that the user has previously visited a page including the javascript library from the same CDN earlier in their internet browsing session, so it will already be cached in their machine, and will not need to be loaded for a second time.

If you are looking for a quick link to the Google Javascript CDN,  you can access it here:

http://code.google.com/apis/ajaxlibs/

Include them only when they are needed!

Imagine that you have a “google map” page on your web site that integrates with the Google Maps API.  You have a fairly chunky 15kb Javascript file that handles your personal Google Maps integration, as well as including Google’s own API file for the maps.  Why would you want this javascript on every page of the site?  A lot of web developers and designers are guilty of putting the javascript in every single page of the site, which means that the request and corresponding bandwidth associated with the maps integration would be used even if the visitor never viewed that area of the site.

Images

This section is going to be quite short, as it isn’t really my department, but my main understanding is:

• Adobe Photoshop has a save for web feature. Use it.
• Application specific META data is not needed in images on the web (I understand that Adobe Photoshop again can be a devil for this). Remove it if you can!
• If you have “hover” states on buttons or navigation items, use CSS Sprites rather than two separate images.  The reasons why are explained in the link supplied, but mainly revolve around making the hover work immediately, and reducing the number of HTTP requests.

CSS

There are two situations here, really.  The majority of the time, most of the CSS will be used on all of the pages of the site, so it makes sense to make this one external cacheable file.  It is important that the CSS isn’t included in <style type=”text/css”></style> tags in the document itself, as this information is not cacheable and will be individually reloaded on the following page.

A lot of sites will include two or three CSS files. One for the site itself, and one for a plugin such as “lightbox” or “slimbox” or something similar.  If lightbox/slimbox is used on most pages, why not combine the CSS files in to one slightly larger one?  This will reduce the number of HTTP requests and put all of the CSS in to a single cached file.

There is an argument, also, that if there is a particularly complicated section of the web site that takes up 10kb of a CSS file all by itself, then that 10kb of the CSS should be split out in to a separate css file and included only in the complicated section, where it is needed.  This kind of optimisation will need to be assessed on a per-case basis!

Finally, remember that css itself can be written efficiently.

Compare these two blocks of code, which do the same thing, and you will see what I mean!


margin-top: 10px;
margin-bottom: 15px;
margin-right: 5px;
margin-left: 2px;



margin: 10px 5px 15px 2px;

In conclusion, the steps above often take less than an hour to implement on a well built web site, and can save a couple of seconds per page load, and a fair amount of bandwidth costs.  With google’s recent introduction of a small focus on page load time in terms of a web site’s ranking, these kind of improvements have more benefits than just making the site appear faster, and are worth paying some attention!

1. Make sure you understand the problem in full.

Generally, when we are presented with a problem by either a client, or a project manager, the problem has been simplified somewhat.  A 15 minute phone conversation or meeting is condensed in to a three sentence paragraph asking you the best way around a problem.  In my eyes, there are a couple of approaches to avoid this.

1. Be involved in the meeting, or the phone conversation.  This is not always possible – not every developer wants to be interrupted every 30 minutes by client questions, and not every developer is necessarily comfortable talking to a client.  But listening in on (and not participating in) a conversation could always be an option!  This means that you get to hear everything that the client has said about the problem.  It’s to be expected that the person relaying the message will miss out minor (but not necessarily insignificant) details.  After all, repeating every phone conversation in full could get a bit tiresome, you’d imagine!
2. Know to ask the right questions. A client asks to make their delivery fee increase with every product added.  Let’s say, increase the delivery fee by 30% for every additional product that needs delivering.  This is simple enough, until you consider that the delivery fee could easily escalate way out of control.  A £10 standard delivery fee could soon escalate to around £50 if someone bought a large amount of products.  This could discourage a purchase.  So should a limit be introduced for the maximum delivery fee?  Remember, the client probably hasn’t thought around this issue.  Asking the question and getting an answer before work starts could save you from having to rewrite a chunk of code.

2. If dealing with unfamiliar technology… allow some research time!

If you’ve been asked to implement an unfamiliar technology, take 10 or 15 minutes to research how it all works.  15 minutes spent now could stop you from estimating that something will take 5 hours when it might take 20, or from estimating 20 hours when it might take 5!   Additionally, when estimating how long the work will take, remember that you will probably spend a fair chunk of time reading documentation and not actually writing code.  In many places this would be considered billable time – and it should certainly be taken in to account when working out how soon you could deliver the work.

3.  Remember to allow time for testing and bug fixing.

Not everyone does this, but in my opinion it is essential.  Allow some time for proper testing and the time it’ll take to fix bugs (this can only be estimated) as well as the time taken to write the code in the first place.

4. If dealing with third party services, you can’t accurately promise a deadline.

A lot of the work I do involves integration with third party services – payment gateway services, SMS services, etc.  These all involve an account application and signup process, and sometimes this process depends on the client completing a form, or submitting payment for the service.   I have found that it is almost impossible to accurately estimate a “go live” date when an aspect of your application depends on a third party service being ready for use.  If you do provide an estimated go live date, it could be worth putting in a note that it depends on the client’s service X application being complete by date Y.

5. If you feel out of your depth, don’t be afraid to say!

This is a very important point.  If you are not confident about working with and fully understanding the technology that you will be using, tell your manager or your client! It’s better to say at this stage than to blindly assume that you will be able to work something out during the work.  They will be a darn sight happier this way around than if you go out of your depth and then the project is late or massively over budget.  Saying now typically will have one of three results:

1. Your company will turn the work away to avoid a problem (or, your client will go elsewhere).
2. Measures will be put in place to avoid the issue. Billing by the hour, or using another developer, for instance.
3. The project will be quoted anyway at an estimated rate, and your company will take a risk. In this case, you at least said something at the start – the risk taken was by someone above you.

These are only very basic steps that can be taken to avoid a problem.  But one thing is for certain.  It is typically better to under promise and over deliver rather than the other way around.  You just have to be careful that you don’t fall in to the habit of *massively* over-quoting projects, because this can have a detrimental effect in terms of reducing the percentage of accepted quotations.

My reasons for this decision are as follows:

1. Database collation.  Searching for strings LIKE '%Ed, Ed & Eddie%' starts to get complicated if you have converted & to &amp; – you have to remember to convert entities in your search string as well.  This could also potentially mess up the effect ORDER BY clauses in the SQL queries you write have on the dataset.
2. Data Integrity.  If in the future I decide that I all HTML, or just specific previously blacklisted HTML tags to be allowed, the data is all still complete and certain aspects of the data have not been removed.
3. Application Consistency.  I know that if I am ever displaying data selected from the database it will need to be ‘sanitised’ before being displayed to the user either in repopulated ‘edit’ forms or in a normal ‘view’ type screen.

I also did a little bit of research in the cakephp manual (as we will be using cakephp for this next project) to see what cakephp creators thought about this and it seems they reached the same conclusion (quoted from this page):

For sanitization against XSS its generally better to save raw HTML in database without modification and sanitize at the time of output/display.

They don’t give any specific reasons but I imagine that their thought process was similar to mine.

Starting with the basics, organisation in projects can be as simple as ensuring that you store all information supplied by the client with the project, in a folder called something like ‘assets’.   Typically I would split them by asset type – images for web, images for print, documents for web download, internal documents, other – and perhaps include a ‘supply date’ in the filename of each.

Next, write stuff down!  If a particular part of the project depends on an external service being available, write this down in a document that stays with the project wherever it goes.  Any useful information that is in your head the day you write the code for the project should probably be written down.  You more than likely won’t remember in 2 years time when something goes wrong!  All of this information could simply be stored in a README file.

Good organisation doesn’t boil down to simply putting things in to folders, or keeping notes.  Of course, these actions are a part of the organisation, but don’t cover everything.  More importantly – especially in the IT industry – consistency can be the best time saving characteristic you can introduce to your work.  Being consistent is almost synonymous with being organised when it comes to your project management…

I save time (and frustration!) by:

• Naming projects consistently.  My project name tends to match the main part of the domain name on which the web site or project will be hosted.  If I’ve a domain called edwardyarnold.co.uk, the project in my subversion repository will be called edwardyarnold.  This makes it a lot quicker to put my hand on the correct project if a change needs to be made.
• Naming the associated MySQL databases consistently.  For the above project, the CMS database would be called edwardyarnold_cms.  If the site were an ecommerce site, it would be called edwardyarnold_ecom.  This makes finding the relevant database in a phpmyadmin screen much quicker than if the databases weren’t named consistently.
• Ensuring that if a project is replaced with an entirely new version, it is archived with a date.  If I replaced the edwardyarnold.co.uk site with a completely new build, I’d move the current project to edwardyarnold_2010_archive and create a new one to replace the old.  This is a better approach to dating the new version of the site – the new version of the site would still exist in 2011 but would appear to be out of date if dated 2010.  Annoying to anyone who didn’t know that that was the ‘latest’ version of the site.
• Naming administration area directories according to a set naming pattern (I won’t disclose that here).  This means that anyone who I work with that knows the pattern can find the administration area without looking up the directory name.  (They will of course have to look up the username and password, if not saved in their browser).

These save a tiny amount of time individually, but collectively – and applied over multiple projects – the tiny amounts of time soon add up, and you can start to actually notice the saving.  Additionally, following these ‘rules’ means that new people joining your team can begin to understand and get a grip of the way you work quicker than if everything was done differently for each project.  In larger organisations this can reduce recruitment costs (remember, downtime whilst training your new staff member is a hidden recruitment cost…!) as well as saving your existing team time.

Until I worked for a couple of established Web Development companies, I never realised the importance of a ‘Checklist’ at the end of a project.  You know, simple things.  Does the site’s markup validate?  Do all images have alt tags?  Is php display_errors off?  But even after getting in the habit of ticking all of the items off this checklist for every site I build, there are still little mistakes that creep through – miscapitalised letters, incorrectly pluralised nouns… eg “There are 1 comments on this post” should be “There is 1 comment on this post”.   No checklist can possibly cover all of these possible errors (though the one I link to later in this post gives it a good go!).

The best way of discovering these problems is to ask a favour of (or even to employ) someone you know – preferably without a technical background – to go through the site and see if they can spot anything that needs changing or fixing.  You will find that they will probably produce a list twice as long as your original checklist!

The beauty of this approach is – as well as spotting spelling mistakes and other simple errors – you may also get some vital usability feedback, especially if you are with them when they are checking the site.  Do they seem frustrated? Did they use the site in the manner you would expect them to?

I was once fortunate enough to be behind a one-way mirror in a usability testing session and it was simply amazing.  We had a captcha image on a form (I know, I know.. don’t start) and the error message was misunderstood or found to be confusing by nearly every user.  The abandonment (and frustration) rate on the contact form was therefore extremely high.  This kind of problem would not normally be picked up in smaller projects where a usability testing session is not included (and you wrote the error message – so find it simple, right?), but if you run through the site with someone to whom the site is fresh, there’s a much higher chance that you will pick up the problem.  Remember that this issue wouldn’t be picked up by a checklist either!

So.. checking through a site with somebody non-technical (and who has never seen the site before) can save you a whole bunch of headaches in the future.  And remember – if you’re launching your web sites without a flight check list (check this one out from Box UK), that’s probably one of the first things you should consider implementing in your project schedule.  It will save you a lot more support time than it costs you.