30 things you need to do to be a great web developer
I'm forever being asked what it takes to be a web developer; and it's not as complicated as it might seem. Learning a subset of the overall skills will get you hired, while a good attitude will keep you employed. But is that really all it takes?
Clearly not. I seem to be in a perpetual cycle of interviewing candidates to join the team, vetting contractors, rejecting freelancers and fixing other peoples problems. So while the core skills aren't that demanding, if you're serious about becoming a great developer - this is my interpretation of a desirable list of characterisms, skills, attitudes and experience.
Core skills
I'm not even going to discuss the concept of core skills. If you're even a web developer then you'll be abundantly clear what skillset is required to do your work. This list is to offer insight into what extra bits I think you should have and how to impress your employers.Accessibility and SEO
I maintain that good SEO is a bi-product of strong accessibility adherence. As such I continually try to educate every single developer I work with that they need to understand this potentially boring topic.1. Understand basic accessibility standards
To be serious in this industry you need to lead from the front - therefore you NEED to know this stuff. Government funded sites for example have minimum standards that must be reached, which can leave your agency in a rather compromised position should it be neglected. Remember the 2001 Sydney Olympics were sued for failing to provide an accessible website. So irrespective of best practice, SEO or any items senior management might try to write off as "nice to have" if timescales are tight - neglect basic accessibility and you might find yourself in a legal struggle.
2. Understand how spiders and bots work
Once you have an understanding of how spiders/bots would negotiate a modern website, you'll have a more clear understanding of how to architect the entire solution. Understand how they interpret markup and follow links and you'll probably realise that you're essentially hiding crucial content from them, or making important items completely inaccessible. Remember, spiders and bots don't tend to use JavaScript, so if there's important content in those widgets you're building - make sure it degrades.
3. Use a screen reader once or twice
Using an application such as JAWS on websites you've built will help you realise how much of a challenge blind users face on certain sites. Realise how difficult it is to differentiate between links when contextual titles aren't used, or how unhelpful vague alt-attributes can be on images.
4. Familiarise yourself with automated testing tools
Automated tools such as WAVE are excellent at flagging obvious problems with websites. Using these for a while will help refine your nose for sniffing out problems. It's not a silver bullet, but it's a handy sanity check. Manually checking huge content-driven websites is probably unrealistic, but if you have set standards to meet, an automated tool can just help mitigate your concerns of major issues sneaking their way into previously verified work.
5. Degrade, degrade, degrade. Or provide an alternate. Understand Hijax.
Any developer worth his salt can create a cool bit of functionality; especially with the rise of JavaScript frameworks such as jQuery. The use of animation and AJAX has become commonplace, but remember these should be considered progressive enhancements rather than primary functionality. Understanding Hijax is a good start. Basically, if you're doing something interactive you need to ensure that all the content contained within is accessible without assistive technology, otherwise you need to provide an alternative version. There is zero shame in providing an alternative - sometimes it is favourable to do this than compromise on creativity. Accessibility doesn't win awards, but it'll lose you legal battles.
Security
Every single developer needs to know a basic amount of security stuff; otherwise every site you build will get hacked. But you need to go beyond basic prevention, you need to understand more...
6. Embrace the dark side, learn some hacking skills
Either spend some time with a hacker or learn some basic hacking skills. In the same way most home security experts are ex-criminals, the best security-savvy developers know the ways of the dark-side. Apologies for the Star Wars reference, but it exemplifies my point well. When Sidious explains to Anakin that to understand the entire picture one must embrace both the light and dark sides of the force, this is loosely parallel to the point I'm making here. If you know the common points of exploitation then you'll know how to close the gap.
7. Validate in both directions
Best practice dictates that you clean your data in both directions; on the way in AND out of the database. It's easy to see this as overkill, rationalising that everything that reaches the database would be clean anyway, so why filter on the way out? That time honoured adage of "what if" comes into play here.
8. Validate against known possibilities
I'm not going to tell you to validate your inputs, because you already are. To reach that next level is to demonstrate a more cynical view of the world. So while you'll be using regex to match email addresses, you'll probably be doing quite little with select/radio/checkboxes. Given you know what the expected values are, validate against these. It's just that extra level of protection.
9. Understand how bots abuse forms
You might know that adding a captcha to a form helps reduce the abuse, but do you know why? What if someone told you that you couldn't use a captcha - would you know what to do? Having alternative solutions such as token based authentication or using secret form fields to detect suspicious submissions. What about timing how long it takes the user to complete the form? To set yourself above the run-of-the-mill developers you need to have a varied arsenal.
10. Don't take security failings personally
A weird point to add, I'm sure you're thinking, but trust me on this one. No matter how long you've been doing this job, no matter how accomplished you are, the enemy continues to evolve. Hackers are clever, bots are innovative and ultimately the goalposts keep moving. The only way the industry catches up is by being caught out and this absolutely happens from time to time. Times when you'll scratch your head and ponder "how the hell did that get through?". Account managers may be questioning your skills and clients may be frustrated, but for a developer it's just another excuse to learn - and one you have to take.
User experience, wireframes and basic interaction
This is one of those areas that developers either don't have an aptitude for, or simply don't enjoy. However, understanding how users interact with sites goes a long way to improving your entire game.11. Do some background reading
Catch up on some good usability material (I find UXBooth to be one of the more enjoyable reads). Anything you pick up will not only improve the way you approach development, but you'll be able to contribute more into the entire process. Visiting such sites once every couple of months will keep you informed of the latest studies which can shape the entire output of the agency. Being able to discuss the merits of certain approaches will definitely earn you points in an interview.
12. Either conduct or watch some user-testing
One of the most humbling experiences you can have as a developer is watching a user testing session. Given we're tech-savvy users, we often take for granted how proficient a client's typical customer is likely to be. Sitting in on a user testing session will make you appreciate the significance of consistent messaging. It might even make you re-evaluate how intuitive certain solutions are. It's too easy for us (I'm including everyone inside an agency in the collective 'us') to forget that not everyone uses the Internet all day, every day. What might be a wonderfully signposted e-commerce solution to us might be a daunting, unhelpful, confusing labyrinth for someone else. Seeing this first hand not only gives you career-broadening anecdotes but also a more broad grasp of user interaction.
13. Learn how to wireframe
A developer who is happy and confident to produce wireframes is a lovely addition to a digital team. Using wonderful tools such as Axure makes the process more enjoyable too - it isn't just weeks of Microsoft Visio anymore! But understanding how to architect different types of page is an important skill to progress as a developer. Whether or not this skill is within your remit at the agency is moot; being able to flag UX concerns and get your hands dirty at devising a wireframed solution makes the agency better. Collaboration is key. One person doing wireframes isn't as good as two people - extra imagination, extra insight... Challenging ideas, innovating; these are things an exceptional developer does. Building whatever you're given without any input all day, every day is not the way to progress. Learning how to create wireframes is a big step in the right direction.
14. Clickstreams, analytics, reporting
One of the most entertaining things you can do as a developer is evaluate how real people are using your websites. Whether that's through generating a clickstream or sifting through your Google Analytics reports - seeing the path users are taking through the site is a rewarding experience. However, go deeper than this. Start looking at where they're dropping off - is there something daunting about the drop-off points? Is the messaging clear? So much of user experience can be done prior to launch, but evaluating performance using real people is far less theoretical. Start taking an active interest in how the sites are performing and whether the pages are working hard enough - these are definitely desirable traits.
15. Heat mapping
Whether you're conducting actual user tests or using automated intelligent tools such as those found at Feng-Gui can improve your understanding of page design and user interaction. It's as simple as that really. It'll help you start to spot bad ideas quite rapidly - a handy skill if you're being set KPI's by a client; certain pages need to convert.
Testing and risk management
Unquestionably, testing is a crucial element to being a good developer. It's really important to know a few common failures, yet time-and-time again test your work. Here are some of my key points:16. Understand that you're not good at testing your own work
This is one of the most significant revelations you can have as a developer - and one that you will eventually have. You're not good at testing your own work. The sooner you realise this the better your work will be. Keep in mind that whenever you think "this is finished, 100% tested", rationalise whether you've actually been through every eventuality. Even then, working as a developer invariably means working as part of a team - so ask others to check the site, and in turn expect to test the work of others. You win as a team, you lose as a team.
17. Have a bug tracking system
It's never a good position to be in, when you're asked in an interview "what bug tracking method do you use?" and have no answer to give. You don't need to have experience of things like Trac, but an answer that shows insight into your thought process is key. I personally use Google Document Spreadsheets for a lot of smaller projects because it's mobile, collaborative and clear. Having zero strategy shows no enthusiasm to improve the way you work or the quality of your output.
18. Risk analysis
A difficult question to answer, but having a grasp of how to mitigate risk on projects - and being able to vocalise it - is a really important part of doing this job to a high level. It's often a case of common sense; do you really want to deploy a new site live at 5.30pm on a Friday? Do you really want to deploy wholesale changes without an easy strategy to revert back in case it all falls down?
19. Bulldoze your way through a broken process
A process is only as good as its weakest point, as I keep saying "we win as a team, we lose as a team", it doesn't matter if the process shortfall is in your department or not, if there's viable risk to your work you must bulldoze your way to fixing it. Specifically with roles like project management. A failure in this can result in you deploying a new live site at 5pm on Christmas Eve for a multinational retailer and high-street brand (true story). Explain in great detail the risks associated with what you need to do - I'll guarantee that no-one in the agency wants to make illogical risks. If they ask you to do them, it's likely they don't understand the risks associated. It is your job to ensure this doesn't happen.
20. There is no such thing as "over testing"
A website, tool or application cannot be over-tested. I'd be surprised if there has ever been a project completed without a single unknown fault, bug or oversight. Acknowledge that excessive testing is not pointless. The dilemma of "deliver on time but 75% tested vs. late but 98% tested" almost always favours the latter. If it doesn't, you'll wish it had. Clients get upset about late deliveries, but they hate incomplete deliveries more.
Working with other departments
Being a good developer means avoiding the stereotypical insular attitude. Agencies are teams. Teams only play well when every player is contributing and working in the same direction.21. Love and educate your client services team
Account management is a difficult job - they need to be mindful of the financials of the business, meet internal targets and receive the brunt of any client annoyance. If you help the client services team with the awkward nature of their role, the entire agency benefits. Writing technical (yet client-friendly) emails affords them the option to forward it in - saving time they might not have. Explain to them what's going on and work with them on finding comfortable client-friendly ways of rationalising decisions to clients. This keeps you in the loop from a client-satisfaction perspective, but it helps the client services team do their jobs by seeing the full picture.
22. Don't ever, ever lie internally
I've seen it countless times. Developers lying about the severity of a situation or how unrealistic their deadlines are is not uncommon. It doesn't matter whether the truth is uncomfortable or not, it needs to be known internally. It doesn't matter if you've personally made a huge error and wish to avoid embarrassment - you need to pick yourself up and take it on the chin. Your feelings mean nothing once a lie has been passed to a client and the entire agency looks foolish. I whole-heartedly subscribe to the "win as a team, lose as a team" mentality - individuals shouldn't be blamed, processes should. If a huge error leaks onto the live server, it doesn't matter who uploaded it or whose code it was, but how it got there unfound is the problem.
23. Project managers are your friend
I know it's a common sentiment that PM's are slave-drivers, but they're your friend. They sit between you and the client services team so that any uncomfortable deadline conversations are not your remit. But the relationship goes two ways. If you're running late, let them know - be proactive! If you're not on target, why aren't you? Again, this isn't an exercise in blame but a means of ensuring that they have all the information. Explain why you're behind, how far behind and what you expect the impact to be is. Offer them constructive ways of dragging it back on target.
24. Work closely with the creatives
It works both ways - if there's stuff you can't physically do, tell them. If you think they're under-selling how much can be achieved, tell them too. Share innovative links and show them the kind of thing you'd like to build. This sharing of experience and innovation can only benefit the department.
25. Understand that being a web developer isn't always a 9-5
Controversial but part of the lifestyle. When deadlines come knocking it's unrealistic to expect that your involvement will always end at hometime. Granted, this isn't a post about being a developer, but about being a good developer. A good dev is a diligent dev, one who stays late when others are snowed under and doesn't shy away from big deadlines.
Blogging, open source and extra curricular
One of the more interesting things you can have on your CV/application is a blog/website. Why? It can show me that you're looking to do more than clock-in and clock-out.
26. Author a blog about a specific subject
Especially if it is within world of web-development. It shows you have passion for the subject and an ambition to be heard. It can indicate how good your written English is, which bits of technology you specialise in and how assured your marketing knowledge is.
27. Build a product to give away or sell
As per the blogging point, building something for yourself is a real measure of a different breed of developer. There's so much more to being good at this job than being competent at coding - having an aptitude to innovate, create and market is priceless.
28. Contribute to the open source community
This really shows a confidence in your coding and an ambition to improve the development world. Something as simple as this can set you apart from everyone else.
29. Have a successful blog
I really must stop bleating about this one point, but I find it so indicative of your understanding of the digital world. Developers who have authored a blog AND had an element of success with it tend to have a more practical and rounded understanding of basic marketing concepts. SEO, copywriting, social media, caching, optimisation and analytics - all of these things are common, transferable skills/knowledge that you obtain chasing success with a blog. Developers who build the site they're told to, test it, deliver it and end their involvement there tend to lack the spark that the bloggers do. Contraversial viewpoint, but a demonstrateable experience of a full website life-cycle is definitely a bonus.
30. Freelance
A slightly awkward issue with a lot of agencies; many include in their contracts that you are prohibited from doing freelance while employed by them. I find this a beaurocratic means of telling you to avoid a conflict of interest - i.e. don't do work for clients outside of the agency that are of a size/budget to actually work with the agency. Whereas in reality most developers will do freelance during their career and engineering a solution without the safety net of other developers (or their guidance) shows confidence in your abilities.
30 unconventional points that set a great developer apart from the others. I spend a reasonable amount of time interviewing candidates and while it's common to find a solid developer (good skills in the desired language, good experience) it's rare to find one well-rounded enough that they can make the agency directly more profitable. This list is my individual interpretation of the 'extra' bits that impress me if you have them.
Enjoy this article? Why not subscribe to the full RSS feed?
