Sometimes its important to sit down and take stock of where you are. Here are some of the guiding principles I try to follow in my working life.
A great part of my identity is that of a developer - someone who builds things. Its not constructing bridges or programming the next Linux Kernel but that does not matter to me. I sit in a studio, write code and build things for people who need them. I solve problems and make lives easier.
Recently as part of the transition process at work I’ve been asked to write a job specification for my own position. This was quite an odd experience but one I was certainly grateful to be a part of finding my replacement. It contained the usual things such as languages, tools or desired skills. However, as I was writing I began to think about what had made me successful in the role - how did I approach things and what did I feel was important as an attitude? The last section was intended to outline how I felt as a developer starting a new project - my own rules as it were.
I thought it would an interesting subject matter for a post (of course I may be wrong). We all have our own principles in life borne out of experience, opinion or personality. Here are mine.
1. Be honest
This is an obvious one, but I think it is the most crucial one. There are times where there will be issues that crop up - building a website is always a choice between two options at every stage. One way may add a great deal more complexity to the code, the other may involve slightly more work and time to achieve.
The worst thing to do is to bury your head in the sand and hope no one notices. This is not only kicking the bucket down the road but others may have came up against the problem you are facing. Or, they have their own suggestions around it. In the worst case the design team and other developers will at least know the problem is there - benefiting future projects or ones still in development.
As a developer you should provide guidance on matters of performance to the design team. I fundamentally disagree with the attitude displayed at times where one side will look down on the other. The design team is there to make something look brilliant, to push the boundaries and make something magical. The developers job is to figure out how to make this happen and to give constructive feedback on aspects that may not be possible. Working together is the key and this can only happen when everyone is honest.
2. No is a last resort
From time to time I have encountered developers who flat out refuse to contemplate something can be done. I can think of nothing more boring than always saying no.
My job is and always has been to make things work - to take some colours from an Illustrator document and wire it all together. To take some system requirements and make a fully functional application. The best projects are ones where the boundaries of what I know have been stretched.
Make no mistake this is not a call to be a doormat for any and all requests. Its about maintaining that passion and drive to build things. To sit and play with the lego of the web and put your imagination to the test.
If every possible way forward is blocked. If there simply isn’t time or resources or the skills to do so then offer alternatives.
3. Be optimistic
Be confident you can do something. Ignore the articles out there saying something is wrong. The clawing feeling that you are not the right person for the job. Put that aside and make something cool.
There have been times I’ve pitched ideas I have had only the vaguest idea of what to do next. Its not gambling on ignorance but having confidence your experience and know-how will carry you through to the next checkpoint.
With this comes a single provision however, be realistic on the timescales. If it will take two months to learn then say so - it may be worth it to the client or your employers to invest that, or maybe not. Promising the moon and missing is catastrophic but saying with a few billion dollars and a big-ass rocket you’re pretty sure you get there then amazing things can happen.
4. You do not know everything
Be humble. There are so many ways of building the same thing with programming it is impossible to know all the answers.
And that is absolutely OK.
Think about it this way, if you thought you knew everything you needed to know why would you ever look anything new up? If that’s the case then by all means continue using tables for layout.
There are always people you can learn from and in turn can learn from you. Be the person who welcomes new information with open arms.
5. Be opinionated but open-minded
You are not paid to be a blank slate mindlessly coding away. Like any artist you should put yourself into the work you do. Code is art (especially with some pretty indentation).
Bring your own style into it, use past experience and try something a little different from time to time. Experiment and play. There are so many parts to a web project where you are able to inject your own personality I could not possibly list them all.
Animation, code structure or even documentation - you can make these all your own even when staying within team conventions.
Speak up if you have a suggestion or a new way of doing something. Listen when others suggest their own. Discuss, analyse and review.
6. You make things for people
I was once told in a performance review that I often had a look of reluctance when working on an older project. One that had been completed a while ago, that maybe did not use the latest kit.
It was explained to me that my view of it could be warped by endlessly marching forward and chasing constant improvement.
I felt terrible as it was an involuntary reaction and from then onwards that lesson has stuck with me. With all the code and hardware it is easy to forget the human face. The little independent shop owner wanting to branch out into e-commerce. The nature partnership who use the website to fund and raise awareness of the fantastic work that they do.
You go into work each day and build for these people. Your ego should be left at the door as these are not vanity projects. There will always be a new shiny toy to entice you along but the people behind the emails are the ones to focus on.
I hope this does not come across as preachy or patronising - it certainly was not intended this way. This article is not meant to dictate how to be and is personal to my own experiences.
Hopefully you have found some of these interesting and I would love to hear any thoughts of your own about this subject matter.