Posted on

Sharing What We’ve Learned

We try to give back to the web community and help others learn (as well as enriching our own skills) in a variety of ways: speaking and attending events, sponsoring things we want to see more of, and trying to participate on social media and in local community discussions. One thing we haven’t haven’t been able to do is mentoring.

We still haven’t really invested in mentoring, but we had the opportunity last week to take a baby step and worked with some new developers on some job shadowing.
Our guests came to us via Akron Women in Tech’s new Code Epic. This is a fantastic program; taking the idea of code schools and bootcamps and making it available to people who can’t afford to quit their day jobs and/or pay the steep tuition.

The developers we worked with had enough experience that we could dive right in and start walking them through our daily routines. We talked through a morning standup meeting, and then went into detail about one of the projects we’re currently working on.

All of us share an overlap of interest/skill in front-end development, so we talked through the tools/projects/frameworks we’re using, and why we made the technology choices we did.

One very interesting exercise was to look at our list of technology involved with the project. We talked through everything, and then went back and added markers by the tools that we knew prior to 2 or 3 years ago. We also made other marks to signify which technology this project is using that didn’t even exist 2 or 3 years ago. The underlying message here was that learning how to learn efficiently, the fundamentals of development, and making informed choices is easily more important than simply trying to master any specific language or environment.

After that we talked through a small feature we need to add, and discussed the pros/cons of different ways we could tackle that problem.

We wrapped up by trying to answer any questions the Code Epic grads had, and we also talked a bit about the pluses and minuses of various work arrangements: consulting or agencies, large or small, in house/product, freelance, etc.

Overall we had a great time. It was really refreshing to talk to some new developers, and learn from them as we shared a bit about what we do and what we’ve learned.

Posted on

Improve your Work by Leveling Up Your Baseline

It’s not often discussed, but it’s easy to be disheartened working as a freelancer or in a small consultancy in this business. More times than I can count, I’ve been to a conference or watched a presentation where someone describes a project they worked on with large teams, long deadlines, and tons of resources. They might discuss how they leveraged a user testing lab, or their findings after a full 508 audit (link), or how their focus on performance sped up their app and increased revenues.

You come home energized and inspired, but then it quickly fades; your projects don’t have the timelines or budgets to accommodate much of what you learned, and pitching accessibility like that to your existing clients makes it seem like an optional piece that can be opted out of. The reality is that unless it’s your niche or you’re known for specializing with it, people aren’t coming to you for a project with a heavy focus in something like accessibility.

Does that mean you abandon what you learned and mope around? Of course not! You should continue to educate current and future clients; they’re hiring you to be the experts, so don’t be afraid to share what you’ve learned and what you’re striving for.

However, there’s a way to start improving your work right now, and that’s simply to level up your baseline. The best example I can think of this is building responsively. A few years ago it was a big deal, or worth calling out (and trying to get client buy in) for building things to adapt to different screens. Now though, we don’t even think about if a project will “be responsive” or not. It’s simply the right way to build things, and the default way we approach all projects. Media queries, scalable assets, and a mobile-first approach are just the way things are done.

There’s no reason we can’t apply a similar approach across the board to our work. We can apply techniques that are new to us, or possibly just new period in bite sized ways, making them part of our default workflows.

Let’s take design and feedback for example. You might not be able to stage multiple design reviews or whole-team critique sessions, but you could probably take a couple hours midway through a project and conduct an interface audit. Once you get used to it, it shouldn’t take too long, and you’ll have a great new tool baked in to your process.

Similarly, you might have learned about improving web performance but you don’t have the time to go all-in and focus on it (like Pinterest has done. But, you can familiarize yourself with the basics of web page test, and run your project/site through it once a week to track your progress (or to highlight areas ripe for improvement). You could identify one area to try and improve, and focus on that as your work progresses.

Accessibility is another area where many of us could improve our defaults. You may not be able to make it a large priority of any given project, but you can take the time to run your text colors and sizes through WCAG tools for contrast and legibility. You can also grab a browser extension like WAVE and check the hierarchy of pages and views your working on, to keep things usable for screen readers and other assistive technologies.

Piece by piece, you begin to level up your defaults you use regardless of what you’re working on. This is a powerful technique to not only help you grow, learn, and implement current ideas and technologies, but should improve the output of any projects you’re working on. You may not have the perfect project or client to do everything you want to do, but if you keeping growing and refining your defaults, each project along the way gets better and better.

Posted on

The Role of Books in a Modern Tech Company

It’s cliché, but the one thing that never changes in the tech industry is that things are always changing. As of writing this I’ve been out of college about 10 years; the devices, environments, and technology I learned are so wildly out of date now that if I hadn’t continued learning, I’d have virtually nothing to offer a client.

We try to make learning and growing a priority at Coffee and Code. We love attending (and speaking) at conferences, and we’re always discussing the latest blog articles and industry news. But for a deeper understanding and more thorough levels of discourse, books are often the answer.

Anecdotally it seems like books have a love/hate place in the tech world. We like to praise authors and retweet new book announcements, but when push comes to shove many of us turn to quick answers on Stack Overflow or social media and blogs almost exclusively. Books seem to be a nice luxury for a company lounge, but not truly essential to our work anymore.

In order to explore books more fully and take our learning as a company to the next level, we started a book club. The rules are simple, choose a book as a team then break it out into reasonable chunks. Set dates to have discussion on the most recent section. The simple act of splitting a book up into sections and discussing each as a group has been refreshing. Peer pressure is an amazing force to leverage to keep yourself accountable (diet and fitness social apps lean heavily on this).

We’ve learned a few things along the way I wanted to share:

Picking titles is hard, but worth spending time on.

Choosing books that suit multiple team members, but also push your team outside their comfort zone is a tricky balancing act. Inevitably a book will probably be below someone’s skill level and likely above someone else’s (and possibly not even in their interests).

If you have a diverse group, trying to alternate between different subject matter is a solid approach. Part of the appeal though is being forced to read something you might not otherwise.

We started out with Git for Humans by David Demaree. Git is something we all use, but have very different backgrounds and proficiency with. Choosing broad topics for the first few books is a good way to get used to the format and the schedule.

Strive to accommodate format preferences.

Some people (I’m one of them) just aren’t fond of longform reading on a computer screen (or tablet/phone). This means paying the extra to get physical copies, or making sure your team has access to e-readers.

Be reasonably aggressive with your schedule.

Everyone is busy; especially in our industry. There’s always something to do, and the pressure to go ‘above and beyond’ is constant: speaking and presenting, blogging, attending Meetups, contributing to open source projects; it all adds up quickly.

It’s easy to set super long deadlines for each chapter or section, but pushing yourself a bit keeps the pressure on and helps you get through each book quicker.

Embrace honesty and have a little fun.

Nothing is set in stone here, if your team misses a session or everyone is a bit behind their reading nothing is going to fall apart. If you haven’t read the section, be honest about it. A little friendly shaming might help a team member who is behind, but remember this is all to help each other grow and learn.

Similarly, if your book discussions veer off on some tangents, that’s fine too. Learning isn’t always a linear process, and inspiration and growth can come from unexpected places.