Alex and Ruth go to events: ReactJS Girls Conference 2019
Ruth: React has been a key part of our tech stack at Personably since I joined over a year ago (as the first employee). Before Personably, I was purely focused on React development as a Frontend Developer at JustGiving. So I’ve had a lot of exposure to it! I knew attending the ReactJS Girls conference would be a great opportunity to meet other developers and learn from some great (all women 💪) speakers.
Alex: I’m part of the team that sells Personably and I really love what I do. My journey into the world of coding began when I realised it would be useful to actually understand what the product team were talking about in meetings. I started by going to CodeFirst:Girls, then studied by myself and more recently, have been attending codebar workshops. Fast-forward six months and I’m attending my first ReactJS Girls Conference 😱!
Design and brand made easier 💅
Ruth: Design and brand are really important parts of building a great product and company. When developing components at Personably we want to make it easy to keep our design and brand consistent throughout. This means making them flexible and reusable - so the first set of talks were really relevant!
Building a Design System with React (Emma Wedekind)
Ruth: As Emma said in her talk, “consumers love consistency and predictability.” She talked about how to achieve this by building design systems with React. Design systems bring designers and developers together which has been one of our focuses in the product team at Personably. A quote Emma used which I love is:
“A design system isn’t a project, it’s a product serving other products” - Nathan Curtis
My main takeaways from the talk were:
- **Prioritise what to build: **You can do this by carrying out a UI audit. I hadn’t heard of the concept before! To carry out a UI audit you should gather together all the components you need to build and plot them on two graphs. The first, consistency against usability and the second, feasibility against impact. Then take the components in the top right quadrant of both graphs. These will be components that are really inconsistent, used a lot, easy to build and have a high impact. These are the components we should prioritise building. A good example of this would be buttons.
UI Audit example
- **“Building for scale is a catalyst for failure.” **Building for hypothetical situations doesn’t allow teams to make meaningful progress. You should start small and build incrementally. Build for scale when you need to. This is something I’m often guilty of, getting lost in thinking about how many different ways a component *could *be used. So, it was a good reminder that sometimes you need to take a step back from your code and think what this component needs to do right now.
Storybook: A React Native Love Story (Erin Fox)
Ruth: Erin’s talk was a great one to follow Emma’s as the last part of a design system is the style guide! We currently use Storybook at Personably for our style guide. I’ve been thinking about moving it to Docz so it was interesting to hear why Erin chose Storybook for Major League Soccer. Erin and her team saw that being able to run the components in isolation using Storybook meant building components was a lot faster.
Having a great workflow like this is crucial for a smooth development process but personally, I’m still not convinced by Storybook as it doesn’t have an interactive playground to change props in the browser (although I haven’t yet upgraded to v5).
Everyone is a beginner at some point
Alex: The majority of the talks were really accessible for beginners. Even when the speakers dived into more technical ideas, they explained it well and I could still follow the logic of their code. In particular, there were three talks that were really interesting to me as a newbie to coding.
Life is hard and so is learning GraphQL (Carolyn Stransky)
Alex & Ruth: both of us could really relate to this talk. No matter your level of experience you’re always learning. Although no two paths are the same we could definitely see the similarities in our own experiences.
Ruth: Carolyn’s take on the documentation out there for GraphQL was really informative given her experience as a tech writer. Throughout her talk I found myself comparing her learning journey to mine and at points they were so similar! We both started by working through the official documentation and it seems that we were both overwhelmed by the GIANT sidebar of things to read. However, as Carolyn said “you don’t need to learn all of this in order to use GraphQL in a meaningful way”. Looking at the documentation as a beginner, I just didn’t really know where to start.
Alex & Ruth: Our main takeaways from the talk were that if you’re writing technical documentation:
- Provide an overview in the documentation before diving into the more specialist parts. You don’t have to know everything about a single tool, in order to start using it. Carolyn advises giving examples of use cases, having an onboarding guide or tutorials to give a frame of reference.
- Avoid unexplained jargon and assuming prior knowledgein your explanations because everyone is a beginner at some point. A good way to avoid this is having a list of pre-reading for a tutorial on a certain project or part of the tool. And remember to write as if you’re talking to people who have never used your framework before.
Ruth: Carolyn’s talk also really encouraged me to contribute more to open source documentation to help this 👩💻
Hooks: the new kid on the block 👶
Ruth: If you’re a React developer, there’s no doubt you will have heard about Hooks. I’ve been seeing a lot of excitement about this new feature but haven’t given it a try yet! Keeping up to date with new technologies and releases can be difficult so Manjula’s talk was another I was looking forward to for its insight into this new craze.
React Hooks: A Hype Driven Development in React (Manjula Dube) React Devs going crazy for Hooks Ruth: Manjula’s talk was a great introduction to hooks. I was initially worried that because I hadn’t tried it out for myself, the talk might go right over my head. I came away understanding the basics and found it really interesting to hear the problems with class components and how hooks could solve them. Manjula also included the things to look out for when using hooks in your code. And crucially:
“It doesn’t mean that if you’re not using hooks in your application, you’re not a cool developer.” - Manjula Dube
Inclusion & accessibility aren’t a choice, they’re a requirement 💻
Alex: One of the really exciting things about joining the tech sphere in London is the speed at which it’s developing. Start-up companies have the advantage of starting from scratch. They’re able to build in inclusivity and accessibility from the beginning and maintain it as they scale.
Ruth: It’s great that more and more talks are focusing on this topic to raise awareness of how important accessibility is in the digital age. Accessibility is an ethical obligation and as developers we have the skills and ability to actually make a difference. I’m still learning a lot on this topic and want to keep improving. There is a whole section on accessibility in the React docs that I’m yet to dive into properly.
Empathy Driven Development, a Live Accessibility Audit With React.js (Marcy Sutton)
Alex: Marcy’s talk touched on a few basic changes you could make for your product to be more accessible to users who can’t use a keyboard/mouse or have visual impairments. If you’re able to implement these early on and have automated tests to maintain accessibility, your product will only improve, and encourage a more inclusive user base.
Ruth: Live coding is always super impressive so I loved this! Marcy explained that what she wanted people in the audience to takeaway from her talk was not necessarily one technique but the process of debugging for accessibility.
How to debug for accessibility:
- The keyboard - the most simple tool that everyone has. Just by tabbing through a web page you can instantly see what elements aren’t reachable and what elements need better focus management.
- axe - automated accessibility checker that can pick up on things like colour contrasts and semantic elements.
- Chrome developer tools - has a very handy colour contrast ratio picker.
- cypress-axe - automated accessibility testing which can really make sure you have accessibility checking baked into your workflow.
Three things to do in your code to improve web accessibility:
- Use Refs - Refs in React can help with focus management.
- Be more semantic - Use a button instead of a div, use header, main and footer elements.
- Descriptive aria labels - “Open pricing modal” instead of just “Open modal”.
Marcy debugging her site live! Architect your culture like you architect your code (Kate Beard)
Alex: Kate Beard spoke about her experience as a student at Founders and Coders (FAC). FAC is a coding bootcamp that takes people from “zero to dev” in just 3 months. Unlike the many other Bootcamps there are no fees, instead you’re expected to contribute to the development of the programme afterwards. Ruth and Katerina (Personably Co-founder) are both FAC alumni!
It seems FAC has come along way since the early days, with each cohort improving the curriculum as they go along. But the values of cooperation, inclusion and social impact remain core to the way the course is run.
Kate spoke about how FAC have built up an environment of psychological safety. People are encouraged to ask questions, give feedback and they feel safe to make mistakes without judgement. It’s this environment she attributes to the students being able to learn so quickly.
These points can be applied not just to the classroom but any start-up or team. It’s a really important part of our culture at Personably too. I learn by being able to take risks, knowing I might make mistakes. It’s easy enough when you’re learning by yourself, but as part of a team, the fear of making mistakes can put you off advancing altogether if you don’t have that safety.
You can read more about this concept and how it was first used in the context of teams by Lazlo Bock at Google.
ReactJS Girls is for both beginner and experienced coders 👯♂️👯♀️
Alex: You don’t have to be a developer to attend these events. This conference was as much about inclusion and getting people excited to learn more, as it was about giving the developers the tools they need to improve their code. I really want to encourage more groups of people who are minorities in tech to join these kinds of conferences and make connections. I found it really useful and had a great time.
Ruth: As a software engineer that uses React everyday, this conference was packed full of great content. The energy of the speakers, sponsors and attendees made the whole day enjoyable and welcoming to everyone. I learnt a lot from all the talks and it’s encouraged me be more active in the React community.