Save 37% off PRO during our Black Friday Sale! »

Bloc Tech Talk: Mentor Availability by Module by Joe Lipper

955a5fe02c974f1ccb7ed1c4590c1d64?s=47 bloc
November 02, 2016

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/

955a5fe02c974f1ccb7ed1c4590c1d64?s=128

bloc

November 02, 2016
Tweet

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?

  4. None
  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?

  7. None
  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~