Pseudocode for Vintage Shell Crochet Hat

Link to original pattern: http://crochet.about.com/library/blshellhat1.htm

This pattern begins with a repeating sub-pattern that takes up 4 stitches of the previous row.
Hence, you need to start with a row of 4*M stitches
In the original pattern, M=6, so you start with 24 base stitches.

U.S. Terms for crochet stitches
dc = double crochet (UK tc)
sc = single crochet   (UK dc)

# if no input number, assume i=1
# general method
def stitch(stitch_name,int i=1):
    crochet i stitch_name stitches

def chain(int i=1):
    stitch(chain,i)

def dc(int i=1):
    stitch(double-crochet, i)

def sc(int i=1):
    stitch(single-crochet, i)

def skip(i):
    skip i stitches from previous row before the next stitch in this row

  
#The definition of "shell" varies with pattern. In this pattern:
def shell(int i, stitch previous_row_stitch):
    dc(i) into the same previous_row_stitch

def flip_work():
    #Rows are worked away from the direction of the dominant hand,
    #If you're right-handed, this means: from right to left

#Turning chains are chains made at the end of the row.
def dc_turning_chain(int i=3):
    chain(i)
    flip_work()

    
#initial loop
def initial_loop(int M):
    chain(M-1)
    join the loop together

# single crochet into all the stitches of the previous row
def end_hat(int i)
    sc(i)

# Pattern = loop of 5 chain-stitches
#           1 row  of dc(24)        =       24 stitches
#           1 row  of sc + shell(3) = 4*6 = 24 stitches
#           2 rows of sc + shell(5) = 6*6 = 36 stitches
#           3 rows of sc + shell(7) = 8*7 = 56 stitches
# dc_turning_chain(3) between each row
# end with single-crochets

# M=6, N=3
def vintage_hat(int M, int N):
    
    initial_loop(M)     # chain 5 & join
    dc_turning_chain()  # chain 3 & turn work

    # 24 double-crochets into the loop
    dc(M*4) into the loop, ignoring the chain stitches themselves

    # now you have M*4 stitches to start the pattern

    # The repeating pattern is as follows:
    # skip 1, sc, skip 1, shell

    # First row:
    for R = 1 to M: #repeat until end of row
        skip(1)
        sc()
        skip(1)
        shell(3) # = 2*1+1 = 3 dc into stitch below

    # Now you should still have 24 stitches in the circle
    #
    for S = 2 to N:
        for row=1 to S:
            repeat until end of row:
                skip(1)
                sc()   into center of previous shell
                shell(2*S+1) into previous row's sc  
            end of row: dc_turning_chain(3)
   shell_size=2*N+1  #=2*3+1=7
   pattern_size=shell_size+1 #=8
   number_of_stitches=pattern_size * M  #=8*6
   end_hat()

python: a little bit about dunder functions

What I learned from looking at Fluent Python yesterday:

• Functions defined with surrounding double-underlines (“dunder”) are called differently
•  e.g. len(my_object) instead of my_object.len()
• In general, we shouldn’t create new dunder  functions
• One reason is that newer versions of Python might use the same name
• __repre__ is called by __str__ if no __str__ defined, so it’s more important to define __repre__()  
• If no __bool__ defined, then python uses __len__() and returns False if 0, True otherwise

Advice on Managing SW Enhancement Requests - Links

From https://www.novell.com/communities/coolsolutions/what-happens-enhancement-requests/:

Once I have seen the request I generally do one of 4 things with it almost immediately.
1. If I know that this is a duplicate of another request I close the new one and mark it as a duplicate of the original.
2. If I see no value to the request, or I see value but the opportunity cost is too high, then I will just close it.
3. If I see value to the request, and it fits in with much of the feedback received on all of the other channels then I will assign it to be considered for a release
4. Finally I can choose to do nothing with it right now. This final one allows me to bear it in mind and use it for consideration on future requests.

From http://support.aha.io/hc/en-us/articles/202000757-Best-practices-to-managing-and-prioritizing-features:

1. You need to know what the goals or key business drivers are for your product so you can create a scorecard that includes these key metrics.;
2. If it is not clear who owns prioritization, your scoring will not be trusted. It's essential to know who is in charge;
3. If there is not enough detail per feature, then the functionality of each feature will be unclear.

From http://johnpeltier.com/blog/2013/12/12/feature-requests/:

1.  Ideas that don’t fit with the long term vision for the product at all.  These receive a polite rejection.
2. Many, many good ideas that you might do someday.  These are usually acknowledged but sit in the “someday” bucket.
3. A few ideas which map to the area of the product that needs work next, or the next most important problem to solve.

Once prioritized, you’ll want to communicate your plans in a roadmap that doesn’t tie you to specific dates.

From https://www.quora.com/How-should-a-product-manager-handle-communication-to-internal-people-who-make-feature-requests-when-the-volume-of-requests-far-exceeds-engineering-capacity:

The backlog should not be a dumping ground for all ideas that may get worked on eventually, or may not. It will become impossible to manage and just gives the requestor a false sense of security by having it added. If you don't see yourself working on a backlog item in the next ~4 months, I recommend just telling the person no, point blank, or maintaining a separate list or roadmap outside of the backlog for these items.