Some quick translations, OO PHP to C#

So a recent project has facilitated me brushing up on my C# – so I thought I would share some basic translations of things that can be frustrating when you know the usual programming principles (object orientated programming), but not all the syntax.

A quick couple of points to note:

  1. C# is a strictly typed language, that means you have to know about what your variables are going to be, and yes, you have to declare them somewhere sensible
  2. Accessing methods and properties within your class does not require usage of $this – you’re talking about true scope of variables and methods, so you don’t have to worry about it
  3. Public, protected and private are essentially the same
  4. You have to declare the return types on every method, none of this return an object or false stuff
  5. Namespacing is essentially the same as if you were following the PSR-4 standard
  6. Everything, including strings, are objects
  7. A single quote and a double quote are fundamentally different things

Declaring a variable

Okay, so starting with the basics, declaring a variable is basically the same, except you have to declare the type, so declaring age as a variable, integer, with the value of 25 would look like this in PHP:

$age = 25;

However, in C# it would look like this

int age = 25;

Moving into this being a property in a class, you must rather than optionally, or have to if you’re conforming to PSR-2, so in PHP it looks like this

public $age = 25;

In C# it’s going to look like this:

public int age = 25;

Declaring methods

Okay this is an easy one in PHP, it looks something like this. Using PHP 7.1 we can strictly type the return.

public function myMethod(MyClassOne &$argumentByReference, MyClassTwo $argumentByValue) : ObjectClass

{

    // Do something in your method here

}

// This would be called by doing something like
$object->myMethod($parsedByReference, $parsedByValue);

This one gets slightly different when translated into C# for a couple of reasons. You must declare the types of the parameter, the type of the response(s), it also gets a bit different when calling the method too:

public ObjectClass myMethod(ref MyClassOne argumentByReference, MyClassTwo argumentByValue)

{

    // Do something in your method here

}

// Now calling your method would look slightly different

Object.myMethod(ref parsedByReference, parsedByValue);

Using Objects

Instantiating objects isn’t much different either, really; it looks different but that’s because it’s strictly typed.

Main difference between use statements in PHP and C# (other than that it is using in C#) is that you use a namespace, the classes contained therein (this namespace only, not its children) are automatically available.

In PHP I want to include a class and then instantiate it, will look something like this:

use Vendor\Project\Namespace\ClassName;

// Then you have all of your usual declarations, which we'll get to

$myObject = new ClassName();

However when you want to do this in C# it looks something like this:

using Vendor\Project\Namespace;

// Then all of your usual declarations

ClassName myObject = new ClassName();

Declaring Classes, using Inheritance and Interfaces

This gets a bit different, but only syntactically. We’re going to create Person as an abstract class, this will be extended by the Employee class. Employee is going to implement an interface called Emailable.

For the sake of ease I’ve not separated these into different files

In PHP it would look like this:

abstract class Person{

    // Shared functionality here

}
interface Emailable{

    // Interface requirements here

}

class Employee extends Person implements Emailable{

    // Employee functionality, including Emailable requirements, in here

}

In C# however it would look like this

namespace ObjectOrientatedPrinciples.MyExample
 {
    abstract public class Person
    {
        
    }
    interface Emailable
    {
        
    }
    public class Employee : Person, Emailable
    {
        
    }
 }

You will see from this that C# doesn’t necessarily draw the distinction between classes being extended and interfaces being implemented.

Arrays and Lists

This is actually the only thing I found to be a little bit painful, however there is a decent tutorial on arrays on the Microsoft Developer Network (MSDN)

Closing Off

I’ll leave it at that for tonight. But a quick few bits that I thought might help someone out, it would’ve helped me if I could’ve found this article this morning. Though admittedly probably only saved me an hour or so. Not the point though, here it is 🙂

How to build a terrible API

Hi everyone

As you may know, throughout my career I’ve ended up doing a lot of integration development. Middleware, APIs, all that kind of stuff. So I thought I would write a quick list of the things you should definitely do to make your API really terrible for other developers to use, so that they put their heads through their desks trying to integrate with it.

Judging from some of the APIs I’ve had the misfortune of integrating with, I thought this was worth writing, for anyone who is building an API.

Obviously this post is humorous or satirical, if you like. Please, for the love of all that is good and sacred in this world, don’t follow these tips!

Tip #1 – Don’t write a darn thing down

No developer likes reading documentation, let alone writing it. So the best tip to make sure that everyone hates your API is to make sure you don’t write a single thing down. Not a thing, nada. Let them guess at how to use it and marvel at your ivory towered genius.

Tip #2 – Make sure that your API is totally inconsistent, especially with documentation

So if you did go to the effort of cobbling together some documentation, and this is critically important, you absolutely must ensure that it is totally out of date. It should be at least 2 major versions behind your developments to keep your job safe.

Also, make sure there are plenty of typos in field names, don’t spell check anything at all; and be sure to use plenty of three letter acronyms that only people within your organisation understand. This will make integration even more surprising.

Top tips for inconsistency include ensuring that you use an absolute minimum of three naming conventions, and at least four different response structures.

Tip #3 – Make sure you use all the wrong terminology

If your API is a straight-up JSON-POST API, which is really simple to use, make sure you throw in a few curve balls. Maybe some GET requests in there, maybe even the occasional PUT or PATCH. It just keeps things entertaining. Parse the API key in the header in some requests, a query string in others and part of the initial request object in the rest.

Also, make sure your account/client/public facing departments refer to your RESTful APIs as Fairy Liquid, and your SOAP APIs as Sleepy ones. This will make sure everyone finds your technical capacity fantastic and will marvel at your technological prowess.

Tip #4 – No version control

If you don’t make sure that your API is versioned, it will keep the developers integrating with it in work; because every time you change it they will have to rapidly drop all of their mission-critical developments to fix any integrations. Be sure to release a patch, break some calls, and then roll it back. Just to punish anybody not using version control on their integrations.

Don’t do anything silly like adding version control, or advanced warning of changes, and definitely don’t even think about doing Beta releases. That just takes the fun out of integration development.

Tip #5 – Throw as many random errors as possible

What you definitely shouldn’t do, under any circumstances, is have a unified and consistent way of handling errors, such as a resource not found or an API key not matching. These errors must be handled differently for every single possible error, on every single possible call.

This is really good for the economy, because it ensures that any developers integrating with your API will have to test every single possibility, against every single call you have. This will keep them in work. You’re doing them a favour, honest.

Why give a JSON error response back, detailing an error code and a human readable message, when a 404 or a 500 will do, that’s what they’re there for! Bonus points if you can throw a 301.

And you’re done.

If you follow these 5 simple rules, you will have a super-awesome-epic API built our of pure ivory, which people will have to pay you to integrate with, because nobody else will know how to.

Then you’ll become like Zuckerberg-cum-Gates rich and be proper leet hacker wizard man (or witch woman).

So there you have it. From someone who’s built, and integrated with, several (probably dozens of) APIs. The top list of things you should definitely never, ever, ever do, if you don’t want to burn in hell for the rest of eternity, stuck in an infinite loop of torture, ridicule and unknown fatal exceptions.

Peace out y’all! 🙂

I’d genuinely love to hear any additional tips you’ve got to build brilliant APIs, and your hilarious anecdotes which are only funny now because you’ve finished the course of therapy and sedatives and recovered from your caffeine addiction enough to laugh at them!

Tech Team Cancer

Hi guys

I keep promising that I will be posting frequently, and then life happens. I will continue my posts and tutorials and trying to share and disseminate things I’m learning or have learned over the course of my career.

I’m incredibly lucky, not only do I have my own experiences and exposures to draw upon when trying to make decisions, but I have a number of friends in development, from starting their careers right through to development managers and such. Of course, it would be unfair for me to take all of the credit for the things I’ve learned along the way, and at some point in the near future I might post a list of people I’ve learned from, but it will be a long list; and it would be wholly unfair for me to miss anybody crucial out of that list. It’s been a long career so far and I’ve met a lot of people.

Anyway, today I want to cover a topic that’s quite close to my heart. I received a huge compliment the other day from a long time friend of mine, Oliver Sarfas, he was saying that he has just picked up a piece of software I’d developed. Now I want to throw some context into this, I first met Oliver when I was only a couple of years into my career. We have stayed in touch the whole time, but were professionally reunited at my last role.

This particular piece of software, it’s fair to say, is quite complicated in its structure; in that very little is hardcoded anywhere. I was taking a matrix of equations and building them into a data structure, running them against years of legacy data as a rule by which to calculate some financial information. In terms of fluidity and flexibility it’s one of the most complicated bits of software I’ve built. It had a feature or two that I didn’t get to finish before leaving for my current role.

Anyway, Oliver was tasked with finishing up the project by building some of the functionality I didn’t get chance to do. He sent me an email, the long and short of this email was a thank you for writing code using industry standard techniques and leaving decent documentation. I can only presume following PSR-2, known design patterns, and decent naming conventions played some part of this.

This really conveniently brings me to the point of this post:

Tech Team Cancer

It sounds like a really horrible thing to refer to, but truthfully the things I am about to describe are cancerous. I’m not pointing at any of my previous roles here, everyone does at least one of the things on the list, some companies are better than others, but generally, these things help kill tech teams:

1. Not Leaving Documentation (Ivory Towering)

There is nothing worse than finding yourself having to work on a project you know nothing about, that has no code comments or documentation attached.

One thing I would like to say on this, however, is code comments are great tips for a developer. But code comments document that piece of code, that module, that class. They don’t document the over-arching design or principles of the piece of software.

Documentation is essential in other developer’s being able to work on your software.

2. Not Following Patterns

This is a bit of a weird one. Using known design patterns, and principles, and everything else does help your code’s maintainability. But what I really mean here is being consistent, across all of your code (really it should be across all of your team’s projects). Any convention is better than no convention.

If you have a piece of software and you name all of your classes following PSR-2 standards and your namespaces follow PSR-4, great! Get everything else consistent too, table and field names are a really common one for this.

3. Not Knowing When You’re Out Of Your Depth

This is another seriously fluid one. Any time you are out of your depth is bad. It doesn’t matter the context. Don’t fully understand the specification, don’t fully understand what they’re aiming to gain, or the use case, for this software, don’t understand the technologies you’re using. Any of these things lead you to build bad software.

What usually happens, in my experience, is that you, for want of a better phrase, blag it. Blagging, in development, is terrible. It means you don’t have a plan, if you don’t have a plan how can you have a coherent software design and accompanying principles?

If you have none of those things you’re destined to end up with spaghetti code, indecipherable nonsense and, as you learn more about what you’re supposed to be doing, horrendous shoe-horning to make functionality work.

The big problem with this one is that if you fall foul of it you will definitely fall foul of the other points here as well.

4. Bad Commit Messages

We’ve all been in that position where we’re asked to fix a bug on an existing piece of software. Fair enough. And then we look at the code, and all we can say or think (depending on your personality) is “Oh for ****s sake, what the **** was that **** thinking?! Seriously why the **** would you do that?” and this usually lasts for a few hours, before resigning yourself to shoe-horning in the resolution or stating it has to be rebuilt.

This is where a decent commit message goes a long way, and a code comment. If I have to do something a bit nasty, dirty or something that would get my immortal soul cussed out once I’ve left the office, I leave a code comment and a commit message; keeping professional but saying something like “This is a workaround for requirement X which was introduced after the original specification; if you change it Y will happen and you will also need to check Z” – because that’s the kind of information I would like to find if I were inheriting the maintenance of that code.

A good commit message is the difference between “Why the hell did you every hire X? He didn’t know what he was doing!” to “Ah, right. I see why he did that, it sucks, but I get it”.

5. Relying on Tribal Knowledge

This one is so much more dangerous than it sounds. When you build something, or when you fix an issue. This one isn’t just for developers either, testers, client facing staff and project staff are all guilty of this (usually). If you know something about a project or a piece of infrastructure it really does need to be written somewhere.

Take this real world example. I was working on a large and complex project which was business critical for the company that I was working for at the time. We were nearing the end. Luckily I keep documentation and code comments pretty up to date and always communicate how I’m working on. Unfortunately one Friday afternoon, I’m on my way home from work, all is good, we’re ahead of schedule and everything is great with regards to the project.

Then I’m on my way home, hit oil and come off of my motorbike. I go rolling up the A14 in Cambridgeshire, breaking and dislocating my shoulder and snapping my thumb. That’s me unable to drive for about 12 weeks in total. I was really lucky, firstly I didn’t die. Secondly, I used to work part remotely, so was able, within a couple of days and a makeshift injury-friendly work space, to get working again.

Imagine if it were worse, or if I couldn’t have worked remotely. The company I was working for would’ve been right up the creek without a paddle.

In Summary

To summarise this article. The main problems any development team, whether growing or shrinking, young or old, is information and sharing it.

Whether you’re sharing it through documentation, code comments and git commit messages. Or however you’re sharing it. Whether than information is software design, client facing, client requirement, anything at all. If ever there is a piece of information that you, and you alone, have you need to find a way to share it; otherwise you really are asking for something to go wrong with no conceivable disaster recovery available.

Tips for commercial WordPress, and open source, development

Hi everyone

So I’ve been using content management systems on and off for the best part of 10 years. From the by-gone days of PHP Nuke and when content management systems like PHP Fusion were all the rage. To using more modern, and definitely more widely adopted systems like Joomla and, of course, WordPress; and just to throw other open source stuff into the mix, platforms like Moodle.

Now I’ve returned to using WordPress on a daily basis, but from a different perspective; I don’t do too much development on WordPress personally; my skill set generally lies in building things on frameworks such as CodeIgniter and Laravel, if not bespoke. But I do use WordPress to the extent of managing multisite installations, managing production stability and servers, as well as deployments and migrations.

Having been in the unique position to pick up some legacy code in my time, and seen what does and does not make a WordPress site easy to work on, manage and maintain; I thought I would put together some tips for building WordPress sites, and functionality, which will stand the test of time.

1. Never modify the core

This is a deadly serious one. No matter what you’re working on it should have a specific way of extending functionality, whether through plugins and themes, extensions or a specific namespace where modifications should be added, never, ever, ever modify the core. The same applies to the core code on a plugin.

The reasons for this are really simple; you probably don’t know and understand the full architecture or what you might break by changing this, and more importantly the biggest strength of using something open source is that updates are generally frequently available. The moment you change something in the core you’re going to sabotage any upgrades; you will have to make the choice. Either update the software (absolutely critical) and lose your changes, or don’t update the software and risk leaving bugs, security vulnerabilities, and all kinds of other stuff in there. Not a good position to be in.

2. Choose the right one

WordPress is the most widely adopted content management system in the world. Impressive, right? And technically, yes, anything can be built on it. In the same way any system can be built using .txt files for data storage. It can be done, but that doesn’t mean it should be.

I’ve laboured this point a few times in a few articles and things, but a good developer will know the tools available to them and choose the best one for the job. It is worth spending six months for a content management system and blogging platform, that does exactly the same as WordPress? Of course not. Is it a good idea to build a secure intranet containing sensitive data about national security on WordPress? Of course not. It’s about knowing what’s available and making the best decision based on this.

This is a difficult one, however, as you need to choose the one that fits your needs right now, as well as being compatible with the long term visions of the site; or know from the start that a rebuild will be necessary.

3. Be wary of plugin dependencies

Why use plugin_function when cms_function does the same job, and is probably going to be better supported in the future? When installing plugins, extensions and add ons; always think about the eventualities? What if this plugin’s core is compromised and I need to disable it right now; what will break? What if the plugin stops being supported? How tied into using it am I right now? If you’re managing lots of websites, especially; be wary of the headache you’re going to have if you’re relying too heavily on too many plugins.

If you notice yourself using plugin X on every site you build, or relying on it super heavily, it might be worth doing one of a few things. Either building your own replacement, so you’re in control of the core. Or perhaps wrapping it in your own functionality, so if you want to swap it out, you can. Using a technique called Facading can help with this, hiding plugin functionality behind you facade means you can swap what’s behind the facade out if you need to.

Really the point here is don’t install things willy nilly, think about the dependency you’re creating on this plugin for your website, and how much of a pain it’s going to be if you want to remove it.

4. Always check the source

Depending on the project and the size reading the source code line for line probably isn’t going to be efficient; so that’s not what I’m suggesting here. By source I mean the author, the factory, the company; wherever it comes from. Make sure they’re trusted, WordPress, for example, examines all of the plugins and themes submitted to their public repositories and they’re pretty stringent on their standards, as well as ensuring they’re safe (from a security standpoint).

Most mainstream CMS have white hat security scanning tools that will uncover most, if not all, known security flaws and vulnerabilities. Running these can only be a good thing, as long as you act on the results you get.

5. Don’t be afraid to code things from scratch

There might not be a plugin which does what you want, or doesn’t do exactly what you want. You have 10 requirements from your client. Plugin X fulfils 9 of them. Do not try and hack it to fulfil the 10th, it will only go badly; honestly, I’ve been there and done it a bunch of times.

Just because you usually use X plugin and Y CMS, doesn’t mean you have to this time. Some things are best built from scratch, whether the whole site/software, or a specific functionality. Sometimes the best option is to get stuck in with coding the thing you want. You’d be surprised at how quick this can sometimes be. And just because your CMS offers a specific functionality doesn’t mean you have to use it. WordPress Custom Post Types are a beautiful example of this, as well as their taxonomies. These are both beautiful pieces of functionality; but they’re not the best way to store bespoke data, for example. They exist for a range of things, but primarily to give you a way to show bespoke content, like recipes, and linking them together in a specific way, dietary requirement for example. Storing anything that doesn’t fit into a custom post type and taxonomy doesn’t make sense, so don’t do it.

Pure OS: The way forward?

Tonight is just a quick one, not my usual essay. I was just curious to see what other people though. Being a PHP Developer I primarily work within LAMP environments. Occasionally having swapped out Apache for Nginx, but I am by far a specialist.

Until recently I was able to jump around through the Linux command line and do whatever I needed to without much issue, but nothing heavy.

I decided, as I often do, that I wanted to expand my skill set and start looking at pure OS, doing everything from scratch, how hard could it be, right? Previously I had used control panels like cPanel and Plesk to make management easy, as I’ve been offloading mail management to the likes of Office 365 and Google Suite, because they’re awesome at it and provide drive solutions, I figured there wasn’t that much really left for my server to manage.

So I put on my big boy pants and launched a Droplet with Digital Ocean and got learning how to set up and manage my own LAMP stack environments. I’ve spent a bit of time learning a few bits, and realised a few things, which I thought I would share. I’m by no means an expert, but these are just some soundbites I’ve picked up

  1. Setting up LAMP stack isn’t difficult
  2. Neither is setting up SFTP and Mail (though I’m dubious on mail and will leave it to the pros!)
  3. Neither is setting up SSL (seriously, look up LetsEncrypt!)
  4. Control panels are heavy!
  5. You really don’t need much on your server to do basic website stuff
  6. If you keep it lean, tiny servers can do amazing things

If you’re a developer, and have never tried to build and manage your own servers, seriously give it a go.

On a side note, some other useful tips and guides – please take heed – this isn’t new knowledge to me by any means, but thought it might be useful if you stumble across this article.

  1. Disable root login access!
  2. Chroot your FTP users
  3. Only install what you NEED. If you’re not doing anything with SFTP (because you’re only using git, for example), don’t install it
  4. Research what you’re installing, only install it if you need it and trust it
  5. If this is the first time you’ve tried to manage your own DNS, most panels create aa bunch of stuff for you; at the very least you need to create a CNAME record for ‘www’ and point it to ‘@’ (so that http://www.website.com also works as well as just website.com)

I think that’s everything for now. If I think of anything else I’ll pop it in a little soundbite.

About Facading and Dependency Injection

Good evening everyone.

I’ve been meaning to write a post about this for a little while, it’s a common discussion point within developers working on enterprise level software. The argument regarding dependency injection vs. facades; how they’re applied and how they relate to most software systems you work with.

The first point I would like to make on this particular topic is that they are both useful, they both have their place.

For those of you who are not exactly aware of what these concepts are I have broken it down a little bit below; but if you’re not comfortable or familiar with the topic it probably is worth doing some research on before you make your mind up.

In essence, dependency injection is where you declare your class usages in a single place as a dependency, those dependencies are injected into where they are used. The concept behind this is that should you wish to swap out your dependency it should be easy. Take the following example;

I have a class named PermissionChecker. This class is used throughout many Controllers in an MVC framework. Whenever I want to check if someone has a permission I simply call upon functionality within the permission checker, which returns me a true or false.

The basic problem here is when I want to change the PermissionChecker, which contains all of my permission-based logic, it is painful, because I have to go through and replace or remove every instance of the PermissionChecker and hope that it doesn’t break anything, and I test everything heavily.

This is where Dependency Injection (DI) comes in. I create an instance of my PermissionChecker (PC) within the DI container. There are various open source DI solutions out there from Pimple to the DependencyInjector by Symfony. Anyway, the long and short of it is that the declaration of the usage of PC is in a single place, so should I wish to change it for SupremePermissionChecker (SPC) then it is easy and done in a single place, assuming the interfaces through which it is accessed remain the same.

This is the perfect solution to an age old problem!

But beware! There is an issue with DI, in my experience, and that is that either you become so dependent on it that it becomes difficult to utilise functionality and you end up writing lots of code which, in practicality, does very little. Or potentially you can end up over injecting, some parts of your system will be tightly coupled to one another by design, the issue with DI here simply compounds this issue, because the tightly coupling in a lot of days makes the DI redundant; as you couldn’t swap out the dependency even if you wanted to.

Now please don’t, for a second, think that I am slating dependency injection, because I’m really not. I think it is a very useful tool, it’s not my tool of choice but it does have a lot of advantages.

Additionally; don’t think the next thing I am going to mention is mutually exclusive to Dependency Injection either, they can be used in tandem without any issues.

So a facade is where you create a class which hides more complex logic behind it. Taking the same example I might have a PermissionChecker class which facades other functionality, for example fetching a user, fetching permission records which it can cross reference against the permission we are checking into.

In essence a facade is a way of abstracting your functionality a layer further. You have your system which utilises your facade, and your facade utilises whatever it needs to.

The reason I prefer this methodology, personally, is because you end up with all of your facades talking to one another. Which makes your Controllers very readable as you end up with something not dissimilar to:

if ( $permissionChecker->hasPermission(‘make-payment’) ){

$paymentThing->makePayment( $account, $sortCode );

}

Which I feel is very “English” in that it’s quite easy to read it and understand what’s going on. Additionally the advantage, for me, is that if Developer A (DA) and Developer B (DB) are both working on functionality within the same version it is easy. DA can be modifying whatever he wants in PC whilst DB can be happily working away on changing the payment gateway PaymentThing is using, as long as the interfaces remain the same then it’s all good.

To add to the mix, remember where I said earlier the two weren’t mutually exclusive? PaymentThing and PermissionChecker could well have both been dependency injected into their current context, so they could be switched out.

My only real question there is: why? If my functionality is all hidden behind facades, which provide easy interfaces to use, if ever I want to change them or do anything with them, I do it behind the facade and I’m fine. With that in mind, does Dependency Injection become a bit overkill?

Both of these concepts, as with all concepts, methodologies and rules within web development, are designed to make maintaining my software easier, rather than having invisible dependencies and entangled tight coupling which is impossible to defuse. That’s a developer’s nightmare when someone says “can’t we just take the payment functionality from X project and put it into Y project?”.

I think we have to sometimes be careful in web development and programming in general that we’re not making more work for ourselves. If facades are working for the separation of concerns, does it matter if the dependencies are scattered through the code, because somewhere that once needed to make a payment will always need to make a payment, and if that requirement changes, the code will need to change anyway, so we cut out the bit that says make a payment. We don’t have to remove the dependency or do anything else.

When I want to include payments into a new set of functionality on the site all I have to do is utilise the use statement to bring in the Facade, which handles everything else, and use the functionality contained therein.

Maybe I am missing the point and the value. And I would rather have Dependency Injection than nothing, but I would rather have an easy-to-utilise set of Facades, than have to Dependency Inject everything I want to use, and remember to rip it out when I don’t.

I’d love to hear other developers’ opinions on this one though, as it is something of a bone of contention in the community.

Take care all!
Johno

To recruiters, from a web developer

So this week I thought I would do a quick article, a bit of an open letter to recruiters, really. Throughout my career, especially when I was contracting, I have had a really rocky relationship with recruiters.

I have to say some agencies have been an absolute pleasure to deal with, others have been down right rude and their behaviour has bordered on harassment. With this in mind, there are a few tips, from my perspective for agencies.

To my favourite agents, and the true professionals, this will be teaching you to suck eggs. To some this may just be of interest, to others it may be a bit of a learning curve. Some may just be procrastinating and killing time.

  1. You don’t need to be a developer or even a techie, but it does make a difference when I can tell you understand the requirements of your client and how they match my CV
  2. Take your time to understand me, too. I get that I’m not your client. However, if you offer me roles that are of no interest consistently, I just junk your emails. I’m sure I’m not the only person out there who gets bombarded by agents regularly. As such, those who target their emails well, and those who I have had personal communication with (especially those who have placed me) will always get read and always get a reply. Some get read, most get binned.
  3. Be polite to me, and whoever answers my phone. In busy times, when I’ve been interviewing, I’ve had my calls forwarded to my fiance who I trust wholeheartedly, knows my skills and is allowed to schedule for me, and effectively field calls so I don’t miss them altogether. When I was contracting she was also my account manager and handled invoicing and scheduling and such. Being rude to her just means I won’t return your call.
  4. Here’s a big one for me. I categorically, will not, ever, even consider looking at a role which fails to state the key details of a role. Location, skills, job role (junior, mid level, senior, lead, manager) and salary/rate (as appropriate). Why would I?
  5. Furthermore; “competitive” isn’t a salary. Competitive to me is in excess of £40k, I know people who are on £70k (who would find £90k competitive) and people who are on £16k (who would find £25k competitive) – all doing jobs with the same title. You telling me it’s “competitive” compels me to believe it’s actually not, because the best roles generally advertise their rates, because the highest rates attract the best candidates.
  6. Don’t assume that I can talk to you on the phone right now, or even in the next working day or so. Be adaptive, some days phone calls are best, they’re fast moving days. Other days I need to be on email and not on the phone. I imagine most web developers are the same; be open to communication on different levels via different channels.
  7. The easier it is for me to work with you, the more I’ll want to work with you, the higher your chance of placing me
  8. One final one. I’m not the most sought after professional in the world, but I’m sought after enough that it has never taken me more than about 2 working weeks to find a permanent role. With that in mind, please don’t be upset or offended if I have nothing tangible from you, so move onto the next offer, it’s just business.

I know which agencies I like (Emma Larrington, Luke Gardiner, and Elliot Smith at The One Group, and James Leech at Opus, amongst others) – so they’re the ones I always respond to with priority. The guys at the One Group have sent me for 3 interviews and placed me 3 times, in roles which were perfect fits on everything I was looking for.

I’m not the end client, but I am the product you may be trying to sell. Based on my success rate, and the fact they understand me, who do you think I call first when I’m looking for a new opportunity? Now I, as an individual, am not that important. But if every candidate is treated in this way, who do you think has the best talent pool?

One final footnote. Agencies are an integral and important part of the process, especially if you intend on aggressive career climbing or contracting. However, the relationship must, must, must be based on mutual understanding and respect. You have to trust I am exactly who I say I am, and I have the skills I say I have. I have to trust you’re going to work with my best interests in heart.

Know me, know my skills, situation, and what influences my decision. Make me happy and I’ll come back to you every time.

To my favourite agents; thank you for making career climbing obtainable and as enjoyable as the recruitment process can be, something which is stressful by its very definition. Keep up the good work!