By me (10/27/2016) Mentor Availability by Module

Stakeholder Needs ● Biggest need: Increase the flexibility of mentor availability ● Other, derivative needs: ○ Search for mentors by what general subject areas they teach on a more granular level than course/programs ○ Keep frontend of this data relatively consistent. ■ Shouldn’t change how students pick mentors ■ Shouldn’t change how we search for available mentors on the admin side

How did this work before?

No content

Mentors could only teach programs ● For example, for a mentor to be eligible to teach any of the Web Developer Track, they needed to know JavaScript, HTML, CSS, Angular, Ruby, AND RAILS well ● Problems the old way creates: ○ Lot harder to hire mentors who teach all of these subjects ○ Forces existing mentors who want to teach for our flagship program to learn material outside of their expertise ○ The effect: unnecessary hiring and training overhead, and decreases availabilty

How do we want this to work?

No content

Tha Code

Before

Problems with the old code ● Lots of it written in 2013 when Bloc had different needs/smaller codebase ● MANY responsibilities tied up in a single class (MentorProfile) that was supposed to be a model ● Unclear flow of responsibilities ○ MentorProfile playing ping pong with other classes ● LOTS of redundant operations ● Super complicated tests

After

Pain points this approach solves ● Clearer flow of data and operations performed on it ● Code grouped by responsibility ● Smaller classes means more easily tested ● Reduce bloat of an already-complicated model

Other tasks ● Created two new models ○ ProgramModule ○ MentoredProgramModule

~let’s get personal~

How did I approach this problem ● I read a lot of code ● Follow the data ● Diagram everything ● Create the necessary data for the solution, then slowly build up the functionality ● Rails console is my friend

Roadblocks and hardships ● Re-writing tests is hard, especially when your factories assume coupled behavior ● Sometimes you miss the details ○ Assume too much about a seemingly unrelated system ○ e.g capacity vs free slots ● Time estimation ha ha ha ¯\_(ツ)_/¯

What would I do again ● I would follow basically the same procedure for getting to know the code ○ Read ○ Diagram ○ Follow the data to understand how the system affects it ○ Plan arch ○ Build the models/create sample data ○ Manipulate the data in a piecemeal way until we end up with the results we want

What I would do differently ● Communicate with others on my team more ○ Pair ○ Speak up sooner rather than later ● Come up with a more concrete plan if you’re not hitting timelines ● Plan for tests ● Make sure I indulge the details of related systems sooner rather than later

~fin~