Recently my mentor, taught me about how to conceptualize programming solutions at different levels. In my recent experience, I was used to developing fast hack solutions which I feel is not correct but given short deadlines, I felt little choice about. But instead of thinking about a problem as having only a hack solution or an ideal world solution, my mentor suggested considering the following:
- The fast and hackey solution (AKA The Bad). Sometimes this is not a bad solution but some time should be taken to document why/how it was done and how it may be refactored when time permits.
- The middle ground solution (AKA The Ugly… OK, it is more Middle than Ugly). This is often an ideal solution.
- The ideal world solution (AKA The Good). This is like a “perfect” programming solution (if you had unlimited time and resources). Most likely this solution is going to going to have maximum flexibility for current and future use cases.
Recent Problem and Application
Recently I was working on a webcompat.com issue where there were some record types returned in github issue searches that should be filtered out. The solution that I came up with doesn’t exactly fit within the 3 categories described above (maybe it is somewhere between the hackey solution and the middle solution).
Since the data was coming from 2 Github API types, 2 approaches were needed:
- For the Github search API, it is possible to intercept the user’s search query, append a custom string (negative label filter since the undesired data had a specific Github label attached) and send the resulting query with the Github API request