With the release of Angular 4, and wider use and acceptance within the community, I decided to get up to speed with the overhauled Angular framework. I am now proficient in Angular 4, having plunged into TypeScript and ES6, learned the new and improved version of framework, and quickly fallen in love all over again.
Once I started integrating with .NET solutions, calling data from and creating pages around backend processes, it became necessary to find a more efficient way of stitching it all together. My code had become riddled with too many if/else statements, heavy with show/hide checks, and was making way too many Ajax calls. I wasn't happy with it; the speed of my sites was greatly reduced, and the complexity of the code became unmanageable. I didn't last long like this thanks to AngularJS. I took to it straight away and started creating my own services and directives to tuck all my code away into its own neat little compartment, ready to be used in my views.
Having mastered AngularJS and looking for my next step in furthering my skills and my career, ReactJS seemed like the logical next step for me take. Though the blurring of logic and view still jars with my core developer training, I like to keep myself open to new ideas and ways of thinking. This learning curve certainly did just that!
I taught myself to code HTML emails when I was in my first job. The very first thing I coded was atrocious, but it worked. I was over the moon with myself, but at the same time I knew I had a long way to go. I started picking apart code written by others, researching techniques and building day and night to try and perfect my skills. I think it took me about a year to feel fully confident that I had learned everything I could about HTML and another year after that to feel the same with CSS. This might sound arrogant, but really, once you have the basics with these languages it is just about having the confidence to apply those basic skills in a more complicated situation. At that time, I felt like there was nothing I couldn't do in a web page or an email. Until there was...
I quickly found that the abilities of HTML and CSS alone were quite limiting. I wanted to go further and do more. That was when I started looking into jQuery. The process was very much the same - I was self-taught and learned by doing (mostly wrong to start with), until things started to come easier and worked first time. I had a few good mentors along the way as well, who pushed me in directions I didn't know existed with jQuery, teaching me different methods of approaching the code, like building plugins, and bouncing events around (thanks Ben). I would never be so arrogant with jQuery to say I know it all. Programming is much more complex than markup, and because of this it is always possible to create new challenges and find better ways of doing things. Whether it is finding the most efficient method, or the most direct, or simply the one that gives me that warm fuzzy feeling of accomplishment inside, I am always learning in jQuery.
ES6 is all the rage at the moment. Its changing the way we write front ends, and it brings JavaScript in to the big-boy leagues. I couldn't wait to start learning it, and I wasn't disappointed. There are some great tutorial and resources out there to get you started, but in the end just reading through the specs on MDN and Es6 Features
Responsiveness is at the heart of all web content these days. Whether its responsive emails, websites, or applications, everything I create fits to the user, rather than the other way around. I use a mobile-first approach with websites, and make sure any responsive emails are backwards compatible with Gmail and Outlook, which don't support media queries.
As a front end developer, my own projects can sometimes be limited by a lack of a back end and a database. Working with tools like Angular and React, the front end comes so close to being all encompassing, I have found it frustrating not to be able to go all the way. Enter Firebase! Its am amazing tool that revolutionises building applications for front end developers.
Once I started working with CSS on large scale websites, I found it imperative that I have a faster, more logical and more efficient way of working with it. I quickly fell in love with SASS, and have worked with a few SCSS frameworks like Susy, as well as having a bank of my own mixins that I can plug into any project. To keep myself diverse, I also picked up LESS and have a similar bank of mixins to use with that, but my preference is always to work with SASS.
Once I started working on full web solutions, I found myself working in larger teams and partnering up with .NET developers. My affinity for learning new technologies fared me well here, and I quickly picked up ASPX Webforms. But shortly afterwards, MVC4 was released and my colleagues were moving to use Razor. Already having JavaScript in my armory, it wasn't too difficult to understand Razor and soon I was writing this too, and back to my old tricks, stretching the limitations of code once again.
I am familiar with agile development processes and whilst I don't buy-in to the trendy use of Agile key words in my daily practice, I do believe in the core concepts they represent. In my experience, the only effective way to complete a web project is with team-work, adaptability, and manageable work-planning, all of which are highly valued in agile processes. I have worked on a few Agile projects, using tools such as JIRA to track and plan progress through the business, coupled with daily stand-ups and sprint planning, and these are certainly the most successful projects I have delivered on. Even when a company does not follow these core concepts, I try to practice them in my own work and encourage my team to operate in a similar way.
A few years ago, I was unexpectedly given a team to manage. I was awkward at first, finding my feet as I learned what sort of a manager I would be as well as balancing my new work load with staying touch with the code and the latest developments, and continuing to hone my existing skills and learn new ones. But I got there, and I found a way to have it all. I think I am an effective manager, staying out of the way of my team, but supporting them where needed. I have had some challenges along the way - having to correct some team members who didn't uphold the high standards of the rest of the team, making my first hire, rolling out new business practices in an unobstructive way.
As you may have guessed from my overly-verbose website, I was originally a graduate of English Literature. I still keep copy-writing close to my heart and step in from time to time to correct grammar and wording, sometimes writing copy for websites and emails as well. I find that coding is not that dissimilar to copy-writing - there are lexicons, narrative standards and grammatical rules to every development language, and web browsers are as equally unforgiving of grammatical errors as any intelligent reader.
The company where I learned to code was, as you may have guessed, a .NET solutions house. So when it came to Content Management Systems there was only really one choice - Umbraco. I have used this extensively on several websites, big and small. It's a great tool, and offers lots of flexibilty, allowing me to build websites the way I want to whilst also allowing clients to keep content up to date. I have extensive training, solid hands on experience and a Level 1 Certification in Umbraco development.
HTML Email sounds easy, but it is actually one of the most difficult things to get right. There are so many different email clients, all of which treat HTML slightly differently. Unfortunately it's back to coding like it's 1990, with tables and inline styling. But it's worth it to see your emails work perfectly everywhere. I started my journey in email, and I still code them regularly for clients, so I have good knowledge of what will and won't work and the fixes that need to be implemented to make sure that the code will work and render perfectly everywhere. I have a high standard when it comes to coding, and email HTML is a skill that requires this perfectionist attitude to be successful.
Responsive emails became popular a few years ago, and I quickly developed a responsive framework which is now used across the company where I started. I have continued to add to this framework and develop documentation around it and I've made it publicly available for use.
Over the years, I have been asked to run several training sessions both within agencies and for clients. I have done this for systems that I have helped to build, systems I have worked with like Lyris, as well as for coding techniques within my team and for clients looking to do their own build work.