Designer and Developer
I see the developer portion of my career as a secret continuation of my design work.
The initial urge to start coding was borne out of frustration with my designs being implemented poorly. In hindsight I realise that what I had in my head went way beyond static visuals, most of which was lost when I handed my work over to the dev team.
As a frontend dev I continue to solve user problems and apply my design skills, its just the tools and others perception of my work is different. Where I work today I am responsible for the look and feel of lendable.co.uk, autolend.co.uk and 3 other 'white label' sites that use the same react code but with different branding. Managing these 5 styles is a constant compromise between technical feasibility and maintaining each ones visual integrity. I play an active part in designing the more complex components and flows. I work with some great designers and have at times given them tips on how to present their work.
The areas of design I'm best at are classic 'Interaction Design' and Typesetting. I know which controls are appropriate for a given interaction and why. How the sometimes the context of a control changes what people expect it to do. I also did an hour long talk about the history of typography from ancient Sumer to the modern era to an audience of backend devs and product people. (and no one fell asleep! I even got questions).
When working on a new problem I focus on the context. The first thing I do is sit down with some (often from product) and write fragments of text that represent the content of a UI. I take the fragments and arrange them into flows, then I take that away to produce wireframes. Occasionally I will do a high fidelity design but this is increasingly rare as I prefer to take the design into code and then review it with another designer to apply the final polish.
Today I work with React.js, Next.js, Redux at a senior level. I’m an expert with CSS and HTML and can achieve pixel perfect results with performant animations. I'm also passionate about writing code that others can read and maintain. A well written .tsx file should tell a story about the intentions of the code and the developer.
These describe my personal approach to writing code in team and also give a flavour of what it's like to work with me.
I believe that to work in software development you need to be studious. I like to understand things properly and feel uneasy trusting black-boxes.
Spending time reading a codebase can help dispel the urge to re-write everything and helps me to communicate how it works to non-technical people.
Only cut corners when it’s a good idea and don’t think you are too important to suffer a little tedium.
A little time spend thinking about what you are going to do before you start is always worth while. Even if the plan is to improvise.
Whether it’s a group situation or one on one, you have to listen first if you want anyone to hear you. To truly listen you have to be open to being wrong. The same also applies to code-style and architectural decisions, you have use a setup before you can suggest an improvement.
I find when people say “it can’t be done” they are making a judgement on the cost vs benefit without discussing either. When you share the your knowledge with people to help them understand what they are asking you can often find to a pragmatic solution, or at least drop it with confidence.
I expect myself and others to make mistakes. I want to be the person who others feel confident coming to when there is a problem. I believe it is how you plan for and deal with them is more important than never making them. When some one comes to me with a problem or bad situation I will listen and help first before discussing how it could have been avoided. When the time comes I hope others can do the same for me.
If some one else had the idea that I’m working on I make sure everyone know where it came from. If a person helped me, either with practical work, advice or coaching I want those around me to know where success comes from. I feel it is important for me personally to do these things because of my background I tend to win peoples trust more quickly and get given the benefit of the doubt more often than others.
That task you said you would do, the solution you just discovered; write it down, and do so in a way that assumes you will have forgotten the context. Your future self or whoever else finds your words will thank you.
Jun 2022 - Present
Nov 2019 - May 2022 · 2 yrs 7 mos
Aug 2019 - Nov 2019 · 4 mos
Jun 2016 - Jun 2019 · 3 yrs 1 mo
Sep 2015 - Mar 2016 · 7 mos
May 2013 - Sep 2015 · 2 yrs 5 mos
Jan 2013 - May 2013 · 5 mos
Mar 2009 - Aug 2012 · 3 yrs 6 mos