XSS
30x500 Slack Sync•3mo ago
taryn

if you have a specif

[2023-05-22 11:34:22 PM] : if you have a specific pain/dream/fix example, it'll be a lot easier to guide you to a confident answer. :smile:
1 Reply
taryn
tarynOP•3mo ago
[2023-05-22 11:49:19 PM] : sure thing :+1: Pain: I don't know how to organize my code logic, I don't even know what a layer is Dream: My REST API code maintains itself Fix: Putting business logic where it belongs (And several other fixes I came up with were similar, like "putting HTTP logic in the right place", "putting model code in the right place", etc) When I did the SKW I grouped this pain under "code organization issues" along with others such as "my controllers are doing too much", "what is the difference between a data layer and a service layer", etc. [2023-05-23 12:02:16 AM] : so for the BOG, would the 3-4 pains come from individual pains related to the core pain (from SKW) of "code organization issues" - pains like "my controllers are doing too much" and "what is the difference between a data layer and a service layer"? or would they be from other safari data on this specific pain? I think I'm repeating myself but just want to give as much information as possible as this is where I'm getting stuck [2023-05-24 12:13:38 PM] : got it! appreciate the info. [2023-05-24 12:18:04 PM] : so the answer here is - both options are totally valid! it might be helpful to zoom out and remember why pain/dream/fix works. • pain grabs attention • dream creates tension and momentum • fix points that momentum towards action (think: the three act play that Amy mentions in the video. With that in mind, you can build a pitch around a central pain by adding individual supporting/related pains from your SKW (basically, pains that you could cluster as similar or related). Or, you can add detail/crispiness with other pieces from your safari. It's not an either/or, it's use what you have! [2023-05-24 12:26:56 PM] : the things to avoid would be: • trying to stuff in too many pains, especially pains that are unrelated • for each pain that you include (primary or supporting), make sure that each line in your dream directly connects to a pain. that part is usually roughly 1-1, but that's not a hard and fast rule. • overstuffing your fix. you want a single fix that connects the pain-> dream arc. even if you have multiple pains/dreams, it's a single fix (possibly with multiple elements, but not multiple distinct fixes) [2023-05-24 12:27:21 PM] : does that help clarify? [2023-05-24 03:33:34 PM] : yes, thank you alex ! so to summarize and double-check my understanding: the first step is grouping related pains into a “core pain” via SKW work, then interrogate/fixstorm those pains (this could be individual ones as well as the core pain but regardless it must be crispy/vivid). and from there you could take a couple different paths for the BOG-style pitch: • path one would be: pitch around the “core pain”, using individuals pain/dream combos that were interrogated, and a single overlapping fix derived from fixstorming, as long as those pain/dream combos are related and the fix applies across those. for example, fixstorming several of those related pains under the “core pain” might produce a common fix. • path two would be: a pitch based around a single pain that was interrogated/fixstormed, and instead of the other pain/dream bullets in the pitch being directly from other fixstorming sessions, it would be supporting pain from safari, with accompanying dream (using pain/negate/obliterate to produce the dream) [2023-05-24 03:34:58 PM] : that sounds right to me. my #1 advice is NOT to get hung up on doing this perfectly, and do your best. will be much easier to give concrete feedback on how an actual pitch connects to your understanding, than the conceptual understanding [2023-05-24 03:37:47 PM] : got it, totally agreed. once i have some pitches ready i may chime in again if i'm still confused but i definitely have enough to keep moving here. will be focused on production rather than perfection, thanks again! [2023-05-24 03:41:15 PM] : That's the move. Keep going and share work. Here to help! [2023-06-30 02:43:22 PM] : Following up on this after I was getting stuck on the concepts (context above). Going through the process of putting together some pitches I think things started clicking more. I put together a couple BOG-style pitches, here is one below: 
- Working with your existing codebase is a nightmare to navigate with request logic all over the place
- What is supposed to go in middleware? in routes? in controllers? where does authentication go?
- That code is spread everywhere and now adding any new feature to your REST API has slowed down significantly
- Your code is unmaintainable spaghetti because you don't know what code belongs where, and this is especially true for your controller code

- Your whole dev team loves working on your REST API
- Churn out features with easily maintainable code
- When writing your code, everything falls into place automatically

- with my ebook, learn separation of concerns at the request layer - what kind of code belongs where and why

- what code to put into routes
- what code to put into middleware
- what code goes in controllers
- how much the controllers should be doing
- what belongs in middleware vs. controllers
- where request validation code goes
- Working with your existing codebase is a nightmare to navigate with request logic all over the place
- What is supposed to go in middleware? in routes? in controllers? where does authentication go?
- That code is spread everywhere and now adding any new feature to your REST API has slowed down significantly
- Your code is unmaintainable spaghetti because you don't know what code belongs where, and this is especially true for your controller code

- Your whole dev team loves working on your REST API
- Churn out features with easily maintainable code
- When writing your code, everything falls into place automatically

- with my ebook, learn separation of concerns at the request layer - what kind of code belongs where and why

- what code to put into routes
- what code to put into middleware
- what code goes in controllers
- how much the controllers should be doing
- what belongs in middleware vs. controllers
- where request validation code goes
[2023-06-30 02:43:52 PM] : The core pain here is not knowing where X type of code should go / differentiating between different types of logic. It’s not just “how do I arrange my codebase folder structure”, which is a separate pain I’ve also seen my audience have. I wrote a BOG pitch where the fix is learning where all types of logic go in a REST API but for my first product that was too big in scope. So I narrowed it down to the “request layer” (controllers, middleware, etc) and included pains related specifically to that, while still including the core pain. [2023-07-17 03:45:57 PM] : sorry I missed this response before! this looks like you're on the right path. and I'm glad you saw that a big, blurry pain turns into a big, blurry fix. perfect example.

Did you find this page helpful?