Now though, I cannot understand how I was programming any Javascript, let alone interactive interfaces without jQuery. For a start, being able to do
$(“#element_id”)
rather than the extremely long-winded and sometimes unreliable
document.getElementById(“element_id”)
is a Godsend.

My main experience in using jQuery came from the need to develop a complex interface to simulate Excel type features. These included highlighting cells in a table and calculating totals, averages and counts of the cell’s contents, hiding/showing/adding/removing columns and rows and advanced validation.

At the time, I loathed the project, but as with most projects like it, you end up learning so much more than on the projects you love. I will never forget that project – for its bad times and for the new love it gave me for jQuery!

Shared elements are suited to this structure, for example classes that output standard pages, or standard model functions, but I prefer file structures that allow for use cases per file. Generally I create each as a separate class, but I’d argue that a file as simple as this can be considered as MVC architecture.

function load($mode){
/////////////////////
// CONTROLLER
switch($mode){
case “printHash”: printMenu($_POST['toHash']); break;
}
}

function printHash($toHash){
/////////////////////
// MODEL
$toHash = stripslashes($toHash);
$hash = sha1($toHash);

/////////////////////
// VIEW
echo $toHash.”=”.$hash;
}

Whilst at University I was taught too much about what MVC is rather than why and when it should be considered, and I think that other developers are suffering from the same tuition. The aim of an MVC architecture is to encourage independent development and testing and to present clean and logical code that is easy to maintain. If you can use MVC to achieve this then it does not matter how you structure your files.

This is nothing ground breaking, and is probably done by any company who realises that decisions can be made quicker when meeting face-to-face and cutting out the process of sending files back and forth. I sat in a meeting room with the client and showed them screens we had developed for each use case of their project. If they didn’t like something I moved it, rearranged it or added notes regarding the inner workings.

Where this doesn’t work:
Design work is creative, and something I withhold that generally the client should have very little input in. Clearly they have to set the foundations, which is usually involves them sending a couple of logos and saying “I’d like something engaging, fun and professional” (which every designer loves to hear, I’m sure). This is good in a way though, as it leaves the designer to do their thing and design. If a designer sat in with a meeting and allowed a client to dictate the layouts then there’s almost no point in there being a designer. I could do it instead: I have no creativity what-so-ever but I can follow instructions.

Where this does work:
As mentioned above, flow charts and use cases analysis benefit from this sort of process. We also applied it to agreement of terms and conditions. My boss took his laptop to a meeting, opened up the terms and conditions of the proposed contract in Word, and both him and the client edited to suit both their perspectives. To do this over email and phone would have taken several days sending versioned files back and forth.

Customers like to see things being done, and there’s no better way than showing them what you’re doing than doing it in front of their eyes, following their own comments. So next time you’re changing a document think whether what you are doing will be the final version, and if not go and pay them a visit.

The site was a content managed site which, to fit into the client’s budgets, we built on our budget system. Prior to launch it was decided that users (of which there are a defined list of 100 or so) could log in and view “members only” content. This was fine, as it simply meant that some of the pages and menus on the site would be for authenticated users only. A few weeks after launch the brief changed, and the client now required the site to have separate content for each user, thereby requiring the system to have over 100 separate menus and 100 sets of pages.

Netready’s main content management system can handle this without any problems, but our alternative system is now struggling to handle a 1000% increase in the number of pages. The main victim of this is the client who has to use the bloated admin system.

I’m not sure how this could have been avoided. There is no way that we could have predicted that the members’ area would suddenly need to be tailored to the level of each individual user. Similarly there is no way the client would have known, as their decisions are driven by a 3rd party board of directors. It is possible that the client did not explain our proposal fully to the board of decision makers (our proposal was very clear on what we would build). Or maybe it was simply one of those times where a project was rushed into when the client wasn’t fully aware of their needs.

One example of a developer playing around was when he decided to use XLST to produce some standard HTML needed on a site. Setting up the parser and getting to grips with it took a while, but we now have a flexible way to manipulate our output.

I’m sure that somewhere in this there is an argument that possibly this option should have been considered at the planning stage of the project. However, spur of the moment ideas like this might not be visible from early on, which is why creative developers perform very well in this respect.

If your deadline isn’t looming branch out a bit and try something different. It may not be as successful as you hope, but you’ll always end up learning something new.

This situation happens when a project comes along and I quote a reasonable amount that includes setting aside time for project management, testing and generally not rushing development. The corner cutting starts when then client grimaces and says that their budget is around 20% less than my quote. “Can I get it down to such-a-such?” they ask, and I generally respond with “yes, but by dropping a few things”.

Sometimes features can be dropped, but often it’s the admin-side of things that get cut. Project management time is reduced so planning becomes less technical; some of the testing is handed over to the client to complete; development is sped up and simplified (flexibility for future development being the main victim).

There is an argument that this will cost the client more in the long run, and it is a valid argument in some cases. On many projects you can see where the benefit lies in investing in documentation, maintainable code and future proofing. But for others, if they don’t have the budget then the alternative to corner-cutting is to not do the project. This means lost business to us and no shiny new website for the client.

It is a difficult decision to make, especially as when I create a website I like to see it “done properly”, but I can hold my hand up and admit that I have said “just get it done whichever way is fastest.” because I know that was the right decision to give the client what they want within their budget.

When someone is given a piece of work to do it’s difficult to think that for two reasons:
1) to think of that belittles one’s role and self-importance
and 2) the more time and effort one invests the more blinkered the importance becomes to oneself

There are some clients that believe they are your most important client, and therefore their project/query is sitting at the top of your to-do pile. Sometimes they are right – they are either a big client and so go straight to the top of the pile, or you’ve found a few minutes to do their relatively unimportant task and so it has made it to the top of your priorities; and sometimes they are wrong – their task is at the bottom of your “things I must do today” list.

Whichever way it is though, it’s best to let them think their query is as important to you as it is to them. People are self-centred, and I don’t mean that in a selfish way. If they have been given a task who are you to belittle their position or ignore their productivity? The difficulty comes when you have to appease them and yet keep stock of all that is happening in your workload. I find the best way to do this is to give a little when you can, and lie. Tell the client you are working on something even when you aren’t. The alternative would probably result in lost business, but a little lie here and there will keep them happy, and as long as you deliver when you say you will they’ll be happier still.

1. Pick a subject line that’s meaningful to the recipient – just “Meeting” isn’t that useful, something like “Website design meeting agenda”.
2. If you’re sending an email containing a list, use numbered lists rather than bullets. This will make it much easier when referencing the list’s points in subsequent phone calls.
3. Keep previous conversation history in your emails by replying to a received email rather than creating a blank email to send a response as it adds context to what you write.
4. Ensure any internal notes colleagues have added to emails are removed if they are for internal use only.
5. When receiving an email try to respond to it by the end of the following day, even if it just a message saying that their query is being looked into and that you’ll get back to them again.
6. When you reference a file you plan to attach to an email, attach the file right then – doing this will make it less likely that an attachment is forgotten!
7. Be clear when referencing files or website pages. As it’s an email you’re not going to waste any paper or ink by copy-n-pasting full file names or website addresses. Also, don’t be afraid to re-send information twice – if it’s easier for you to place information in an email again rather than have the recipient search through previous conversations you are only helping them.
8. Final one is an obvious one: re-read your email to make sure it makes sense and is spelt correctly. Unintelligible emails are a waste of time and bad spelling and grammar is unprofessional.

I like to think that I stick to those points – looking through my Sent Items it looks like I do for most of the time. Point 5 is the hardest to stick to, as sometimes if an email seems low priority it is hard to respond when you have higher priority things to do first. Even so, it would do well to remember that replying promptly could save aggravation from the client in the long run, allowing you to concentrate on the higher priority tasks.

The article made points that remote working can be an extremely advantageous option to developers’ and employers’ productivity, well-being and finances. It also argued that if “your team leads won’t support remote working because they aren’t comfortable managing remote workers, get better managers.” This is a strong statement, but I particularly uphold the article’s own counter-argument: developers must prove they are responsible enough to deserve the privilege, or rather they must never show signs of being irresponsible and abusing the privilege.

A few months ago we missed a project deadline because the developer did not communicate their progress on the project whilst they were working from home. There may be a number of reasons why this happened (I have only managed a small team for two years), but in an attempt to aid communication on future projects remote working option has been withdrawn. This is because for the time being there are more advantages to us working as a team in the same physical location than separately. Eventually the option to work remotely will be offered again, and hopefully we’ll each have learnt from the previous time we worked remotely and from when we worked on opposite desks.

So what’s in it for the employer? I believe there are three main advantages. Firstly, a lower salaried employee. The wage our placement students earn is good for their level of experience, but because they are not expected to have the full responsibility of a permanent developer the salary is reduced. Secondly most students arrive brimming with new ideas, which they wish to try out on various tasks they are set. It’s a good way for a company to introduce new techniques, opinions and ideas into their practices. But I think the major advantage the company gains from employing a student is being able to give back a little to the industry. By taking on someone and investing time and money into them will mean that more developers will graduate with experience under their belt – which will hopefully benefit whichever company they end up working for, especially if it is the company that gave them the experience in the first place!