Larger Codebases

[00:00:00]
>> So some larger codebases, let's talk about in an enterprise context, or simply on a larger engineering team. When you encounter a large codebase to navigate, especially when you're new on a team, it can be tough to sometimes navigate around, especially as a tech lead. I think sometimes tech leads are hired from within.

[00:00:20]
I've also seen tech leads roles where they're hiring brand new people, so you have to get up to speed and so to gather enough context to make contributions. It's like one of the questions I asked in interviews was what's something that a new hire could do within 30 days that would impress you?

[00:00:38]
And an answer I got a lot was make contributions, cuz it can be hard to figure out what is up to be effective. So that's what this is all about. It's like how do you do that? And I have a graphic about different code bases, interestingly, they have the space shuttle on here as being like a big code base.

[00:00:58]
Photoshop 1.0, it's kind of some old classic software. I always call my iPhone my pocket space shuttle, cuz it has more computing power than the first space shuttle, [LAUGH] kind of interesting. Here are some tips, some practical tips. So use core components like either third-party component libraries, Chakra's amazing, there's a bunch now.

[00:01:22]
Headless UI has some good parts. When you centralize the UI components for reuse, either in your own design system or a third party design system, there are so many opportunities for accessibility, or challenges, depending on the library. But as consumers, you can take advantage of those decisions. You definitely wanna test it out.

[00:01:44]
I think sometimes with design systems and component libraries when you're a consumer of them, they're like, they handled it, we don't need to test it, it's fine. But you really do, I think you can do your framework authors a solid by testing it and reporting back. Report issues, cuz they're just assuming it works, it might not work that well.

[00:02:07]
But at the very least, if you centralize to a core set of components, you can make improvements in the central location over time, and that's just fewer places that you have to go and make changes. I've been making a lot of core component improvements to date pickers and selects, and so then we can go grab those.and that already has the capabilities that we needed the last time we worked on it.

[00:02:31]
So some more code base tips, observe conventions and don't be afraid to suggest more accessible improvements. Read through the code base, look who committed what code if you can. Use a get lens extension or something and figure out who committed the anti-patterns and who committed the code that worked better?

[00:02:50]
And can you go and talk to those people nicely and figure out what happened there? What's the story here? Collect all that information and kind of gather your perspective for a bigger picture. And can you make contributions in the scope of your current team priorities? Cuz that can be challenge.

[00:03:09]
Make accessibility easy to test. Get some preview URLs, use storybook, whatever you can do to make it easier to test, you'll probably increase quality. So I'm always pushing for that and it can be hard in some environments, so find however you can do it. Storybook might be the answer, because it's free of some of your other pipeline constraints.

[00:03:32]
Look for accessibility documentation, including some testing steps, and if there aren't any, create some. If you have an accessibility team, maybe you could consult with them, or working with a third-party company of an accessibility vendor, they might have some checklists or some guidance. And then if you have champions on your teams, give them a little time to contribute some accessibility tips, especially when they're tailored to your code base, that can be helpful.

[00:04:06]
Use consistent accessibility test rules and processes. So as accessibility matures on your teams, you wanna all be testing against the same standards. So using the same axe versions, using the same, whatever that rule set is, make sure your axe chrome extension is on the same version as your automated stuff, cuz they improve rules and sometimes they're changes.

[00:04:29]
So yeah, we wanna be aiming for consistency. And there are products at all of the big accessibility vendors that are geared at banks and airlines and those bigger teams that are a bit more mature for accessibility. And then kind of after you've gathered doing the git blame, looking at the code base, see if you can talk to some of those authors to understand what constraints were they under.

[00:04:55]
Cuz it could tip you off on some things that might need to get handled for you to do things right, but be diplomatic about it. We don't wanna be like, why'd you do that? [LAUGH] We wanna be like, hey, what, talk to me about this component. Tell me about what it was like working on that and what's our stance on accessibility?

[00:05:14]
Do you know anything about how we could make this better? The person that wrote it might not work there anymore, that could be interesting, you could learn that too. So just kind of the code has these layers of sediment and artifacts that can tell us some of the story about how the code came about.

[00:05:33]
That can be helpful to learn about.