Bloc Tech Talk: Mentor Availability by Module by Joe Lipper

Bloc Software Engineer Joe Lipper takes us through the "Modular Mentorship" project he recently shipped and imparts his lessons.

More info: http://code.bloc.io/bloc-tech-talk-mentor-availability-by-module/

Transcript

1. By me (10/27/2016) Mentor Availability by Module
2. 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
3. How did this work before?
5. 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
6. How do we want this to work?
8. Tha Code
9. Before
10. 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
11. After
12. 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
13. Other tasks • Created two new models ◦ ProgramModule ◦ MentoredProgramModule
14. ~let’s get personal~
15. 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
16. 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 ¯\_(ツ)_/¯
17. 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
18. 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
19. ~fin~