It's easy to find faults when I look in a mirror. It's easy to play comments about my body on repeat in my head from the days of "baby fat" and beyond. It's easy to see the changes of age and having created and birthed an entire new human.
It's easy, when I see my body, to find things to hate.
One of the many things I have thought about lately is determining why I write and draw. Knowing your "why" is helpful, especially when you're stuck. It gives you an opportunity to ask yourself: Does this align with my values as a writer/artist/whatever? Does it align with who I want to create work for? With what I want them to feel? You can use your own history of what you've written before or wanted to write (or your own interests if you're just getting started) to figure out what your guideposts as a creative should be.
To say it’s been a while since I wrote an official blog post – or did a lot of things, really – is an understatement. It feels more like twenty years has passed than just two!
I had slowed down my productivity towards the end of 2019 as the due date for my daughter approached. She arrived fashionably late (as is typical for first-borns hoping to bypass any "my parents offered me in exchange for something" contracts). Life has been a whirlwind since! Just when I was looking forward to getting back to work, the pandemic hit, and I never did make it to the new office. Still haven't as the time of this post!
One of the biggest mistakes in development is not making your website or app accessible from the beginning.
Many reasons are given, from it "not being in the budget" to "we don't need it for the MVP". The reality is that it should be done from the beginning. Not only are you excluding people from being able to interact with your content, but it can be more costly to revise inaccessible code later down the road. It's a complex topic with a lot to cover, so this post will not be an end-all-be-all. However, I'd like to encourage developers to learn the basics of a good foundation for building an accessible website or app, as well as questions to consider when reviewing their work.
Anyone can be a mentor to someone else, irrelevant of a formal structure. We all can help in areas another needs it. This goes beyond your work team, too. You may be a mentor to someone you know online, met at a convention or meetup, or through a formal program.
Knowing you have the experience or skills to help and wanting to help them is only the beginning. Knowing how to help them is what will set you apart as a good mentor.
Getting to work on a new web development project is always exciting! But the excitement falls as soon I open the repository and see an empty README with nothing but the project title — if even that. Now instead of diving into building new features and squashing bugs, I'm spending hours trying to get started. I have to take time from other developers to ask why the build won't start, how to integrate with their custom services, where something should go in their code architecture, and so forth. Instead of spending my hours building and testing, I'm forced to wrestle information from multiple people if I can — some who aren't even available anymore and left the company.
Those are the good cases, too. Sometimes the original development team has long gone, there's no documentation, and no one to ask. In instances such as that, hours soar every time an unknown is encountered.
The worst part? All of these problems could have been avoided with the help of proper documentation.