Amber: Blog

Conferences and Connections

Sun, 15 Mar 2026 24:00:00 GMT

I was so excited to come to Brighton on March 12th 2026 to attend Web Day Out. It's been a long time since I regularly attended conferences. Since COVID, I've attended two, the other being Beyond Tellerrand. Both of them run by very good people, both with very good speakers and attendees.

New Road in Brighton, UK

Before COVID, in the early days of my web career, I was fortunate to take part in a lot of conferences—whether attending, volunteering, speaking or representing codebar. Being part of the web community in this way was pivotal in my career as a web developer. It's a special experience—being in a room and in face-to-face discussion with other web nerds.

Having a chance to swap ideas, discuss web news, meet new people, or simply take in the inspiring atmosphere is just a snippet of what makes a conference (or a meetup) worth your money and/or time. Events like these take you out of your regular flow, usually to a place you don't normally visit. They provide a chance to discover new places, get a better idea of the web world (whether it's a new CSS feature or the state of the job market), and to top up your enthusiasm for working as a developer.

Coffee chats at a Brighton coffee shop

Let's talk about connections. I mentioned earlier that attending conferences was pivotal for me in my web developer career. Here are the things that helped me make (and keep) connections and how they helped me find success:

Developers tend to be incredibly nice people who are more than happy to give advice. As a profession that doesn't always require a formal degree, developers (particularly self-taught ones) understand that the advice they can give, based on their own experiences, can be extremely helpful to others. I never had to feel nervous or shy about asking other developers questions.
I have never felt the presence of a "hierarchy" among fellow developers. It's rare that anyone puts themself onto a pedestal. It feels like developers all understand what it takes to become and remain a developer. There is an inherent aura of respect and support, and a desire to swap stories and advice.
Experienced developers can help newcomers, that seems obvious. But newcomers also help out those who are more experienced. For evidence of this, look to a meetup like codebar. Experienced developers volunteer to coach more junior developers. Why do these coaches give up their time? Ask them and you might get a lot of different answers. One that I have felt myself is that that coaches give knowledge, but newcomers bring enthusiasm and new ideas that a coach who is more stuck in their ways may not have considered. Win win!
In my experience, the people I meet in the development and design world are more than happy to remain connected over the years. At conferences, I chat with people that I haven't seen for years, and it's always like meeting up with close friends. So many connections became and remain my greatest cheerleaders, and that's really special.

In a nutshell—the kindness and support of the community helps lift me up, boost my confidence, and keep me motivated. Through my connections, I was able to prove my enthusiasm and abilities to members of the community, which resulted in job opportunities that would not have been available to me otherwise.

The web community lifts you up when you need it, celebrates your wins, and wants you to succeed.

A speaker at Web Day Out told me that years ago there were a huge number of meetups and conferences. It was easy to find speakers, sponsors, and venues. These days, it's harder. Therefore, it's harder to keep community events alive and there are less chances to bring community together. That's why it's a great idea to support people running conferences and meetups.

Jeremy Keith of Clearleft at Web Day Out

Buy your event tickets early and help organisers spread the word. Keeping the web community alive is something that benefits everyone ♥️

Five Things I Like and Dislike #1

Sun, 11 May 2025 24:00:00 GMT

Inspired by Paweł Grzybek who was inspired by Michael Crittenden.

Like

That the weather is getting warmer so we can all wear cute summery things.
Using simple techniques to get better at completing 10-15 minutes of a project per day and seeing good results (book writing, piano, exercise).
Daydreaming about learning languages — Spanish, French, sign language etc.
Reconnecting a bit more with web folks.
Learning more about finances and experimenting more with saving money.

Dislike

Things I pay for being late — public transport in Berlin, hairdresser, piano teacher (I understand companies and people have their reasons though of course).
My short (1-meter) charging cable. I should have spent €10 extra for the 2-meter one.
Not having enough time or brain power to read all my books.
FOMO on Bluesky just because it gives me too much of a Twitter vibe and I don't want to be on it.
Being ill a lot because I have a child who goes to daycare.

Writing a Book in Public - Switching to Web Dev

Wed, 08 Mar 2023 24:00:00 GMT

I'm writing a book for people who want to change careers and get into web development!

To get updates and sneak peeks please sign up below ❤️

To sign up as a beta reader please send an email to switchtowebdev@gmail.com ❤️

Timeline

October 2020

I opened Google Docs. Inside, I wrote down everything I could think of about switching careers to web development. I added a table of contents.

April 2022

I bought and read "How to Write a Nonfiction eBook in 21 Days - That Readers LOVE!" by Steve Scott. I opened my Google Doc and wrote down some useful pointers from the book.

May 2022

I thought I better get on with my book, so I opened my Google Doc. I wrote an introduction and something about personal projects.

June 2022

I used flashcards to organise a table of contents (which later changed almost completely).

September 2022

I bought and read "Write Useful Books: A modern approach to designing and refining recommendable nonfiction" by Rob Fitzpatrick. I opened my Google Doc and wrote down some useful pointers from the book. The book helped me realise the table of contents I had created needed improvement.

I bought and read two other career-switch-to-web books. These books helped me figure out what I did and didn't want in my book: "How to Get a Job in Web Development: The Ultimate Guide" and "How to Become a Web Developer: The Career Changer's Guide".

March 2023

Now that my child is in daycare, I can dedicate a little more time to writing. I can also keep telling myself that a little bit of writing a day is better than none. Logic over fear, let's go!

My writing mantra is to cut the fluff and tell people exactly what they need, in plain language. Currently feeling thankful for the longer, fluffier paragraphs I wrote years ago. I can take those and cut them down!

Update email 1 (31.03.23)

Progress

I have begun to include a mix of personal stories and more factual information.

Even though I know I don't need to yet, I'm worrying about things like how to fit the personal stories around the facts, among other things like tone of voice.

I'm spending lots of time moving chunks of text around and deleting stuff.

I'm finding that I'm not very comfortable writing huge blocks of text without immediately editing them. Going back to the blocks the next day brings me fresh clarity that enables me to edit better!

Sneak Peek

None yet. Maybe next time ;)

Inspiration

I found a good post from Leo Babauta. He says to make writing easier, write for one person only. I'm writing for people who are in the position I was years ago. I'm writing for people who wish for a career change and are interested in becoming a web developer.

April 2023

Chipping away at the book, paragraph by paragraph, night by night. The work feels slow. Like I am adding dominoes, one at a time, very, very gradually to a long and dusty, years-old line of old dominoes that stretches further than the eye can see. But, I feel good about it! I can't see or even feel the progress. Not really. But I know it is there. Once I wrote 100 words a day for 100 days and at the end had 10,000 words of material. Those few words I wrote every day felt so easy to write and grew into something huge. This is what's happening with my book as well.

I asked a good friend of mine if she'd share her experiences of becoming a developer with me. She said she'd be happy to support me ❤️

I asked on Mastodon whether anyone knows a new web developer who used to do something else. I am excited to chat with people!

August 2024

Hello! I'm back! I've been writing. I have a few chapters set up.

I'm currently grappling with a question.

If I write this book in public, include real developer stories, and ask for review help from other developers, how do I market the finished book?

I don't want to sell the book as if it's my accomplishment alone. I don't want to profit off of it alone. That feels greedy.

My current idea is to put it up as a digital file via an indie seller website for around $5. This feels underpriced but would make it more accessible to more people and hopefully nod to all the people who supported me along the way.

April 2025

Alright. Nearly 5 years after starting the book, I am serious about finishing it this time. This may be due to my three year old now sleeping at a consistent time every evening.

I am planning to interview at least two more people for the section on people's personal experiences switching careers to web dev.

A pile of good notes exists that will slowly be worked through.

The task ahead feels daunting. I need some writing inspiration! On that note, a big shout out to my pal Laura for giving me some much-needed motivation.

May 2025

Post by @ambrwlsn@indieweb.social

View on Mastodon

June 2025

I signed up with Kit and sent my first book update to my 7 subscribers via that platform! Sign up with my shiny new newsletter form at the top of this page (I added my own label to the email input — do better, Kit!).

Making the Time to Review Pull Requests

Tue, 22 Nov 2022 24:00:00 GMT

Code review is super important. At times I have worried that I've spent too long reviewing and not enough time working fast and breaking things. Today I was reminded that time spent on code review is worth its weight in gold.

My Code Review Story

I was invited to a 1 on 1 meeting with a colleague who had offered to review my code in a pull request on GitHub. She wanted to discuss the three questions I'd left on my pull request.

Her review was so careful and thoughtful! During the call, she whipped open a Notion file that contained answers to the questions in my pull request. She also showed me a sheet she had created that contained various URLs for testing, along with information about each link.

I felt so good that she had put so much time and effort into her review! She had even had a chat with another engineer to find out how to answer my questions better.

We discussed possible improvements and solutions for about half an hour. After the call, I felt great. I felt more confident that my pull request could be improved and, once merged, really add value to the project I'm working on. Not only that — but the code will now be clearer and more future-proof.

Benefits of Code Review

Here are some benefits that code review offers:

Adds to shared knowledge and increases the bus factor
Improves the quality and future-proofness of code
Decreases the chance of bugs in code by picking up on things others miss
Improves the end-user experience
Reviews are a form of documentation
Lots of emojis are allowed

Summary

There are so many reasons to review code. I urge you to set aside abundant time for code review! It isn't a waste of time. Anyone who thinks so is a bit silly. Good luck :)

How to Approach a New Codebase

Thu, 25 Feb 2021 24:00:00 GMT

What is your approach for understanding a brand new (complex!) codebase, whether open source or at a new job? I posted this question in the form of a tweet earlier this month and got lots of honest and heartfelt answers from developers! In this blog post, I grouped the answers to help you learn how to approach a new codebase.

What is your approach for understanding a brand new (complex!) codebase, whether open source or at a new job? ⬇️
— Amber Wilson (@ambrwlsn90) - Tuesday February 2nd, 2021. Original Tweet →.

I want to give a huge thanks to everyone who participated in the above Twitter thread. I have not included handles or names, and have edited responses a little to give this post a consistent tone. Please let me know if you replied to the thread and wish to be credited or are unhappy with my edits.

Explore

Build

Step by step advice

Step by step advice

Humour helps

Funny stories

Start from the top

Sketch out the structure of a codebase and look through it with my team or the person I am replacing.
I agree that a high-level conceptual overview first is a good idea.
I start by drilling down to something specific. Not “what does this do”, but “how does this do 'X'?”.
Find the highest level of interface, whether user interface (UI) or application programming interface (API), that a customer or end-user would use. View the user interaction as the top level of a feature, and drill down from there, taking it apart piece by piece, right down to the lowest level.
Get a high level overview of a codebase, and then learn by example. This means solving a specific problem and using this to help understand a codebase. This also works for onboarding, especially for a complex project, where it is usually best to give a high-level introduction and then learn details doing the first story or ticket.
I like to get an overview and then go straight to work on something small. This way, the unfamiliarity fades away. Then I either find I like the code or I don't.
Maybe emerge could help to visualise, inspect and understand structure, dependencies, and some common metrics in your codebase, if the language is supported.
Set up meetings with people on the team to understand the architecture and what parts of the software are responsible for it. Then it’s usually best starting with a small task and over time taking bigger tasks. This way I gradually get an understanding of the codebase.
I'm a consultant, so I have to do this at least once every 6-12 months. Learn systems, not codebases:
1. How does the app work from the user's point of view? Ask this first.
2. How is the application glued together? How does data flow in the context of the architecture?
3. How does code go from my computer into production? Understanding the details of the code is much easier in context.

You do not need to understand the whole codebase

When I started my 1.5 year tour at Google a long while ago, it was the first place I'd ever worked where knowing the whole codebase was clearly impossible. Accepting that was liberating. Since then I haven't concerned myself with knowing a whole codebase and I'm better for it.

Use the finished product yourself

Use it. Like a user. Applies to APIs and libraries too. They all have a user interface.
Browse through the live version to get an idea of what the application does. Sort of see it from the eyes of the users.

Run the code locally

Set up the codebase locally and get it to run.
I try to make sure my environment, builds, and things like that work. I can't count the number of hours I wasted trying to do something, before realising I was missing some key part of the process. Simply going from cloning a repository to building and running the latest version locally gives you loads of good information.

Ask questions

Do not be afraid to ask questions.
Ask people if you can't find the answer quickly. It's better to ask than to waste time.
I ask someone who is familiar with the codebase to give me a big picture overview.
Keep asking questions to the person who wrote the code, with increasing urgency as they get closer and closer to leaving.

Pair program

Pair programming is great for getting started with a codebase. We use this technique a lot at @qumulo and it is a fast way to pick up a lot of details.
Grab hold of the nearest experienced developer and make them pair program with you until they're sick of you! Seriously though, pair or mob programming is probably the best way to introduce anyone to a new codebase or team, regardless of skill levels or complexity!

Read and write documentation

Try to find internal documentation for certain domain knowledge. Unfortunately, good onboarding documentation for new joiners or new contributers to a codebase is often not readily available.
Read the documentation, perhaps find a textbook explaining how to understand a codebase based on its tech stack, and try searching for answers on Stack Overflow.
Writing the often missing documentation is a great way to learn and a good excuse to talk people and ask questions.
Good documentation and a code editor with the ability to jump to method definitions is essential I think. That's the number one thing that helps, for me at least.
Read the docs if available.

Take notes

Take notes on everything, in whatever form works for you. You WILL forget things. That's okay and expected.
Ask questions and takes notes as much as possible.

Fix bugs and debug code

Go spelunking (a term used to describe exploring a cave) in order to find bugs. Reading code or documentation in isolation does not help me to grok (understand) a codebase, but contributing to the codebase does.
Look at a REST endpoint then follow it to the actual data or action. Add breakpoints to debug the code bit by bit. You can add breakpoints to code within your chosen code editor or inside a browser's developer tools.
Add a small cosmetic change somewhere - extra logging, some debug output in the user interface for example. In trying to make those kinds of changes you often learn a lot.
Find a simple bug to fix: reproduce it, look in the code to find the call stack that leads to it. Timebox this! Don't worry if you get lost. If you are lost, ask someone who has knowledge of the codebase.
Run the debugger with some breakpoints. Observe what's going on.
I've been fascinated by how people use incidents as pulling back curtains on specific facets of how things are supposed to work.
Most of the tickets for new hires should be bugs. Maybe the occasional copy change – something small like changing the default order of a list to be 'creation time' rather than 'alphabetical'.

Tests tests tests

This may sound aspirational, but get the project up and running and run tests.
I expect there to be well-documented tests and overall workflow.
Focus on parts of the system needed for a certain feature and discover things through tests and static analysis.
Look at the tests; hopefully they exist.
Start with test cases.
Hands down my preferred approach is to start writing tests for a codebase, or if it already has unit tests, find what area is under tested.
Writing user interface tests, for example using Cypress and API mocking.
Changing or adding some tests can help you understand how things work.
In practice, almost everybody has to work on codebases they don't fully grok (understand). I forget parts I haven't touched in a while, so that's why it pays off to invest in practices enabling people to understand a codebase quickly. These practices involve good tests, good continuous integration/delivery, and ultimately good observability in production too.

Watch logs and error messages

If I’m trying to work out what to grep for, looking at logs or error messages is often helpful. For example, passing random input to a service will spit out a stack trace and an error message as it fails to parse whatever you sent, and that can be pretty revealing.

Build features

Dig in to wherever there are actual changes to be made, and give yourself time to learn from there.
Splitting up a code base into smaller, self-contained pieces works especially well for Open Source. It makes one-time contributions easier by minimising the required mental overhead.
I focus on understanding the bits I need to work on. Whether it is a bug or feature I’ve been assigned to, and I skip the rest. 95% of the time, a good choice of grep will help me find the files I want, and I work things out from there.

Step by step advice

From experience, it takes time to learn the different components of a codebase, especially ones that are large and complex. Learning comes from working on different features or components, reading documentation, and asking lots of questions.
I recently started a new job at a company with a HUGE and very complicated codebase, for an enterprise software suite. Here's what has helped me:
1. Find a mentor who is familiar with the code, able to explain clearly, and whose communication style matches yours.
2. Get a 10,000 foot overview of the codebase from your mentor: what products the projects or solutions correspond to, any external dependencies on 3rd party libs or apps, a high-level dependency tree, what projects are most relevant to you at this time. Your mentor can hopefully point you in the right direction.
3. If you don't know where to start or what you're going to be working on, ask! When you start a new job or project, this is the time to ask questions. Ask who the best person is to talk to about each framework.
4. Ask about the development process for the area, project, or team you're working on. What's the workflow for issues? Who will code review your stuff? Who will test it? What things need to be checked off to call the issue done. Does this involve development testing notes, pull requests or merges, documentation, etc?
As usual, I feel like my answer leaves people pretty unsatisfied. You won't get a handle on a codebase quickly. You can start to understand certain parts and let the rest unfold over time.

Whenever I talk to people about where questions like this come from, it often one of two things. "I feel like I want to learn this skill" and/or "I feel like I need to learn everything quickly in order to be productive". That second one is the challenge. I don't think the second one should be as big a concern as people make it out to be.

You can contribute without learning the whole codebase. And contributing something that actually ships is the best way to learn a codebase over time. For the first couple of months, I just focus on the thing I want to build. I ask people "where should I put this module?". More importantly, I ask them why they chose that location. Every time I ask, I get another piece of the puzzle on why the codebase is the way it is.

There are lots of skills and tactics we can and should pick up as developers. For example, you can pick a feature you understand and then trace how it works. Find all the files that enable it and learn why they are in that location. Most importantly, I wish people would feel less pressure to know a whole codebase in-depth.

I've been at my current job for 2 years and I haven't seen everything. I'll learn about a new area when I'm doing something that gives me a reason to learn it. And that's totally okay. To be clear, what I'm saying is that knowing the codebase won't help you with fixing incidents as much as you think. When something is broken, it's usually not code. And if it is, roll it back and look closer at it later. There are a lot of assumptions here. Like having easy, push-button rollbacks. If you don't have that, then start fighting with whoever you need to in order to get it.
Resource one: Highly-recommended presentation on how to read other people's code
Resource two: Reddit comment on how to approach a codebase

Funny stories

Being a developer can be hard work. At least we can laugh about it with our fellow developers though, right?

Surprised no one has said “Build a feature using it, then have that feature burn to the ground at 2am.” Because as far as I know, that is most people’s approach.
Panic, become convinced that the person who wrote this was a million times smarter than me, question my choice of profession, wonder how long it will take them to fire me if I can figure this out. Find someone to ask a question, lightbulb moment. All is well with the world again.
One exercise I like is digging for the longest code block that nobody else has dared refactor, so it has survived for a long time. I start asking people about it because I know it’s going to be a mess compared to the rest of the codebase. Everyone will give different answers.

Mini Blogging Masterclass

Thu, 11 Feb 2021 24:00:00 GMT

A very mini list of things that I usually think of while I'm writing about life and tech, that have helped me to blog better!

My number one tip is that a blog post does not have to be polished and perfect (nothing is ever perfect!) before you post it. This blog post is a great example. It had been a draft for a long time, and I was hesitant to publish it. I waited and waited, just in case I could think of a few more tips. I mean, everyone would benefit from 15 tips rather than 10, right? Wrong. If I didn't publish, then nobody would benefit from even 1 tip. A draft post tends to remain a draft. Get your posts published. I want to hear your ideas!
You don't always have to write about the next big thing, or what everyone is currently talking about. Countless millions of websites use web technologies that are many years old. Write about whatever interests you and you will find an audience, trust me.
Blog about things that scratch your own itch. For example, you may have had trouble setting up a server, or found it hard to understand a JavaScript library. It can be anything. Posts that explain and describe how you solved a problem you experienced are really helpful to other developers.
If you are planning a complex or technical blog post and it seems intimidating, try breaking your plan into smaller steps. Limit the time you spend on each step–30 minutes, for example. Completing each step will help give your motivation a boost, and help you stop feeling lost in one huge task. You can use these regular motivational mini-boosts to keep going and help you write your post!
You may think of something you would like to write about, but do not know where to start, or have little idea how to structure the information. A good way to overcome this is to create headings, and place information under these headings. This can influence how you write and section your work and can help you get your awesome post out to the world faster.
As Anne Lamott, who wrote a book on how to write, says—get all your thoughts down in a "shitty first draft". Don't focus on editing grammar or spelling right at the beginning. Your draft will most likely change a lot as you are writing.
I don't use grammar or spellcheckers much myself but there are definitely a number of tools that can help!
Don't blog for attention or money! This will most likely make your motivation for blogging hit a roadblock, and fast. Blog for fun, let your creativity flow, and connect with other people. That's all it should be about. Other rewards are just side effects.

Writing a Winning Web Developer Resume

Fri, 15 Jan 2021 24:00:00 GMT

It's hiring season!

Do you want a new web developer job? You might call yourself a frontend (front-end/front end) engineer, a UI developer, a full-stack engineer, a software engineer, etc. There are many different and fun combinations of job titles!

I will assume you develop things for the web, so you are a web developer.

This post will give you, a web developer, tips on how to make a good impression at companies you'd like to work at.

Who cares about a good resume? Well, unless you know people at the company you want to work at, it's likely the first impression you'll make is with your resume.

Tips on writing your web developer resume

There are loads of tips out there on how to write a good resume. Below are some of my favourites that I gathered from both applying for jobs and from reviewing applications:

Write things you achieved, not only things you did. For example, instead of "added lots of JavaScript features", try "added JavaScript features that lowered load time by 400ms". Did you save your company money? Cool! Did you reduce loading times? Awesome! Explain how you did it and how it benefited your company or customers.
Evidence for how you helped your company succeed or improved customer experience allows reviewers to imagine how you could provide value at their own company.
Make sure your listed skills are relevant. It is not good to list a skill or technology just because you read a blog post about it or because it is popular. Focus on skills and technologies you have used, enjoyed, and want to use in your next job. There's nothing much worse than listing way too many skills for a job—mostly because it shows you don't really care about your application.
Adding relevant skills gives a clearer impression of what you actually enjoy and want to do in your job.
Separate your skills section into what you use daily, weekly, and monthly. If you only used Redux once a few months back, it's best not to give the impression that you use it all the time.
Being clear about how often you use different skills or technologies helps a reviewer understand your strengths.
Keep your "education" section simple. Reviewers won't pay too much attention to it, especially since many web developers are entirely or partially self-taught.
Details about your hands-on coding experience are most often more important than details about your studies.
The person reviewing your resume is short on time but has lot of other resumes to look at. Keep your resume short and concise. Imagine a reviewer has only thirty seconds to read each application.
If you can read through your own resume in 30 seconds then it is a good length.
Look at your resume and be honest - would you enjoy reading it? If not, then try to add space between content, use whitespace well, choose a pleasant font, make sure spelling and grammar are correct, cut it down to maximum two pages etc.
A tidy, short, and well-designed resume with no spelling or grammar errors shows you put effort into your application.
Add links to your projects and (if you want) social accounts. Linking to project work on a personal website or repository is a great way to show off what you can do. But beware, reviewers will look at your source code! Linking to social accounts is good if you are comfortable with that and believe it can give a useful impression of you.
Links to projects can help reviewers learn even more about you than what you can squeeze onto your resume.
Introduce yourself and your hobbies. At the start of your resume it can be nice to introduce yourself by summarising your work experience and perhaps mentioning some of your hobbies. A reviewer may be glad to see that you have interests outside of coding.
Summarising your work experience along with your non-work experiences (hobbies) can help a reviewer see that there is more to you than coding.

Bonus tips for cover letters and interviews

Being a web developer isn't only about writing code. Aside from coding achievements, describe proud moments you had while interacting with others at work, or decisions you made on a problem that helped you avoid wasting time and building up technical debt. Describe how well you collaborate with others and show off your problem solving skills.
Awareness of the importance of non-coding skills is crucial to being a good web developer.
Don't address your cover letter with "Dear sir or madam". It's a good idea not to assume the gender of whoever is reviewing your application. Find another way to start your letter - for example "Dear {company name}" or "Hello!"
Neutral language ensures that everyone is respected—including your reviewer and your customers.

2020 Year in Review

Thu, 31 Dec 2020 24:00:00 GMT

I got the idea to write a my first ever retrospective for the year from Monica Lent.

What a year it has been. Back in February I had no idea what the rest of the year was going to look like. I even attended a comedy night in Berlin where one of the comedians joked that she had coronavirus, and the audience actually found it genuinely funny!

I didn't get to fly and visit any of my family or international friends this year, which has honestly sucked. I also don't see much of my local friends and family. I really miss everyone and it feels like a piece of me is missing. The pandemic has also delayed several of my important appointments.

However, despite the pandemic and its effects on me this year, I am under no illusion of my privilege:

I am happy. I am loved. I have a roof over my head. I am fed. I have disposable income. I enjoy my job. I am warm. I am healthy. I am educated. I have prospects. I have time. I can pursue hobbies. I am safe. I feel included.

Have you checked your privilege today?
— Amber Wilson (@ambrwlsn90) November 10, 2020

Anyway, in this post I want to try and focus on what I learned and achieved as a web engineer this year.

What I set out to do in 2020

For 2020, I did not set out with a particular goal in mind. I was happy to go with the flow, work hard at my job, and maybe write a couple of blog posts on the side.

One reason I may not have set goals for myself this year is because I had been working towards getting promoted to a mid-level web engineer since October 2019. I got promoted in March. I was pleased with this and did not make any more solid professional goals.

For 2021, this is going to change. I've definitely got some plans for 2021.

Achievements in 2020

It felt really good to remember things I achieved this year:

Got promoted to mid-level frontend engineer.
Wrote 16 blog posts (averaging 1 post every ~23 days).
Read 12 books (I wanted to read more than twice this - oops! I'll do better next year).
Spoke on my first web podcast.
Set up my own home office space that I'm quite pleased with.
Coached remotely at codebar Berlin.
Re-designed and re-wrote my site with a static site generator called Eleventy, which turned out to be the most fun I've had coding all year.
Began a CS50 course with some nice people, so I can dive into some fundamental computer science topics.
Cooked a lot of new meals and made a recipe book so I can remember them.
Got around 40 new plants, three quarters of which I managed to keep alive.

Thanks I want to give

I want to thank a few people this year:

My partner for being amazing as always. You know why you're awesome!
Jeremy Keith for his support, mentorship, and being my most fave person ever to debate the web with.
Kitty for their support, mentorship, and enviable ability to make pretty much anything.
Eva for being a bright light in the murkiness of this year, and getting people motivated to socialise and learn together.
Kristian for keeping codebar Berlin alive and kicking while staying as cool, calm, and collected as ever.

The whole of the web community this year has, as usual, been my rock. I can always count on my web friends to lift me up, support me, and motivate me to be the best I can be. I'm looking forward to being a part of this amazing community again next year. Huge love to everyone who is a part of it.

Plans for 2021

Create a Career Management Document. In short, this involves writing down personal and professional achievements at least once a week. It helps you remember what you've done and learned, and helps you show this off to employers!
Write 3 to 4 blog posts a month. By the end of the year, this means I would have written at least 36 blog posts. That's more than twice the amount I wrote this year! I want to write this many because there is so much I want to learn.
If I don't understand something, research it and write about it.
Be aware of the "curse of knowledge" and continue to write posts that developers of all levels can follow along with.
Read 30 books!
Do more codewars challenges.
Write at least one codewars challenge.
Coach at least 5 times in a virtual codebar workshop.
Record a video post and/or hold a live stream to teach something about web development.
Make an Eleventy plugin (e.g. for Webmentions).
Make more cute things, because the web is a place of expression where you can let your creativity roam free.

Happy New Year!

How and when to use React useCallback()

Tue, 22 Dec 2020 24:00:00 GMT

In short, React's useCallback hook is used to wrap functions. It tells React to not re-create a wrapped function when a component re-renders, unless any of the useCallback's dependencies change. But when is it necessary to use useCallback?

Most blog posts I have read on useCallback contain example code where a function wrapped in useCallback could just be moved outside of a component function body and into its own scope. Or placed into a useEffect instead. React is a smart library that is optimised to not need a hook like useCallback in most situations.

The example code in this post aims to be more "real-world". Because of this, it's necessarily quite complex. As well as using common React hooks such as useState, useEffect, it also uses a number of JavaScript methods such as the fetch API, promises, filtering, splicing, destructuring, and currying.

Even if you aren't an expert in all of the methods used in the example code, I hope you can still learn something!

Object references

I want to explain an important fundamental JavaScript concept that will make understanding useCallback easier—object references:

Functions are objects in JavaScript. Even if two functions are identical, they won't equal each other:

var dog1 = func(){console.log('14/10')}; // has a unique object reference
var dog2 = func(){console.log('14/10')}; // has a unique object reference

dog1 == dog2; // false
dog1 === dog2; // false

In comparison, if an object assigned to a variable is directly assigned to another variable, the references will match:

var dog1 = func(){console.log('14/10')}; // has a unique object reference
var dog2 = dog1;  // assign the unique object reference of dog1 to a variable named dog2

// dog1 and dog2 point to same object reference
dog1 == dog2; // true
dog1 === dog2; // true

In the next section, we'll see why object references are fundamental to writing and understanding React apps.

Example app

This section will go through and explain each step of a dog park example app . If you want to take a look at the final code, here is the Dog Park GitHub repository. If you want to see a live version of the app, here is the Dog Park app.

The initial features that I built into the dog park app were pretty cool. They let you set a name for your park and choose the number of dogs in it!

Inside the function body of the DogPark component, there is a function called fetchDog. This function fetches an array of dogs from The Dog API by Postman. DogPark re-renders whenever a user interacts with any of its elements, including its child component, Dogs. Whenever DogPark re-renders, fetchDog will be re-created and receive a new object reference.

import React, { useState, useCallback } from 'react';
import Dogs from './Dogs';
import shuffle from './shuffle';

const DogPark = () => {
  const [text, setText] = useState('');

  const handleText = (event) => {
      setText(event.target.value);
  };

  // Gets a new object reference when it is re-created.
  // It is re-created whenever DogPark re-renders.
  const fetchDog = (number) => {
    const result = fetch(`https://api.thedogapi.com/v1/breeds/`)
        .then((response) => response.json())
        .then((json) =>
        shuffle(json).splice(0, number)
        );

    return result;
  };

  return (
    <>
      <h1>Welcome to {text || 'The Dog Park'}!</h1>
      <p>
        <label>
          Name your dog park:{' '}
          <input type="text" value={text} onChange={handleText} />
        </label>
      </p>
      <p>Add the perfect Dogs to your park! Maximum of 10.</p>
      <Dogs onFetchDog={fetchDog} />
    </>
  );
};

export default DogPark;

Let's take a look at the Dogs component:

import React, { useEffect, useState } from 'react';

const Dogs = ({ onFetchDog }) => {
  const [number, setNumber] = useState(1);
  const [dogList, setDogList] = useState([]);

  // Runs the "fetchDog" function when either the number
  // variable or the onFetchDog variable changes.
  useEffect(
    () => {
      if (number && typeof onFetchDog === 'function') {
        async function fetchDog() {
          const response = await onFetchDog(number);
          setDogList(response);
        }
        fetchDog();
      }
    },
    [onFetchDog, number] // dependencies of the useEffect
  );

  return (
    <>
      <label>
        Number of dogs:{' '}
        <input
          max="10"
          min="1"
          value={number}
          type="number"
          onChange={(event) => setNumber(event.target.value)}
        />
      </label>
      {dogList && (
        <ul>
          {dogList.map((dog) => (
            <li key={dog.id}>{dog.name}</li>
          ))}
        </ul>
      )}
    </>
  );
};

export default Dogs;

The useEffect in the Dogs component has in its dependency array the fetchDog function (which has been passed down as onFetchDog), and the numbers variable.

An input with a type of number lives inside the Dogs component. Whenever the number of dogs is changed, Dogs will re-render and fetchDog will be run. This is good! It's what we want. Note: when state that lives inside a child component changes and the child is re-rendered, this will not trigger a re-render of the parent component.

If state that lives inside the parent component changes and the parent is re-rendered, the child component will also re-render. In the majority of cases, this is normal, expected behaviour. In the small number of cases this is causing an obvious rendering issue, you can try wrapping the child component in React.memo. However, if a value in the parent component that the child component depends on gets a new object reference, React.memo won't work. In our app, Dogs depends on the fetchDog function coming from DogPark.

Whenever a character is typed into the "Name your dog park" input in DogPark, DogPark will re-render and fetchDog will be re-created and get a new object reference. Dogs will also re-render and because the fetchDog dependency in its useEffect has changed, the useEffect will trigger, and the fetchDog function will run. This means that the list of dogs inside Dogs will refresh every time a single character is typed into the "Name your dog park" input. That is not good! It's not what we want. But what can we do?

We could wrap the fetchDog function inside DogPark into a useCallback to ensure it is not re-created each time DogPark re-renders. However, as the fetchDog function has no dependencies, it can safely be moved out of the function body of DogPark. This is a simpler way to ensure that fetchDog is not re-created every time DogPark re-renders:

// This function now lives outside of the DogPark function
// body and so is not re-created whenever DogPark re-renders
const fetchDog = (number) => {
  ...
};

const DogPark = () => {
    ... // DogPark function body

Ok, so, useCallback wasn't needed. But now, a third feature is going to be added to the app that is going to require useCallback. This feature will be the ability to choose dogs that have names beginning with either A-M or N-Z.

A new state variable and two radio buttons are added. And the fetch function is moved back into DogPark and altered a little:

const DogPark = () => {
  const [text, setText] = useState('');
   // New state variable
  const [charRange, setCharRange] = useState('A-M');

  const handleText = (event) => {
    setText(event.target.value);
  };

  const fetchDog = (number) => {
      const result = fetch(`https://api.thedogapi.com/v1/breeds/`)
        .then((response) => response.json())
        .then((json) =>
            shuffle(
                // Filters dogs depending on the value of 
                // the new state variable "charRange"
                json.filter((dog) => { 
                    return charRange === 'A-M'
                    ? dog.name[0] < 'N'
                    : dog.name[0] > 'M';
                })
            ).splice(0, number)
        );
    return result;
  };

  return (
    <>
      <h1>Welcome to {text || 'The Dog Park'}!</h1>
      <p>
        <label>
          Name your dog park:{' '}
          <input type="text" value={text} onChange={handleText} />
        </label>
      </p>
      <p>Add the perfect Dogs to your park! Maximum of 10.</p>

       {/* Two new radio buttons */}
      <p> 
        <label>
          A-M
          <input
            type="radio"
            checked={charRange === 'A-M'}
            onChange={() => setDogHalf('A-M')}
          />
        </label>
        <label>
          N-Z
          <input
            type="radio"
            checked={charRange === 'N-Z'}
            onChange={() => setDogHalf('N-Z')}
          />
        </label>
      </p>
      <Dogs onFetchDog={fetchDog} />
    </>
  );
};

The fetchDog function now relies on the charRange state that lives within DogPark. This means fetchDog has to live in the function body of DogPark. I thought I could solve this issue by passing charRange to the fetchDog function that's passed down to Dogs:

// Here, fetchDog is outside of DogPark and gets the
// charRange state as a curried value but the returned 
// function is still re-created each time DogPark re-renders
const fetchDog = (charRange) => (number) => {
    ...
};

const DogPark = () => {
    ...
    <Dogs onFetchDog={fetchDog(charRange)} />
};

Even though I successfully moved fetchDog out of DogPark, fetchDog is still re-created every time DogPark re-renders.

So, fetchDog needs to stay within DogPark, and useCallback can help to avoid fetchDog being re-created every time DogPark re-renders. This means that when a character is typed into the "Name your dog park" input, even though DogPark re-renders, fetchDog keeps its object reference, and so the useEffect in Dogs is not triggered. And the dog list in Dogs is not needlessly refreshed!

// Now the fetchDog function is wrapped in the 
// useCallback hook, with "charRange" in the hook's
// dependency array.
const fetchDog = useCallback(
    (number) => {
        const result = fetch(`https://api.thedogapi.com/v1/breeds/`)
        .then((response) => response.json())
        .then((json) =>
            shuffle(
            json.filter((dog) => {
                return charRange === 'A-M'
                ? dog.name[0] < 'N'
                : dog.name[0] > 'M';
            })
            ).splice(0, number)
        );

        return result;
    },
    [charRange]
);

When to actually use useCallback

In most use cases, your application won't be affected if a function is re-created and gets a new object reference upon each render. Even so, it can be tempting to proactively wrap a function in a useCallback to improve app performance. However, this premature optimisation can actually do harm rather than doing good. A blog post by Kent Dodds explains when and when not to use useCallback.

A good way to approach using useCallback is reactively rather than proactively. This means that, depending on your components, use it when you obviously need to, and not as a premature performance optimization. In short, don't wrap every function living inside a function body in a useCallback.

It's highly recommended that you have React linting in your development environment, so that your linter can suggest appropriate times to use useCallback.

If your linter is not suggesting useCallback, but you see that your UI is re-rendering in unexpected ways (as in the example in this post), or you have an infinite loop, check to see whether useCallback helps.

Resources

Official React docs for useEffect and useCallback
Kent Dodd's post on when to use (and not use) useCallback
Dan Abramov's guide on useEffect() offering a deep dive into React hooks

Are your Anchor Links Accessible?

Mon, 14 Dec 2020 24:00:00 GMT

One day I decided I wanted to add anchor links to each of the sections in my blog posts. Over the past few months, I'd seen these links on a lot of pages—from official documentation pages to smaller blog posts. I find them really useful for sharing sections of pages with other people!

To make the different sections of my blog posts shareable, I decided to add an anchor link to all of the section headers (<h2>s) in each of my posts.

While researching the best way to do this, something I noticed again and again was that other sites had almost always implemented anchor links in an inaccessible way.

Within a few hours, I had made a plugin to automate the addition of anchor links to my blog post sections, AND I had ensured the links were accessible!

What are anchor links exactly?

Anchor links provide a way to link to separate sections of a page. On this page, hover over the level two headings on desktop to see the links (the links are always visible on smaller screens).

In essence, an anchor link is a link containg a URL fragment. This fragment usually appears at the end of a URL. It begins with a hash character (#), and is followed by a string. This string identifies a section in a web page.

For example, a page may have a section containing a section header element such as an <h2>. This element can be given an id attribute. An anchor link is created when the value of the id matches the href value of an anchor (<a>) element on the same page. Consider the following code:

<h2 id="introduction">Introduction</h2>
<a href="#introduction">#</a>

Imagine the web page containing this code had the following URL: https://example.com/blog/nice-post/. Clicking on the hash character within the <a> element would do two things; the browser window would scroll to the beginning of the introduction section, and the URL would become https://example.com/blog/nice-post/#introduction. This URL can be shared and when opened in a browser, the page will automatically scroll to the introduction section.

Accessibility check

Of course, I wanted to make sure the anchor links I had written were accessible. I turned on VoiceOver (a screen reader for MacOS), and using caps lock with arrow keys to interact with the page's content, I moved to my section heading. I found a few issues. Below is the first version of my anchor link:

<h2 id="introduction"><a href="#introduction">#</a>Introduction</h2>

When the <a> element is inside the <h2>, VoiceOver reads out "heading level 2 2 items, visited, link number introduction". A screen reader user who wanted to skip across multiple headings at once would have a nicer experience if they only heard the actual heading text (i.e. "introduction").

I realised the <a> element should exist as a sibling of the heading element, rather than a child of it. This is so that the <h2> text content remains clear. Below is the second version of my anchor link:

<a href="#introduction">#</a>
<h2 id="introduction">Introduction</h2>

When the <a> element is outside the <h2>, VoiceOver reads out "link number" for the <a> and "heading level two introduction" for the <h2>. This is a problem, as the elements are not associated with each other in any way.

Associating anchor links with what they link to is important. Some anchor links I found on a popular site have SVGs with no labels or titles as content. When there is no information about a link available, the screen reader falls back to the href value (e.g. https://example.com/blog/nice-post/). This makes the purpose of the link hard to decipher.

I realised I needed to better associate my section headings with their anchor links. Below is the third version of my anchor link:

<a aria-label="link to this heading" aria-describedby="introduction" href="#introduction">#</a>
<h2 id="introduction">Introduction</h2>

The attributes I added are aria-label and aria-describedby.

The aria label is read out by a screen reader in place of whatever child the <a> element has. This is necessary for anchor links, as these links often have a single character as text content. One alternative is to describe the link using text content, but visually hide it (hint: I removed this attribute in a later version of my anchor link - refer to the fifth version).

The aria describedby matches the id of the <h2>. When the link is focused, "link, link to this heading" is read out, followed by "introduction". This is much better, but there could be one more small improvement—having the heading before the link (hint: I removed this attribute in a later version of my anchor link - refer to the fifth version).

I realised that my anchor links would make more sense if the heading came before the link. Below is the fourth version of my anchor link:

<h2 id="introduction">Introduction</h2>
<a aria-label="link to this heading" aria-describedby="introduction" href="#introduction">#</a>

VoiceOver reads the <h2> out as "heading level 2 introduction" and the <a> as, "link, link to this heading, introduction". When the heading is first, screen reader users may be able to associate a section heading more easily with its corresponding anchor link.

While I made great progress by the fourth version of my anchor link, there are final some outstanding issues that I wanted to address. Thanks to my friend Kitty for helping me realise these outstanding issues. Be sure to keep up to date with Kitty's current A11y Advent Calendar and check out their other great posts.

First, aria-label is not actually brilliant for accessibility, as some translation services can have trouble accessing its value. So, it's best to add text content to the <a> element, and make sure to visually hide it. This way, screen readers can still access it but it'll be visually hidden for other users. Second, the # can be left in and hidden from screen readers using aria-hidden, while still being visible on the page.

Lastly, I removed aria-describedby because the anchor link's text content now references the section heading.

Here is the fifth version of my anchor link:

<h2 id="introduction">Introduction</h2>
<a href="#introduction">
  <span aria-hidden="true">#</span>
  <span class="hidden">Section titled introduction</span>
</a>

This fifth and final version of my anchor link is the one I am using on this page, along with a wrapper <div> for styling purposes. It is much better than the first version! However, if you can think of improvements, please let me know.

A word of caution

Edit (17th December): Beware, there be dragons! I realise that including a link (that has its own text content) as a child of a heading may seem tempting (as it can make styling an anchor link easier). However, it's worth repeating that this can harm accessibility.

Version one of my example anchor link (see accessibility check) introduces the issues caused by placing a link inside a heading, but I want to provide some more context to why it is not a good idea! I'll do this by describing a handy feature of VoiceOver.

VoiceOver (and likely also other screen readers) gives a nice overview of a page's section headings. This feature, called the web rotor, is accessed by default by pressing caps lock + u while VoiceOver is on. Below are two screenshots of the web rotor comparing how headings are formed, depending on whether a link is inside or not:

VoiceOver web rotor displaying headings containing links

VoiceOver web rotor displaying headings without links

If a link that has its own content is placed within a heading, the computed heading text may be more difficult for a screen reader user to understand. This can affect how clear a page's structure is.

Another option

Edit (18th December): Despite warning against the following option above, I want to write about making a whole heading into an anchor link. Or, more specifically, wrapping the heading text content in a link. Several people across different sites have asked me why I didn't mention this option before:

Interesting reading but why do you need the # symbol in the HTML at all?

Why not just make the whole heading the link (easier clicked too!) and use ::before or ::after to put the symbol there through CSS? https://t.co/ecaDkZjJH0
— Barry Pollard (@tunetheweb) December 15, 2020

I think both options—using an icon as a link, and making the header a link (when the content of the link is the heading text)—can be valid. However, I have a few concerns with wrapping a heading's text content in a link:

It can be useful separate the anchor link from the heading so that the link can have its own text content
It may be harder to select heading text wrapped in a link
Both screen reader and non-screen reader users may find this option less familiar and not understand its purpose

Here are two examples of sites that implement anchor links where a link wraps the text content of a heading: MDN Web Docs and The Web Almanac.

Here is a code example of an accessible anchor link where a link wraps the text content of a heading:

<h2 id="introduction">
  <a href="#introduction">
    Introduction
  </a>
</h2>

Would you rather implement anchor links in this way? It is a simpler solution. However, it is also less flexible.

Of course, the way a feature is implemented depends on your own personal use case. But, no matter which way you implement something, please remember to think of the user experience!

Automating accessible anchor links

I use Eleventy together with markdown-it to convert my markdown files into HTML files.

I tried finding a plugin that would help me to automate the addition of anchor links for all my <h2> elements. I did find one but soon realised it didn't make accessible links possible. So, I decided to make my own plugin.

There is handy markdown-it developer documentation for people wanting to create plugins. Using these docs, a markdown-it demo page, and some inspiration from a plugin called markdown-it-anchor, I wrote a plugin.

Here is a permalink to my plugin file. It recreates parsing functions for opening and closing <h2> elements from the markdown-it library. In my eleventy.config file, I use (connect) the plugin with markdown-it. This allows me to automatically add custom anchor links for all my level two headings.

Continued discussion

A few people have been inspired by this post and one of them is Nicolas Hoizey. In February 2021, Nicolas created an issue in markdown-it-anchor's GitHub repository, hoping the maintainers would consider making changes.

What followed was a really good discussion among several people, kicked off by Valérian Galliat, regarding the solution I decided on in this blog post. I definitely recommend reading through the comments because there are some great nuggets of information about accessibility in there!

Here are some criticisms of the approach to accessible anchor links that I took in this blog post:

The text hidden with CSS creates a large gap between heading and paragraphs in Firefox reader mode. However, this could be seen as a reader mode limitation.
There is an SEO concern that text usually hidden with CSS shows up in descriptions of posts in Google. However, anchor links will most likely not being reported as illegitimate content.
Text usually hidden with CSS also shows up in RSS readers.

Some suggested that aria-label could be used to offer accessible text without the need for aria-labelledby. Kitty reminded us that aria-label is notoriously bad with content translating services such as Google Translate.

I learned a lot from the discussion. I still think there is not really a silver bullet to creating accessible anchor links that would suit everyone. There are quite a few ways to approach it, each with their own advantages and disadvantages, based on things like browser support, screen size, screen readers, and more.

However, Barry Pollard made a good point. His idea is that there are several advantages to making headings into links themselves. I would be happy to use this approach on my own site. Try to hover or focus a heading on a Web Almanac post to see the approach first hand.

What do you think? I'd love to know if you have any ideas. If so, please comment on the GitHub Issue!

Grow the IndieWeb with Webmentions

Tue, 08 Dec 2020 24:00:00 GMT

When I re-made my site with Eleventy, the pages didn't change much, but I had loads of fun adding new features. The most fun was webmentions and I'm here to convince you to add them!

First, let me step back and explain why webmentions exist—the IndieWeb.

IndieWeb

Check out this official description of the IndieWeb:

The IndieWeb is a community of individual personal websites, connected by simple standards, based on the principles of owning your domain, using it as your primary identity, to publish on your own site (optionally syndicate elsewhere), and own your data—indieweb.org

So, a community of personal websites, connected together, used as identities, that makes ownership of data possible. 🦄 🌈 How does this all work?

There's a great IndieWeb resource that will tell you everything you need to know
But, start here if you want to know why the IndieWeb deserves your attention
When you're convinced, see this handy page for a quick start to becoming a citizen of the IndieWeb
International IndieWebCamps are here to help—I wrote a post about my first IndieWebCamp visit
Nürnberg IndieWebCamp 2017 (I'm in the bottom right)

Webmentions

Now the juicy stuff!

I think the coolest thing about the IndieWeb is that it is decentralised. Currently, there is a handful of corporations that own much of our data. With webmentions, each person owns their own data and each person can communicate with others. Webmentions are basically a way to display on your personal site ways that others have interacted with your content.

On my site I display mentions and bookmarks. It's possible for someone to link to one of my blog posts within one of their blog posts or bookmarks. If they do this, I won't know about it unless they let me know about it. Letting others know you've mentioned their posts can be done manually or can be automated.

I also display likes, retweets and replies on blog posts that I have tweeted about. If the URL to my post is in my tweet, I can gather the interactions on that tweet and display them on that post. Although most social media platforms do not support webmentions, it's possible to gather them by using a great free service called Bridgy.

Some people have had webmentions on their site for many years, so I am a bit behind. Jeremy has had webmentions since 2013. But, there are more people posting content online than ever before, and personal websites aren't shown the love they used to get.

So, there has never been a more pressing need to put content creation platforms (e.g. Medium) and social media platforms (e.g. Twitter) second, and put your very own little corner of the web first 💖

I used Max Böck's post on using webmentions in Eleventy to get started. I was able to get something on the screen quickly with Max's advice, and then I refined the incoming data a bit. Here is a summary of what I did:

Sign up via Webmention.io - if this doesn't work right away, check out ways to set up your website for indie logins (I'm able to sign in by linking to my GitHub account on my site's homepage)
Add two <link> tags to your HTML document's <head> element: <link rel="pingback" href="https://webmention.io/{your-domain-here}/xmlrpc"> and <link rel="webmention" href="https://webmention.io/{your-domain-here}/webmention">
For social media mentions, sign up to Bridgy
Fetch all of your site's webmention data in JSON format using one of the webmention endpoints described by IndieWebCamp co-founder Aaron Parecki and the API token provided by Webmention.io
Shape your webmention data however you like - I filter webmentions into separate re-tweet, reply, like, mention, and bookmark functions using the 'wm-property' (check out the filter functions and before you say anything, yes I know they could be DRYer)
Use the data to display webmentions on your blog posts

Here are some of my webmentions (from my Gatsby to Eleventy post):

If all of this seems too difficult and inaccessible, please don't give up! I thought getting webmentions on my little static site would be way too difficult. But there are so many wonderful posts about setting up webmentions, and so many great people willing to help. I count myself as one of those people :) If you want to implement webmentions on your site and are stuck on any of the points I listed above, ping me on Twitter and I'll do my best to help out.

From Gatsby to Eleventy

Fri, 20 Nov 2020 24:00:00 GMT

In this post I'll compare my experience building my personal blogging site (the one you're on now) with two static site generators (SSGs) - Gatsby and Eleventy.

The first version of my site was rolled out with Bootstrap CSS and no framework, the second and third used SCSS and again no framework. The fourth version was built with a popular static site generator (SSG) called Gatsby. This SSG uses React and GraphQL. My learning curve from using no framework to using Gatsby was not huge though, as I use React and GraphQL at work.

The fifth, and at the time of publishing this post, current, version of this site uses a static site generator called Eleventy. I was a bit daunted about using this SSG, because the tools I was used to working with all day weren't baked in. This meant no default React, or GraphQL. This SSG would be a new paradigm for me to learn from scratch. I'd have to pick a templating language I had never used before, and learn how Eleventy manages data. Even so, there were a number of reasons I wanted to move from Gatsby to Eleventy.

Firstly, I'll summarise the reasons that I decided to use Gatsby in the first place. It lets people write React, takes care of a lot of performance concerns for you, and has a lot of good starter templates. So, it's excellent for getting started quickly, getting a reasonably good site created, and offers a good developer experience. This was a big pull for me, in addition to all the hype it was creating a few years ago, and the fact I could already use its baked-in tools. Also, the fact I could have my very own, nice and shiny single page app (SPA) was a plus for me, at the time.

Gatsby sounds really good, so why did I move to Eleventy? This is a question I've put a lot of thought in to. First, I want to explain that I didn't add any new features to the site between the Gatsby and Eleventy versions. The only thing that changed is that now, all the learn posts have their own page, instead of existing on one page.

Benefits Gained

As my Eleventy site outputs a non-SPA, I didn't need to check or ensure that it is server-rendered, is able to be crawled by search engines to allow good search engine optimisation (SEO), or works without JavaScript. Non-SPAs do all of this by default.
A number of Gatsby plugins stopped some of the functionality on my site working. For example, Gatsby's progressive web app plugin caused my server-side rendering to stop working.
My site is a personal blog site that does not have thousands of users or masses of data. So, I don't need to make sure I'm saving on bandwidth or server resources. If I did need that, I would consider creating a SPA, as they tend to request fewer server resources across page views, compared to non-SPAs.
I don't need to force users to download large chunks of React library in their browsers. Gatsby by default forces this, and requires a plugin to ensure that React is only used on the server.
I didn't need to bother code-splitting any React components to ensure users aren't downloading my whole site on initial page load.
I was able to gain more control over performance optimisations such as image rendering. When I first released my Gatsby site, I used their image plugin but ended up disliking several things about it, such as styling inflexibility, and inability to use the <picture> element.
I know enough about web development that I can write performant code on my own. Therefore, I can do without plugins that enhance performance, but don't make it clear how they do so. Also, I prefer using my own skills to create things wherever possible, as it teaches me how things really work.
I could pick and choose what JavaScript is necessary in the client (browser), thereby limiting the size of the JavaScript a user needs to download. The only JavaScript my site needs on the client-side is for the dark mode toggle, the blog search input, a tiny (and privacy-first) analytics tool, and some linked data (JSON-LD) for SEO.
By writing lower-level template code (Nunjucks vs JSX), I felt like I had more control over the generated code, which allowed me to output better and more consistent HTML.
Gatsby has GraphQL baked in. For a lot of use cases, especially a personal blog site, GraphQL is overpowered and can be a large learning curve for some.

Challenges Faced

Eleventy is newer and maintained by less people than Gatsby. Therefore, I felt that Eleventy is a bit less feature-rich and has less documentation. Although honestly, this isn't a huge deal. Firstly, I found Eleventy simpler to use (less abstract), and found the documentation covers all the most important aspects of the SSG. Secondly, almost any time I needed extra help or information, I found it in the form of excellent blog posts or example repositories created by other web developers.
One of the very few issues I couldn't find help with was the sharing of one type of data (blog post excerpts) across my Eleventy-powered site. Gatsby, along with React, makes it easy to see what data is being shared and how. Eleventy has a fantastic data-sharing API (in my case the data sharing was orchestrated between Nunjucks and the Eleventy config file). However, I found it to be quite abstracted and struggled a lot trying to get my blog post excerpt data to be easily shared across pages. In the end, I created a workaround for this, but this workaround is quite hacky. I plan to write about it in a separate post.
I had to learn how to use the Nunjucks templating language. This is only a small nitpick, as the learning curve was in no way steep.

Concluding Thoughts

Using Gatsby has taught me a lot about single page apps, and that's important! Sometimes using it was frustrating, and a few things broke without me realising why or even when, but these experiences can be good lessons. Also, I am employed to work on a large SPA, and probably will continue to work on SPAs professionally for years to come, so any experience working with them is good!

I believe it is a good idea to use the least-powerful technology possible for any given task. Building with Eleventy made this possible for me. I find React and GraphQL nice to use, and I was daunted at the thought of not being able to use JSX. But, using simpler and lower-level tools such as Nunjucks made me feel more confident about my site's output (robust HTML and the least JavaScript possible), and I enjoyed the experience much more than I thought I would.

Please don't take what I've written here as a reason not to choose Gatsby over Eleventy. I chose to re-write my site in Eleventy for several reasons. I have the knowledge to build in performance and accessibility myself, I realised I didn't need an SPA for my use case, and I wanted to use simpler, less powerful developer tools. I think developers should use the tools that suit them best. There is only one thing I want to encourage you to do: no matter what tools you use, please pay attention to your site or app's final output! It's never a good idea to make users pay for your technology choices.

Caches are for Copies

Wed, 11 Nov 2020 24:00:00 GMT

When someone uses their browser to visit your website, the browser fetches files from your website's server. One example could be a CSS file. Once the CSS file has been fetched, the browser can cache (store) a copy of it. This means that, as the visitor browses your site, the CSS does not need to be fetched once again from the server.

The advantages of caching a file are: one less network request per page load, less use of the visitor's internet data, and faster load times. Additionally, CSS is a blocking resource. This means that while it is being fetched and loaded, other files have to wait to be loaded. So, the quicker CSS can be loaded, the quicker a visitor can enjoy your site.

It is important to note once again that the files cached by the browser are copies. This means that if a file living on your server is updated, the browser might not know about it. Therefore, a visitor might get the outdated copy of that file, rather than the updated one. The file will still load fast, as it is coming from the browser cache, but it will be outdated.

How do servers manage files?

The server you're using to serve your website determines which of your site's resources are cached, and how they are cached. There are many different server options available. For the rest of this post, I'll talk about the one hosting the post you are reading - Netlify.

Netlify has default cache settings. This means that with no effort on my part, I can write my website, deploy it, and share it without needing to worry about configuring cache settings. There is a blog post about Netlify's default cache settings entitled "Better Living Through Caching".

I briefly mentioned earlier the issue of getting an outdated file from the cache. Netlify admit that "cache invalidation is one of the hardest problems in computer science" and that they have found a way around this issue:

“max-age=0, must-revalidate, public” = “please cache this content, and then do not trust your cache”. This seems a bit counterintuitive, but there’s a good reason. This favors you as a content creator — you can change any of your content in an instant.

So, no visitors will be served outdated files. However, all files are re-requested on every single page load. This would be no good, except that Netlify uses "e-tags". These are hash values (long strings of unique characters). The server and browser share the e-tags. If a file changes on the server, for example a CSS file, the e-tag value changes, the browser notices, and the changed file is requested.

Additionally, Netlify makes the constant checking of files faster using their CDN (content delivery network) and HTTP/2. Please look up these two things, as discussing them is beyond the scope of this post.

Trust, then verify

It is a really nice thing in modern web development to be able to enjoy stuff done for you automatically by your browser and server. This doesn't mean that you shouldn't know how it all works, though.

If a server such as Netlify offers default cache settings, it pays to look up what they are, and how they work. A server's default cache settings are unlikely to be the best for every website.

If it is necessary to change cache settings for your website, look up how to manually create your own settings. Here is a post on how Netlify users can set custom cache headers.

Accessible Link Text

Thu, 05 Nov 2020 24:00:00 GMT

I use a bookmarklet tool called Tota11y, which gives me a quick overview of my site's accessibility. I opened it on my site's homepage and clicked "link text". The tool flagged not one, but SIX inaccessible links. Woops!

The homepage, GitHub, Twitter, and LinkedIn links were all flagged for the same reason. There was no text between their opening and closing <a> tags, only an SVG. Even though the tool flagged these links, I didn't have to change anything. This is because each SVG already had a <title> element, paired with a <description> element to aid accessibility. A screen reader will read out the values of the title and description elements.

I was a bit confused why the 'learn' and 'about' navigation links were flagged, so I checked Tota11y's source code. The words 'learn' and 'about' are listed as stop words. I believe these words are singled out because they can be used alone or out of context. However, I think that both words make sense in my navigation bar. So, I ignored the warning.

I was happy that I didn't have to add any new code in order to make the six flagged links accessible! If an accessibility audit flags any links on your site, and you determine that they are in fact inaccessible, there are a few things you can do.

One method is to add a <span> next to the existing text that is hidden (this post describes a method for visually hiding text using CSS). This would make the text invisible in the UI, but a screen reader would still read it out.

Another similar method is to add more descriptive (non-hidden) text to links, just as I have done for the link in the previous paragraph.

The most common method is probably the aria-label attribute. This is popular because the value of this attribute is read out by a screen reader even if the link already has text. For example, for my 'project' link, I could have added aria-label="a selection of my projects".

A screenshot of the VoiceOver for Chrome screen reader announcing the aria-label of the 'projects' link

Note 1 of 2: please see this post on aria labels for the important difference between aria-label and aria-labelledby (hint: aria-label values are not always easy for translation systems to access).

Note 2 of 2: try to use a variety of accessibility tools to audit your web pages. It isn't possible to catch all accessibility issues with one tool. It's also probably not possible to catch all issues with ten of them. Manual testing is highly recommended! By that I mean using a screen reader and keyboard to tab around your web pages.

More resources

From Office to Remote (During a Pandemic)

Thu, 10 Sep 2020 24:00:00 GMT

Background

I wanted to write my thoughts on remote working as I enter my sixth consecutive month of it. This remote working situation I am in is special because it was not a personal choice, nor would it have been allowed by my company under normal circumstances. As you may have guessed, I am working remotely due to the global corona virus pandemic. Before mid-March of the year 2020, for 5 days each week I travelled to the office, worked there for eight hours, then travelled home.

In the ~12 years since my first ever job, I've never worked remotely 100% of the time. Until two years ago, I'd never worked a single day remotely (I became a web engineer around three years ago).

I want this post to compare my experience working as a web engineer in an office versus working as a web engineer remotely. I want to note that while I was still working in the office, I had the occasional (once every one or two weeks) work-from-home day. However, I have found that this is not comparable to working from home 100% of the time.

Comparisons

I hear a lot about companies that have always been remote, or have been for a long time. Most of these companies seem really happy, and say great things about working remotely! I can't tell whether the experience of working in a team that has always been remote versus working in a team that pivoted incredibly fast to working remotely during an emotionally-straining global pandemic is similar. I have a feeling it is not, but I can only guess at that.

For me, the there are some quite strong comparisons between my experience of working in an office, versus half a year of remote working. Some of these lean towards being negative. I'll mention these first so that I can talk about the happier, more positive things I have gained from the experience, and what I would like to see in the future.

Minus points

The first couple of months into remote work, my new working situation was still a novelty and I didn't have many things to say against it. Half a year in, I am finding that the biggest challenge is the lack of socialising with my colleagues. I can be quite introverted and can get exhausted when lots of people are around me for an extended time. However, I do thrive on meaningful social interactions. Things that I am personally really missing include lack of day-to-day interactions, physical meetings (versus switched-off cameras/staring at screens), and team activities.

Due to all of this, the way my team works feels more "fragmented" to me, although it's hard to explain exactly what I mean by this. I feel like it's a shame that we can't really share small coding victories, or voice sponteneous ideas to each other. I worry that my team members and I are less able to improve on our professional development, whether from lacking opportunities for informal feedback or being less able to share our needs/wants with each other and get advice.

To be clear though, I still think my team works really well together and we are still getting features out, making fixes, and moving along with projects at a similar speed to before. I also personally feel like I am still learning a lot, particularly because without a neighbour to ask, I have been solving more problems by myself.

Plus points

As mentioned in the previous paragraph, I am learning more, becoming a more independent web engineer, and am still able to work as fast (sometimes faster!) than before. Not having to commute any more (which took away 1,5 - 2 hours of my day) is one thing that helps me finish work faster and remain a lot more focused. Also, I can start work earlier if I feel like it, which also means I can finish earlier if I need to.

If I am struggling with a code issue, or I am stressed, or I really need a break, I can go and take one. And the break can be in any form I want. I can either take a nap, look at my phone, have a snack, go for a walk, chat with someone outside of work, etc. Ok, so I can do all but one of those things (napping) in an office, but I can do them at my own pace and without being disturbed or feeling pressured to go back to work within a certain time frame. Taking these breaks has helped me solve coding problems and made me much less stressed in my general life.

My work-life balance has improved a lot due to the removal of a long and often stressful commute, and being trusted to work and get features completed without feeling pressured to appear like I am working. I feel more like I can conduct both my work and life on my own terms. In the last six months as a web engineer, compared to the last three or so years, I am generally calmer, more focused, and less anxious during working hours and non-working hours, thanks to working remotely.

The future

I can't tell how working remotely during a pandemic is going to feel after another six months. I haven't read anyone else's take on this subject, so I am writing blind here. So then, if asked the question whether I would want to continue working remotely in the future, or join a fully-remote company in the future, what would I say? I think I'd say... "Yes"! But, to continue working remotely I'd want some conditions to be in place. Most importantly for me, I would want a strong team event calendar to be in place. Or some way for the team to bond.

Team bonding is definitely harder during a pandemic but not impossible. For example, in the past six months that I have been working from home, I've attended three remote team event evenings (where we played online games or simply chatted), an in-person meetup with my immediate team, and will soon meet up outside with a few team members to go on a socially-distanced guided tour of Berlin.

I've looked forward hugely to each of the few team events I've been a part of since working remotely, although they have all necessarily been quite short, or remote. I look forward to a time when me and my team members can meet for longer periods of time again, like going on a whole-day offsite with the web team. Anything to help my team and I feel more connected!

Make Your Own Dev Tool

Wed, 19 Aug 2020 24:00:00 GMT

Bookmarklets - a cool personal dev tool

I have just found out what bookmarklets (aka favelets - a term coined by my friend Tantek back in the early 2000s) are and I like 'em! So what are they?

Bookmarklets run a JavaScript (JS) script against the DOM of the current document loaded in the browser. They allow a way to alter the DOM at the press of a button. They may not offer all that a browser extension or add-on can, but they can still be super handy, and also do not require downloading or installation of software.

What's a nice example of a bookmarklet? Here is a nice accessibility bookmarklet called Tota11y to try out! Thanks to Jeremy for showing me this one 👍

How can a bookmarklet like Tota11y be used? First, the bookmarklet's link needs to either be saved as a bookmark, dragged into the browser's bookmark toolbar, or be available to be clicked on a web page (used as a normal link within an href attribute in an <a> element). Second, while on a valid website, the bookmark containing the bookmarklet link should be clicked to run the bookmarklet's code.

How bookmarklets work

First you should know (or be reminded) that in a browser, bookmarks are made up of URIs (uniform resource identifiers). Each URI consists of a protocol such as http:, https:, file:, etc., which is followed by a string. An example is https://cat-bounce.com/. The https: is the protocol, and the string is the domain.

There is also a javascript: protocol. The browser treats this protocol and its following string just like a JS application. When visiting a link that is using this JS protocol, the JS code it contains is executed. If such a link is bookmarked, it is called a bookmarklet!

Something to note is that a link usually works by sending the user to a new page. To prevent a bookmarklet from triggering a page reload, the JS code that makes up the bookmarklet should return an undefined type. To do this, an anonymous, self-executing function can be used (i.e. one that does not return a value, doesn't have a name, and executes immediately).

The Tota11y bookmarklet example has a link that points to a hosted JS file. This is because the link would be pretty messy if all the JS code was included as a single string within it. Below is what the Tota11y bookmarklet's link (in a beautifed format for readability) looks like:

javascript:
  (function()
    {
      var tota11y=document.createElement('SCRIPT');
      tota11y.type='text/javascript';
      tota11y.src='https://khan.github.io/tota11y/dist/tota11y.min.js';
      document.getElementsByTagName('head')[0].appendChild(tota11y);
    }
  )();

In order for a bookmarklet to point to a hosted JS file, its URI needs to contain a few things. At the very least,it should create a new script element, make this element's source (src) the hosted JS file, and then append this script to the head of the document.

Making your own bookmarklet

I tried making a bookmarklet and found it was really easy to get started.

I decided that I'd try something really simple that does not use a hosted JS file, but contains all the JS code in one line. So I made a bookmarklet to put a red border around each paragraph on a page. Here's what it looks like:

javascript: 
(function(){
    let paragraphs = document.getElementsByTagName('p');
    for (let i=0; i < paragraphs.length; i++){
      paragraphs[i].style.border = '3px solid red';
    }
  })();

As mentioned in the previous section, "How bookmarklets work", a bookmarklet can be made available to use as a link. To do this, the bookmarket's URI is placed inside the href attribute of an <a> element, that can then be dragged into bookmarks or the bookmark toolbar.

If you like, try either clicking the following link, or drag it into your bookmarks and click on the resulting bookmarklet (refresh the page to remove the effects)!

Paragraph border maker

Here is the code that makes up the above link:

<a href="javascript:(function(){let paragraphs=document.getElementsByTagName('p');for(let i=0;i < paragraphs.length;i++){paragraphs[i].style.border='3px solid red';}})();">
  Paragraph border maker
</a>

Some things to note

A browser will automatically encode any characters within a URI that it does not understand (such as quotation marks, spaces etc.) so that a bookmarklet can run smoothly.

As bookmarklets contain JS, there are security concerns to be aware of when using bookmarklets created by others. However, making a few of your own bookmarklets for personal use, or using ones that have been shown to be trustworthy, is fine. More than fine - it's great!

Why are bookmarklets so great? You can make a separate folder for your bookmarklets within your bookmarks folder. Then you can place this bookmarklets folder in your bookmark toolbar for your own list of easy-access, personal dev tools.

Sometimes browsers may cache bookmarklet code, so changes made after it is added won't show up.

Check out this nice video on bookmarklets (Chrome-focused) that covers what I have written about in the "Making your own bookmarklet" section.

I am completely new to bookmarklets so I may not have covered every essential thing regarding them. I really found them super easy and nice to get started on though. As usual I learn more about them as I keep trying them out!

In a Land Before Dev Tools

Wed, 05 Aug 2020 24:00:00 GMT

A long, long time ago in a land before dev tools, there lived all of its predecessors. These ancestors were more basic and didn't offer the wealth of tools we enjoy today. But, they certainly paved the way!

The beginning

How could developers view code in their browsers in the early nineties?

They could check out view source (see how to open view source here).

They could place alert() boxes throughout their code to test JavaScript. This wasn't great though, because alerts cannot display complex objects like functions. Also until the alert box(es) are gone, no other tabs or windows can be used.

Some got into the habit of commenting out code and then uncommenting it, to see if there was any difference in outcome.

It seemed like there was work to do...

The middle

Later in the nineties, a better way to debug HTML came along in the form of this live DOM (document object model) viewer page by Hixie. The page doesn't seem to working currently. When working, any HTML entered into the first text area is parsed and appears in a visual DOM tree right underneath. Slightly further down it shows the rendered view.

Being able to see the DOM was a really important step to understanding how browsers interpret HTML. In the early 2000s, there were a number of people working on tools to improve the useful ability to visualise the DOM, in addition to CSS and JavaScript.

One of these tools, named Firebug, gained quite a bit of ground. First released in 2006, it existed as an addon (plugin) offered within the Firefox browser itself. The addon served as an extension to its browser software (first released in 2002). To learn more, see this blog post on Firebug. On this page, there are links to videos that offer a peek at what Firebug was like to use.

Only a few days after Firebug's release came Web Inspector. This was bundled directly into the Safari browser. Check out a picture of Web Inspector here. This tool also offered the ability to debug HTML, CSS, and JavaScript!

By 2010, the Chrome browser (released in 2008) had added the ability to right click a page, choose "Inspect element", and open dev tools.

From the early 2010s onwards, browser dev tools went from strength to strength. Things like remote debugging of mobile devices, performance panels, and audit panels (plus a lot more) were added. Nowadays, even Node.js can be debugged in dev tools.

The end

Ok so don't worry, there is no end in sight to the dev tools story!

Who knows what developer tools will look like in the future? Almost two decades since these tools first began to appear, major browsers are still actively developing them. And, there is no standards body dictating what the tools should do. This means browser makers are pretty much free to add to their tools whatever they like. When and what is added depends quite strongly on what the browser makers' priorities are.

Some web users choose a browser based on whether their own values line up with that browser's priorities. For example, any one browser might lean more towards offering more security to its users, becoming more performant, or more accessible etc. That's a topic for another blog post though…

Custom Property Coverup

Wed, 22 Jul 2020 24:00:00 GMT

The other day I was discussing CSS custom properties with Jeremy when I noticed something. When using custom properties, some (but not all) of the custom property values do not show up in the computed values in Chrome dev tools. Jeremy tried the dev tools in Firefox and found the same thing. However, when the same values declared as custom properties are declared as regular CSS properties, the values show up in the computed values section.

Neither of us had noticed this behaviour before and we were both a bit baffled. Why would the makers of these dev tools purposefully leave out some of the CSS custom property values from the computed values section while the same values declared without custom properties are shown?

It should be noted that computed custom properties can be shown in dev tools by toggling on browser styles. However when toggled on in this way, the custom property values are not interactive. And, more importantly, custom property values are not browser styles.

I made a reduced test case in Codepen to show how custom properties are treated by browser dev tools.

The test case has three divs - one not using any custom properties, one using some custom properties, and one using only custom properties. Each div has exactly the same styles. Below is what the computed styles section in Chrome, Firefox and Safari dev tools shows for each div (skip to next paragraph).

Calculated Custom Property Results Per Browser (Chrome, Firefox, Safari)

Chrome

Chrome - no custom properties:

background-color:rgb(198, 255, 133);
border-bottom-color:rgb(0, 128, 0);
border-bottom-left-radius:15px;
border-bottom-right-radius:15px;
border-bottom-style:solid;
border-bottom-width:5px;
border-left-color:rgb(0, 128, 0);
border-left-style:solid;
border-left-width:5px;
border-right-color:rgb(0, 128, 0);
border-right-style:solid;
border-right-width:5px;
border-top-color:rgb(0, 128, 0);
border-top-left-radius:15px;
border-top-right-radius:15px;
border-top-style:solid;
border-top-width:5px;
color:rgb(3, 3, 3);
display:block;
height:100px;
margin-bottom:10px;
padding-bottom:20px;
padding-left:20px;
padding-right:20px;
padding-top:20px;
width:200px;

Chrome - some custom properties:

background-color:rgb(198, 255, 133);
color:rgb(0, 0, 0);
display:block;
height:100px;
margin-bottom:10px;
padding-bottom:20px;
padding-left:20px;
padding-right:20px;
padding-top:20px;
width:200px;

Chrome - only custom properties:

background-color:rgb(198, 255, 133);
color:rgb(0, 0, 0);
display:block;
height:100px;
width:200px;

Firefox

Firefox - no custom properties:

background-color: rgb(198, 255, 133);
border-bottom-color: rgb(0, 128, 0);
border-bottom-left-radius: 15px;
border-bottom-right-radius: 15px;
border-bottom-style: solid;
border-bottom-width: 5px;
border-left-color: rgb(0, 128, 0);
border-left-style: solid;
border-left-width: 5px;
border-right-color: rgb(0, 128, 0);
border-right-style: solid;
border-right-width: 5px;
border-top-color: rgb(0, 128, 0);
border-top-left-radius: 15px;
border-top-right-radius: 15px;
border-top-style: solid;
border-top-width: 5px;
color: rgb(3, 3, 3);
height: 100px;
margin-bottom: 10px;
padding-bottom: 20px;
padding-left: 20px;
padding-right: 20px;
padding-top: 20px;
width: 200px;

Firefox - some custom properties:

background-color: rgb(198, 255, 133);
color: rgb(0, 0, 0);
height: 100px;
margin-bottom: 10px;
padding-bottom: 20px;
padding-left: 20px;
padding-right: 20px;
padding-top: 20px;
width: 200px;

Firefox - only custom properties:

background-color: rgb(198, 255, 133);
color: rgb(0, 0, 0);
height: 100px;
width: 200px;

Safari

Safari - no custom properties:

background-color: rgb(198, 255, 133);
border-bottom-color: rgb(0, 128, 0);
border-bottom-left-radius: 15px;
border-bottom-right-radius: 15px;
border-bottom-style: solid;
border-bottom-width: 5px;
border-left-color: rgb(0, 128, 0);
border-left-style: solid;
border-left-width: 5px;
border-right-color: rgb(0, 128, 0);
border-right-style: solid;
border-right-width: 5px;
border-top-color: rgb(0, 128, 0);
border-top-left-radius: 15px;
border-top-right-radius: 15px;
border-top-style: solid;
border-top-width: 5px;
color: rgb(2, 2, 2);
display: block;
height: 100px;
margin-bottom: 10px;
padding-bottom: 20px;
padding-left: 20px;
padding-right: 20px;
padding-top: 20px;
width: 200px;

Safari- some custom properties:

background-color: rgb(198, 255, 133);
border-bottom-color: rgb(0, 128, 0);
border-bottom-left-radius: 15px;
border-bottom-right-radius: 15px;
border-bottom-style: solid;
border-bottom-width: 5px;
border-left-color: rgb(0, 128, 0);
border-left-style: solid;
border-left-width: 5px;
border-right-color: rgb(0, 128, 0);
border-right-style: solid;
border-right-width: 5px;
border-top-color: rgb(0, 128, 0);
border-top-left-radius: 15px;
border-top-right-radius: 15px;
border-top-style: solid;
border-top-width: 5px;
color: rgb(0, 0, 0);
display: block;
height: 100px;
margin-bottom: 10px;
padding-bottom: 20px;
padding-left: 20px;
padding-right: 20px;
padding-top: 20px;
width: 200px;

Safari - only custom properties:

background-color: rgb(198, 255, 133);
border-bottom-color: rgb(0, 128, 0);
border-bottom-left-radius: 15px;
border-bottom-right-radius: 15px;
border-bottom-style: solid;
border-bottom-width: 5px;
border-left-color: rgb(0, 128, 0);
border-left-style: solid;
border-left-width: 5px;
border-right-color: rgb(0, 128, 0);
border-right-style: solid;
border-right-width: 5px;
border-top-color: rgb(0, 128, 0);
border-top-left-radius: 15px;
border-top-right-radius: 15px;
border-top-style: solid;
border-top-width: 5px;
color: rgb(0, 0, 0);
display: block;
height: 100px;
padding-bottom: 20px;
padding-left: 20px;
padding-right: 20px;
padding-top: 20px;
width: 200px;

↑ Back to the top

Why do browsers differ?

Interesting! Why is it that Safari shows all the custom properties in the computed styles list? I am not sure. In Safari they are also interactive. Clicking a computed style directs you to the location of the style and allows you to edit it in the dev tools. This is not the case in Chrome or Firefox.

Does anyone know why this is?

Where did the focus go?

Wed, 17 Jun 2020 24:00:00 GMT

There was a bug in some of my code recently. A skip link was not working correctly. When it was focused and enter was pressed, focus was placed on the main content. Seemed okay. But, when tab was pressed to go into the main content, the focus went off to some place I could not see! I spent a few minutes trying to figure it out but could not. Then, I searched for how to programatically find focus. I found I could log document.activeElement into my console to do this.

You can log the document's active element in any browser console by placing a console.log into your JavaScript code. See the code block below for how to do this (thanks to my friend Eva for teaching me this):

document.addEventListener('focusin', function() {
  console.log('focused: ', document.activeElement)
}, true);

Below is an image showing what such a log looks like in Firefox. It shows that the first element focused when I opened the page was a div. When I moved focus to the light/dark mode toggle, the focused element was an input:

In Chrome there is a live expression tool for logging the document's active element. The following two images show examples of this tool in action.

There are two things to note:

Ensuring focus is handled correctly is important for the accessibility of a web page. However, focus behaviour is not always consistent across browsers. If you're developing something and you are not sure whether focus is being handled correctly, it's a good idea to investigate by logging the document's active element.
If the element that is currently focused is removed from the DOM, the focus is moved either to the document's body element or becomes null.

Resources:

Console logging the focused element as it changes (Hidde de Vries)
Inconsistent Button Behaviour (Zell Liew)
Document or Shadow Root (MDN)

Pandemic

Tue, 26 May 2020 24:00:00 GMT

What is a pandemic anyway? I mean, why did I never actually properly learn what that term meant? There have been pandemics in the past. Sure, I know that. But were the importance of these ever conveyed to me? I can say “not really”. This is the very first pandemic-type experience I’ve ever lived through. The fact it has affected the whole world, will change some lives forever, and the behaviour of many people forever, is a mind-blowing, wonderful and deeply scary thing to me.

I have been listening to a 2.5 hour podcast episode where the covid-19 pandemic is being discussed. A woman with an astonishingly broad range of expertise, Ada Palmer, speaks briefly about two pandemics - the Swine/Spanish Flu (1918) and the Black Plague (started 1300’s and some people still get it today!). Both combined killed staggering amounts of people - even more than are being killed by the current pandemic. What if the world was exposed to a virus that was ten times more deadly than covid-19?

Ada Palmer also said something that I’ve never heard someone say before. She said that if you know a lot about the past, you automatically know a lot about the future. To me, it seems like she was echoing the saying: “Those who cannot remember the past are condemned to repeat it.” - George Santayana. I am not a good historian but the saying makes sense to me. Humans, the dominant force on planet Earth, were, are, and likely forever will be, strongly governed by things like emotions and greed. Human nature is definitely a thing, and it’s not always a good thing. If human nature is more or less constant, then it makes sense that we should learn from our past behaviours and strive to behave in a way that is better for everyone in the future.

My desperate hope for the outcome of the current pandemic is that humans learn as much from it as they can. That they learn ways to prevent the same or similar pandemics happening in the future. Of course they are not entirely unavoidable but I believe there are things we can collectively do to lessen their frequency and/or impact. I am hugely hopeful that humans will now be kinder to animals, and realise we absolutely need to respect animals and their natural habitats. We can reduce both blatant and secretive animal cruelty, reduce harm to the environment, reduce the influence that industry lobbyists have over everyone’s health, reduce harm to the poorest people living in environments affected by meat production, and reduce the effects of cheap, hormone-stuffed, overly-fatty meat that we absolutely do not need.

What if a virus or disease 10 times more deadly than covid-19 comes along? One that kills 50% of infected people as opposed to 5%? How can we ensure that lessons about the effects of disrupted supply chains are learned, and lessons from the responses of various governments around the world are learned, and lessons from the delicate balance of safety and economy are learned? We can probably ensure these lessons are learned and discussed if the world takes them seriously. The world contains more humans than it ever has before and the number keeps on growing. The spaces between humans and their animal neighbours is shrinking, while human greed is not slowing down.

Are people going to learn to live in harmony with the rest of life on Earth? Or will we continue poking holes in it until one day everything goes to shit and no amount of technological know-how or hoping or praying can save us? Humans are typically not good at delaying gratification in return for future rewards, so let’s see!

Webrings

Fri, 15 May 2020 24:00:00 GMT

CSS Tips for New Devs

Mon, 04 May 2020 24:00:00 GMT

May the 4th be with you!

If you enjoyed that greeting you'll love the nerdy stuff that is to follow. Over one evening, I wrote down some of the CSS tips I've learned over a few years of being a developer and put them in this post 😃. I saved my most important tip for the end of the list. Enjoy!

CSS stands for Cascading Style Sheets. This means that they are style sheets that cascade. Take a look at this brilliant site on the CSS cascade (that has quizzes!) to learn more.
Various online games have been made to help people learn CSS and they are amazing to this day! https://flexboxfroggy.com/ for Flexbox, https://cssgridgarden.com/ for Grid, and https://flukeout.github.io/ for CSS selectors.
One part of the CSS Cascade is Specificity. HTML elements can be styled in a number of ways. Some of your styles may be overridden depending on the way you've targeted your element for styling. Writing inline styles will override any style in a stylesheet. An id on an element will override a class, and a class will override targeting the element directly. In the spirit of the day this blog post was created, see this post on calculating CSS specificity - Star Wars edition! Note that Many CSS-in-JS libraries are designed to take care of specificity issues for you by scoping styles to single files. It still absolutely pays to learn about it though!
It's not a good idea to fix shortcomings in your HTML with CSS. Fix your HTML first!
There are pseudo elements in HTML that can also be styled and provide handy hacks when it comes to styling elements. The most well-known are ::before and ::after, but there are seven pseudo elements in total.
CSS allows organisation of elements on web page. There are even some layout systems - the most well-known include Grid, Flexbox, floats and table (in order from newest to oldest).
If your project's browser support allows, definitely try some of the newest CSS out there, e.g. Grid. If people are too afraid to try new CSS even if it doesn't have full browser support yet, then nobody would ever try it out! Check browser support with https://caniuse.com.
Elements on a web page can be sized and spaced using quite a number of different values. There are px, ems, rems, ch, vw, vh, %, etc. When building more complex web pages, the interplay of element sizing or spacing values can make a big difference in the ease and maintainability of styles.
For every shorthand way of writing CSS, it's more than likely that there is a long-hand way to write it. E.g. margin: 20px 30px 10px 15px can be margin-right: 30px, margin-left: 15px, margin-top: 20px, margin-bottom: 10px. Writing the long-hand version can sometimes be clearer for other developers reading your CSS!
You can change CSS right in your browser's dev tools (to open them, right click the browser window and choose "inspect" or "inspect element"). The great thing is, none of the styles will be saved so you can experiment here! Another great thing about the dev tools is the "computed styles" tab, because this shows you exactly what styles are currently applied to an element. This can be really helpful when it comes to debugging your CSS!
As well as computed styles, the dev tools will also show the layout styles, giving you a clear indication what margin, padding and borders are applied to an element.
Stack Overflow and CSS Tricks are two of your CSS-related-questions friends (but beware of outdated answers).
Check the MDN docs for up-to-date CSS documentation. They even have some live playgrounds for many CSS properties - e.g. https://developer.mozilla.org/en-US/docs/Web/CSS/transform.
It pays to learn about position relative and absolute. By this I mean parent elements with position: relative that have child (nested) elements with position: absolute.
A web page tends to consist of a lot of different-sized boxes. Every element is actually viewed as a box by the browser - headings, paragraphs, spans, everything. Each box consists of 4 things - the element's content, its padding, margin and border. By default, the box model states that any border or padding you add to an element will be added on top of the element's width or height. This can be confusing or counterintuitive. Setting box-sizing: border-box tells elements not to grow in width or height when border or padding is added. Instead, the content size is adjusted.
Don’t remove the default browser focus outlines unless you are sure you are managing your own focus state correctly. Removing the outlines could prevent a user from being able to navigate your site using assistive technology or the keyboard.
There are a lot of CSS preprocessors that allow you to generate (compile) CSS using their own unique syntax, which often offers a way to write CSS in a more organised, shorter or functional way. Beware using preprocessors, as they can be overkill for many projects, create over-sized compiled CSS, or make CSS hard to refactor in the future. Examples of preprocessors include Sass, Less, and Stylus.
CSS custom properties (aka CSS variables) are a way for developers to move away from CSS preprocessors and still get the benefits. They allow you to define specific values under a variable name. These variables can be used on any number of elements and if the value needs to change, it only has to be changed in one place. E.g. a variable containing a large font size such as --fontSizeL: 150% can be used on many different elements like this: font-size var(--fontSizeL). If the value needs to change to 140%, it can be done once quickly and easily. There is no support for Internet Explorer, but polyfills exist to get around this!
CSS has a lot of weird quirks that you’d not think of. If you don’t know why some CSS is not doing what you want, feel free to search for the reason. Just a couple of examples include images being display: inline-block so that they have an implicit bottom spacing, or that you need to set min-width: 0 on flex items to stop the items from growing infinitely.
CSS doesn't have to be overly complex. There is most often a simple solution to a styling problem. I can't tell you how many times I have over-used CSS and hacked a fragile solution together. If I had looked at the DOM (document object model - something you can see within your dev tools) and thought about what was happening properly, I could've saved myself time and many lines of unmaintainable CSS.
As with all programming (and to non-believers, yes, CSS is programming 😉), if your head is too far into the CSS you’ve been doing, take a break and go back to it later. It can work wonders.
Check out some blog posts about the history of CSS and who works on it today. There is still an active CSS working group thinking about the future of CSS!
You may have heard of CSS3, but don't hold your breath for CSS4. The CSS working group is working on different CSS feature modules, each of which have their own 'levels' or version numbers, e.g. Flexbox version 1, or selectors level 4, etc.
CSS expertise comes with time! While CSS is easy to start with and gives you immediate visual results, mastering it takes time and this is perfectly okay 😃. It is the same for everyone.

Accessible HTML Elements

Thu, 19 Mar 2020 24:00:00 GMT

The goal of this post is to highlight a handful of useful HTML elements for improving a page's accessibility, and show that every developer can learn about and write accessible HTML!

You may be aware that ARIA roles are often used with HTML elements. I haven't written about them here, as it's good to see how HTML written without ARIA can still be accessible. I'll write a separate post describing the combination of HTML elements, ARIA, and landmarks.

An important thing to remember is that HTML is the semantic structure (like a skeleton) of a web page, and is not for styling. Elements such as <strong> and <em> do alter styles, but also have semantic meaning.

Section Heading (h1-h6)

<h1>My Cool Page</h1>

  <h2>Read about this</h2>
    <p>This is great because...</p>
      <h3>More reasons</h3>
        <p>About more reasons</p>
      <h3>Even more reasons</h3>
        <p>About even more reasons</p>

  <h2>Read about that</h2>
    <p>That is great because...</p>
      <h3>More reasons</h3>
        <p>About more reasons</p>
      <h3>Even more reasons</h3>
        <p>About even more reasons</p>

Section heading levels are an important part of a web page's HTML structure. They allow screen reader users to effectively "see" a web page as a tree of contents. This allows content to be navigated much more quickly and easily.

If section headings are skipped, e.g. a fourth level heading is used before a second level heading in the same section of the page, screen reader users can become confused when trying to work out the page's contents and structure. However, as shown in the above block of code there are third level headings followed by a second level heading. This is fine because section headings can be nested. Here, the third level headings act like subsections of the second level headings.

A great way to check the heading structure of a web page is by using the W3C Validator. First, add some HTML via URL, file upload or direct input. Then, open the 'More options' dropdown and select the 'Show outline' checkbox option. Then, click or tap the 'Check' button. Finally, select the 'outline' checkbox. Right at the bottom of the page should be the HTML's heading-level and structural outlines, similar to the following image:

Heading-level and section-level outline output from W3C Validator

Another site for checking outlines with is the HTML 5 Outliner!

Paragraph

<p>Some content that you can skip.</p>
<p>Some content that was skipped to!</p>

Breaking content into paragraphs is another way to section content. Screen reader users can skip forward or backward between paragraphs, improving the navigability of a page. Using empty paragraphs for visual spacing or for any other styling consideration tends to hurt accessibility. This is because screen readers will announce even empty paragraphs, which can confuse users.

Ordered List, Unordered List, and List Item

<ol>
  <li>Item 1</li>
    <ul>
      <li>Do something with item 1.</li>
      <li>Do another thing with item 1.</li>
    </ul>
  <li>Item 2</li>
  <li>Item 3</li>
</ol>

<ul>
  <li>Unordered item</li>
  <li>Unordered item</li>
  <li>Unordered item</li>
</ul>

An ordered list (ol) can provide a numerical list and an unordered list (ul) can provide a bullet-point list. These elements are used to wrap list item (li) elements. Ordered and unordered lists can be nested within each other and will still be accessible.

Screen readers know to announce nested or unnested ol or ul elements as a list, and li as a list item. If an element other than ol, ul, or li is used to create a list, a screen reader will not recognise the list or any list items. In this case, ARIA roles can help. However, it's definitely best to use the correct, semantic HTML element wherever possible.

Description List, Description Term, and Description Details

<dl>
  <dt>Phone:</dt>
  <dd>0123 456 789</dd>
  <dt>Email:</dt>
  <dd>email@email.com</dd>
  <div>
    <dt>Hours:</dt>
    <dd>Monday to Friday 9am-5pm</dd>
  <div>
</dl>

Any key-value-paired information fits well inside a description list (orginially known as a definition list).

The three elements dl, dt, and dd are designed to be used together. In a description list, dt represents the key and dd gives the value of that key. For styling, adding microdata or other attributes, it is allowed (although some see this as a grey area) to wrap each key-value pair in a div element. You can use more than one dt element with a dd element.

A few screen readers such as VoiceOver for iOS will not announce these elements as lists (see how description lists are treated differently). Because of this, it's important to make sure each list item makes sense in the context of the other list items. Don't at all be put off that some screen readers do not announce these elements properly. Think of how many other screen reader users will still benefit.

Time and Datetime (attribute)

<p>
  We first opened our doors at <time datetime="2018-07-20T09:00:00Z">9am on 20th July 2018</time>
  for <time datetime="PT2H00M">2 hours</time>, as a trial.
</p>

The time element is used with the datetime attribute. This attribute's value can take formats such as:

YYYY-MM-DDThh:mm:ssZ
PTDHMS

See these used in the example code block above.

The datetime value can provide a standardised, machine-readable date or time that can be accessed by assistive technology. The human-readable date or time can be placed between the time element.

There are quite a few ways to provide a valid datetime value so I won't list them all here. However, there are available resources on the web for checking this. If a page uses JavaScript, then one great resource for creating dates is date-fns. As with all JS libraries, it's really good to check that the HTML it outputs is accessible and semantic.

ARIA labels

Fri, 14 Feb 2020 24:00:00 GMT

Recently, I've been chatting about accessibility with two of the biggest experts on the subject. Also, the web developers I work with at N26 take accessibility very seriously. This got me interested enough to read some blog posts on the subject. Many of these posts mentioned 'landmark roles' - one of which is 'navigation'. The navigation landmark is for identifying groups of links that help users navigate around a site, or within a page. You can give an HTML element a role of navigation (please see code block below):

<div role="navigation" aria-label="Main navigation">
  <!-- list of links -->
</div>

However, the nav element in HTML is automatically assigned role = navigation, making it the best element for creating navigation sections. It is always best to use native, semantic HTML elements where possible, to avoid writing too much ARIA.

For developing the N26 web app, we use agnostic axe to warn us when accessibility is not up to scratch. In my console, it notified me of the following:

New aXe issues
moderate: Ensures landmarks are unique https://dequeuniversity.com/rules/axe/3.5/landmark-unique?application=axeAPI
Element: <nav>…</nav>

I knew from my reading that this warning came from having two nav elements (i.e. two elements with role=navigation) on the same page. The nav elements need to be distinguished from each other in some way. This is where aria-label and aria-labelledby come in.

My first attempt at a fix involved using aria-label (please see code block below):

<nav aria-label="Text describing the purpose this navigation">…</nav>
<nav aria-label="Text describing the purpose this navigation">…</nav>

Whatever value is given to aria-label will be accessible to screen reader users, making it much easier to understand a HTML page's structure and purpose. The labels should provide a concise description of what each navigation element contains.

Tricky translations

After using aria-label, the warning was gone from my console! Was I all done? I could have been. However, I soon learned something else. Some translation systems (e.g. Google translate) might not translate the value of aria-label. Luckily, there is a way around this (please see code block below):

<nav aria-labelledby="main-navigation">
  <h2 id="main-navigation">
    Text describing the purpose this navigation
  </h2>
</nav>
<nav aria-labelledby="secondary-navigation">
  <h2 id="secondary-navigation">
    Text describing the purpose this navigation
  </h2>
</nav>

Here, an aria-labelledby value of a nav matches the id value of an h2. The h2 contains human-readable text. It is this text that will be accessible to screen reader users. The element containing this text can also be a hidden element which exists purely for screen readers. In this case, the hidden element of course still needs text content. This method has an advantage over aria-label in that the human-readable content is contained in a text node rather than an attribute. Text nodes are easier for some translation systems to access.

I learned all of this today and I am very grateful for the knowledge. Now I know it, I'll be able to apply it wherever needed in my HTML.

For more information, check out this post on the navigation element from html5 doctor.

What Makes a Mid-Level Developer?

Wed, 02 Oct 2019 24:00:00 GMT

Image by hugues-dbm

I was recently asked by more than one junior developer about how to progress to a mid-level developer. As a junior developer looking to move towards a mid role myself, I wanted to collect a few of my thoughts in a blog post. This isn't a checklist of skills that a workplace might typically give you. Instead, it's a collection advice from my own, lived experiences!

I've worked for nearly two years as a front end web developer in a multidisciplinary team. Currently, I work on a product that requires me to handle API data, authentication, localisation etc. This isn't the case for every front end developer. No one developer has the same experience as another.

So, please see this post as a list of suggestions and not as a complete to-do list on how to progress in your career :)

I've organised my thoughts into three categories:

Non-technical skills

As a junior it should be expected that you get better at writing code, and spend most of your time writing it. You should also get feedback on your learning and performance and be helped to get better. Becoming a mid-level developer involves spending more time on things that don't involve writing code. You should spend more time looking at the bigger picture of a project. In other words, it will become more important to look at how all parts of a project (that are worked on by every member of the team) fit together, rather than focusing solely on your own, separate coding tasks.

Writing well-structured code

Writing code is one thing, but paying attention to how well it is structured is another. It's worth taking time to write code that is as clear to others as it is to you three months after you wrote it. Practice this by breaking down the logic in the code you (and others) write. Try seeing where a feature originates, how and where data flows into it along the way, and what the end result is. Note the architecture down in a notepad, or explain to another developer (or rubber duck). This will show how well you understand what the code does and where improvements can be made.

The advantage of well-structured code is that it creates a codebase that is easier to traverse and understand. This helps you make better and more confident decisions about a project, reducing stress and confusion for yourself and your team. It also limits mistakes and technical debt - meaning there is less need for refactoring or necessary re-writing of code that was poorly written.

Encouraging better communication

Paying attention to your team's communication patterns means you notice unhelpful patterns when they appear. A retrospective is a good place to suggest ways to improve. My team at work noticed that there were pockets of smaller conversations happening between some team members. This resulted in information getting lost and not everyone being informed. So, we began documenting the results of meetings, no matter who they include, both in our team’s main communication tool, and on our story tickets.

Spending time thinking about and implementing ways to improve communication has helped everyone in my team to understand project requirements quicker and easier. Another thing that was noticed is that we rely a lot on other teams for some features, whether design, marketing, product or back-end related. Our features can be slow to progress when we do not make an effort to talk with other teams about deadlines and requirements.

No team can have perfect communication, but we continue striving to become even better at documenting information and informing everyone involved in a feature of necessary info.

Taking ownership of work

Taking ownership of your work brings a lot of benefits, and it should happen right from the beginning of a project. Be as involved as you can in decision making during planning meetings. This limits the work others have to do and reduces the chance of decisions being made that will slow the whole project down. It encourages you to do more than the minimum required to finish a feature.

Both when planning and implementing tasks, try taking some time to find out how similar features have been implemented. Think about how your tasks fit into those of other people, and whether you need to collaborate on something. Remember that taking this time is expected of you as a more experienced developer. Spending less of your time coding than you used to doesn't mean you're failing.

Spending less time coding and more time thinking about how best to approach a feature actually saves time in the long run. Creating features that are robust and well-thought-through helps you and your team feel much more in control and able to move onto new features faster.

Current skills

This list covers both technical and non-technical skills that I've already begun using as a junior. If I'd gone into depth on them it would have made this post five times longer. Still, I think it's fairly easy to grasp their importance. I find it really valuable to remind myself of them:

Writing tests to make both refactoring and finding bugs much, much easier.
Paying attention to error logs, learning to read them, and using them to find the origin of bugs.
Asking questions about WHY things are implemented the way they are and not another way.
Asking questions about anything that is not clear.
Looking closely at code that has already been written, by you or others, and suggesting refactoring changes (if needed) to make it clearer and less prone to breaking in the future.
Reading your project's code styleguide/docs and making sure the codebase adheres to the rules stated there.
Suggesting/implementing updates to current documentation (especially since docs can get out of date relatively quickly).
Taking time to review other peoples' code.
Trying several methods of approaching a problem, discussing the pros and cons, and choosing the method that makes most sense at the time.
Making sure to spend plenty of time not coding, so that you get a rest, and have more fun when actually coding.

Skill focus

Finding what to focus on

When it comes to skills, maybe you've had similar thoughts to me - now I am good at quite a few things. I am feeling quite proud of myself, even. What a nice feeling! Now, how can I get really good at something? Can I dig down into something and become a bit of an expert in it? Is there a point in that? Yes! I've been told by more than one person that this is a good idea. Why? Mainly because web development is a huge field, so it is not possible for someone to be good at, or enjoy, everything.

Maybe you have a good idea of what you are particularly good at as a developer. Maybe you have an almost intuitive feeling on what you're most interested in. Could be accessibility, performance, security, whatever. Whether you know what you are most interested in or not, I am guessing you may feel like you don't have much time to really focus on coding that much outside of work.

It's a good idea to let your colleagues at work know where you'd like to focus. Your workplace should take an interest in helping and supporting you in getting better at the things you like most. That's not to say you should drop your efforts to learn things outside of your fave topics. It's about finding some extra time to focus more deeply on such topics. At my work one developer interested in accessibility has set up weekly mentoring meetings around it, and recently begun holding a series of presentations on it.

This sounds like a lot of pressure, but don't worry. The things we are most interested in might totally change from one month to the next, and that's fine. Life is short and coding should be something you enjoy, especially if its your job. So take deeper dives into things you enjoy and feel you can handle. You might end up diving into some things more than others. Even if your learning was unplanned, it's all good.

Finding your developing style

Aside from specific topics, take a look at your strong points as a developer that involve your approach to development as a whole. Some people's style might be that they are good at coding many things in a short space of time and taking a trial-and-error approach. Others may prefer to study a concept for a few hours and take a more measured approach. Some leave the coding to others but tend to be very good problem solvers. A few may be particularly good at explaining coding concepts.

Most developers are a mix of a number of the things mentioned above. The web team at my work contains people who fit into the points I made above and this is a good thing. It's an advantage to have a web team containing people with different strengths, because these strengths can complement each other.

No one developer can know everything, and no one developer can be good at everything. My advice is to find the things you like doing most, find how you like doing them most, and still challenge yourself to learn new things some of the time ;)

In conclusion to this post, I want to remind you (and myself) that everyone started at the beginning. We all still feel imposter syndrome and shame when things go wrong. We are all learning all the time, which can be exhausting, so don't beat yourself up for not knowing something. We all need to hear stories from and support each other so please share your experiences with people too. No developer has to be alone!

Imperative and Declarative Programming

Sun, 28 Jul 2019 24:00:00 GMT

In spoken languages, the imperative is used to express commands/give orders. This helps me remember how programming languages use the imperative.

In programming languages like JavaScript the imperative is used for giving orders that describe to the computer how to do something! An example of imperative programming in JavaScript is a for loop that does something to items in an array. Check out the comments in the code below that represent what the computer is being ordered to do:

var catRatingOutOfTen = [10, 12, 15, 14, 11, 13]
// Create a variable containing an empty array.
var accurateCatRating = []

// Create a variable called i and give it a value of 0. Run a loop and,
// each time, increase i by 1. Only loop while i is less than the number
// of items in the catRatingOutOfTen array.
for (var i = 0; i < catRatingOutOfTen.length; i++) {
  // Take catRatingOutOfTen array item number "i" out of the catRatingOutOfTen
  // array and multiply it by 2.
  var newRating = catRatingOutOfTen[i] * 2
  // Append the calculated value to the end of the accurateCatRating array
  // initialised earlier.
  accurateCatRating.push(newRating)
}

console.log(accurateCatRating) // [20, 24, 30, 28, 22, 26]

Quite verbose, eh? However, looping through an array can also be done in a declarative way! The map() method is one way - it states what the code does, and lets the computer figure out the how to do it. In spoken languages, the declarative deals with informative statements. The computer can be told what code is supposed to do, and be allowed to figure out how to do it by itself. Check out the comment below:

var catRatingOutOfTen = [10, 12, 15, 14, 11, 13]

// accurateCatRating is a new array consisting of each item of the catRatingOutOfTen
// array mapped out and multiplied by 2.
var accurateCatRating = catRatingOutOfTen.map(function(n) {
  return n * 2
})

console.log(accurateCatRating) // [20, 24, 30, 28, 22, 26]

Quite a nice shortcut, isn't it? Declarative programming is a powerful way to write less verbose code. Since declarative programming is more abstract than imperative programming, it can take longer to learn and understand what declarative programming does under the hood. We often cannot immediately see exactly how declarative code works and creates its results. But once we understand how declarative code works, it can help us achieve in a shorter time what we would have achieved by instructing the computer step-by-step how we need it to do something.

JavaScript ES6 syntax allows an even more declarative way to get the accurateCatRating. Check it out below - the function declaration has been shortened with an arrow function, which makes an implicit return possible:

var catRatingOutOfTen = [10, 12, 15, 14, 11, 13]

var accurateCatRating = catRatingOutOfTen.map(n => n * 2)

console.log(accurateCatRating) // [20, 24, 30, 28, 22, 26]

A lot of popular and powerful libraries, such as d3.js, Zdog, and GSAP take advantage of the declarative programming style for abstracting away logic and allowing cool things to be achieved with less code.

Please check out the super good article on imperative and declarative programming by Philip Roberts that inspired me to write this post!

Giving Back

Mon, 10 Jun 2019 24:00:00 GMT

@Sareh88 wants to set us a challenge - giving back to the web community. Can you think about the things people have done to help you? Is there a way you can give the gift of your support to help support those who need it as much as you once did? @CSSconfeu #CSSconfEU2019
— Amber Wilson (@ambrwlsn90) May 31, 2019

What is giving back? It can mean so many things.

What have people done for me? How did I go from wondering what next step to take after a masters degree in psychology to working on a challenging and exciting web app, being flown out to amazing places to speak, and getting involved in a truly incredible community that has taught me so much not only about tech but also about myself?

The answer lies in the support that others have given me. People have given up their time to coach me, extensively mentored me, promptly answered my slack and twitter messages, invited me to speak at a conference even though I never had before, given me scholarship tickets to conferences, given me feedback, given me step-by-step instructions over video chat to build something I couldn’t have done alone, offered me extended 1-on-1 time to focus on a topic I want to improve, gone out of their way to help me feel comfortable, given me free books and online learning materials, organised free workshops, given me kind and supportive words, assured me that I have what it takes to succeed, made me feel my non-technical skills are highly valued, etc. By the way, if you are one of these people, thank you so much.

I am thrilled to have the chance to give something back since I began getting paid to be a developer, and that’s helping to organise codebar. Doing so is a way of thanking everyone who has helped lift me to where I am today and helping to give other people the same support as I received. But it’s actually only one way of giving back. Not everyone has to organise meet ups or put in a large time commitment in order to help others. Small things such as giving a supportive word, taking a moment to give someone feedback, or checking your privilege to help ensure everyone has the chance to feel comfortable and accepted, can help others so much more than you may think.

I have heard concerns from people who’d like to give back but are unsure how to, or nervous that their attempts at helping would not really help at all. If you feel this way, I can assure you that this is very rarely the case. At codebar we often get emails from developers who’d like to try coaching but worry they’d be terrible at it and end up boring their student rather than helping. Firstly, we direct them to our common-sense code of conduct, and our coach guidelines. Secondly, we reassure them that students would be thrilled with any sort of support given, whether it be technical, or something more like career advice or sharing stories. A really cool thing is that we have so many returning coaches at codebar who love coming along, which shows that they also get something from the experience.

I can very safely say that without the people who have given either a little or a lot of their time to me over the past two years, I wouldn’t be where I am today or have the confidence going forward to achieve even more in the future. I owe my success to the combination of all the little bits of support that people have given me. I am very much community-taught, and not self-taught. Being in tech can sometimes feel extremely overwhelming and also lonely. The best way to give back is by getting involved in the tech community, and offering your kind words and using any privilege you may have in order to support your fellow humans. You will lift others up and make them feel fantastic, and it'll lift you up as well (that's a promise). Win-win, I would say 😊

The Big Picture

Thu, 25 Apr 2019 24:00:00 GMT

I think it’s important for junior developers to learn to see the bigger picture in projects. However, this can be hard for new developers, particularly those with no computer science background. I have been told by experienced developers that the ability to see the bigger picture comes with time and working on multiple large projects. As a junior developer who is looking to transition to mid-level, I feel more and more aware that I still occasionally miss the bigger picture. I also think this is something that can be improved over time. To do this, I have to be aware of it and its importance.

It’s important to see the big picture because it will inform how developers write their code. If they understand that code needs to be maintained in the long run, and needs to be flexible and scalable, they will feel more motivated to write their code in a particular way. Naming and commenting are good examples of this. The way components, variables and files are named and commented is quite crucial to the maintainability and understandability of a codebase in the long run - and not only for the team but also for the developer who writes the code in the first place.

Seeing the big picture is very useful when it comes to naming code. Here are a couple of examples: 1. An API used as a proxy should be, in effect, ‘dumb’. It should not be named in such a way that suggests it is connected to another part of the codebase. It should be named for the purpose it serves and nothing else. When the API is used in a codebase, then it can be customised to fit the codebase’s purpose. 2. An icon should be named according to a decided pattern. One suggestion could be to name icons for what they are - e.g. a box with a shadow could be ShadowBox. In this case, any new icons added to the codebase should not be named for what page they are on or what function they serve. Both of these examples will help keep the codebase clear and understandable for developers who use it.

If a piece of code is complex, it pays to comment why it is there and why the code was not written in an alternative (and to the uninformed eye, a different but equally good way). People will thank you tremendously and you will thank yourself even more strongly for taking the time to comment code.

To conclude, I think it can be hard for new developers, particularly those coming from a non-computer background, to see the big picture. Most beginner projects that new developers can do by themselves also do not give the aspiring developer a very good idea of what it means to scale a project. Due to this, I think new devs should not stress too much about missing the big picture, but that they should always be aware that it’s an important thing to learn. If you’re a new developer, take your time and work on as many large projects as you can. Be involved, ask questions, and ask for feedback. Seeing the big picture and writing readable, maintainable code is a skill that comes over time and it totally learnable.

What Is Important To Developers?

Wed, 24 Apr 2019 24:00:00 GMT

What is important to you as a developer? Over time I've found that each developer has their own ideas of how to progress in their career, where they want to focus in the near future, and what being a good developer looks like. If you think about these things, what do you come up with?

Personally, having come from a non-computer-science background, I’d very much like to gain some knowledge around backend langauges. This might include things like Java and NodeJS. To understand these languages better, I also need to improve my knowledge of client-side JavaScript so that I can better understand how the languages compare to each other. What will a comparison of different programming languages give me though?

I think any sort of information—even a simple comparison–can open the gates to more easily understanding other important things in web development. For example, knowing how one programming language functions in comparison to another will allow me to understand how and why these language fit into a project ecosystem. A large project will be worked on by a team or teams that contain developers with very different levels of knowledge on different things. It pays to have at least a good, basic understanding of what everyone in your team does and why.

Knowing what people in a team do and why can limit frustration - both on your side and theirs. This is because an understanding, even a basic one, of how parts of a project architecture fit together, and why they are there, will inform how you write your code. It will limit technical debt piling up from code that turns out to be irrelevant or not fit into a projects needs. Also, a healthy and maintainable project isn’t the only benefit - individuals benefit too.

This benefit is developer experience. I find it so much more fun being a developer when I understand what is actually going on and why I am writing code. As a brand new developer, there were too many things to learn at once and as a result I felt overworked and underskilled. The result of this for me was imposter syndrome. Why was I there and how would I ever make valuable contributions? It took a long time for this feeling to fade and two years in, it is not completely gone. However, for the majority of the time I spend coding these days, I feel like I am on a good path and not stuck in a rut. There are still too many things for me to learn at once but I can now greet this as a healthy challenge rather than with a feeling of doom. A great thing about being a web developer is that there is so much to learn, and so many people to discuss with and support you in the web development community. For me this sparks a motivation to learn, share and be a better web developer.

Being a better developer might be a universal goal that is shared by the majority of people who write code. I think finding the motivation to do this is the most important thing. Beyond this, you can do what you like to achieve it. Focus on a particular topic like security or accessibility, contribute to open source, write more documentation, review more PRs, create more PRs, speak at a conference, give a small presentation at work, read a book on a programming language you know nothing about, create a new personal project, whatever. Another important thing would be to share what you’ve learned and get feedback from others. Having a community to support what you’re trying to achieve is likely to get you there faster that working through things alone.

Can You Code A Design? - Part Two

Sun, 13 Jan 2019 24:00:00 GMT

Last time I wrote about coding up a design, I was only two weeks into the related project. Now, it has been weeks since I finished and I am documenting the remainder of my scribbled-down points in the event that I or someone else might find them useful in the future. The below points are formatted exactly how I wrote them in the heat of varying degrees of exasperation - enjoy!

Check the most minimal thing you can do to get it out the door.
Check with more than one person on specs!!! - one person may say you need something, another says you don’t etc.
Heavily scrutinise the design for common design patterns and put these into your globals. Ask designers whether these are likely to change.
PAIR PROGRAM WITH THE OTHER DEVELOPER FROM THE BEGINNING!!!!
Make sure each dev respects coding, commenting and reviewing practices (this can be super hard).
Don’t trust that you have the correct information. Communication between individuals in the project isn’t always perfect. Speak to each team member you work with. Ask them what they’re up to, share successes and information. You might (correction - probably will) find that they haven’t been given enough information by the PO and are stuck. You can then give them the required information, making everyone happier and less stressed. In short, over communicate rather than under communicate.
Get info you need before people go off on holidays.
Smile and be nice, it might make someone’s day or make their job easier or more pleasant. Be to others how you wish others to be to you.
Get automated testing in, don’t throw stuff at QA engineers and say “If the QA engineers say it’s fine, push it to production”.
Get some decisions for padding, fonts, colours and spacing in early people COME ON!!!

Can You Code A Design?

Wed, 31 Oct 2018 24:00:00 GMT

If you said "YES", how exciting! Well done, you :-) But wait... it's not always a bed of roses. If you've already developed a real web page from a design, maybe you'll nod along to some of the points I have made below. The past two weeks, I’ve learned loads from building a static page using Gatsby (React) and SCSS (in this case CSS Modules, although I'd have been partial to some Styled Components). React and SCSS get on pretty well from what I have seen. And static site generators like Gatsby help you set them up to work together. The configuration is the hardest part. Once you're past that, developing with these two is a breeze. But wait... is it?

In short, this post is all about things I’ve learned from building a page from a design (so far - I am only 2 weeks in - part two of this post will come once I wrap the project up) ✏️ 💻

So, here is my two-weeks worth of advice:

GET STANDARDS IN REALLY QUICKLY. By this, I mean that if you're a developer, sit down with the other developers working on the project, and the designers. If you are a designer, sit with the developers working on the project and the other designers. Once you're all sat down on nice seats, talk about all the good stuff like margins, paddings, deploy host, font-sizes, unit testing library, font-weights, colours, responsive behaviour, commit hooks, maximum-widths, content, naming things, linting, and where to all sit for lunch together to help strengthen your bond, etc.
Related to the above suggestion is COMMUNICATE WITH YOUR TEAM FROM THE BEGINNING. In fact, be each others' new best friends. This will help get your project off to the best possible start. Like nurturing a newborn baby, input and support from each other will help reduce individual stress and help you all raise something really great. Chances are high that everyone on the team would really, really love to do a good job on the project. To achieve this, please don't hesitate to reach out and talk to each other.
Back to point one for a minute. SET UP GLOBAL CSS STYLES and put them in a neat, tidy place. For the project I am working on, this meant getting stuck into a sass folder and setting up a few important files. For example - constant values such as media query breakpoints, colours, font families/sizing and spacings, and functions to plug these into and use with terrific mixins that can be set free throughout your site to work their magic.
AVOID TECHNICAL DEBT. After a couple of weeks developing a design that was ever-changing, myself and another developer built up a shiny mountain of it. For a few moments, I became certain that if the designers had simply given us a solid, unchanging design from the beginning, we'd have done a better job. Then, I remembered that this isn't exactly the most agile idea. Waterfalls are old news. So, my developer friend and I decided that a great compromise would be to take design iteration #1 as our template and finish developing it. Then, the design would be free to change and mature, ready to be iterated on in round two of development. This way, tiny design changes would hold us back much less.
DAILY STANDUPS. Try to have these at a set time, or at least try to have impromptu meetings (as many as you want) with people you should be communicating design and development decisions to and with. Again, this is really important to the health of the project. If you're hesitant to communicate with other people in your team, the chances are that they are too and just wish you'd approach them so they don't have to do do the scary thing and approach you.
GET CODE REVIEWS FROM ALL DEVELOPERS, and I mean all developers company-wide, not only those assigned to the project. Why? This has several benefits. It helps you to increase your company's bus factor, i.e. it gives a higher chance of someone being able to pick up development tasks on the project if all assigned developers are away for whatever reason. It increases individual developer competency. Also, developers who don't have their heads stuck in the project code all day every day tend to be better at spotting things and having ideas that the assigned developers did not.
Related to the above suggestion is DOCUMENT ALL YOUR THINGS. This means commenting any CSS that is not obvious at first glance, commenting JavaScript functions, keeping the project readme up-to-date, shiny and fabulous. Maybe then a developer who had never seen any of the code would be able to look at the code and feel comfortable and confident about contributing within a small amount of time. Confused developers tend to be stressed, too, and this doesn't benefit anyone or anything. Writing documentation takes time and slows down development tasks, but remember this - you will actually ferociously thank yourself a few weeks down the line when you look back at something you wrote, while slowly tilting your head to the side while thinking how that code could possibly have gotten there.

You can apply all, any or none of the above suggestions, plus any others that you find. All of them will require some effort, and definitely some extra time. How much effort is the outcome of your project, and the stress levels of those involved, worth? 😉

See this post on Medium here.

I am a 1-2 year developer

Mon, 15 Oct 2018 24:00:00 GMT

I recently read a blog post that grouped developers into categories depending on how long they have worked as one. I felt a little proud that I wasn't in the 0-1 year category, but in the 1-2 year one. This made me want to write about other things about my new career that I feel proud of.

How do I feel now that I've been a professional developer for more than a year? I certainly feel I have come a long way and accomplished things I never thought possible - especially when it comes to the current breadth and depth of my skills. A year ago, if you'd asked me whether I'd become so good at looking at a programming problem and confidently considering ways to work around it, become so good at finding answers, or intuitively avoid certain methods, I'd have laughed.

I like how being a developer surprises you. Over the last months, I’ve surprised myself with what I have been able to achieve. Most importantly (and intriguingly) for me, I’ve realised that while I still have a mountain of things to learn, whatever is left will always integrate with and enhance the knowledge I already have. This is intriguing because I didn’t have a strong sense of this at the beginning of my career. The skills and knowledge I have picked up remain with me and give me little “pick-me-ups” when I need them. This was something that was lacking before - when I had less of a strong foundation.

My achievements are definitely the result of stepping outside my comfort zone and feeling uncomfortable with the tasks in front of me. I can certainly say that being challenged hasn’t always been easy. It’s made me feel a lot of low feelings. It’s also given me the wisdom that I’ll certainly experience low moments in the future, but that these will also afford me the opportunity to grow. Knowing this adds to my newly found confidence by helping me envision what to expect in the future.

I recently began working, for the first time, with a developer who is more junior than me. I didn’t know that was going to happen, or even that I was going to work on the project I am on now. But I am really enjoying the experience. I immediately felt quite strongly about helping out and supporting this developer as much as I could. Over the past couple of weeks I think I’ve succeeded in doing that, and I think they feel the same way. I’m really excited about seeing what we will achieve together on the project and how our skills will grow.

I have become more acutely aware of areas I would like to especially grow in. One of these is discussing technical topics with fellow developers. I want to take my opinions and feel smart enough to voice them, and I really want to have discussions with other developers that lead to productive outcomes. This skill is something I've seen improvement in over time, but slower than I'd have liked. Perhaps, as with my other work, I need to push myself out of my comfort zone and speak up more.

In conclusion - sticking with the job even through hard times, especially through hard times, has made me a better developer than I ever expected, has made me more excited to continue and improve than I ever expected, and reminded me of the great Jessica Rose’s sentiment that feeling challenged is essential as it often means you are improving (without even knowing it).

Playing with Pixels

Wed, 08 Aug 2018 24:00:00 GMT

I visited a great place with lots of graffiti at the weekend, and decided I'd take one of my pictures from there and pixelise it - see the pixel version below and the original further down. Can't wait to practice more!

Build Yourself Up

Sat, 04 Aug 2018 24:00:00 GMT

What I've written here is meant for developers but I think it could work for anyone :)

I feel like this post could be part of a series all about my experiences as a new developer that I've written about over the past year. It's been great having the chance to experience becoming a developer and share my thoughts along the way.

My idea for this post built up over a few months of working on a complex project at my new job. I was completely new to some of the technologies (React, Redux, GraphQL). At the start, I didn't use these, but rather took on smaller stories/tasks and tried to prepare for taking more complex ones.

A few months in, the larger stories began to grow in number and I tentatively took some on. At first, nobody expected me to go too fast and I asked a lot of questions. Eventually, I began to complete stories faster and with less help. While it was challenging and fun, there were times when I got stuck, felt frustrated and guilty about the time I took. Other negative things I felt included wondering whether I'd ever get better or ever learn how to do these things at all. In general, I was quite quick to put myself down when I didn't do something right the first time.

It struck me this week that I often put myself down for doing things wrong, but hardly ever build myself up when I do things right. I wondered why people tend to do this, and was reminded of something I learned studying child psychology.

Despite people having different ideas of what is right and wrong, it's usually clear whether something is one or the other. For children, this might be using a fork to eat their dinner vs. repeatedly chucking the fork as far as they can across the dining room. It somehow seems easier to react to the fork chucking rather than sitting and eating quietly. This means the child gets more attention for misbehaving than behaving well. In psychology, this is called giving positive reinforcement (attention) for 'wrong' behaviour, and no reinforcement for 'right' behaviour. This can lead to an escalation of negative behaviour and frustration for both the child and caregiver.

I think a few developers may do this to themselves - i.e. pay a lot of attention to their perceived failures and not enough to their victories. I've definitely done this a lot since becoming a developer. It might be because a lot more time and emotion is involved when something isn't going right. In contrast, when completing a task quickly and efficiently, it might seem less significant, and less energy might be put into celebrating. This is something I'm going to try and change. I think everyone needs positivity and reassurance when they are doing things right. Just as much from themselves as everyone else.

Being a developer can be really hard and feelings of frustration can be common. I'd love to hear ideas on ways to pay less attention to the frustrating moments, and celebrate the positive ones more. If you have any ideas, let me know :)

Scotland CSS | Scotland JS

Mon, 30 Jul 2018 24:00:00 GMT

This post is split into three parts. Click and choose!

Diary of my time in Scotland
Tips from speakers used in this blog post
✨ Why this conference is special ✨

I will post a link to the official photos once they are out! (hint: they are good).

See Katie Fenn's terrific and poignant article on the conferences.

Diary #

At 12.58pm on 17th July I stepped off the train into Edinburgh station. It was sunny! I noticed the architecture immediately - very beautiful and old. It wasn't long before I got to meet up with a very good web friend of mine, Flaki. We found the longest staircase we could and took our suitcases up it on our way to our accommodation. Once there we met up with two more good friends, Pilar and Ramón. After this, I met up with an old friend for dinner at The Castle Arms, before we all made our way to a Ceilidh dance Peter invited us to. This was a blast and a perfect way to begin the great things to come!

The Castle Arms pub (photo / Me)

Ceilidh (photo / Me)

At 7.15am, I walked to the conference venue, Dynamic Earth, and met up with the rest of the volunteers. I'd already met some during our code of conduct and speaker buddy training a few days previously. We got our t-shirts on and got to it. Soon the first attendees were arriving and the talks began. Peter did a great job of answering any questions we had and making us all feel very comfortable and welcome. I was so happy to hang out with my friends. I even got to see Emily and Anwen from codebar Brighton again! codebar is the amazing free initiative that helped me become a developer <3 <3

Fred, Bæla, me, Flaki (photo / Frederic Marx)

Emily, me, Anwen - codebar Brighton reunion! (photo / Anwen Williams)

The quality of the talks at Scotland CSS were, in Peter's words, beyond phenomenal. The quality and variation in the topics was amazing. Each talk was 20 minutes, and in a set of three. After each set there was a separate discussion slot for each speaker, which the audience could attend to ask questions. This was a really nice and down-to-earth format that broke down barriers between audience and speakers and allowed everyone to feel on the same level! The stage for speakers was also very low - at the level of the audience. No hero-worship of speakers here.

Chat with Meara Charnetzki (photo / Scott Logic)

Trishul Goel on the low stage (photo / Flaki )

After Scotland CSS, some of us headed to dinner at Holyrood 9A (amazing burgers) where Emily and I had vegan haggis burgers! After this we made our way to Hemma where we had drinks with other conference goers. They had some of my favourite beer. By now, everyone was tired but we were all having such a nice time, it was really hard to drag ourselves away and go home!

At 7.45am I arrived for the second day of conferencing and the beginning of Scotland JS! This day was just as amazing as the one before. The volunteers all helped each other to see our desired talks, speak with friends and feel relaxed and happy. I am so super grateful to every single fellow volunteer there. Anwen and I met Evelyn from codebar Edinburgh. Evelyn not only volunteered but also MCed at Scotland JS! From left-to-right, we represented codebar Berlin, Edinburgh and Brighton! Nicki and I were lucky enough to be approached by avid-coder Connie (the youngest attendee at 10 years old) and her mum who asked us if we wanted to Floss! For anyone not cool enough to know, flossing overtook dabbing as the in-thing. Find the video below, featuring our very own Peter, if you are still confused.

Me, Evelyn, Anwen - codebar * 3! (photo / Anwen)

Nicki, Connie & me flossing (photo / Connie)

The first night of Scotland JS, we were lucky to be treated to gin and whisky tasting where we sat with friends and sampled some of Scotland's finest spirits. I also had a fantastic vegan haggis baked potato (never thought I'd put those words next to each other in a sentence) with two fantastic humans. Some people went to karaoke but I was way too tired so I went to bed. Not before being shown where the deep fried mars bars were sold, though.

Potato posers - me, Peter, Fred (photo / Me)

2 gins, 3 whiskies (photo / Me)

The last day of the conference began a little later at 9am. It was just as good as the previous two days, and I already began to feel a little sad that the conferences were nearly over. As the last speaker was wrapping up, everyone thought that was it. But, Peter had a surprise for us. Read about it at the end of this post ;-)

The last night of the conferences was spent again at Hemma, amongst friends. And amonst fish and chips because Edinburgh restaurants are really busy on Friday nights! I was very glad that I was staying in Scotland for one more day so I could walk around beautiful Edinburgh. I miss it and my web friends already - until next time :-)

Tips #

I used tips from speakers in this blog post, because the material was just so good! I wasn't able to see every speaker, but I'll watch all the videos once they are out :-) All tips are from Scotland CSS, as I'm not using any JavaScript on my site:

Peter Müller's "High Performance Web Fonts" was about improving performance using local fonts rather than Google fonts, font subsetting, and his node package subfont. He added network tab visuals to help us understand the performance benefits. I went ahead and downloaded the two Google fonts I usually access with two separates HTTP requests, and added the local versions to my site.
Anna Migas's "Fast But Not Furious: Debugging User Interface Issues" taught me the order pages load in. An event is fired (JavaScript), styles are calculated, layout is calculated, things are rasterised and painted into layers, layers are composited together. Check out a site's layers by going to the layers tab in chrome dev tools! I figured out my site only has one layer as it is static and has no JavaScript.
Natalya's "Bootstrap to CSS Grid" encourages companies to adopt CSS Grid and explains the benefits of doing so. Grid can be gradually adopted into an existing codebase. I demonstrated this here by using it to position my images and figure captions. I used grid-template-columns , grid-template-areas , and grid-area to position things exactly as I want them. The mobile version of this page uses Flexbox instead. Yep, you can mix Grid and Flexbox! Check out Firefox dev tools for a great visual representation of my picture grid.
Sareh Heidari's "Quick Tips for Performant Websites" encouraged us to think what our users' priorities are. Sareh taught us about some resource hints to give browsers a helping hand loading things. I had not heard of these before. See an artice on how resource pre-fetching helps performance.
Jessics Rose's talk on Impostor Syndrome and Individual Competence taught me something completely new. Not something technical that I can add to this post, but something really important. About how feeling yourself struggle means growth. You have stuff that's too easy and stuff that's too hard and right in the middle of the venn diagram (the zone of proximal development) is where you should be, in order to grow. Challenging and pushing your mind. It can feel uncomfortable - this is where imposter syndrome can often kick in. But in these cases, it helps tremendously to give yourself a gentle reminder that you are absolutely fine. Of course while remembering to give yourself sufficient periods of rest to recover from the sustained effort of learning.
Steven Robert's "CSS Animation - Best of the Web" was my favourite talk. I really couldn't wait to have a go at creating my own animation using code. He showed us how to use SVGs in separate cells (frames) with keyframes and animation properties to create just about any animation we'd want. Here is a link to Steven's codepen, and a link to his bird animation that inspired his talk and the below rabbity animation. Scroll to number 4 in this list for the tutorial. Steven helped me out when I had questions and I'm really grateful for that :-) Through making the rabbity animation), I learned more about SVGs and how the viewBox attribute works.

Why This Conference is Special #

I believe the technology community and related events can learn a lot from Scotland CSS and Scotland JS.

I think Frederic did a good job explaining why.

Resting up after an intense week of @ScotlandCSS and @ScotlandJS.
☕️🛋🎶

Thanks so much to @jiggy_pete & team for fostering a community that’s equally inclusive and transformative for long-time industry experts, as well as total beginners, and everyone in between.
— Frederic Marx (@fredericmarx) July 22, 2018

Scotland CSS and JS is created and curated by Peter Aitken. The community Peter works so hard to build (not only at these conferences) is inclusive and transformative for everyone, no matter what their level. At some conferences, I have felt left out in favour of developers who are much more established. I didn't feel like that for a second at Peter's conferences. On the contrary, I felt safe, welcome, and included.

I am thrilled that so many others seemed to have a similar experience.

@ScotlandJS is the first Tech conference in 10 years in Europe, where I felt that people like myself, and @CodeYourFuture_ students, are first-class citizens. Thank you @jiggy_pete for making a Tech event that is genuinely and sincerely welcoming and inclusive to *others* 1/3
— Mozafar (@kabaros) July 23, 2018

On the first day of the conferences, at Scotland CSS, the first thing we all saw was one of the code of conduct banners. The other banner (not shown here) had the short AND long version of the code of conduct written on it. We were also introduced to our lovely code of conduct team - Evelyn, Katie, Nicki and Peter. I've never seen or experienced the code of conduct being enforced in such a diligent or more organised way. It made me feel very safe and I hope it did the same for others.

Code of Conduct banner (photo / Julie Broadfoot)

Code of Conduct team (photo / Julie Broadfoot)

The youngest attendee, Connie, was 10 years old. Peter introduced her to us and all the great work she's already done. I was lucky to get to speak (and dance!) with her. I heard about the adventures she's been on with coding so far, saw some of her work and chatted with her about Harry Potter. She is a Gryffindor.

So pleased to welcome our youngest attendee to #scotlandjs

We’re glad you had an amazing time and can’t wait to find out what you create in the future 💛 https://t.co/HlX3xPT106
— Scotland JS (@ScotlandJS) July 21, 2018

Connie was also Upfront. Other people were too, including my good friend Anwen. I first learned about being Upfront last year at UX London where I met the great Lauren Currie. She is from Scotland and has done a tonne of amazing work. She wanted a way for people to get experience being on stage without having to speak. What happens is a few chairs are set up on one side of the stage, and aspiring speakers sit down while a speaker gives their talk. Lauren hopes these people gain enough confidence to speak one day. I am on the Upfront blog :-)

As I mentioned in the first section of this post, there was a low stage, and also face-to-face speaker discussion - both of which broke down barriers between speakers and attendees. There has been talk around 'hero-worship' of speakers at some conferences. This certainly was not the case here, and I'm sure many people had a much more genuine experience because of it.

Some things weren't as obvious as inclusive measures at first glance, but they were there. For example, Peter convinced the venue to add gender-neutral toilets. He took the advice of Nat Tarnoff on adding animation warnings for those with vestibular disorders, and also added warnings about flashing lights and loud videos. There was plenty of vegan and vegetarian food and snacks. Based on past feedback, Peter set a board game evening up to run alongside gin and whisky tasting for those who didn't want to drink.

Scotland CSS & Scotland JS was certainly a team effort: organizers, volunteers, speakers, even attendees (who, as ticketholders, got to vote & decide on the final lineup) — worked together tirelessly to make it happen…

BUT.

I need to leave this here: https://t.co/M4ToVpPou7
— 𝔣𝔩𝔞𝔨𝔦 (@slsoftworks) July 23, 2018

This conference feels different to any I've been to before, and by now I have been to quite a few. This feeling began even before the conference began, with a video call from Peter. He took time to have a face-to-face conversation with me to tell me all about what volunteering would involve. After I'd agreed to volunteer (not a hard decision at all), Peter arranged for Katie and Alan to have a video call with all volunteers. On this call, we were able to learn more about the code of conduct and how to help out speakers on the day. At all times before, during and after the conference, Peter would reply to questions quickly and enthusiastically.

This is the first conference, event, meetup, anything that I have been to that made me really, truly feel that change is really possible. By this I mean change in people's attitudes to diversity in tech, and diversity everywhere else too. As a white person in tech, I have plenty of privilege. As a woman in tech, I've also felt an undercurrent of discrimination. I hope these two postions / viewpoints help me to be more aware and empathetic towards the experiences of everyone. I am definitely aware that there are people in tech, and everywhere, that are not comfortable feeling uncomfortable. By this I mean certain people are much more likely to sweep certain people's experiences under-the-rug than do something to help.

Peter surpised us with an unexpected speaker at the end of Scotland JS. Kim Crayton spoke to us about privilege, diversity, and how we need to get comfortable with being uncomfortable. So that we can change where tech is heading today, allow everyones voices to be heard (not only a select, privileged few), and work towards a world where every single person feels safe in their own skin. I had a second surprise, and it seems nobody else saw it coming either, but this was to be the last Scotland CSS and Scotland JS. Peter, speaking slowly and purposefully, told us that his focus going forward must be on Global CFP Day, a worldwide event that helps people begin speaking and sharing their knowledge and experiences. See a photo below of the Berlin version that I was lucky enough to mentor at back in February - one of over 50 events worldwide.

Kim Crayton (photo / Flaki)

CFP day in Berlin (photo / Priyanka Naik)

A third surprise awaited us. Peter got onto the stage once more to announce that with the rest of the conference money, he was going to donate 10 computers to Code Your Future - a UK-based coding school for refugees who want to become web developers.

It was hard to fight back the tears when Peter's family came on stage to hug him and his wife said she is really proud of him. It must be safe to say that we are all endlessly proud of Peter, and the genuine enthusiasm, kindness and tireless hard work he puts into what he does.Thank you, Peter Aitken!

The Floss @scotlandjs #scotlandjs2018 edition #Floss #flossing @jiggy_pete @waffles193 @herecomesjaycee pic.twitter.com/KFvyl7QNOq
— Amber Wilson (@ambrwlsn90) July 19, 2018

JSConf EU: Community Lounge

Thu, 07 Jun 2018 24:00:00 GMT

One month ago, I was invited by Vanessa and Michele to speak at the JSConf EU community lounge in sunny Berlin. This was a tremendous honour - not only would I be able to talk about how great codebar is to a crowd of eager attendees, but I'd be able to participate in both CSS and JSConf EU, and catch up with lots of old and new friends.

Something I couldn't help noticing as soon as I arrived, was the fantastic effort the conference organisers put into designing a great space for everyone.

One of the best corners of this space was definitely the community lounge!

On arrival, I found the lounge prepped and pillowed-up, the sticker table and job board ready to be filled, and plenty of space available for people to watch lightning talks from local tech initiatives. The thing I was most excited about, though, was to see the codebar poster sitting proudly right at the entrance.

Across three days, there were so many great speakers who shared their local initiatives - ones that had made such a difference in their own lives. Among them were several Berlin meet ups I had long admired and attended. Wanting to give codebar every ounce of credit it deserves, I created the best presentation I could. I wanted to talk about how codebar works, and let people know how to get involved in codebar Berlin. I also wanted to get across to the audience how much codebar means to me personally.

It was mid-2016 when I attended my first codebar in Brighton, UK - and without exaggerating, I can confidently say that it amazed me beyond words. I remember thinking "how can it possibly be that I'm here, being introduced to codebar by fantastic organisers, inside a lovely venue, with free food?" Not only that - how was it that I got to sit with a super nice coach for TWO hours to refresh my rusty HTML and CSS? Since being supported through codebar to achieve my first internship in tech, and becoming a coach and organiser myself around a year ago, multiple students have approached me with exactly the same questions.

One of the best things about the whole experience of the community lounge for me was hearing from people who feel equally as strongly about the initiatives they are part of, and who have achieved similarly wonderful things - all through the tireless efforts of volunteers who make such things possible.

Here is the list of everyone who did a lightning talk ⚡ -

ClojureBridge / Dani
PyLadies / Jessica
Summer of Code / Laura
Spektrum / Wolf
BerlinJS / Robin
It’s a Volunteer’s World / Dajana
Alva / Julian, Markus, Tilman
Women Tech Makers Berlin / Corina
OMGDPR / Chris
NodeSchool Berlin / Finn
Choose Your Own Instrument / Tiffany
Simply Secure / Eileen
Common Voice / Mike
CSSClasses / Katrin
AfroTechFest / Debs
codebar Berlin / Amber
UpFront / Katharina
Rails Girls (Code Curious) / Ferdous
ReDi School / Inana & Obay
Open Tech School / Mohamed

See the tweet below that links to each and every initiative and the people who spoke about them!

🤩🌈 The Community Lounge is welcoming 20 unique presentations across all three conference days at @CSSconfeu and @jsconfeu.

We're so thrilled to have an amazing program that showcases people who are doing remarkable and noteworthy work in the community ⚡️
— JSConf EU (@jsconfeu) May 31, 2018

I want to sincerely thank the organisers of CSSConf EU and JSConf EU for being so kind to invite codebar, and all of the other great initiatives that provide safe spaces for people to learn. I want to give a special shout out to Jan who was an amazing host. It was an incredible opportunity to spread information about the great things codebar makes possible. I am really, really excited to report that on the Monday after the conferences, we had the busiest Berlin codebar on record - and I can't wait to see what else we can do to help even more students learn and discover possibilities for themselves in tech.

If you'd like to get more involved in codebar - we are always looking for more students, coaches and sponsors! - please see (and sign up on) our website, check out our main Twitter (each chapter around the world has their own Twitter account), email us at hello@codebar.io, see our main Facebook and Instagram accounts, and find our Slack channels! ❤️

Pair Programming

Sun, 06 May 2018 24:00:00 GMT

Firstly, what is pair programming? It’s two developers sitting together, usually at one computer, where one types code and the other checks the code. In essence, it involves two developers who are thinking about different aspects of the same programming feature, and are constantly communicating in order to keep their understanding in sync. Some of you may know this already. Apart from this very short introduction, I can really only tell you about my own personal experiences with it. But first I’ll tell you a little bit about me.

I am a front end developer currently working at Edenspiekermann in Berlin, where I code alongside many talented and friendly developers and designers. It’s my second ever job as a developer, and in total, I’ve been working as a developer for less than a year. Other facts about me include that I’ve lived and worked in six countries (including the Netherlands where I got a masters in Psychology), I really love writing, I really really love my developer community and my favourite text editor is VS Code.

My current career in tech is exciting, full of opportunities and it’s fast-paced. My past career in psychology involved learning how to understand and help people. The mix of these two careers has led me to take an interest in the more human side of web development, and how we can all feel better about the jobs we do. I believe that the better we feel about what we do, the better the results of our work will be for everyone. The reason I want to write about pair programming is entirely selfish. It’s something that makes me feel much, much better about the job I do and I want to share with you the reasons why.

I don’t want to give you a list of pros and cons. I think comparing the pros and cons is a bit impersonal, which makes it difficult to connect any of the benefits with your own experiences. Instead, I’ll be telling stories about my own and others’ experiences. I hope that these can click and resonate with you.

To me it seems some of the hardest things for a new developer, and also any developer who is just beginning at a new company are getting used to the company culture, learning how members of the team do their best work, and getting acquainted with the codebase.

At work, we have dev couch every Monday. All the developers sit together for an hour to discuss what they’ve been working on. We recently began to collect topics we’d like to take a deep dive into. One of the senior developers suggested we discuss the idea of starting cross-team code reviews. His thoughts were that, while it was a smaller step than launching straight into pair programming, it wouldn’t exactly hurt the levels of communication, collaboration, and knowledge of the company codebases. Over the next few weeks, he gently reinforced the idea while reminding us that we could take it slowly, and nobody was forcing us to review or pair with each other all the time. This casual and unpressured approach helped the practice to become more common. And I loved it - it helped me feel more comfortable communicating and collaborating with other developers.

As code reviewing increased, I started to feel better about asking for feedback on my work. This is something I can find hard to do because I rarely want to bother busy people and don’t want to be seen as incompetent. It also made me feel like a more integral part of the company as a whole, and I know I’m not the only developer who began to feel more like this. The all-around good vibes reminded me of a past experience of mine that I want to tell you a little story about.

It’s about one interview I attended in London last year. I sat with a lovely senior developer who told me we were going to solve a coding challenge together. He must have sensed my nervousness because he began by reassuring me that I wouldn’t be doing it all myself, and the exercise was to get a good idea of how I work. We chose the ‘game of life’ challenge. I hadn’t heard of it before. We got straight into it and with what little Javascript experience I had, we got through a good amount of it in 45 minutes. Afterwards, he had a lot of encouraging things to say to me and I felt comfortable and valued by him. I did end up taking another job in the end because London is just so expensive. However, I won’t ever forget how it took less than an hour to feel valued and worthy as a developer, and during an interview no less.

I heard such a variety of things from other developers who I asked about pair programming. Every story was different. Nobody had had the same, or even a similar experience with pair programming. Some people had always done it, some never. Some companies only pair program! Some had never wanted to, and some want to but can’t. Some only ever found one person they were really comfortable pairing with The message that rung loud and clear is that pair programming doesn’t work in every situation. That’s fair enough. There are many factors at play. Here’s a little story from one developer I talked to.

This developer said to me: "For years, I didn’t pair program. Then I started working with a new developer. I was very much into high-end CSS and code quality, and my new friend was a fantastic problem solver (which I wasn’t). So, we both managed to learn from each other and the resulting work was just better than what any of us could have done on our own. We ended up pairing for months, and for 6 to 8 hours a day! Especially on complex stories. Despite reservations from our product manager, we enjoyed success. The reasons I see for our success are as follows: Our skills complemented each other, we could see the big picture and edge cases more clearly, mistakes were minimised, we reduced the knowledge island and bottlenecks, we gained shared ownership of the code, and pushed each other’s learning and expertise further." To bring a dose of reality to this warm and fuzzy sounding tale, the developer finished their story reconfirming my suspicions that pair programming isn’t for everyone. They told me that they know developers who simply prefer working on their own, or need space to focus and be in the zone. The fact that everyone has different personalities, means pairing with others shouldn’t be forced upon anyone, and even if people do pair, there is no set time limit or a set way to do so.

So, there’s no roadmap. There’s no step-by-step guide in a readme file to successfully install pair programming. In the end, it all depends how you feel about it. Well, and how your company feels about it. In essence, it is flexible.

For a hint at how flexible pair programming is, I want to take a quick look into some of the different types. For the sake of clarity, I’ll describe junior developers as novices, and seniors as experts.

We have the one that most people probably think of - the driver - navigator. This is the one I described at the beginning. It's where the driver uses the computer and controls the main actions. The navigator answers questions and points out potential problems. This can work for an expert and novice where the novice is the driver, but it can also work great for two experts as well.

Then we have the backseat navigator. Like driver-navigator, the driver sits with hands on the keyboard and types. However this time, the navigator dictates tactical instructions. This could mean telling the driver when to create a method or open a new file. Or what to name a test or a variable. This style works best with the novice as driver, and the expert as the navigator. It gives the novice (i.e someone like me) a chance to learn by doing things the way the expert would.

The last driving-based metaphor we have is the tour guide. Imagine being a tourist, getting on a bus, enjoying the scenery while someone explains to you what you are seeing. This works really well when the novice is the tourist, and the expert is the tour guide. The expert does the technical thinking, the problem solving and the typing, and, crucially, explains what is happening at every turn. This is the type of pairing I did right at the beginning, and I still do a lot of today. Again, the roles can be switched - with the novice being the tour guide and the expert being the tourist.

Lastly - and nothing to do with driving, we have ping-pong-pairing. This is the most fun type to say out loud. It’s all about unit tests and test-driven development. The first person writes a failing test and the second gets it to pass. Then the second person writes a failing test and the first gets it to pass. So people take it in turns to be on the ball. Kind of like a game of ping pong. This can work well with any combination of novice or expert because it really facilitates communication and focus, and keeps both members of the pair thinking and learning.

Remember how I mentioned that we began to do more code reviews at my work? I want to leave you with one more story that I heard recently.

Two developers I work with (and who also began to take part in the cross-team code reviews) recently decided to spontaneously pair up on a complex set of tasks. Afterwards, during dev couch, they told everyone that they’d achieved beyond what they’d expected, and were really happy with how things went. I asked what type of pairing they’d done, and they said there wasn’t a defined type, and they'd both switched roles a lot. They also said they’d managed to pair for 3 or 4 hours in one afternoon, but thought doing more than that may be too tiring. One developer told me pairing had been really enjoyable as it had enabled both of them to focus really well on the task, and provided much less opportunity to drift off-task and do things like re-factoring code or checking messages. Conversely, the same developer also told me that they usually get the most work done while doing home office.

So, what I am trying to get across with all these stories is that pair programming is a flexible thing with no strict set of rules. It can start with something small like occasional code reviews. It can be something to try to see whether it works well, and bring a pleasant surprise when you find out it does. It can work well for some developers in some circumstances, and not in others. It’s not something that has to be entirely formalised and it can be fit into what works best for you and your team. By the way, after our last retrospective, my team and I created an actionable item stating that pairing should always be considered for more complex stories.

What pairing means to my team mates is more robust code, a greater understanding of the codebase, and a closer relationship with each other.

What it means to me as a new developer is greater confidence, stronger connections with team members, and faster competency. It helps me feel like I am learning at a good pace, and allows me to get welcome feedback from other developers. As a package, this helps me to combat imposter syndrome and feel happier doing my job.

A collaborative exercise like pair programming helps developers of all levels to communicate, push each other forward, and feel more like a team. After all, a stronger team most likely builds stronger things.

Have a think about what pair programming could do for you.

~ This blog post is based on the talk I gave on Sunday 6th May 2018 at the Beyond Tellerrand Düsseldorf side event hosted by InVision. ~

Tempelhof Sunset

Sat, 28 Apr 2018 24:00:00 GMT

I love how photography allows you to be as creative as you like. I had some fun taking pics at Tempelhof Field today.

New Camera

Sat, 28 Apr 2018 24:00:00 GMT

I got a new camera. It's really lovely. Why do people buy cameras though? Is it to take pictures of their friends, to sit there looking pretty but gathering dust, or to attempt to be recognised as a terrific photographer? Perhaps it is all or none of these. I got mine because I want to have a cool, small piece of equipment on me at all times that I can whip out and make some memories with. I'm not nearly as excited to edit the crap out of the pictures as I used to be a few years ago when I was using my clunky Nikon D5100 though. I also want to take videos with it, and it takes 4K video. Pretty sweet. Although the built-in stabilisation is bad so I'll need one of those fancy stabilisers on a stick. Here are a few unedited pics I took at Tempelhof Field in Berlin (compressed to 0.43 MB in total, and 336kb for people able to view WebP images.

Apart From Code

Sat, 28 Apr 2018 24:00:00 GMT

Yes, exactly!!!!
— Amber Wilson (@ambrwlsn90) April 26, 2018

Apart from code, what makes a good developer?

After a brilliant meeting with Richard, the tech lead at my company, where we discussed my progress as a developer and what I could start aiming for, I came away with some (what I think are) really nice insights from our discussion. I want to share those here.

I think the advice here builds on my previous post from last month on beginner programmer advice. I am writing for everyone, but particularly for new developers, and particularly those developers who may feel a bit lost or hopeless due to the fast-moving pace of the web.

Ahem, so. Good developers. They write good code. Good code is their output, the end result of their work. It directly produces the stuff that people see. It’s tangible and visible, user experience depends upon it, and it’s what developers are paid to produce.

To be a good developer, it follows that the developer must write good code. Writing good code is hard. Much harder than I ever thought it would be. There are so many things to consider in the process. Many more things beyond producing something reminiscent to the picture below - i.e. the first sort of code I ever wrote and that allowed me an introduction to web development

Credit and big thanks to Frank Chimero for writing this article and providing the above picture.

To be a good developer. This is something I am still learning. But it is fun. Challenging, too. I’m sure I’ll get to the tips in a minute. It feels good to muse for a while, though, don’t you agree? Right, let’s get to it.

First and foremost, a good developer debugs.

I did read somewhere recently that web development isn’t so much about creativity, as much as it is about fixing wonky code. That while web development is an attractive prospect for those who want to create beautiful and tangible user experiences, developers have to know they’ll mostly be spending a long time debugging in order to make broken code work again. I’ve begun getting in the swing of this by writing console.log(); and debugger; into my (JavaScript - other languages have other methods) code. My developer tools are now always open, on a nice, big, separate screen to my browser, text-editor, CLI (other developers may prefer to use Git GUIs), and occasionally Redux dev tools. I am also learning where best to place my debuggers in my code, in order to get the desired result in my console. Something I’ve not done much yet, and I am still not so good at, is isolating code and placing it into either JS Bin or Codepen. Splitting code into smaller units, away from the other code it’s attached to. This is part of a good debugging process. Creating quick prototypes from parts of code where you have discovered a problem or bug. Apart from using console.log(); or debugger;, developers can also try commenting out include files one by one, to see if the problem lies in code outside of the file being worked on.

Ok, breathe. That was a chunky paragraph. The second thing I think a good developer does is follow the KISS principle. My British sensibilities are delighted by saying outloud the long-form of this acronym - “Keep it simple, STUPID!”. Personally, one of the things that overwhelms me as a new developer, coming from a different career, and only having been exposed to table layouts before, is the “here’s a brand new way to do this one thing”™ that happens every few days. I have been lucky, though, to have been (and continue to be) guided by some great people who constantly and kindly remind me that I can relax. See Charlie Owen’s brilliant article here for a deep dive into exactly what I mean. In short, web development doesn’t have to be as overwhelming it seems. Keeping things as simple as they need to be isn’t only something I hear from my friends who are developers. I hear it every day at work. It makes sense that developers build the most simple, MVP version of a feature they can, and then build on it later. This follows the principle of YAGNI (You Ain’t Gonna Need It). Building simple things makes sense because it stands to reason developers will lose a lot of time refining a feature, only to be told the refinements were unnecessary weeks later. I don’t know why I need constant reassurance that simplicity is best, but it is. Although to be honest, I am actually slowly getting better at believing it, and I can already tell I am producing better and faster code because of it.

Wow, that was an even chunkier paragraph. The third thing a good developer does is good research. I heard this one very, very early on in my web development career. Be a good researcher, aka, know how to Google an answer to a problem or issue. This is an art to be refined over time, as a developer discovers new nooks and crannies of the web that they never knew existed before. Some places are excellent sources of knowledge. I’ve gotten into the habit (does anyone else do this?) of bookmarking nearly every web page I visit that helps me find the answer to a development question. Knowing what words to use in the search bar is very important. It’s quite similar to academic research (something I had to get good at as a psychology student). Searching using the right language helps you find the right material. This gets harder when people use different terms for the same thing, or like to make up their own terms for things that already have names. Another tip is to check the source code of web sites and apps that do the kinds of things you want to do, and learn how those developers did those things. This is of course more difficult these days with the increasing tendency of developers to generate dynamic HTML using JavaScript (something else Frank Chimero talks about in his article). Anyway, to close this paragraph so it doesn’t beat the length of the second paragraph, I’ll leave you with a question. When should you reach out to other developers for help?

Following from the question at the end of the last paragraph, I’ll finish by saying that good developers should learn to work well with others. What does “well” mean? It depends on your team or the developers, designers, managers, and whoever else you have regular contact with. People in a team tend to be busy, and most of them appreciate being left alone to focus in order to get work done. I have found this to be especially true of developers. In my three months working on a team on a complex project in Berlin, communication has been extensively discussed, as much within retrospectives as out of them. Being a developer is hard, writing good code is hard. Developers have to keep in mind not only the three points from the previous three paragraphs (please recap those, they are important), but also often have to keep complex file trees in mind while desperately trying to focus. As well as this, developers need to think of the quality of their code, whether it is accessible, how performant it is, whether stylelint will accept it, how to alter config to allow a certain piece of code or new feature to work, etc. Regular discussion with other developers around good communication and respecting their space has worked wonders in my team. We are very happy to be working with each other. In the past weeks, I have been pinging other developers over Slack, rather than addressing them directly (this was an actionable item from a retrospective). I often catch developers over lunch, when they are away from their work and tend to be more relaxed. Here, I usually ask them how I could best approach them with issues, ranging from code structure to deployment methods, to CLI issues. Alright, maybe short paragraphs aren’t my thing.

Short extra tip that I just thought of - a good developer finds good developer tools. I won’t get deeper into this, but I think it’s important to mention. Having a good set of developer tools and utilising the shortcuts in these tools can improve a developer’s development experience. I am quite in awe of the workflow of more senior developers I work with. In a nearly indiscernible flurry of keys, some of these developers achieve the same series of events/outcomes that can take me twice or three times as long. While I do like the more manual way of doing things, I am slowly but surely coming round to using a set of tools (usually tools that are open source and maintained by hard-working developers in their free time) that shave more and more seconds of my development time and cause me to feel less stress. Oh and one other thing, good developers write good tests. I feel like writing a separate post on testing as this is a big part of being a developer (that I certainly wasn’t aware of when starting out).

TL;DR

Apart from writing good code (well, in order to actually write good code), a good developer:

debugs
follows the KISS principle (and respects YAGNI)
knows how to research
works well with others
finds good developer tools
tests code

Many other developers have written extensively about all of the above points. One nice article I found is this one by Dean Hume.

Please let me know what you think of these tips. If you agree or disagree, I’d love to hear. I hope you can help me learn to be a better developer :)

JSUnconf

Wed, 18 Apr 2018 24:00:00 GMT

The first unconf I’ve ever been to just wrapped up and it’s been a really great experience. Not least because of the thoughtful, kind and funny people I was lucky enough to spend it with.

First of all, I must say that I am exhausted from all of the fun, but I am tired in the best possible way. On top of the tiredness is a feeling of deep contentment, relaxation and all-round good vibes from my experiences. At the conference, everybody was approachable and easy to talk to. The organisers did a fantastic job of getting potential speakers together, introducing them and allowing us to vote for the talks we wanted. We were fed good food, given plenty of yummy snacks, and lots of great swag! The socks must be my favourite.

For those who haven’t been to an unconference before, this is how it works (well, from what I experienced this weekend) - those who wish to speak are asked to propose their talks before the conference so that the proposals can be collected and pitched at the conference itself. All attendees arrive for registration in the morning (pick up their swag!), are introduced to the conference, hear the code of conduct are shown who to talk to if there are any problems. Then, the potential speakers give short abstracts of their talks, which are numbered. After this, attendees are given a certain number of votes and asked to vote for the talks they want to see. The conference organisers work very hard to collate the votes and quickly produce a talk schedule for everyone. The talks are a defined length (~30 minutes) and are spaced throughout the day with breaks in between. There are usually some drinks tokens provided for attendees to spend at a bar where everyone gathers at the end of the first day.

At JSUnconf, there was also the opportunity to spend plenty of time relaxing outside with old friends and new friends, getting into some great conversations. The atmosphere the organisers provided for everyone felt wonderful to me. It definitely helped that Hamburg was kind enough to give us some great sunshine!

There were lots of little things I noticed that the organisers had put in place to help us feel more comfortable and welcome. Little things like placing toiletries and other helpful small things in the bathrooms. I am always so grateful for these little things. I think they make a big impact on how comfortable everyone feels.

Overall, I learned a lot from the talks and from chatting with the absolutely amazing people who attended. I want to thank all of the organisers for offering me a scholarship ticket including travel and hotel, and being so open and approachable even while running around for us trying to provide everyone the best experience. I always leave events like this feeling so good and motivated. I'm really looking forward to seeing my web (ONESIE!) family again :) By the way, watch out for my mood video, coming soon :D

Thanks to Dominik Kundel for inviting me and sorting out the Airbnb for everyone. You're a star!

House Elves

Mon, 02 Apr 2018 24:00:00 GMT

I’ve been wanting to write about psychology for a while now. However, despite having quite a few years of formal education in it, I was unsure where to begin.

My love of psychology is still strong, despite having left the formal study and practice of it behind a couple of years ago. I love to chat about it with people who are as interested as I am in the beauty and mystery of the human mind. I find comfort and growth in doing so. Lucky for me, I have some brilliant friends who I can sit with for hours, reeling off idea after idea, debating, hypothesising and marvelling at what we do and don't know.

Because of this, I want to finally begin writing about psychology. A friend of mine shared his opinion that writing about this is probably best left to experts. I tried to tell him I think that people should write about whatever they want. He argued that whatever he could write about psychology has probably already been written about a thousand times. I told him that I’m going to be writer number 1001, and I’m going to write something great that nobody has written before.

Recently, I have been feeling quite down and unenthusiastic about life. It’s definitely not the first time that’s happened. I find feelings like that always seem to spring from an ever-lengthening downward spiral of negative thought patterns. Along the journey, my enthusiasm and optimism begin to shut down, I withdraw into myself and begin to do the bare minimum to get by. I begin to feel like a burden to people around me, I never want to bother anyone with my feelings, and nothing seems worth doing.

I have a terrible habit of being consumed by negative thoughts, and letting them dictate how I live my life. It definitely feels easier to do that, to be puppeteered by an unknown but powerful force, than to take your rock-climbing tools, and scale yourself to the top of the dark empty pit you’re in. Maybe this is due in part to laziness, to entitlement or to an inability to see how good taking control of your life can be. It could be none of those things. Who knows? That’s one of the many mysteries of being human that we may never find out.

Anyway, while I am prone to be a puppet in the story of my own life, I am also vividly interested in ways people are able to overcome this unhappy and rather pitiful theatre. Some days, I am able to gather enthusiasm to explore more ways to be happy and in control. One way I’ve been doing this recently is by reading.

Books, writers, libraries, research and anything else to do with writing have been things I have respected for a long time, as long as I can remember. Even so, reading has not always come naturally to me. Over my childhood, I read a few books here and there, but I never read consistently. Throughout my teens I read even less and my 20s didn’t get off to a very rich literary start either. Only in the past month have I picked up and dusted off my Kindle, which I’ve completely ignored for about three years, and begun to read again. And this time I am loving it. I actually look forward to coming home and reading. And, now that I am doing it, I really really wish I’d begun earlier. Everyone should read books. Not only one type, either. Fact and fiction both contain their own unique magic. Inspired by Jeremy Keith, I have decided to read a good balance of both factual books and novels.

So, I am supposed to be writing about psychology - in this case, how to be more in control of your life. I want to talk about one of my favourite things that I’ve discovered from a month of reading books. All authors have their own unique style - this is great! Being exposed to different perspectives and personalities is brilliant. Nearly all writers make use of metaphors to make their writing come alive and to give their readers an alternate angle to look at life from. This is invaluable for those of us that tend to wallow in our own negative and gloomy perspectives, gradually believing more and more that this is how things are meant to be and there’s no point in changing them.

Perspectives other than our own bring a breath of fresh air. They open doors and allow light to flood in. They wrap us in a warm, comforting blanket by letting us know other people go through similar struggles. There is a tonne of writing out there that exists because the author suffered through something. Suffering tends to give you a strong desire to prevent others experiencing similar pain, just like this author of this post about relationships. Writing books is a great way to tell your story of suffering to a wide audience. The book I am reading right now is called ‘Big Magic: Creative Living Beyond Fear’ by Elizabeth Gilbert. Her writing is beautiful and funny and whimsical and amazing. It’s also really down-to-earth. I imagine she is a really fun and interesting person to know. Anyway, amongst many lovely perspectives she shares, is one of my new favourites. One that I’m sure I’ll never forget. While talking about creativity, she says:

…the Greeks and Romans both believed the idea of an external daemon of creativity - a sort of house elf, if you will, who lived within the walls of your home and who sometimes aided you in your labors. The Romans had a specific term for that helpful house elf. They called it your genius - your guardian deity, the conduit of your inspiration. Which is to say, the Romans didn’t believe that an exceptionally gifted person was a genius; they believed that an exceptionally gifted person had a genius.

Perhaps this passage doesn’t make too much sense when read out of context of the rest of the book, but I wanted to share it because it’s something that made me feel good. It made me feel like it’s okay to not always be producing amazing work, to give myself a break and to not always put myself down (i.e. plummet down a negative spiral) when I feel less motivated and inspired than I did the week before. This small history lesson reminded me that humans aren’t perfect, and that people should never feel under pressure to perform all the time - unless they want to feel terrible about themselves. Sometimes my creative house elf goes off to do its own thing. It’s still there, and it’s still loyal. It simply sometimes needs its own space and time to relax and unwind. And so do I. I think you and your genius can be a good team, always supporting and building each other up, and reminding each other that its okay to take a break once in a while.

I imagine my house elf is a bit like Dobby from Harry Potter. A kind creature who always has something nice to say, and helps keep me positive. I think we all need a positive house elf in our life. What do you think?

Nobody Said CSS Is Easy

Wed, 28 Mar 2018 24:00:00 GMT

Wait, some people have said this. But I'd like to politely voice the opinion that they are wrong.

For almost two months, I have been working on a complex React project involving a complex SCSS implementation. I am new to such complex projects, and so have only just begun to really learn about what SCSS can do. And... there is a lot to learn. But, it is a beautiful mess ❤️

Before diving into the project two months ago, I refreshed my awareness of Sass basics. Then, I opened the project code in my text editor, and jumped in. I was dazzled by the lines and lines of multi-coloured code, immediately puzzled when I saw countless @ $ _ and, something I hadn't expected - functions. Up until now, I hadn't written much of my own SCSS, and to be honest, I still haven't. However, I am proud that I wrote a fully-functioning each loop in SCSS last week :)

I was actually inspired to write this article after another fairly long struggle trying to style a component. I had to add a focus state to a custom checkbox. This seemingly simple task led me down a few rabbit holes. I learned a lot about the difficulties of styling a custom checkbox (i.e. one that is not browser-implemented).

^ Browser-implemented checkbox styles

^ The custom checkbox style I wanted

After reading a few articles and finding lots of similar but differing opinions, I asked another developer, Nevan, to come and help me.

.cp-#{$type}__input:focus {
    ~ .cp-#{$type}__dummy {
        border-color: cp-get-color-action(cta);
    }

    ~ .cp-#{$type}__label {
        font-weight: 700;
    }
}

Above is code from the project. I knew I had to work on this specific piece of code in order to get a focus state on the checkboxes. See the little tildes (~)? Nevan pointed out to me that these can be used as a special CSS selector, making the general sibling combinator possible.

We talked through different CSS selectors and Nevan drew some out for me. Once I'd learned what the general sibling combinator does, I was able to write the below code, which gave me a nice focus state for my checkbox:

.cp-#{$type}__input:checked:focus {
    ~ .cp-#{$type}__dummy {
        box-shadow: 0 0 0 0.075rem cp-get-color(base), 0 0 0 0.2rem cp-get-color-action(cta);
}

I have come to realise that a lovely side-effect of working on a large project & using SCSS has been an increasing awareness of how & where to implement accessibility. I will write about this in another blog post. One thing I gained a stronger awareness of (simply from working with checkboxes) is that it's important to progressively enhance UI components, so that a fancy custom one is able to fall back to the default browser styles and functionality. This way, a user can still access the UI if JavaScript or CSS fail.

In conclusion to my first two months on a big project, I now know that getting confused, spending a long time studying many different files & folders, and asking other developers for help is a right of passage to becoming a better developer. I completed CSS Diner a long time ago. However, nothing increases your learning power more than working on something big, real, confusing and frustrating ;)

Books

Fri, 23 Mar 2018 24:00:00 GMT

I am starting this post almost 4 months too late, but I want it here so I can be kept (at least a little) accountable for starting (and finishing!) as many books as I can.

Most of the books I read are recommended by friends. Any others will either be completely random or based on my interest in science, design, psychology or philisophy. Some will be about things that I really think I should know more about, like politics.

Here are the books I have read so far:

Shakespeare - Bill Bryson

A really cool insight into just how hard people have tried to gather reputable, solid evidence about Shakespeare's life and who he actually was. Throughout, it becomes ever clearer that the truth is likely forever lost. I loved the picture that's painted of Shakespearean London, and the antics of other prominent figures from the time period.

It's Not How Good You Are, It's How Good You Want To Be - Paul Arden

Rollercoaster of good ideas that were learned from a career in advertising. Stuffed full of tasty advice on how to be creatively brilliant. Insights into the minds of clients and what they really want. And that they don't want what you think they probably want. We may all hate adverts, but really we are all selling something. "We are all in advertising. It's a part of life."

All Neon Like Love - Dan Gennoe

First novel I've read in a long time, and I'm proud that I did! This story is a psychological, often dark, and always thorough, look into the mind of a man obsessing over a women he thinks he knows. We hear plenty about his sadness, his thoughts, his anxieties and concerns. Bit hard to get through at times, but I think it's worth it. I like how it made me feel a range of emotions, made me empathise with the characters, and painted vivid pictures using great descriptive language. Think those are signs of a good book.

Big Magic: Creative Living Beyond Fear - Elizabeth Gilbert

Where can I start with this book. I've never highlighted a book so many times, never read something and thought "yes, I do that" or "that's me!" so many times. This book contains messages that I will never forget. Messages that people are probably generally aware of, but that get buried under fear, anxiety, lack of confidence, doubt etc. It's a rare thing for me to read something and feel so confident that it has changed my life for the better. But this one has. The wise, funny and completely relatable Liz Gilbert has an honest, no-bullshit conversation with you. A conversation that feels like it's over coffee and she's known you for years. Thank goodness for people like her.

Women and Power: A Manifesto by Mary Beard

A short and thought-provoking book. Mary Beard deconstructs some of the history behind the lack of women in power today. She uses clever and interesting analogies and brings together pieces of information that I am sure people who aren't looking might miss. I wish it would have been longer. Definitely a good read for anybody curious about the balance of power between men and women in various positions.

Psychology for Designers by Joe Leech

A sweet and short introduction to psychology and design. Joe tells us his story, his experience with academic psychology and human computer interaction. He provides many examples and resources. Reminded me a lot of my own academic studies in psychology. My favourite part was at the end of the book in 'Extras' where he talks about myths and key findings in those areas of psychology that are most important to design. I particularly like the idea of mental models. A really nice little book. There are some spelling and grammar mistakes but I'm personally nitpicky about that stuff.

Real - The Inside-out Guide to Being Yourself by Clare Dimond

At risk of sounding cliché... where has this book been all my life? I've never read such a pure, real or beautiful book. I repeat the words inside it to myself daily... "There is only the moment, we are merely an idea of a self, thoughts rushing through us like waves. We only exist in the prescence of another. We need nothing, we are already all we'll ever need". Another life-changing book for me. Absolutely and completely.

A Man with One of Those Faces by Caimh McDonnell

I'm not one to usually go for crime novels, but the prologue made me laugh so I gave it a go. A great thing about this book is that it's set in Ireland and that the author has portrayed everyone's accents and personalities perfectly. The characters are great. I love the way the story twists and turns and is really not that predictable at all. Looking forward to reading the next three books in the series!

The Day That Never Comes by Caimh McDonnell

Just as funny and surprising as the prequel!

The Curious Charms of Arthur Pepper by Phaedra Patrick

A lovely book that had lots of English-y things for me to identify with. It is very centered around communication between family members and about the struggles normal people face. There were lots of moments that had me nodding my head and feeling emotional - especially where Arthur was reflecting about his life. Really glad I picked this little gem up.

How To Stop Time by Matt Haig

Saw a friend reading this on Sunday afternoon, July 8th and by Tuesday evening, July 10th I had finished it. Beautifully and poignantly written. I could barely put it down and couldn't wait to pick it up again. I got lost in the fascination of a person's experience through time. Great messages in the book as well. I am sure anyone would enjoy many of the quotes in there. I loved it, loved it, loved it. Even if it rather often reminded me of a movie script.

Notes On A Nervous Planet by Matt Haig

I had high expectations of this book, because the last book I read by Matt was so good. Unforunately I didn't like this one as much. The subject matter is great, but it felt as if the book was rushed and could have used a much more coherent structure. That's not to say I didn't get anything out of it - I did. I love any honest portrayal of mental health issues and ways to move forward. The content could have been organised a lot better. I sped-read the last 50 pages.

To Be A Cat by Matt Haig

I bought this third book by Matt Haig after reading glowing reviews. I knew beforehand it is meant as a kids book (although I am really unsure what age) but that it was okay for adults, too. I am unsure of the age because some parts are a bit more graphically described than they need to be and I didn't like that the main character has freckles and this is made out to be a bad thing (?!). Skipped over a few pages. There is a nice message hidden there somewhere about how it's important to be yourself and like who you are, but some of the ideas and writing style I didn't like much at all.

Angels in the Moonlight by Caimh McDonnell

Didn't realise this was the prequel to all three of Caimh McDonnell's Dublin crime trilogy books. I loved how there was so much Bunny in it, and you've got to read it to know what I mean. Very interesting characters, with even more interesting stories and ideas. There were parts that had my eyes glued to the page. There were parts that made me laugh my head off (metaphorically, not literally). This book, like its relatives, are so clever. The language and humour is a total delight. Super duper happy I stumbled across this series.

American Psycho by Bret Easton Ellis

I didn't really get it. I think the message is supposed to be that we shouldn't be too materialistic, and some people are psychopaths. Was difficult to finish because nothing about it really hooked me in.

Animal Farm by George Orwell

Tried reading this as a child but couldn't get into it. I was glad to be able to enjoy it this time. It's fascinating for a few reasons. First is the writing style, which is understandably old-fashioned as the book was written in the 1940s. Second is how it reminded me of how society is fed lies to keep everybody calm and placated, most often for the benefit of the few. Third is the real-life events the story was based on. I only glanced at the Wikipedia article so far, but I recommend giving it and the book a read if you're interested.

The Man I Think I Know by Mike Gayle

Got this because of glowing reviews saying what a feel-good novel it is. It started out alright, because the format of the unlikely friendship seems unique. The entire book lacked any sort of depth for me, though. It's written in such a pallid, bland and sickeningly oversimplified way. I rolled my eyes at least a few times throughout. I don't understand how people could be crying and so deeply touched by it. Each to their own.

Eleanor Oliphant is Completely Fine by Gail Honeyman

A friend recommended this book via an Instagram story. She said that the story gets into the main character's head and deals with all the emotions. This is true. I found the book hard to get into at the beginning, but the last half is better. Some characters I liked, some I wasn't so sure about. There have been some people that bash the book's attempt to highlight the effects of trauma and I can understand the criticism, but it still gets some good points across in my opinion. Would be interested in the same sort of story where the main character experienced more subtle sorts of abuse than the main character in this book, since I believe many thousands of people suffer much more hidden sorts of abuse.

Beginner Programmer Advice

Tue, 13 Mar 2018 24:00:00 GMT

I realised I published Newbie Dev Tips nearly seven months ago. I found it super interesting to reflect on my opinions then versus now :)

If you want to get really good at a programming language, write stuff in it over and over, and only then take a deep dive into reading a book or watching a lot of tutorials about it. I’ve heard and lived this advice myself one hundred times over, and when I inevitably stray from it, I always find myself going back.
You can’t know it all. Even if you try for a hundred years. All developers, no matter their experience, still poke around in the dark trying to figure out what works.
In the beginning, shorter and more basic tutorials are best. However, it can take time to find a tutorial that explains things in a way or context that's right for you. If a tutorial doesn’t feel right, look for more and you’ll find one that speaks to you.
Learning a programming language is sort of like learning a spoken language – take a look at the similarities between them and how people best learn to speak a language, and I think it’ll help guide you to learn a programming language.
Do try to search for and attend local events and meetups near you. My network of friends who work on the web is worth its weight in gold.
Talk to as many web people as possible. Some of their stories will amaze you, and you will learn so many different things from them. However, remember that everyone has an opinion and it’s best to receive advice light-heartedly, and not to take anyone’s opinion as law.
Try to focus on one thing at a time. This can help you avoid being overwhelmed and experiencing racing thoughts like “how did anyone ever learn how to do this?!” or “I must not be cut-out for this”. See earlier point about how nobody can ever know it all. It's also a general rule that many more abstract or complex topics can escape your attention in the beginning. You're bound to run into them again, and by then you'll be better prepared to understand them.
You may have to spend days or weeks on learning a single topic or a small part of what a particular language can do. Don’t pressure yourself. Going at your own pace and enjoying yourself is what matters.
The most important thing is to not give up. You’ll have good days and bad days. Sometimes the bad days are so bad that you begin to wonder why you should tap yet another key. The good days will shine like a bright light, feel so amazingly satisfying, and make you feel on top of the world.
If I had to choose my favourite thing that programming has taught me so far – it’d be that nothing needs to be perfect. Conditions don’t need to be perfect before you start, they don’t need to be perfect during a task, or even after the task is done. This lesson has impacted more than one area of my life in a really positive way.

Unit Tests

Mon, 05 Feb 2018 24:00:00 GMT

This is a bit of a retrospective post, because the things I’m going to talk about happened on the last day of January. It was the day before my new job began, and I’d been in Berlin for 10 days. I had signed up to a codebar Berlin meetup about a week before, as a student, and was really excited to go along and see what codebar in Berlin was like. Before I moved to Berlin, I’d been part of codebar Brighton for about 1.5 years as a student, coach and organiser.

I had chosen to focus on the 7th JavaScript lesson – Introduction to Testing. There was a good reason for this! After my first 6-month long internship as a web developer, I had either worked on or had an overview of a few large projects. I'd seen every developer devote a really large chunk of time to testing their code - and in multiple different ways. So I knew that testing is really, really important, and I definitely wanted to know more about it. I knew that unit tests are designed specifically to test code in isolation, and that they are the simplest ones to write and run. So, I decided I wanted to ask my coach about unit tests, and hopefully try writing some.

When I arrived at codebar, I found the venue, hosts, organiser, coaches and students to be really wonderful. I was paired with a lovely guy, Dave. I asked him about unit tests and he said rather than follow the tutorial, it'd be a nice idea to search through one of my existing projects, take a snippet of code from it, and re-write it using unit tests and TDD (Test-Driven Development). I've written more about TDD below.

The code in question was this function:

function validatePrice() {
  var $price = document.getElementById('price')
  var priceValue = $price.value
  var regex = /^[1-9]\d*(((,\d{3}){1})?(\.\d{0,2})?)$/
  var invalidMessageNotDisplayed =
    document.querySelectorAll('.invalid_price_span').length <= 0
  var isValid = regex.test(priceValue)
  if (!isValid && invalidMessageNotDisplayed) {
    showInvalidPriceMessage($price)
  }
  return isValid
}

This function is designed to validate user-inputted prices. It isn’t the messiest function ever, but there is definitely room for re-factoring.

Dave suggested we use the popular testing framework Jest, and the command line, to help me re-write the function, and write my first ever unit tests.

I created a new folder with the command line mkdir price, I targeted the folder cd price, and ran npm init. My package.json data was created. I then ran npm install --save jest. My package.json then looked like this:

{
    "name": "price",
    "version": "1.0.0",
    "description": "",
    "main": "index.js",
    "scripts": {
        "test": "jest"
    },
    "author": "",
    "license": "ISC",
    "dependencies": {
        "jest": "^22.1.4"
    }
}

I opened my text editor and added my new price folder to my workspace. Within the folder, I created a file - validate_price.js. In here, I created an empty function - validate_price. Beneath the function, I made sure to add a line of code that enables the file contents to be exported - module.exports = validate_price. I then created a sub-folder - __tests__. I formatted the name like this so Jest can recognise it. In this sub-folder, I created a file - validate_price.spec.js, which Jest can also recognise. In this file, I wrote - var validate_price = require (‘../validate_price’), to link it with my validate_price function.

Dave then showed me the syntax for writing unit tests with Jest:

describe('validate_price', function() {
  it('accepts numbers without decimals', function() {
    var result = validate_price('45')
    expect(result).toBe(true)
  })
})

I had just written my first ever unit test! I ran npm test in the command line, triggering Jest to run. The result was:

The result helpfully informed me that my validate_price function was still empty (i.e. not defined). I then wrote just two words inside my function, ‘return false’. I ran npm test again. I got another failed test. This is because the expected value (boolean) had been ‘true’, and it had received the boolean ‘false’. When I changed the boolean to ‘true’, the test passed!

I then added a second unit test to my validate_price.spec.js file:

it('declines values with non-digits', function() {
  var result = validate_price('foo')
  expect(result).toBe(false)
})

What do you think would happen if npm test was run now? You may or may not have guessed correctly, but we get this:

This is because we have ‘true’ written in our function, and the expected result of this test is ‘false’. So our first unit test passes, and our second one fails. This is easily fixed by creating an ‘if, else’ statement that returns true or false, depending on whether the input is a number or not.

It was at this point that Dave began to further explain what Test Driven Development (TDD) is. This is an agile method whereby an empty function is written, and each part of the function is written just well enough so it passes a test written specifically for it, and is then refactored. This helps code to be as DRY and readable as possible. Read more about TDD here.

Dave also told me about red, green, refactor (RFR). Uncle Bob does an amazing job of describing this here.

the RGR cycle tells us to first focus on making the software work correctly; and then, and only then, to focus on giving that working software a long-term survivable structure.

In other words, write a unit test for a specific bit of code before you even write that code so that the test initially fails (red), write code that makes the test pass (green), then refactor the code to be readable, DRY, maintainable, and built for the future.

I had unknowingly already been doing this. I had written my first unit test before writing the code that it was meant to test. The test failed (red). I then wrote code, any code, that would make the test pass (i.e. 'return true'). The test passed (green). I then re-wrote the code so that it’d make sense to other developers. The code was refactored (refactor).

Next, Dave and I talked about my next task - how I could write code that would allow both unit tests to pass, without having to use an 'if, else' statement. We decided to use a regular expression. Dave helped me write the regular expression from scratch, which we tested using this cool site that I had never heard of. In the end, we came up with this, which looks pretty nice if I say so myself:

function validate_price(price) {
  var regex = /^[0-9]+$/
  var result = regex.test(price)
  return result
}

export default validate_price

A few minutes before codebar wrapped up for the evening, I wanted to ask Dave the difference between unit tests and a few other testing methods I have been exposed to as a new developer - integration tests, end-to-end tests and browser testing. He answered my question by drawing out the "testing pyramid" for me. This is explained really well here (there's also a video). Basically, at the bottom there are unit tests, above there are integration tests, and at the top there are user interface/end-to-end tests. The other kinds of testing (other than unit testing) are beyond the scope of this post, but I plan to write about them later!

Overall, I had a great time learning about Jest, unit tests, testing in general and using regular expressions. I love how unit tests allow developers to write really nice code that is more likely to be understood by other developers.

Inclusionary and Exclusionary Language

Sat, 03 Feb 2018 24:00:00 GMT

Today I attended the Global Diversity CFP Day – Berlin style. There were 13 amazing mentors and over 20 students – all of us hosted by the awesome Stefan Judis and Irina Botea in the Contentful offices. The day was pre-planned for us by the great Peter Aitken. We watched inspiring educational videos, had discussions and completed exercises. The exercise which struck the biggest chord with the participants was the one on use of exclusionary language within public speaking, and how we can work to be much more inclusionary. Two groups of around 15 people discussed and wrote their ideas down so they could be presented to everyone. Here were the things (formatted as issues) that my group discussed:

Issue #1: general language use

Words like ‘sexy’ or ‘crazy’ can make people uncomfortable, because the use of such words varies greatly across cultures and languages. Words like these that might seem low-level offensive or part of everyday conversation for some may be taboo and highly offensive to others. There is no way to tell if such words will be received as derogatory, so they should not be used.
Swearing can also make people uncomfortable.

Issue #2: addressing people in the audience

Even a seemingly neutral greeting such as “hey guys!”, which is appropriate in many but not all places, may confuse audience members, especially if English is not their first language.
When you address people, try to do so in a way that includes everyone, for example “hey everyone!”.
Women are not “girls”, just as men are not “boys”.

Issue #3: jokes

There are some jokes you may wish to include in your talk that seem normal to you, or that you may be desensitised to. However, there is no guarantee that everyone in the case for everyone in the audience.
Dry jokes (i.e. ‘dad’ jokes) that do not belittle or offend others in any way are usually acceptable, but conference organisers should always be informed. This is because the organisers of a conference or any public speaking event are the ones who know the audience best. They are the people to go to for discussing any jokes you wish to use.
Jokes should build people up, but never knock them down.
Don’t joke about other people's job titles, tech stack, or anything else. Never try to make yourself look good by belittling others.
Don’t translate jokes from your native language into the target language of the event.
Jokes that are designed to make fun of yourself, in an acceptable self-deprecating way, may be okay. Always check with the event organisers as there may still be people who will not understand such jokes.

Issue #4: potentially offensive material in your talk

As mentioned above, it is a great idea to discuss potentially offensive material in your talk with the event organisers before you present it to your audience.

Issue #5: stereotyping

Sterotyping may delight some audience members and offend others.
Leave it out of your talk altogether.
Never assume anything about other cultures.

Issue #6: sexualisation of speakers or audience members

This is never appropriate! There have been highly publicised cases of this, but it unfortunately still happens.

Issue #7: not knowing whether you’ve made the audience uncomfortable

Be open to feedback!
Present yourself as approachable!
On your last slide you could, for example, add some information that would give your audience the chance to provide anonymous feedback on any aspect of your talk. Also tell people they can approach you with feedback, but keep both options open for those who are more comfortable remaining anonymous.

Issue #8: leaving out attendees

This is a point for both speakers and all other people present at a speaking event – if you see someone looking lost or left out, ask if they need help, or invite them into your circle to join the discussion you are having.

Issue #9: audience knowledge levels

While giving your talk, ask your audience about their experience levels or what technology they have used before. This way, you can direct your talk content to focus more on what is relevant to those listening.

Issue #10: advanced vs. beginner

Be aware of the curse of knowledge!
When talking about a topic you know very well, you may leave out information that is relevant for beginners.
Do not feign surprise when the person you’re talking to knows nothing about your topic, as this can be condescending.
Do not assume someone’s level of knowledge.

Issue #11: complexity

Use the rule of least power in your talks – i.e. use the simplest language possible that will still convey the lessons or message you wish the audience to take away. This means make your talk as complex as it needs to be, but not more.
Being able to explain a complex topic in a simple or novel way is an indicator that you, as a speaker, really understand the topic itself.

Issue #12: exerting your privilege

Be aware of any privilege you may have, and be careful when talking about how much it benefits you.
You may, for example, want to talk about how great it is to be a digital nomad, spending time in lots of different countries while freelancing. However, it is good to be mindful that some of the people in your audience will not be able to do this because of visa issues.
Sometimes you may be able to help out less privileged people. For example, if a conference accepts your talk proposal and offers to pay for your flights and hotel, but your workplace has already agreed to pay, then contact the organisers and ask them to offer your flights and hotel (and a ticket) to someone who can’t afford it.

Issue #13: colour-blindness and contrast

For accessibility purposes, test the colours and contrast of your presentation before speaking. There are many tools for this. Here is one: lowvisiontools.barrierbreak.com.

Issue #14: distracting aspects

Be aware of and limit use of flashing, GIFs, complex or messy slides and laser pointers.

These were all of the issues my group covered, although if we’d had more time, there’d definitely be more!

^ group discussion :-)

I hope the issues we raised seem relevant to the topic of inclusionary and exclusionary language and practices involving public speaking. Please message me with any of your comments or own ideas!

January, Journey, Job, and Germs and Self-Care

Sat, 27 Jan 2018 24:00:00 GMT

This post details how my January has gone so far, my reflections on it, and has an important message at the end.

This January is almost over! How many of you have achieved goals you set out for yourself? And if you didn’t have goals, do you feel you’ve accomplished something good in the first month of 2018?

Sometimes goals you set for yourself don’t get accomplished for one reason or another, and that’s okay. It’s probably not healthy to beat ourselves up in any way for ‘failing’ to achieve a more or less arbitrary goal that we set.

As I was between jobs this month, I’d planned to spend the whole of January in coffee shops and libraries working hard at some personal web projects. This desire got put on hold practically the moment the new year fireworks began. I contracted a cold.

I thought ‘ah, this cold will go away in a few days, they always do, especially when I’m at work and I’m too busy to think about being ill’. However, I wasn’t at work, I was out of my routine and so I sort of lingered at home waiting to get better. Unluckily for me, the cold evolved into a really bad chest infection – I think it was pneumonia but I never found out for sure.

During the infection, I rested, visited an a&e doctor and got myself some decongestant, but didn’t do much else really. 10 days into the new year, I finally began to feel better but was still fatigued. The bags under my eyes told that story.

With around 10 days until I was due to move to Berlin so I could look for flats before beginning work in February, I couldn’t find any time to work on my projects between the logistical juggle of storing my things, packing, throwing things away, opening a new bank account, getting health insurance, finding temporary accommodation, and organising goodbyes with friends.

On the 21st January, I flew to Berlin. I spent the next 3 days moving my heavy suitcase around, spending time at my new office, meeting my new work mates, going to a cool meetup, and finding a flat. It was on the 22nd that I realised I was getting ill again. This never happens, right? Getting flu or a cold, and then getting another nearly straight after?

It had never happened to me, but there’s a first time for everything. To say I was gutted would be an understatement. With so much to see and discover in Berlin I was determined to double-down on this illness and recover as fast as humanely possible. I bought ginger, lemons, apples, oranges, 100% fruit juice, a re-fillable water bottle (thank goodness Berlin’s water is drinkable), and lots of other food.

I slept nearly all hours of the day for the next 2 days, ingested about 5 different sources of vitamin C, took my multivitamin I’d been neglecting, and ate lots of food. I began to feel better fast. The infusion of vitamins and rest took my fatigue away. I felt like doing stuff again. I’m sure the oranges are the only reason I feel like writing this post.

When I reflected on the month, and about how ill I’d been, I realised that I’d expected my first illness to go away and to be fine within days. Did I treat the illness, or myself, seriously? No! I’d expected to be fine and bounce right back on track. I got reminded of something incredibly important this month – and that’s self-care. It could be because I’ve been out of my usual routine and had lots to do, but I think a lot of people neglect this crucial thing no matter what they’re doing in life. I’ll save the ‘but this is the world we live in now’ debate for another time because I think it’s really interesting.

From February onwards, I am going to make sure that, despite being in full-time work again, I’m going to treat myself kindly, sleep a lot, and eat plenty of healthy meals (something I definitely neglected the past few months). In other words, I’m going to be proactive instead of acting reactively after I’ve been pushed to breaking point. Being proactive rather than reactive is a good thing for any aspect of life – from raising kids, to staying healthy, to achieving a goal. Just don’t be so proactive about one thing that you neglect others – something I am also guilty of.

What Am I Looking For?

Wed, 06 Dec 2017 24:00:00 GMT

Equally importantly - what are you looking for?

What people want is important. And that’s never truer for web developers and for the people who employ them.

Hello people of the web. I am looking for a junior web developer position! Preferably in sunny Brighton by the sea 😎

However, please read on even if you are not based in Brighton!

As a junior developer who has just finished her first internship at a web design agency, there are many things I’ve learned.

The learning process has been great. I’ve tried so many different things and been able to form ideas about what I really like doing, how I like to work and how essential it is for me and the people I work for to look out for and support each other.

Over the past few weeks, I have enjoyed diving into varied and structured tasks that range from using HTML, CSS and JS all the way to PHP, content management systems (Craft CMS), and databases. Please see what I’ve been working on here.

I am really interested in working for a web design or development company that will be happy to help me continue learning and increasing my skills.

I am equally interested in giving back to the people I work for and helping them achieve exactly what they need.

I tend to like working primarily on the frontend and with the UI (especially using HTML and CSS), and am interested in working a lot with JavaScript. I am also very interested in working with back end technologies and knowing how everything hooks up.

Aside from this, I really do love learning everything and putting it all into practice. Whether it is front end, back end, best practices, semantic code, SOLID principles, documentation. Everything that goes into creating a successful product while working alongside a lovely team who also love to learn and try new things.

Speaking of trying new things, I would love to work somewhere that has begun to use and work with new and emerging technologies such as AI, VR and machine learning.

With my experience working in and studying psychology, I can provide a very useful perspective in my approach to development and the products I work on. I value communication and wellbeing in teams really highly and always want to look for ways to improve this - whether by talking to people, reviewing how we work, and helping to keep people motivated and happy in their jobs.

I love to be involved in the web development community as much as possible. From humble beginnings attending codebar as a student all the way to organising it, public speaking at three conferences (Material, NightlyBuild, and Bytes), attending and volunteering at many different conferences and events, and writing about psychology, tech and everything in between.

If you are a friendly and open company on the search for a junior developer who is insatiably curious, lives to learn, and loves to try new things, please get in touch either through Twitter or email :)

See my CV.

Looking forward to hearing from you!

Also published on Medium.

Remembering Why

Wed, 06 Dec 2017 24:00:00 GMT

(Originally published on SuperYesMore)

Your productivity is all about you.

I don’t ever like to advocate for lists like “10 ways to boost your productivity today”.

Productivity is personal. Everyone’s ideas about it are different. We all seek a definition of it, and when we find one that sounds sensible, we put precious energy into achieving it. However, if it’s someone else’s definition, there’s not a huge chance we will achieve it and this can leave us feeling bad.

Seeking an easy answer or universal definition for something like productivity is not unusual. Encapsulating something into one definition is easy and tidy. We can move onto the next thing quickly. It’s one of our many priorities we can attend to and then cross off the list.

Not only is it kind of useless to have one definition of productivity because it’s personal to each of us, but the way we feel about things is transient in nature. Emotions are fleeting, priorities get re-shuffled, things constantly change. What works for us at one point in time may not work at another.

Exploring what helps to increase your productivity at any given point in time is a great opportunity to learn about yourself. One way to begin this process is to think, and really get to the root of, why you do the things you do.

Before doing this, it’s really good to remember that trying to achieve a perfect level of productivity isn’t a good idea. In the increasingly competitive environments we find ourselves in, we tend to strive for perfection to try and stay ahead of everyone else. However, when we fail to meet the mark we set for ourselves, we become understandably disappointed. There is no perfect mark, there is only doing the best we can. Perfection isn’t an achievable goal, but doing our best is something much more within our control.

When I wanted to increase my productivity in my job as a web developer, I thought back to what excited me about it in the past. I used to enjoy huge levels of productivity and motivation just as I was beginning my new career.

I was reading articles and blog posts, watching videos, meeting more and more people in the creative community around me, enjoying connecting with them, having interesting discussions, and getting lots of advice. Part of the excitement came from everything being new. I can almost compare it to the honeymoon period at the beginning of a relationship. It was a great buzz. I also spent a lot of time outside in the job I had before being a developer, which helped me clear my mind and relax. Most importantly, it was way easier to give myself breaks from coding.

These days, I work inside for at least 8 hours a day as a developer. I have less time for the things that I really enjoyed about development in the beginning. Once I reflected on this, I remembered the things that used to really excite and motivate me. I then figured out some things I could do to enjoy more productivity in my job.

Three of these things are:

Connecting more with people at work and discussing things that interest me.
Paying attention to my work-life balance - going outside more and taking more breaks!
Not striving for perfection, and instead doing my best because I can always achieve that.

Through reflection about what motivated me in the past, I not only learned what it takes for me to be happier and more productive at work, but also what makes me happy and productive in general. I think it's possible to apply this reflection to any part of life.

Sometimes when we’re really busy and juggling a lot of things, it’s hard to remember why certain things are important. If we take time to reflect on where we used to be, where we are now and remember where we got our motivation for these things in the first place, it might help us be a bit more productive.

Public Speaking - I Did It

Thu, 26 Oct 2017 24:00:00 GMT

Originally published here: #upfront conversation with Amber Wilson

A couple of months ago, I arrived in Iceland to do my first conference talk and I want to share that journey with you.

A year ago, with years of psychology study and experience under my belt, I moved to Brighton to begin my path towards becoming a psychologist. Soon after, I tried out my first codebar meeting because I’ve always secretly been interested in Web development. On that first evening, I met some of the organisers – three incredible, confident and successful women – Charlotte Jackson, Rosa Fox, and Dorothy Wingrove. I was in awe of them. I remember thinking ‘Wow, how are these women so calm, so confident, and so accomplished?’ It wasn’t very hard to make the decision to go back.

Every single Tuesday after, I went to learn to code and hang out with the fantastic organisers and coaches. One of the evenings, I had a chance meeting with my future mentor, Jeremy Keith. I impressed him with my enthusiasm! I was lucky to meet even more people through him – one of whom, Joschi Kuphal, had heard that I’d studied and worked in psychology for years. Six months ago, he asked me if I’d like to speak at a brand new conference he was running in Iceland with a friend – one called Material that looks at what other disciplines can bring to Web development. I agreed right away because it sounded so exciting. The chance to go to a beautiful country, share what I’m passionate about, hear great speakers, meet interesting people, and help pioneer a cool new event? Yes, please!

I had six whole months to prepare, had great support from the people around me (especially my mentor), and I knew I could speak passionately about psychology – a subject I love. So, I rationalised I’d be okay!

I knew deep down, though, that I was woefully unprepared to get up and speak for half an hour in front of a large, expectant, intelligent crowd.

‘Not only had I not written such a long talk before, but I absolutely hated speaking in front of people – it wasn’t something that came naturally to me at all. In fact, I’d find any way to avoid it whenever I could.’

However, I do love a good challenge, and I always jump at chances to improve myself. Right away, I set to work on getting as much public speaking experience as possible. I joined a lovely, friendly Toastmasters club (where I found another brilliant mentor, Pat Young), attended a few public speaking workshops and practised my talk in front of people at every opportunity.

I heard tonnes of inspirational people speaking, either at conferences or online – I attended conferences such as Beyond Tellerrand, UX London, and Patterns Day. I watched lots of Ted Talks and Toastmasters speakers online and tried to analyse their speaking styles. I read books on public speaking – including ‘Talk Like TED’ (a book about how Ted speakers are able to give such good talks) by Carmine Gallo, ‘Speaker Camp’ by Russ Unger and Samantha Starmer, and ‘Demystifying Public Speaking’ by Lara Hogan.

I began to ask everyone I could what their number one public speaking tip was, wrote them all down, and was surprised to see that everyone said something different.

Some of the tips include smiling, not saying ‘I think I can do it’ but ‘I CAN do it’, owning it, not saying sorry if you mess up, PAUSING, etc.

I got warm advice and thoughtful feedback from the people who wanted me to succeed – which was everyone.

This is another tip to remember: everyone wants you to succeed – they are all on your side.

I spent countless hours taking in their feedback and altering my talk, practising it again in front of people, and altering it again. In the weeks before the conference, I began to feel so calm and confident speaking in front of people – whether they were big or small groups, full of people I knew, or full of people I didn’t know. A few months before, I was a nervous wreck speaking in front of anyone. I’d experience the familiar adrenaline rush, butterflies, and shallow breathing and would sweat, shake and clam up.

The day of the conference finally arrived. I’d been preparing for so long that it almost felt just like any other day. I stood up on stage, gave my talk – and… aced it! I was confident, spoke clearly, kept a great rhythm, and people congratulated me afterwards. I inspired the people in the audience! I helped make the experience worthwhile and thought-provoking for them.

Would I say to other women: ‘You can do it?’ Yes, yes, and yes. You can get up there on stage and share your ideas. In fact, you absolutely should, because you have so many amazing things to offer.

I think it’s extremely sad when women shy away from the stage because they think nobody can learn something from them, or nobody will listen to them, or they’d rather be pushed off the top of a building than speak in front of people.

I am living proof that with some focus on practising your skills, you can completely turn yourself from super-scared to super-speaker in a few months! All the advice, all the support from mentors and friends, all the practice, all the hard work, all the feedback, all the reading, all the getting out of your comfort zone, it all works.

I’ve never used the term miracle to describe anything before, but this is exactly how I describe what happened to me. I improved so much in such a short time, it feels like it simply can’t be real. But, it is real and I am reaping the benefits, as well as managing to inspire other people in the process.

I am showing women that we can be up there, that we are important in this industry. I really can’t wait to do more things like this. And, I’ve been challenged to wear heels next time I do a talk. I think I will do that. Challenging myself has been a wonderful exercise so far – why not see if this is the case in the future too.

If you are currently trying to think of potential topics for conferences and you’re stuck, try a small exercise. Write down the things you are most passionate about. Great speakers are always passionate about their topic, and this shows on stage (it also shows if they have little interest in it). I love psychology and the Web. My passion was with me from my initial ideas through to getting up on stage to talk.

I’m based in Brighton and would love to meet you if you want some more tips on public speaking, if you are working on a talk, or if you have ideas you’d like to make a reality! Let’s get your voice heard!

I’m itching for my next conference invitation so if you’d like a speaker to talk about psychology, tech or anything in between please do get in touch with me on twitter @ambrwlsn90 or email me at ambrwlsn90@gmail.com!

JPG? PNG? SVG?

Mon, 25 Sep 2017 24:00:00 GMT

There is a room that contains all there is to know about images. The door to it is locked. Most of us have casually peered through its keyhole or witnessed light of various colours and brightness spilling from it. If you are granted a guest pass to the room, beware. Akin to JK Rowling’s Triwizard Maze, you are likely to get lost in its twisting passages, or be usurped by something surprising along the way.

Most of us know that when building stuff for the web, optimising HTML, CSS, JavaScript or whatever else is good – but if you don’t optimise images, all other efforts will be in vain.

I’ve always been in love with pictures but knew little of the technical details behind them. Now I realise there are more of these details than you or I would ever have expected.

This article barely scratches the surface of web image choice. Beyond its scope (to name but a few) are things like the maths behind image formats, GIFs, TIFFs, BMPs, use of fallback images, dots per inch, the webP image format, decreasing image requests, image metadata, image scaling, browser rendering differences, automated optimisation tools, saving for the web, sprites, lazy-loading, the picture element, srcset, re-use of images throughout a site, etc.

Here are a few questions to ask yourself that may help you plot a basic map of one tiny corner of the image room – whether to use PNG, JPG or SVG image formats. Of course, as usual, it depends, and you may not get it perfect but you can, and should, damn well try! ;)

How many colours do I need?

PNG-8 limits you to 256 colours, which is enough most of the time, has by far the smallest file size, but may exhibit “banding” of colours. If you need more colours or want to avoid banding, consider PNG 24 or 32, but be aware of huge increases in file size. JPGs can contain millions of colours and have much smaller file sizes, but are best for photos where there are no crisp lines or text. For pictures with crisp lines or text (e.g. a graph), stick with PNG and compromise on the number of colours you use. Replace PNG with SVG for simple line drawings, logos and icons.

Bonus fact: the way PNGs are structured means two near-identical files that are separated only by a size difference of a few pixels may differ dramatically in size.

Do I need transparency?

JPGs don’t offer this (although some people came up with clever hacks to merge SVG with JPG to make a transparent JPG - see here). PNGs and SVGs support transparency. PNG-24 will likely give better quality than PNG-8, tempting you to create a large file. SVGs are transparent by default and can be a lot smaller.

Do I need the whole image to be sharp?

JPGs are lossy meaning they lose quality when compressed or saved, plus they are raster-based meaning they don’t scale well. They are best used for more complex photos that have many colours - not illustrations, logos, web comics etc., where sharpness of every line is important. Another good thing is that you can selectively blur parts of a JPG, leaving more important parts sharp, but shaving more of the file size off. PNGs are lossless, so don’t lose quality when compressed or saved. This makes them a good alternative to JPG when you need crisp lines or text. However, they can be large in size and are also raster-based so won’t scale well. SVGs are vector-based and scale incredibly well, remaining sharp at any size, but aren’t suited to photos or more complex graphics.

What devices do I need to optimise for?

On retina screens, JPGs rarely look good and PNGs have trouble scaling. SVGs look good and will scale. Support for JPG, PNG and SVG is good across all browsers, and there are work-arounds available for older browsers (e.g. IE6 to IE10). There are ways to provide back-up images to help browsers choose which format and size of image to render, depending on screen size and resolution - but these deserve their own dedicated article.

TL;DR

JPG – lossy and raster-based, use for photos and images with loads of colours where crisp lines aren’t absolutely essential. They won’t support transparency, although there are ways around this.

PNG – lossless and raster-based, use for images that need crisp lines or text (but do not need to scale), need transparency, have few colours. There are PNG8, 24 and 32 – research the best to use for your specific case (see this great article)

SVG – vector-based, use for flat line drawings, icons, logos that’ll scale to any size while file size remains small.

For some heavy reading on JPG and PNG science, click here and here. These articles blew my mind!

Choosing image format is only one step towards optimising images on the web. There are many, many other steps to consider, and so, so much to learn! I hope you feel brave enough to explore more corners of the image room – it’s courageous people like you who will pave the way for the excellent web experiences of the future ;)

Nightlybuild 2017

Wed, 06 Sep 2017 24:00:00 GMT

Darkness. A good kind. The theatre dressed in purple and black hues. The theme colours. Quite empty at first, smattered with only a few people. Organisers, speakers and sponsors. Everyone calm and confident, or maybe hiding nerves well. Time moved fast. The seats, around 200, seemed to fill at the blink of an eye.

Stefan Judis spoke. His passion for web accessibility is uplifting. His ideas mean something, but don’t register as relevant to everyone. He is future-focused. He has smoothly conquered the human urge for immediate results. No easy feat and one that deserves respect.
Jana Beck spoke. Ideas are the possession of many. Making them real is hard. She does it. She takes ideas from start to finish. Incredibly well. Far beyond my abilities (for now). Her skills both perplex and delight me.
I spoke. Exhilarating and fun. Nerves not there. Audience seemed tiny. Learned things I couldn’t have any other way. Not from reading, talking to or even watching others.
Aminata Sidibe spoke. She’s foreseen something. Something wide-reaching. Matters to all of us. Personal fulfillment and happiness. A basic human right? Seems not. Society and individuals are only as strong as the weakest of us all.
Natalie Pistunovich spoke. Eye-opening barely describes it. We ignore the world. Our field of vision heavily blurred. Crystal-clear vision exists in story books. Her calm confidence drew me in. She laid out clear points. They’ll stick with me. In all the work I do. Some perspectives change people. Hers changed me.

Thank yous. Lights on. The seats empty in half a blink. What now? Some chatting. Some beer. Then it’s over.

Quality over quantity. Coming together is what we need. Inspiration plus connection plus perspectives equals sparks. A flicker of light that ignites, fueling confidence and passion for what we do. The massive energy put into a conference sits, invisible, in every corner. Each attendee gets a little bit of it. Then they go out to spread it across the world.

See Nightlybuild 2017 site.

3 Months Vegan

Tue, 05 Sep 2017 24:00:00 GMT

I watched the documentary “What the Earth” three months ago and became vegan the very next day – totally cold turkey – no meat, no milk, no cheese, no eggs, no honey…

Over the years I’ve spent time thinking about what the actual characteristics of meat and milk are (saturated fat and/or not actually designed for consumption by humans), and I’ve been wondering why we consume these things at all. Once I also saw how poor in quality meat and milk are most of the time (hormones, massive amounts of processing, shocking care of the poor animals), I began to scratch my head even more. The kicker was watching this documentary and being reminded once again how meat and milk industries are really, gigantic corporations who want profits and won’t stop at harming animals, people or the environment to get them. They’ll bribe, lie, use force, shirk responsibilities like animal welfare, environmental regulations, and quality control, and generally be pretty sneaky.

I know and feel the steel-rod-strong cultural ties that people have to these types of foods. I was myself brought up on a diet of cheap meats like fish fingers, turkey drumsticks, mince, hotdogs, ham, and more. I also began to drink my daily cup of fresh milk at school at four years old. Milk was always pushed as the essential liquid for bone health, and also general health. I think meat and milk are so ingrained in our daily lives that people take them for granted, barely questioning their consumption.

On the subject of consumption, since becoming vegan, I’ve felt my food choices sometimes limited and sometimes quite fruitful (pardon the pun). It depends where I go. I’ve consumed a lot of hummus, fruit juice, plus slightly more bread and pasta. I definitely need to learn some recipes that contain a lot more vegetables. On the plus side, I often get a break from carb-heavy stuff by happening across the odd vegan gem on a supermarket or café shelf. So, at the moment I’m eating more carbs and fat, but also more vegetables than I was before. I can’t quite tell if this is a good balance.

Many things I learned since becoming a vegan fall under the category of ‘you don’t know what you don’t know’ – meaning that if I hadn’t become vegan, I wouldn’t have experienced them and they’d be out of my awareness completely. I’m glad I have them there now. I found out how bad palm oil is and how different countries (i.e. UK v.s. Germany) give different levels of fucks about how much of it they stuff into their products for unassuming consumers. Germany won on the level of fuck-giving here. Thank you Germany. I was pleasantly surprised to receive far less eye-rolls (that’s not a food), head-shakes, and awkward smiles than I’d expected when I explained to people I’d become a vegan. Even my meat-loving family and friends. People have been very accommodating and kind about it all, which I massively appreciate. I learned how many different types of milk alternatives there are. I heard from some people vegan cheese is actually really good. I learned that some people don’t know what vegans can and can’t eat. Even people who work at restaurants with vegan food advertised on the window. I found out that most dark chocolate is vegan. I learned that someone who rarely drinks milk can now detect even tiny amounts in food, and that when I sniffed some shortbread the other day (a food I used to like), it smelt like rotten milk.

Newbie Dev Tips

Tue, 29 Aug 2017 24:00:00 GMT

I coached a new codebar student on HTML tonight. As she and I made our websites on owls, many tips for new developers popped into my head - in the order you see below!

Let me know your thoughts ❤

Developer tools - Developers use this every single day...it's awesome and super helpful, and smart devs know how to utilise it!
Text editor - Every dev has their fave one...they have tonnes of downloadable extras to help you create the perfect development playground!
Github - version control, collaboration with other devs, and code sharing... so many great projects and people!
Open source - Shared projects, diverse inputs, inspirational outputs... the spirit that makes the Web great!
Stack Overflow - A developer's encyclopedia... a good dev will spend time every day searching online for the best answers!
Readable code - Writing code and commenting for other devs in your team to read... hugely important for a happy developer environment!
HTML = structure, CSS = style - Very important to keep in mind... see CSS Zen Garden for the best depiction of this!
Devs aren't perfect - Even the super-super smart ones... everyone has gaps in their knowledge, and there are definitely things you can teach them too!
Networking - meetups, workshops, pair-programming, clubs, events... doesn't matter where, but it matters that you do it (good things happen)!
Learning - This is key to enjoying development work... learn, create, share, repeat!

Pictures, Psychology and Piano

Fri, 18 Aug 2017 24:00:00 GMT

Five days ago, I gave my first speech at Toastmasters - the first out of ten outlined in the official manual.

It’s 4–6 minutes long and designed to be all about the speaker — it’s called The Icebreaker.

Due to being busy with a conference speech, I was only able to speed-write this 2 days before giving it.

Nevertheless, thanks to the brilliant people who'd helped me practice my larger speech, I delivered this one fantastically!

Out of 4 speakers, the audience voted mine the best.

I think they were pleasantly surprised at how far I'd come since I started to attend Toastmasters as a guest a few months ago. Not nearly as surprised as I am though.

Here is my speech:

Pictures, Psychology and Piano

We all have a past, present, and future. This is something universal between all of us. We commonly tell other people about these things using stories. I thought up a little story to describe my past, present and future.

In my past, I spent a lot of time admiring pictures. Perhaps this love of pictures came from my mother. Always modest and humble, it was difficult to get my mother to admit she was good at anything. Although that didn’t stop her cheeks from glowing when you talked about her many skills. One of these skills was drawing. She doodled on napkins, scribbled on corners of paper while on the telephone, crafted beautiful greeting cards for family. When I was a baby, she painted lifelike cartoon characters on my bedroom wall. Every photo she took, she would print, date and organise neatly into labelled boxes. All of this meant that pictures were a natural part of my life. I drew my own pictures – portraits of friends, of animals and cityscapes. I took my own pictures, thousands of them. I spent hours editing them, posting them online and putting them on my wall. Additionally, I spent a lot of time admiring the drawings, photos and designs of others. They communicated things to me – ideas, stories, emotions. They connected me with what it is to be human and I loved that.

In my present, I use a lot of psychology. Although, I can actually count psychology as part of my past too, as I’ve been immersed in it for nearly 10 years now. Why so long? Well, it seemed like a natural thing to study for me. And I think this was partly down to pictures. They had fostered in me a fascination about the things that connect us – about ideas, stories and emotions. I studied a lot, then I worked lot, and then I studied again – this time getting my Master’s in Child Psychology. I’d known for a while that I would love to work with children, but it took me some time to figure out why this was. I thought about it and came up with the best explanation I could. I knew that childhood is the time we first begin to connect with others, figure out our emotions, and learn how we fit in the world. I remember it being a magical time of discovery for me – beginning with my Mum and her way with pictures, progressing through to me finding my own way with them, which opened up the joy of sharing and connecting with others –pause-. I became passionate about uncovering as many ways as I could to help children learn how to connect with others. I want every child to experience the magic of doing this – to help them discover the power of ideas, the delights of stories and the nuances of emotions.

In my future, I’d like to continue learning about the many ways to bring people closer together. I don’t actually work in the field of psychology any more – I work a Web developer. But, the world of Web development has so much psychology in it. It basically consists of a bunch of humans communicating with humans in order to make things for humans –pause- I haven’t talked about the last thing in my talk title tonight – pianos. I put piano in the title partly because it begins with ‘P’, which gives the title some nice alliteration, but also because the piano is something I’d really like to learn. After all, music is at least one other way to communicate.

So, I’ve talked to you about my past, present and future. It was one story. I could’ve crafted any number of stories about these things. And, this is something I might try. Each would be a piece of me I could keep forever. I encourage you to try it.

Also published on Medium.

Material Conference

Fri, 18 Aug 2017 24:00:00 GMT

Where do I start? The preconceptions I had about the experience were inaccurate. I thought it’d be an absolutely great day – a day full of learning about the Web, meeting cool people, and achieving my first big talk. Those things turned out to be included for sure. The thing is though... it was also so much more.

There’s an element of magic in the air that you get to grasp and breathe in when you gather in the same place with so many different people – people with stories and paths they could write books about. The passion, the ideas, the stories of difficult journeys (the behind-the-scenes that you never see on social media). All of this makes not a basic recipe for a good time, but one for a delicious, enlightening experience that I’ve not seen replicated in any other environment.

The hall was oddly calming – the carefully thought-out architecture making me feel peaceful. The podium was there, I checked my computer and everything worked fine from the start. I felt the tiniest pang of nervousness, but no more.

We started just a few minutes after 9am with a talk by Solidwool that taught me things I hadn’t expected to learn and won’t ever forget. Then the chocolate talk by OmNom – listening to the inner workings and philosophies of an upcoming, innovative brand of chocolate made in the heart of Reykjavik. I tried some of it and said I wished they’d always keep experimenting. Then it was my turn. I stood up on stage. I managed to smile. I gave my talk with as much passion as I could and hoped people felt that. Once I sat down, several people congratulated me, and more did throughout the day. The mini talk by Halldór was mesmerising. He achieves something incredible - pairing music and technology – a synthesis that can create original mixtures of sounds nobody has ever heard before. Next was a fantastic talk by Icelandic designer Goddur, master of his craft, who knows his material so well that he spoke with little or no prep and plenty of tonal variety in the right places (something I want to work on).

Lunch time was tasty, intriguing and culturally satisfying. We ate great food, talked in depth on a few topics, and enjoyed a hugely thought-provoking art gallery. After lunch was Tristan from the BBC talking about storytelling and the many different ways you can do this. This was very exciting to me. Then was Tristan, who also had little or no preparation, pouring forth her passion for Icelandic nature, meditation, and how she’s combining this with an exciting, up-and-coming technology. Even her voice made me feel I was meditating. I tried her VR headset and meditation program. I felt instantly calmed. After coffee, we heard from Dan who talked about remembering people in design – something overlooked but crucial. Then we heard Tommy who talked about Polaroid and going back to the physical, to what makes us feel all warm and fuzzy. I never knew vinyl sales was a billion-dollar industry now.

This conference was unusual. The speakers all so different. The location unique. How could my preconceptions have been accurate? They couldn't have been. I found though, that when you have little idea of what’s coming, you’re able to be so much more immersed in it. Something sparks, then clicks, then you see magic unfold before you. I gained a truly meaningful experience – one that I am immeasurably glad to have been a part of. Joschi and Brian – thank you for taking this conference from idea to reality and bringing us all together for such a special time. I have no doubt that people walked away invigorated and full of ideas about looking at different materials and how they can inform the Web. I can’t wait for the next one. I urge anyone to go - but make sure to make some room in your brain first. You're gonna need it.

Also published on Medium.

What I Learned Today

Thu, 22 Jun 2017 24:00:00 GMT

Today I sat with Russell Ward, technical director at The Unit. We talked about how I can get involved in the development team as part of my internship. This quickly turned into a discussion about programming languages and the Web.

I was introduced to a lot of topics, including:

SOLID principles - see video
1KB challenge - see example project
Domain-driven design theory
Functional, procedural, and object oriented programming

Throughout, Russell explained how he got into programming and what he enjoys about it. He likes to solve problems but also likes pulling problems apart and figuring out why they exist in the first place. It may be an issue today that new developers only do the former.

I explained the premise of my upcoming conference talk I'll be doing in Iceland at Material and in Cologne at Nightly Build:

I want to give people some inspiration to look back on where the Web came from, and get insight into what another discipline is doing. Other professions may have hundreds of years behind them - the Web is barely a quarter of a century old, yet most of its technologies are already outdated. What insights could we gain from architects, psychologists, engineers? Many established Web developers have grown up with and spent many years immersed in technology and therefore know its history and have a solid intuition about Web development. However, most new developers have almost no clue about how Web development got to where it is today. They are woodworkers with no idea of how the wood was grown, how heavy it is, or how to build something sturdy from it.

Russell explained how many new developers got into Web development for different reasons to more seasoned developers. In the past, to learn programming languages, it was a necessity to be motivated and focused. There were no university courses, bootcamps, video tutorials, CDs, or coding meetups. You learned through typing code, solving novel problems, and finding the smartest person you could in the hopes they'd mentor you. You learned what worked, what didn't and why. Today, there are still ways to learn programming in creative ways, but there are also other, faster routes that don't give so much of a solid, theoretical grounding.

I asked Russell if he thought mentorships or apprenticeships are a good idea. He explained that he has found various mentors over the years to be extremely helpful. Even the blunt, grumpy ones taught him a lot. I got the impression that Web development as a profession is no different to that of any other - it's best to learn it from the 'masters' - those who have been around long enough to have a grip on why things are done the way they are. I think it can help get people excited about solving problems in new and creative ways, which can only be good for the Web.

Public Speaking Workshop

Thu, 15 Jun 2017 24:00:00 GMT

Earlier this week I attended a public speaking workshop run by Matt Matheson. There were ten people in the group. We wrote stories. We played games. We presented. One hour in we had already talked in front of everyone four times. The lovely thing is – everyone did really well. We were all praised and given immediate feedback and I learned something new each time I spoke.

There was no time to sit in a corner and hide during the workshop. Had we been given that opportunity, I don’t think we’d have performed nearly as well. I think there is something great to having to think on your feet, be exposed, and present talks of various lengths and types. It feels like a worthwhile challenge that you take in your stride, allowing you to perform much better than you ever thought you could. I won’t go into detail about any of the exercises – the magic behind them has to be experienced in person.

I learned that other people have very different concerns and fears around public speaking than I do and that some of us share the same fears. I learned a lot about the importance of positive praise - both receiving and giving it. I walked away with techniques I will be able to remember and utilise for a long time to come. I learned that everyone is a natural storyteller and that you never come across as bad a public speaker as you think you do. There is always a way to harness your passion for a topic and translate it to confidence on stage. It's absolutely worth getting out there and talking about things that mean something to you. You'll always find people who want to listen and will learn something from you.

Here's just a tiny snippet of the things I learned from the brilliant attendees of the workshop under Matt’s guidance:

Say “yes” to invitations to speak
Integrate your facts into a story
Know, engage and connect with your audience
Be authentic - say the good, the bad and the ugly
Appeal to the audience members’ emotions as well as their minds

If you'd like to discover your own fantastic tips, you can get in touch with Matt here to ask about workshop possibilities :)

Very happy workshop participants - thanks Matt for the workshop and the pic!

URLs

Wed, 07 Jun 2017 24:00:00 GMT

Welcome to my learning process. Today I tried learning about URLs.

1: Sizzling Intro (Overconfidence)

URLs are still a killer feature of the Web. This is what Chris Coyier wrote recently on CSS tricks.

Cool!

So, URLs have stood the test of time on the Web, providing us from the very beginning with an unmanned gateway to information, ability to share things, and to search (where would we be today without our trusty search engines?)

URLs seem simple. You type them in and voila. There can't be much to them, right?

2: Lots of Confusion

Wrong. I found these. What do they mean?

3: Craving Different Perspectives

I learn by researching the same topic written on by different people (btw this is why you should blog). I found articles on URIs/URLs/URNs, e.g. here, here and here. I discovered lots of different, confusing terminology.

4: Listening is Learning

Desperate for some understanding, I watched two videos, here and here. I discovered simpler explanations and handy diagrams.

5: Drawing Pretty Pictures

I want to convey simply what a URL (and URI/URN) is. This inspired me to draw!

6: URLy Like This

This pic contains all parts of a URL I could find. Below are the (non-exhaustive) 1000 words it paints:

Scheme/protocol - Identifies a resource and tells you how to interpret the part of the URL after the colon. Mostly http/https/ftp, but there are lots more.
Subdomain - The default is 'www'. Tim Berners-Lee admitted this should have been 'info'. TBL also admitted this mistake.
Domain - A nickname for an IP address (the string of numbers read by computers) that identifies Web pages.
Second-level/top-level domain - For 'example.com', example is the second-level domain and .com is the top-level domain.
Port - 443 is the default port for secure web servers (https). 80 is default for http. Web servers can listen on a port specified by a user and otherwise are usually hidden.
Path - The part of a URL that is designed.
Query string separator - The '?' separates the query string from the other parts of the URL.
Query string/parameter - Set dynamically with an unstandardised structure, they commonly contain the the content of an HTML form. In the picture are 'docid' (document identifier) and 'hl' ( host language) with respective values of '720' and 'en'.
Fragment/anchor ID - Refers to an internal section within a web document.
URI - Uniform Resource Identifier. An entire set of directions for finding any sort of resource on the Web. Has two subsets - URLs and URNs.
URL - Uniform Resource Link. Identifies but also specifies network location of a resource. What most think of when imagining a link to a website, i.e. a Web address. Absolute URLs (i.e. including scheme) should link to external pages/images and a relative URLs should link to internal pages/images within your own site. This helps avoid broken links when schemes or domain names change.
URN - Uniform Resource Name. Specifies name of resource. Useful because they are globally unique and persistent over long periods of time, even after the resource which they identify ceases to exist or becomes unavailable.

6: Examples I Found

URN

urn:isbn:0451450523 - The 1968 book The Last Unicorn, identified by its book number.
urn:lex:eu:council:directive:2010-03-09;2010-19-UE - A directive of the European Union, using the proposed Lex URN namespace.

URL

URI

http://example.com/resource?foo=bar#fragment (also a URL)
978-0553293357 - unique identifier for a book (also a URN)

7: TL;DR

A URI identifies a resource either by location, or a name, or both. A URI has two specializations known as URL and URN.
All URLs and URNs are URIs (see argument against this here) but not all URIs are URLs and URNs.
Read my shorter, friendlier follow-up post on URLs.

IndieWebCamp

Tue, 23 May 2017 24:00:00 GMT

My experience of IndieWebCamp Nürnberg (check out the GIF at the end!) was complemented by Beyond Tellerrand Düsseldorf and the Evaluating Technology workshop by Jeremy Keith.

It was my first time attending any of these events and each brought its own unique experience.

The IndieWebCamp was split into two parts. On Saturday we gained inspiration from discussing different topics suggested by camp attendees. On Sunday we harnessed this inspiration and, alone or in groups, we got to work.

Through the continuous but pleasant hum of tapping keys and some select songs from a German radio station, we spent many focused hours working. The scope of the work varied quite a lot. A few of us were fairly new to the Web scene (me included), and we worked on making a number of small improvements to our sites. Some more seasoned Web developers had more specific projects in mind, from working with Grav and Jekyll (CMS), to tinkering with Webmention formats, to improving back-end systems using Node.js. Others were working on things like personas or information sites that will help encourage more people to learn about the IndieWeb. One attendee worked on a four-year old project involving creating decentralised social networking sites, with the ultimate goal being getting rid of Facebook.

We all demoed what we'd done - check these out here :)

Personally, I worked on HTTPS, site search, file extensions, HTML/CSS tidying, redirects, and passing IndieWeb levels one and two via indiewebify.me.

Thanks to Joschi for this shoutout.

Some of my takeaways from the camp were:

I might not yet understand how to use the hugely varied technologies that contribute to forming the Web, but that's okay. I can and should keep asking, doing and learning.
The developers at the camp were so friendly and encouraging, just like the developers I've met in Brighton. I've achieved so much with their help and am so happy to belong to a community of such nice people.
There is a point to decentralising the Web and I'm really glad to be part of the effort towards achieving this.
The idea of POSSEing (publishing on your own site, syndicating elsewhere) is very powerful and helps keep the Web independent as well as allowing you to own your own content.

Thanks to Joschi for inviting me and making my stay really comfortable. Thanks to Aaron for helping the camp run so smoothly alongside Joschi and Jeremy. And thanks to Jeremy for helping me with Web stuff.

Looking forward to future IndieWebCamps - hopefully the next one will be in Brighton in September!

Mobile First

Fri, 19 May 2017 24:00:00 GMT

Today I realised I wasn't adhering to a new, up-and-coming idea called 'Mobile First'...maybe you've heard of it?

Once I had written a correct media query to adhere to this interesting new idea, I noticed my site looked pretty ugly.

But still good on all screens less than 520px.

It is supposed to look similar on desktop.

I effectively had to switch my mindset around. Instead of thinking of everything inside a media query as belonging to the mobile part of my design, I had to imagine it contained the desktop design. And the place where desktop code lived before now resides within a media query. The resulting switch didn't take long to accomplish and gave me another chance to look at my CSS, and to tidy it up a little - always a good practice now and again.

In any case, I can now feel proud that my site adheres to the best practice of Mobile First design.

Btconf Düsseldorf 2017

Fri, 19 May 2017 24:00:00 GMT

What can I say? My first conference experience. Many thanks to those who made it possible - especially Joschi Kuphal. It was such a whirlwind of knowledge, meeting new people and enjoying good food & beer. All the while enjoying the unxepected but intense sunshine that had appeared after weeks of cold and rain in Germany. I am keen to return again and again, most of all to reunite with the kind, funny and extremely interesting people I was so lucky to meet there.

Storytelling

Mon, 08 May 2017 24:00:00 GMT

Today I was lucky to attend a workshop on storytelling held by Matt.

In two short hours, we did various thought exercises, shared our tips on telling good stories, and were asked to write and tell various stories - both factual and fictional.

At the end, we each explained what we'd learned.

My favourite take-away was that it's useful to include things in your story that are important to the people listening. This helps engage them. Some of these might be:

Themselves
Food
The company they work for
Explosions
Shock, awe & swearing

Some other things I learned about are that:

The delivery of a story is very important.
Having a beginning, middle and end is a good strategy - the end could be a moral or a cliffhanger. Ending on a point/punchline brings clarity to listeners. Conversely, people react well to suspense and surprise.
Adding intrigue, twists and revelations - topped with a satisfying ending - can keep listeners engaged.
People can relate to the protagonist (hero) and antagonist (villain) structure. Having someone to care about/root for, or to dislike, is useful.
Stories are innate to humans, and they make things easier to remember.
What makes a good story has changed over time.
Benefits include sensemaking, emotional engagement, advanced understading.
Having 'some friction in the fiction' - i.e. making people think and creating a balance of effort and reward - can keep listeners engaged.
Having believable characters is important - people can smell lack of authenticity!
Making stories silly/fun. A story can be what you make it. Why make it serious?
Using visual analogies helps - e.g. the pile of clothes was as tall as Mt. Everest. Images are enjoyable and easy to remember.

Storytelling is an incredibly powerful tool in the web developer's arsenal. It can help us build better relationships with clients, staff, friends, and family. It can help us better understand ourselves. As a communication tool it can be used as an icebreaker and a point of reference. I think it's in the interest of anyone and everyone to practice telling stories. It is a tried and tested medium for better understanding of ourselves and others. Go tell!

HTTPS Poem

Mon, 08 May 2017 24:00:00 GMT

A little poem about HTTPS. https://t.co/kTuK3Fr8Es
— CSS-Tricks (@Real_CSS_Tricks) May 12, 2017

Sending info over the Web?

If yes it pays to use your head.

HTTP is the protocol which

Can send data at the flip of a switch.

But did you think where your info’s displayed?

It could get lost or might end up astray.

We all like to login or buy things online.

But in doing so, will our data be fine?

Tricksters and thieves are watching and waiting

For your info they get by locating

The plaintext file containing your details.

This is where HTTP alone fails.

Have no fear, add an ’S’ to the end.

Then attackers cannot read what you send.

The ’S’ is short for ‘SSL’,

Something really very swell.

It helps you to encrypt your files,

And does this with integrity and style.

Data integrity to be exact,

Authentication, confidentiality and all that.

Your data is encrypted and needs the correct key

To be seen and read by you and not me.

To be certain SSL makes a site secure,

A certificate authority helps reassure

That a site is in fact the real deal

And not a fake, hacker-rich ordeal.

Of course SSL is not without flaw

But it always evolves and won’t ever withdraw.

If the information here is confusing to you,

There are others who have explained this stuff too.

Find some great info here, here, and here,

For those of you who are still quite unclear

On how HTTP can add just one little letter

To help make the Web securer and better.

What I Learned Today

Thu, 13 Apr 2017 24:00:00 GMT

At Clearleft today, I ran through many new (and some familiar) things with Jeremy:

We talked about Jeremy's upcoming event - Patterns Day (check out the site, it's nifty - also, buy a ticket!), to be held on June 30th. Jeremy kindly invited me along and I'm really excited!
I found out where Clearleft got their idea for the 100 day challenge - Aaron Parecki's 100 days of music!
I learned that these amazing color fonts won't be available for a while (sadly).
I discovered a nice example of excellent forward-thinking. The creators of the font-weight CSS property use 100-700 for weighting type, not 1-7. This is because they anticipated that more values could be utilised in the future. Now they can, with variable fonts.
Microformats rel values (a question about these sprung up when I coached at codebar earlier in the week).
HTML5 link types.
XFN - The HTML5 Friends Network. Jeremy has nice examples on his own site including rel="friend" and rel="met" in his 'bedroll' section.
Examining what rel="canonical" does (it helps Google reference original publications).
Twitter card validators.
I completed CSS Grid Garden. It was really fun and I like the specs a lot.
Jeremy has written things about CSS Grid. We dove into discussions about Grid, and also Flexbox. I learned how Grid and Flexbox were created by the same people and share a lot of vocabulary. This means they can both be utilised in the same stylesheet to suit different purposes.
I downloaded Firefox, as it has some nice developer tools for visualising a grid on the page.
I learned a little about product management in a 'brown bag' talk at Clearleft. Very interesting learning about exercises to coordinate teams and define roles (including those of clients) within a project and help everyone communicate better.
Talked with Jeremy about my upcoming Material conference talk. We brainstormed lots of great ideas that I wrote down. My next step is mindmapping to find some golden connections between ideas.
Chatted with Jeremy and Luke about roles that involve both front end development and UX. An area that draws heavily on both roles is performance, particularly percieved performance.
Jeremy recommended some books on writing - including Steven Pinker's 'Sense of Style', particularly the chapter on 'The Curse of Knowledge', and 'Bird by Bird' by Anne Lamott.
I learned of the Open Library where e-books are lent out free of charge.
Talked with Jeremy and Hannah about cookies, caching, and public speaking.
I was introduced to a number of very useful thought exercises I can have a go at once I have some content for my talk.
I discovered Google's Page Speed Insights tool for evaluating websites.
Jeremy set me homework - 'What is the Difference Between HTTP and HTTPS?'
Jeremy suggested talks that could help me with mine from Render Conference 2017 - Ana Balica's talk on HTTP and Frances Ng's rise from Aerospace Engineer to Front-End Engineer.
Jeremy introduced me to @supports in CSS, plus a neat way to load fonts using JavaScript that improves perceived performance by customising font loading behaviour.
Jeremy showed me the difference between not using the font-loading method vs. using it. There was a really large difference in perceived performance (font loading was better, despite the page loading slightly slower).
Jeremy showed me 4 design boards (each from a different designer) that helped him design his event site for Patterns Day.
I saw some 'page painting' in chrome developer tools showing after a discussion on 'janky' sites. Jeremy told me he had to remove an image from his event site after he found it to be create this unwanted phenomenon.
I was introduced to CSS shapes and the browsers that currently support them.

An intense but fantastic day - I'd like to thank Jeremy once again for his time and great advice :)

Preparing to Talk

Thu, 13 Apr 2017 24:00:00 GMT

If you went to #BrightonSEO and thought "Hey, it would be cool to speak on stage one day"... Read this! https://t.co/Xhdj2RI0w6 pic.twitter.com/8nayH2lBNs
— Hannah Butcher (@HannahFButcher) April 12, 2017

It is T-minus 4 months and 3 days until I am due to give my first talk on web stuff at Material in Iceland.

I decided to jump in the deep end with this one, but I'm relishing the challenge.

Recently, I've gathered resources on public speaking, talked to people about it, and joined clubs like Brighton and Hove Speakers Club (BAHSC).

Hannah Butcher, the author of the quote above, recommends this: Identify a topic, choose a title, get your slides ready, build your confidence. Hannah also talks of being an introvert and how this doesn't stop her from speaking on stage, which is great.

I can't thank people enough for getting their advice and stories of personal experience out there. I am also humbled by the kindness of other speakers, particularly at BAHSC where I had my first meeting last night. The members are so eager to help and so wonderfully positive that I'll surely thrive under their guidance. They even offered to give up weekends to mentor me and help me practice my talk.

Next step - prepare my talk. Another fun step :) Let's go!

Cookies

Tue, 11 Apr 2017 24:00:00 GMT

What is a cookie? If you have a sweet tooth like me you might imagine a round, freshly-baked treat containing chocolate chips:

Conversely, internet cookies (a.k.a. HTTP cookies) contain data, usually in the form of a text file:

What's in the name? Derived from the term 'magic cookies' (packets of data that have been used to send data over the web since 1979) the term 'cookie' was coined by Lou Montulli and first utilised as an e-commerce solution in 1994. They enabled items in a shopping cart to be saved while you browsed the rest of the site. Cookies quickly gained popularity and began to be used for other purposes.

How do cookies work? When you visit a site, it saves information about you to a document (a cookie) on your hard drive, via HTTP. When you browse or return to a site, saved cookies are sent back to the site's server. Sites mainly use these cookies for the following purposes; updating your preferences, keeping you logged in/remembering items in your cart, or tracking your path through the site.

In essence, cookies leave a sort of bread crumb trail on the web, allowing sites to tailor information specifically for you. They can store all sorts of data, and these are determined by the site's creator. They are website-specific, meaning a cookie created by one website cannot be read by another.

However, one site can contain bits of another, e.g. adverts. If you previously visited, say, an online clothes store, you are likely to have cookies from this site saved on your computer. When you visit a different site on which the clothes store's adverts are embedded, the store is able to access the cookies they saved earlier and dynamically alter the ads to fit your preferences. These cookies are 'third party' cookies. They come from a different domain than the site you are on. Many browsers allow these by default, although there are ways to block them.

What about privacy? After years of ethics debates, in 2011 an EU law was passed stating sites using cookes had to alert visitors, seek permission to store and retrieve data, and draft policies.

See the following examples -

Need more information? Some great resources exist on the privacy and security issues surrounding cookies. This site explains how to opt out of cookies in different browsers. This MDN article covers security and how cookies are sent over HTTP response headers. This article provides very detailed information on how to keep information stored in cookies secure. This site contains a wide breadth of information and helpful tips.

Thanks for reading my short article. I wrote it from scratch with no previous knowledge of cookies. It was fun to learn and I hope to continue increasing my understanding. Please share your own thoughts and research processes!

UX Curriculum

Sat, 08 Apr 2017 24:00:00 GMT

Inspired by David Venturi's writing, this article includes a bit about me, something about fun, and my UX curriculum. Being new to User Experience Design, I found this to be a really useful thought exercise and I hope you do too.

Have you pursued higher education or years of work experience in a field unrelated to design? Live in a city but don’t have the money or time to pursue a User Experience or Human-Computer Interaction degree?

If so, we have something in common.

It is possible to take what you already know and apply it to a career in UX design. Passion, self-learning and reaching out to others in the industry will help get you there.

I’ve met people from a huge number of backgrounds ranging from marine biologist to maths teacher to anthropologist to marketer who have all been successful switching their career to digital. They have all been more than happy to talk to me about their experiences and help guide me to form my own.

Why do I like User Experience Design?

I’ve always had a spark of creativity inside me, finding my happy place in hobbies of drawing, designing and photography.
I have a background in psychology and completed a Master's in Child and Adolescent Psychology here.
The UX industry is dynamic, encourages life-long learning and is fun.

“You can’t be creative if you’re not having fun” - Dave Kelly of IDEO

This phrase speaks to me on many levels. It reminds me of the magic of childhood where play is encouraged and creativity is always rewarded. Adults glean delight from witnessing children having fun, and will always seek opportunities for them to have it.

Why then is fun encouraged so much less in adulthood? A culturally-defined cut-off age, for example 18, signifies a sharp boundary between childhood and adulthood. Between playful learning and serious responsibilities. There are responsibilities to be serious about but, as is more often the case these days, young adults tend to get bogged down and feel hopeless when it comes to fulfilling them.

Imagine if it was a top priority of employers to make workspaces as fun as possible, help employees feel good, and inspire creativity. Maybe this isn’t feasible in every workplace, but it seems to be readily encouraged and available in the creative industry. I want to experience for the first time what it is like to be part of such a fun and nurturing environment, while getting to indulge my hobbies every day.

I’ve had a go at creating my own UX curriculum based on my psychology Master’s programme. This exercise has helped me uncover important aspects of UX that were not apparent at first. I wrote it based on what I've learned in the past nine months (from knowing nothing about the industry to getting an internship). I'd like it to show UX from a different perspective and help inspire people to learn more. These articles really helped me get started - 'Designing a free online learning curriculum' and 'How to teach yourself UX design'. Please note what I've written below isn't exhaustive and is meant to be taken light-heartedly and encourage thought :)

Original Curriculum (MSc Child and Adolescent Psychology)- need minimum of (65) points:

Compulsory components

Advanced Psychodiagnostics in Children and Adolescents (5)
Behaviour Training with Children (5)
Solution Focused Therapy (5)
Cognitive Behaviour Therapy with Young People (5)
Master Thesis in MSc. Psychology (20)

Choose one of the following options as an internship

Internal Practical Internship (10)
Practical Internship Psychology (10)
Research Internship Psychology (MSc) (10)
Clinical Practical Internship Psychology (20)

Recommended elective(s)

Child Neuropsychology: Theory and Assessment of Neurodevelopmental Disorders (5)
Trainers Course Communication Skills (5)
Advanced Child and Adolescent Psychiatry (5)
Transdiagnostic Approach of Eating Disorders (5)

New Curriculum - need minimum of (65) points:

Compulsory components

Cognitive Psychology (5) - examining the brain from a neuronal/chemical level to understand how users think, what their motivations are, what they need
Web Development (5) - HTML/CSS/JavaScript, introduction to backend systems, CMS
People Management in Research (5) - users, clients, stakeholders (getting people to realise what they need versus what they want/think they need)
Quantitative and Qualitative Research Methods in UX (5) - differences, when to choose, types, mixing.
Design Tools (5) - photoshop, illustrator, affinity - watch online video tutorials (YouTube, Udemy, Lynda etcetera)
Master Thesis in MSc. UX (15)

Choose one of the following options as an internship

Internal Practical Internship (10) - a small project for a friend (e.g. website redesign for a friend or non-profit)
Practical Internship Psychology (10) - source and contact a firm, enquire about helping on one project for 4-6 weeks, ask for a formal feedback procedure (see requirements and feedback template for this in course folder)
Clinical Practical Internship Psychology (20) - secure an internship in a firm lasting no less than three months and up to six. Ask for formal feedback procedure (see requirements and feedback template for this in course folder)

Recommended elective(s)

Empathy in Design (5) - more in-depth cover of this important topic
Trainers Course Communication Skills (5)
Time Management & Organisational Skills (5)
Public Speaking Workshops (5) - modes of presenting
Reading list.

GET vs. POST Requests

Mon, 27 Mar 2017 24:00:00 GMT

Amidst a learning spree on semantic HTML and the ways servers communicate with web browsers, I was introduced to 'GET' and 'POST' requests.

These are HTTP (Hypertext Transfer Protocol - the language the browser uses to 'speak' with servers) request methods, typically used for sending and receiving data in forms. They are written like this inside the HTML5 form element:

 <form method="GET"> or <form method="POST">

The semantics behind the form element could form (see what I did there?) another lesson entirely. They are explained nicely here.

GET and POST requests can be tricky to understand because some explanations are too techincal and miss the big picture. Here are some basics:

GET requests are the default method used by browsers, meaning that if no method is specified, a GET request will be issued automatically.
Both methods are able to send to and retrieve from data a server, however GET should only really be used as a 'getter' for retrieving data, because using it to send data raises some privacy issues.
GET requests send information (name and value pairs in forms) within the URL of HTTP requests, rather than in the body. This means information submitted in a form will be visible in the URL. For example, when logging into a site, sensitive information such as a password would be part of the URL.
In addition, a limited amount of data can be displayed in a URL. This means submitted data could be lost.
POST requests send information in a separate header file. Data sent this way is also not encrypted, but is safer.

This video gives a practical example and describes further differences between GET and POST (skip to 5:19).

The Internet and The World Wide Web

Thu, 16 Mar 2017 24:00:00 GMT

I was tasked by Jeremy to explore the differences between the Internet and The World Wide Web. At the start, I was hard pressed to explain them. All I knew is that the 'Web' was created by someone called Tim Berners-Lee. I thought this meant he'd invented the entire Internet. I soon realised how wrong I was.

This site describes the differences in one sentence - "The Internet is a giant network connecting everyone's computers and it uses languages known as protocols to send information, and the Web is just one of these protocols". Simple, right? I went on to read that the Web is built 'on top of' the Internet. My confusion began. I knew I needed to get some background knowledge.

On Tim Berners-Lee's Wikipedia page were unfamiliar terms such as CERN, Hypertext, Transmission Control Protocol, etc. I deciphered that 'hypertext' is used to compile documents, 'hyperlinks' allow linking between such documents, and 'hypertext transfer protocol' (HTTP) is the internet protocol used to exchange or transfer hypertext. However, this didn't tell me about how the Internet and Web differ. This video describing Tim Berners-Lee's life, this Wikipedia article and Jeremy's book helped me figure out the following.

In short, in 1980, Tim worked for a company called CERN, the European Organization for Nuclear Research, and created a program called 'Enquire'. This let him easily manage information within the company by interlinking keywords in text documents. Such linking of textual information creates hypertext, and the links between them form hyperlinks. The hypertext transfer protocol communicates with the Internet to allow information transfer. This is the basis for the Web.

Long before this, the giant network known as the Internet (term coined in 1983) had already become an established part of many universities and scientific institutions. Functioning via physical connections that had already been laid for telegraphs and telephones, this decentralised network was robust in that it could still function even if parts of it failed.

The problem was that the Internet linked very different computer operating systems. Recalling knowledge from one to another required hefty expertise. In 1989, CERN wanted Tim back to help them with this issue. He created 'hypertext markup language' (HTML - based on CERN's 'standard generalised markup language' or SGML) and 'uniform resource locaters' (URLs). These allowed information to be accessed more readily.

The World Wide Web had been born. However, it only ran on the operating system used at CERN (NeXTSTEP), and the browser Tim created for it (the world's first) called 'World Wide Web' ran only on NEXT computers. Nicola Pellow saw to this problem by creating the 'Line Mode Browser' at CERN. Many browsers followed. These browsers could be installed on any computer, thus allowing anyone to use the Web.

I ended my research with this lecture by Tim Berners-Lee. It is his account of how the Web just 'happened', mixed with an enthusiastic account of the powerful personal and social reasons behind it. He explains how certain creations, e.g. a telephone, only work if other people use it as well. To build a sufficient network, you need early adopters, people with a 'gleam in their eye' as he puts it. He explains how everything that has been designed for use over the Internet or the Web is just like this and so can be deemed both technical and social. He goes on to explain how the Web took off:

"It's the psychology of people wanting to be read that makes them make links to other good things. And when they make links to other good things, by doing that, they are actually voting for those other good things. And the links themselves form this huge mass of critical review, which is actually how the web works. And the search engines aren't smart, they just use that massive critical review, put in by human beings. So, the search engines all rely on those links, critically. So, it's all about people. The system is a social, technical thing. The design of the technology and the design of the social piece - absolutely intimately linked."

Markup-Masterclass

Thu, 16 Mar 2017 24:00:00 GMT

Today I spent a great day at Clearleft, soaking in the lovely atmosphere, chatting with the wonderful staff. I sat down in the morning to talk with Jeremy about the web and the internet, web apps and native apps. We chatted about tech company structures, job titles, career advice and much more.

For the main part of my day, Jeremy set me the task of re-formatting my CV (currently only in PDF format) into an HTML document. I thought to myself “ah, easy!”. I had little inkling of all the new things I would learn, or how much fun I'd have. See a summary of my learning at the end.

I began like this:

Copy and paste text from the PDF file into my code editor.
Add some h elements that matched to the size I wanted the text to be.
Use a bunch of br elements to break up my text.
Add some hyperlinks.

Right, the page looked well structured, and I thought I'd nailed the task already. "Next!" I shouted in my head. I ask Jeremy to come see what I'd accomplished. He told me I had been fast. A little too fast, perhaps?

Firstly, he noted that I hadn't filled in a title, something very important. He then sat down and taught me about 'metadata'. This is data that describes other data. I added 'description', 'keywords', and 'viewport' meta tags (e.g. meta name=“description”), and gave each some “content” (e.g. Amber Wilson's CV). A meta tag that's commonly used these days in the era of responsive design is the 'viewport' meta tag. It controls layout on mobile browsers and allows users to pinch and zoom content.

Jeremy noticed I had formatted my paragraphs using the div element. He asked me why and I told him that I wanted to use them as a visual aid for breaking up sections of text. We then discussed the difference between div and span elements. Both essentially do nothing, except that the former acts as a block element, the latter as inline. We then went on to discuss section and article elements. I was using a site that gave a handy list of HTML5 elements, W3 Schools, which Jeremy told me to exit immediately. This site may have hijacked the World Wide Web Consortium's (W3C's) name and be at the top of all search results, but it is one to be avoided. The Mozilla Developer Network (MDN) is much better.

I swapped div elements with section elements. I thought these elements only helped developers make sense of code. I was wrong. They also differ practically in that section elements help assistive technology and search bots decipher site content for the benefit of all users. By now, I thought that I really must have nailed the perfect semantic document. I thought I'd try to be clever and stick an hgroup element in - something I read about on the MDN. I triumphantly called Jeremy over. In a fraction of a second, he'd spotted my error and told me to research 'hgroup' more. After ten minutes, I hadn't got far.

Jeremy recommended I find a way to validate my markup. I found the w3c HTML validator, and almost switched it off because it looks like a W3 Schools site. I was wrong, it is a W3C site. No matter how hard I tried, I couldn't get it to tell me my 'hgroup' element was valid. The realisation came that I'd been trawling quite heavily out-of-date sites for a lot of information. Eventually, I scrolled down the MDN page a little more and saw that this element was removed from the HTML5 specification. Oops.

Recapping, I'd gotten rid of my hgroup element, I had my section elements in place, and I'd added my meta data. What else? Next, I was asked why my 'h' elements were all odd sizes. I said it was because I wanted the headings to present text in a certain size. I was told this is CSS's job and to "not worry about how it looks". These elements are for adding structural outline to a page. I changed my markup until I received this outline summary from W3C -

Jeremy noticed other content where I'd been more concerned about presentation than structure. I was again reminded take my mind off presentation and focus on the structure. I could change the presentation later with CSS. I wanted some sections to have content that sat in a nice line. After successfully pushing the urge to present the content this way, I put it all into list (ol and li) elements. I was introduced to elements I'd never heard of - dl, dt and dd. These go a step further than list elements and add semantic meaning. The 'time' element is also new for me, and I added this to all dates.

Some more reading on the MDN taught me that the humble br element, is now obsolete. Jeremy encouraged me to use the p element in their place. I didn't think I could live without br, but p came to the rescue. Lastly, I asked Jeremy about the 'hcard' element, one I'd learnt about in Homebrew Website Club.

This element is a microformat used for embedding data (on people, companies and organisations) and making it more easily accessible on the web for use in applications and services. It should be noted that microformats2 have superceded the classic microformats. I added p-name, u-url, u-tel and u-email for my name, site, phone number and email. There are a wide range of microformat elements to explore. I am still in the process of doing this and want to add a 'resume' element soon.

Here's a summary of what I learned today:

Focus on the structure and meaning of elements, not the presentation.
Think of the 'h' element as structural, not presentational.
Search up-to-date information when researching correct HTML markup.
Check elements have not become obsolete.
Place elements in order of their importance.
Pay attention to meta tags and microformats.
Always validate your markup.
& a lot more.

Thank you Jeremy for teaching me.

Learning

Thu, 16 Mar 2017 24:00:00 GMT

Best thing you can do for your career is to be active outside your employer. Publish, speak, build. Repeat. Publish, speak, build. Repeat.
— Rachel🦄Nabors (@rachelnabors) July 3, 2017

I discover ideas every day by talking to people, listening to them, reading, writing, attending events, going to meetups, sharing ideas, pushing myself out of my comfort zone.

None of these are restricted to Web development:

I studied psychology for six years. I bring a huge number of things I learned from that experience to my new job as a Web developer every day.
I read books on writing, artificial intelligence, war-torn Cambodia and many more. They help me get a broader, more informed view of the world, and this helps me be a better developer.
I am interested in the stories and views of everyone I meet. The variety of things I've learned from people by just asking them questions is amazing.
I've volunteered and worked for companies that have nothing to do with technology. Every single one allowed me to meet people and learn things that make me a more well-rounded developer.
I've worked and lived in (for at least 6 months) six different countries. Being immersed in cultures unlike my own helped me open my mind, consider others' points of view and learn that our similarities are stronger than our differences.

There have been so many moments where I’ve gone a little out of my way, above and beyond the call of duty, to seek out a new perspective, and come away thinking ‘Wow, my views have just been entirely shaken up or changed’.

Such moments are like little flames that keep me motivated and constantly wanting to find more. I don’t know how many people get to experience such shifts in their views as often as I do, but it’s something that feeds my thirst to know more, get a more holistic view of the Web industry and figure out how I can help it move in a good direction.

I've been granted so many cool opportunities by being proactive and enthusiastic about learning. To name a few: a internship where I get paid to learn, a great and supportive mentor, a chance to speak internationally, a meetup where I learned and now teach, a website where I can spill my thoughts, endless tips and advice, a huge and amazing network of friends, etc.

The Web is at a point where more of us need to be putting in some effort to get a broader view of the world and the people living here. The social effects of the Web are stretching further and further every day. More and more people are getting access to it. More than ever, we need to make sure it's an accessible and secure place for everyone.

Make a plan, set yourself time, push yourself out of your comfort zone, talk to people, write down what you learn, enjoy what you experience. Get excited about learning and experiencing. Get excited about Web development. The Web needs you :)

Get in touch with me if you have any thoughts about this article, how you learn outside your employer, or to share what excites you about Web development :)

Podcasts and Knowledge Sharing

Tue, 07 Mar 2017 24:00:00 GMT

Let’s talk about podcasts. I have always liked the idea of them. Like audio books, you can take them anywhere and listen anytime. They enable you to access up-to-date, current opinions on just about any facet of life you can think of. If you’re wondering whether there is a podcast on a topic you’re interested in, I can bet you there is. And, if not, you could make one. Please excuse me while I shield my ears while you scream “but what could anyone ever learn from ME?!”.

Over the past months, I’ve encountered people who are on the extreme ends of willingness to share experiences, either though speaking, blogging, or through other forms of communication. Some have animatedly explained how writing about their experiences has not only helped them track progress, but also consolidate their knowledge and receive thanks from people. Others look at me with mild confusion and ask what good could possibly come from sharing their pallid, commonplace, and unremarkable experiences.

I’ve always been at the more willing extreme when it comes to writing about what I’ve done. To me, the idea of helping or inspiring even one person this way gives me a warm, glowing feeling inside. I believe that information and education are important for leading a more happy and productive life. A person can learn, through reading about or listening to people with similar experiences, ways to increase their own happiness and that of those around them. Shared knowledge is power. Not only does this knowledge teach us, it makes us feel more connected to each other. And this is a beautiful and comforting thing.

A lot of the time, learning from others involves emotion. Hearing about similar experiences from others, being able to relate to their ideas and thoughts, can bring rushes of exhilaration, moments of ‘a-ha!’, and sobering realisations. When we share, we place a little bit of ourselves out there for others to do with what they will. There is a sense of vulnerability to this. It is the willingness to be vulnerable, though, that can encourage others come out of their shells and rejoice in their new-found knowledge. They may feel inspired, motivated, reassured, at ease.

I believe that sharing of knowledge and experiences should never be discouraged. Personally, I’ve always found that other people’s perspectives hugely increase my ability to step outside myself and consider the bigger picture. I always find that this improves my wellbeing. Our own perspectives can become stale and fragmented so quickly, which can lead us to feel confused, worried, unsure, and even sad. I like to gather as many different perspectives on a single subject as I can. Each perspective is like a puzzle piece. Put them together and you have a brightly-coloured, easily-understood, comprehensive view of the thing you are trying to make sense of.

The topic of this post is podcasts, but communicating your ideas can take many forms. Another method is blogging. This is something I absolutely love. I don’t only enjoy doing it myself, but also when other people do it. I always feel a child-like thrill when I discover an awesome piece of writing from someone on a topic I am interested in. My feelings rise to ecstatic when I realise the author is also incredibly passionate about what they are writing. Recently, much of what I have read or listened to has been about tech. I still read up on many other things, especially on psychology and life (I am especially interested in how parents raise their children). I’ll write a new post on the podcasts I like listening to and the blogs I like reading soon. Look out for it and remember, don’t be afraid to share! Connect with others through your ideas and help to build a more informed and happy world.

Also published on Medium.

Mentorship

Mon, 06 Mar 2017 24:00:00 GMT

It was around October last year when I arrived at 68 Middle Street for a codebar session. It was the first time I had been in the building and I was immediately struck by how spaceous and well-designed it was. Even if I wasn't entirely sure what people did there. I had begun coming to codebar about two months prior, and hadn't missed a single session. I loved how I got to see a different working environment each week and meet developers from any and all backgrounds. Not to mention, I was completely blown away when I first attended. The brilliant Lotte Jackson, Rosa Fox and Dorothy Wingrove showed me that strong, intelligent, kind, ambitious (+ many more adjectives) women could feel comfortable in the tech world and that there is indeed a place for us there after all.

After the half-hour informal chat, I made my way along with the other code newbies and tutors into a room further to the back that had a projector screen and a number of round tables, dotted with chairs. I found a group of people I knew at a table, but all the chairs were taken. I went to sit on an empty table with someone else I knew. Here, we were both greeted by a man I hadn't met before. He sat between us, introduced himself as Jeremy, and said he'd help by sharing his time between us. I began getting on with my CSS tutorial. A little while in, the other student asked about hex codes.

Busy with my tutorial, I was only half listening. About five minutes later, I realised Jeremy was still talking about hex codes and what's more, he seemed to be enjoying it. So, I began to listen properly. I really liked how in depth his knowledge was and that he was so happy to share it. After a few minutes, we moved onto a discussion about HTML and I asked Jeremy if he could recommend any tutorials or books to me. Without hesitation, he kindly offered to give me a book on the subject! He told me there were a few spare copies lying around. He returned with a small, thin orange book called HTML 5 for Web Designers, which he handed to me. I was so busy thanking him that I didn't notice it was his book. He set me an HTML task based on the book, which I wrote down. Shortly after this, the session wrapped up for the evening.

It wasn't until some months later that I was at a pub after a codebar session. It was cold, windy and wet outside. I remember it well. Sitting with me was a developer I had not previously met, Charlotte, Julian, and Cassie. All wonderful people. We were chatting happily and the conversation arrived at experience. It was then Charlotte told me that, If I liked, I could come along to her company, Clearleft, for a few hours of shadowing. I was very excited at the prospect and gladly accepted. It wasn't long before I'd paid my first visit to Clearleft. This visit was amazing - I got to have one-on-one conversations with so many people, including the company's founders. I learned about how many different skill sets are needed in order to run a successful, innovative digital company. To my delight, I was invited back again. I spent a lot of my free time between long work hours coming to Clearleft to soak up the atmosphere and learn from the great staff.

Each time I was there, I began to chat more and more with Jeremy. I found that his passion didn't stop at hex codes. He possesses a deep knowledge and enthusiasm for what makes the web tick, and what lies behind the scenes of what we see on the screen. He knows that in order to create a fair, robust web that is as true to its content as to its users, developers must respect where the web came from and what brought it to greatness in the first place. I easily learned more about this in my free time by listening to Jeremy's book Resilient Web Design, which is all about the history of the web.

One day in January, I had spent a morning at Clearleft, and Jeremy decided to make me a really neat offer. He asked me whether I'd like him to mentor me, but that I didn't have to take him up on the offer if it didn't sound like something I wanted. I was thrilled with the offer and gladly accepted, but was immediately worried that I'd be taking up too much of his time. I asked him about this and he reassured me that although he had not offered to mentor someone before, it was something he wanted to try and to do right. I thanked him once again and over the next few weeks, we planned what the mentorship would look like. I came up with some things I'd like to get out of it, which we discussed together. Jeremy blogged about these things, as well as how we came to be mentor and mentee, here. I am so grateful for his kind words and the offer of his time, and I am looking forward to working very hard and learning as much as I can! :-) Hooray!

Also published on Medium.

Germany Trip

Thu, 02 Mar 2017 24:00:00 GMT

An incredible time with wonderful friends ❤

Click here for the video

22.02.17 - Brighton Coach Station

23.02.17 - Cologne

24.02.17 - Essen

25.02.17 - Hannover

26.02.17 - Bamberg

28.02.17 - Berlin

Amber: Blog

Conferences and Connections

Five Things I Like and Dislike #1

Like

Dislike

Writing a Book in Public - Switching to Web Dev

Timeline

October 2020

April 2022

May 2022

June 2022

September 2022

March 2023

April 2023

August 2024

April 2025

May 2025

June 2025

Making the Time to Review Pull Requests

Contents

My Code Review Story

Benefits of Code Review

Summary

How to Approach a New Codebase

Contents

Explore

Build

Step by step advice

Humour helps

Start from the top

You do not need to understand the whole codebase

Use the finished product yourself

Run the code locally

Ask questions

Pair program

Read and write documentation

Take notes

Fix bugs and debug code

Tests tests tests

Watch logs and error messages

Build features

Step by step advice

Funny stories

Mini Blogging Masterclass

Writing a Winning Web Developer Resume

Tips on writing your web developer resume

Bonus tips for cover letters and interviews

2020 Year in Review

What I set out to do in 2020

Top 5 Articles Released in 2020

Achievements in 2020

Thanks I want to give

Plans for 2021

How and when to use React useCallback()

Object references

Example app

When to actually use useCallback

Resources

Are your Anchor Links Accessible?

Contents

What are anchor links exactly?

Accessibility check

A word of caution

Another option

Automating accessible anchor links

Continued discussion

Grow the IndieWeb with Webmentions

IndieWeb

Webmentions

From Gatsby to Eleventy

Benefits Gained

Challenges Faced

Concluding Thoughts

Caches are for Copies

How do servers manage files?

Trust, then verify

Accessible Link Text

More resources

From Office to Remote (During a Pandemic)

Background