DEV Community: Nellie

Learning K8s on EdX

Nellie — Fri, 02 Jul 2021 21:22:52 +0000

Background:

I have never been great at learning from text. It becomes easier for me if I can apply knowledge, and if I can visualize it. So when a good friend pointed me to the EdX course, I initially browsed the chapters in the unpaid version. Paying money to learn from texts is a hard sell for me. When the friend offered to pay for the course, I had to give it a try.

Things to know about the course:

1) The quizzes or chapter knowledge checks at the end are open-note. You can look at the questions before going through the chapters. I didn't realize this until about chapter seven and had failed a few questions because I didn't know I could go look for the answers in the chapters.
2) There are a few 'trick' true and false questions. With true and false questions you do not get more than one attempt at a correct answer. A straightforward example would be asking if a pod is self-healing, by phrasing it, "can a pod heal itself". The answer here is not true. Although the internet will tell you Kubernetes pods are self-healing, they in fact do nothing to heal themselves.
4) The chapters are an info dump and expect to have to look a lot of things up to get a clear picture of what you are learning.
5) A few of the links are outdated, and I failed to install Kubernetes on my Windows home machine after fighting for days trying to find a solution. Linux for the win
6) There is a lot of useful information in each chapter, and I feel that for people who can learn from text, this course is a great option.

What I learned:

HOLY CRAP is Kubernetes huge and complex. I can also understand, in my small way, why container orchestration is necessary for large-scale projects in today's inter-webs-driven businesses.
The interconnections between containers/pods/api and end user or developer are important steps to conceptualizing how all the components fit together.
A lot of the info in the course can be daunting and scary if this is your first encounter with containers and cloud web-type interactions.
If you are like me and have trouble passing over topics and concepts that you don't fully understand, please do yourself a favor and stay out of rabbit holes. You can look those things up at leisure another day, focus on the Kubernetes material. It is hard, but I promise the final exam is open book, and most things are googlable or findable in the course material.
Special note, there are some things that I could not find either through google search or in the chapters. It may be my skill to blame, or it may be that some questions were written to have you infer answers from the given information.
Communities around Kubernetes are there waiting and willing to help as you learn. insert shameless plug for my favorite k8 community

Data on Kubernetes Community

I've never had the opportunity to work on a project that needs such a robust and complex system to keep it running and maintainable. If I do, I won't be as terrified, but still a mite frightened, of using k8. At least now I know why I'm afraid. I think.
Link for course: Introduction to Kubernetes
Happy coding, and may the spam be ever in your flavor.

Double Linked List part 3

Nellie — Sun, 15 Nov 2020 20:48:37 +0000

Moving it all around.

When I wrote the original swap() method it took many twists and turns to get unwanted results. When I approached it this time, I wrote bits and pieces and tested it as I went.

All the current code for the Double Linked List, it’s pytest file, and a simple starter file to play with methods are in this GitHub repo:

Python DLL on github

What are the reasons you would want to move the nodes around?

To sort
To remove/add data
To get/set new data

When looking at sorting methods in many languages, the language needs to be able to change the position of the data in the list. A simpler way than the swap method below, is to just swap the data from one node to the other and not mess with the pointers/links.

The problem with doing that is there may be more than one data set in the node. Now given the node in this particular case has just one data, self.value, if in the future the node was modified or replaced to hold more than just one piece of data, we want to preserve all the items in the node. Even though it’s more complex to swap the entire node, we now have a Linked List that is written for future use.

I stumble around every time I have to play with the next and previous. Especially with this swap. The code, and then some explanation.

swap code:

 def swap(self, index1, index2):
        node1 = self.get_node(index1)
        node2 = self.get_node(index2)
        print(f"size = {self._length}")
        if node1 != None and node2 != None:
            #print(f"node1 = {node1.value} , node2 = {node2.value}")
            self.swap_helper(node1, node2)
        else: 
            message = "One or both of the index's are an index Error. \n Could not swap"
            print(message)
            raise IndexError

    def swap_helper(self, node1, node2):

        #[or NONE spam -- n1-->][<---spam---node1--eggs--->][<--n1--eggs or NONE]
        #[or NONE bags -- n2-->][<---bags---node2---nots-->]<---n2--nots or NONE]
        ### make sure they are not next to each other ###
        temp1_next = node1.next 
        temp1_prev = node1.prev 
        temp2_next = node2.next 
        temp2_prev = node2.prev
        #print(node1, node2)

        #[<--  node1 --->]*CHECK*[<--- node2 -->]
        neighbor = False
        if node1.next != node2 and node1.prev != node2:
            node2.next = temp1_next
            node2.prev = temp1_prev
        else:
            neighbor = True

        if node2.next != node1 and node2.prev != node1:
            node1.next = temp2_next
            node1.prev = temp2_prev
        else:
            neighbor = True

        if neighbor:
           if node1.next == node2:
               node1.next = temp2_next 
               node1.prev = node2 
               node2.prev = temp1_prev 
               node2.next = node1 
           elif node1.prev == node2:
               node1.prev = temp2_prev 
               node1.next = node2 
               node2.next = temp1_next 
               node2.prev = node1 


        #print(node2, node1)
        # swap the nieghbors pointers               
        # neighbors 
        #[<-- prev neighbor -->][<-- node1 -->][<-- next neighbor -->]
        #[<-- prev neighbor -->][<-- node2 -->][<-- next neighbor -->]

        if temp1_next != None:
            if temp1_next != node2:
                temp1_next.prev = node2

        else:
            self.end = node2

        if temp1_prev != None:
            if temp1_prev != node2:
                temp1_prev.next = node2 
        else:
            self.begin = node2

        if temp2_next != None:
            if temp2_next != node1:
                temp2_next.prev = node1
        else:
            self.end = node1

        if temp2_prev != None:
            if temp2_prev != node1:
                temp2_prev.next = node1
        else:
            self.begin = node1

Explanation swap()

In the code, the swap_helper is doing the work of reassigning our addresses, (the links/pointers).

There are a few things that need to be considered when moving them:
1) Are one, or both nodes the lists tail and head? (self.begin, self.end)
2) Are these nodes pointing back at each other? (neighbors)
3) Do the nodes exist? (IndexError)

The code addresses each of these statements in steps.

An IndexError is handled in the top method swap(), if it is not a valid index, we want to let the user know right away, and stop the process there.

The tail and head, begin/end are important, because if we just swap out the links, the attributes that the list uses, self.begin and self.end will not change. Our list is now broken. Whenever we use either of these to retrieve something from the list the self.begin and self.end were not set to the new node values that point the the appropriate next and previous nodes.

The reason the neighboring links are important, is regular swapping of these nodes will cause a recursion. They will point back to themselves and cause a loop.

By addressing each of these issues, we can also assure that any two valid index’s can be given by the user, in any order, and they will be swapped effectively.

They can use swap(0, 10) and get the same results for swap(10, 0). Whatever the preferred order of the user is in entering the index they want swapped, it will work either way.

This is accomplished because each node is treated as it can be anywhere on the list. The first index could be an end node, or it could be a begin node. We check both things for each node to ensure the swap is done correctly.

The bit I’ll admit I always stumble over is the last piece. Swapping out the neighbor pointers.

Each node has two neighbors, (If it is not an end, or a begin).

#[<-- prev DATA A -->][<-- node1 -->][<-- next DATA C  -->]
#[<-- prev DATA H -->][<-- node2 -->][<-- next DATA J  -->]

Since we’re swapping the entire node out to preserve all pieces of data, We will need to change the pointers/links that inhabit the neighbors.

#[NEXT points to node1 address -->][NODE 1][<--PREV points to node1 address]
#[NEXT points to node2 address -->][NODE 2][<-- PREV points to node2 address]

When we change these nodes, the address in the prev and next nodes needs to point to the proper address for the swapped node.

Since this is a doubly linked list, we can access those nodes to change the pointers just by having the nodes that are being swapped.

The next of node 1, is node1.next. The previous of node1 is node1.prev.

Once we have those, we can just change them to point at the swapped node, node2.

The problem when these two nodes are next to each other is that the nodes already point at each other, and not some other item in the list.

Instead of the next/prev of its neighbors pointing to a different unique location, they will point at the nodes we are swapping.

#[<-- DATA A -->][<-- node1 -->][<-- node2 -->][<-- DATA D -->]

So instead of those temps being something like
PREV neighborA = node1.prev
NEXT neighborB = node1.next
PREV neighborC = node2.prev
NEXT neighborD = node2.next

That neighbor B is actually node2.
So if we were to swap the links without accounting for that our new arrangement would look like this:

# [DATA A -->][<--  node2   <--next  ]       [--prev -->  node1 --> ] [DATA D]

Our list is now broken, because once it hits either of these nodes, it circles back on itself, and as I found out, it could loop indefinitely.

In order to fix this, we check both nodes to make sure they don’t point at each other in either the NEXT or the PREV. If they do, we need to manually set those links to point at the other node, because otherwise, the nodes will point back at themselves.

How could swap be used?
Python already has a neat trick built into it. You can swap assignment values like so:

somelist[A], somelist[B] = somelist[B], somelist[A]

Think sorters, higher structures that may access the lists like hash tables, and if there are more reasons I’d love for you to drop them in the comments.

Insert

The insert can be used when a user wants to add new data into a specific location in the list.

This currently does not attach already existing nodes.
May add this feature.

This too does a bit of manipulation with the neighbor links, as we are pulling two nodes apart to add the new node in. If the item is going at the beginning of the list, I have written a ‘prefix’ function to handle that, and if it’s going at the end it will be a push(). We cover those grounds even though a user should be pushing instead of inserting in the instance of wanting it at the end of the list, but humans are human. Let’s leave wiggle room for whatever they can throw at this list.

When I wrote this, I had to look up C implementations to see how they changed the links, because I couldn’t wrap my brain around setting the links in the correct order without overwriting links and destroying the order before it could be changed.

Example:

#            NODE B
# PREV = NODEA,  DATA,  NEXT=NODEC
#
#            NODE C 
# PREV = NODEB, DATA, NEXT=NODED

If I change that NEXT pointer in NODEB before I have that address stored, like so:
NODEB.NEXT = Newly_Inserted_Node

When I go to get the next node, NODEC, to assign it’s previous pointer, I’m actually going to get
Newly_Inserted_Node instead of NODEC

The Insert



    def insert(self, obj, index):

        head = self.begin
        tail = self.end
        length = self._length
        # check if they are just pushing.
        if index == length:           
            self.push(obj)

        # check if they are prefixing        
        elif index == 0:            
            self.prefix(obj)

        # check if they are indexing out of range:
        elif index > length:
            # to bypass pytest error, import pytest and in your test use:
            # with pytest.raises(IndexError):
            #    mylist.insert('obj', 99)
            # where obj is the item being pushed, and 99 the index out of range
            print(f"the length of this list is: {length}")
            raise IndexError



        # [(/), (a)DATA, (b)-->]  [else]  [<---(a)DATA, (/)]
        else:

            head = self.begin
            count = 0
            while head:

                if index == count:
                   self.attach_node(head, obj)
                   self._length += 1
                   break
                else:
                    head = head.next
                    count += 1




    def attach_node(self, node, obj):
        #                    newnode
        ### node ### [<---a ,   x   , b--->] ### node ###

        #    old previous ((a))      index node being replaced((b))
        #  [ ~~ ,  a , --->]   ((x))    [<----, b , ~~ ]

        newnode = DLLNode(None , obj, None)
        #1 [<---a--,  x ,  (/)] set prev of newnode
        newnode.prev = node.prev
        #2 [<---a--, x , --b--->] set next of newnode
        newnode.next = node
        #3 [~~  ,  a  , ---x-->] set next of previous node to newnode
        node.prev.next = newnode
        #4 [<--x---, b , ~~ ] set previous of the index, given node to newnode
        node.prev = newnode
        # doing (3 and 4)   out of order will break your list.

explanation insert()

When working with data structures, inserting an item at an index can be a useful tool. Think once again of sorting, or higher order structures that may access a linked list as storage.

A table for instance where you want a new data row to go in between two other pieces.

The table will need to be able to insert the row, or an existing row, moving the data around to the users specifications.

Data Structures are a foundational piece of software engineering and data manipulation. I hope these articles have helped in some way to broaden the understanding of what happens under the hood of your code.

Drop comments, as always, feel free to take it, break it and have fun.

Internet Explorer compatible
Level 2 of LinkedList game

Double Linked List Part 2

Nellie — Sat, 14 Nov 2020 18:30:33 +0000

The importance of the links.

A double link makes a few things possible. As a foundation, the two links are also foundational to binary trees, and many sorted data structures. In a binary tree the links can be used to insert data into a structure on a ‘more than’ and ‘less than’ value system.

Think of travelling on a set of streets. The linked list is linear, and there are no shortcuts. As the search for the address goes on, you can only travel down the short one way streets in one direction, so even if that address is at the very end of the path, the whole path has to be traveled. Also related, bubble sort.

To sort this kind of structure, one must touch every node on every iteration to change it’s location. Slowest of sorts, in contrast something with double links can be sorted with a quick sort, where nodes when you have them, can be swapped in place because the neighbors and it’s addresses for it’s neighbors are contained in the node.

In a binary tree, the data is arranged so that one can cut across the paths, or in better words, the paths are set up in such a way that travelling down the roads directly to a location is not bound by one way travel. The car can go left, if the value is known to be on the left side of town, or right if it’s on the right side of town. Once in that position, we can once again say, do we need to go east or west? And so on, until the location is reached, bypassing all unrelated paths to the address.

The delete/remove method

The value of double linked lists lies in the ability to look ahead, and look back. In a single linked list, you can move among the nodes, but once you’ve gotten to your location, there is no going back. This is where the double links are helpful. Removing, replacing and swapping out values becomes easy. The addresses of the neighbors are known by each node. Delete/remove is a great example.

-- start code block --

 def remove(self, obj):
        head = self.begin
        while head:
            if head.value == obj:
                result = head.value
                self.detach_node(head)
                self._length -= 1
                return result
                #testing return result
                break
            head = head.next


    def detach_node(self, node):
             ### node ###   [  <---1  , 2DATA , 3--->  ]  
             ### list ###
       # [(/), 1DATA , ((2--->))][**<---1**, 2DATA** 3--->**](([<----2)))), 3DATA, (/)]
             ### after detach ###
       # [(/), 1DATA , 3--->][<---1 3DATA, (/)]
        if node.prev == None and node.next == None:
            self.begin = None
            self.end = None

        elif node.prev == None and node.next != None:
            # node is a begin node:
            #[(/) node ---next-->][<----new---->]
            newnode = node.next
            if newnode.next != None:
                # newnode is not the end node
                self.begin = newnode
                self.begin.prev = None
            else:
                # newnode is the end node
                # two items on list
                self.begin = newnode
                self.end = None
                self.begin.prev = None


        elif node.next == None and node.prev != None:
            # node is an end node:
            # [<---new ---node ---->][<--new--- node  (/)]

            newend = node.prev
            if newend.prev == None:
                ## newend is the begin node
                ## two items on list
                self.end = None
                self.begin.next = None
            else:
                ## node is end node
                ## more then two on list
                self.end = newend
                self.end.next = None

        else:
            ## item in the middle of list.
            ## not begin or end node

            prevlink = node.prev # <---1
            #[(**<---1**), 2DATA,  3-->]

            nextlink = node.next # ---> 3
            #[(<---1, 2DATA, (**3--->**))]

            #node.prev.next = 2--->
            #[(/), 1DATA, ((**2--->**))]
            # nextlink == ----> 3
            node.prev.next = nextlink

            #node.next.prev = <----2
            # [**<---2**, DATA3, (/)]
            # prevlink == <-----1
            node.next.prev = prevlink

-- end code block --

The middle of the list is the important bit. When I’ve passed the node in to be removed, it has both neighbors’ information. We can tell the neighbors to this node, this is your new neighbor’s address, and remove the one that originally occupied their links.

The node to be deleted holds the previous nodes address, and the next nodes address, and as such we can access them, and tell them that the node in question is gone, and squeeze them together by changing the links that originally pointed to that removed node, to each other instead.

Wikipedia: Double Linked List

The pop method

With a single linked list, depending on which direction the list is built, only the next neighbor is known, and to retrieve the neighbors a sorting algorithm would have to find that neighbor before a removal can be done. Once again think bubble sort in comparison to Quick Sort.

The detach node in the code can be reused in different operations, think pop() where the last item is removed and returned, or shift(), where the first item is removed and returned.

Here’s the code for those two operations.

--start code block--

 def shift(self):

        head = self.begin
        # end and begin node never occupy the same space
        # If a list size is one, we will still be retrieving the first node

        if head != None:
            temp = head.value
            self.detach_node(head)
            self._length -= 1 
            return temp 
        else:
            message = "This is an empty list"
            print(message)
            return None

#--------- pop() --------------# 

def pop(self):
        lastnode = self.end 
        if lastnode != None:
            temp = self.end.value
            self.detach_node(self.end)
            # in detach_node, the length is not changed
            self._length -= 1
            return temp

        elif self.end == None and self.begin != None:
            temp = self.begin.value 
            self.detach_node(self.begin)
            self._length -= 1 
            return temp
        else:

            message = "The list has no last value: empty list."
            print(message)
            return None

--end code block--

As I wrote this draft, I realized I had never created a pop() for my Double Linked List and set out to make it. Through the typos, and the pytests, I cleaned it up rather quickly and was able to add it as intended to the post. Some would say knowing these lists are unnecessary in entry-level jobs, and as someone who is horrid at memorization, I agree that memorizing them is not efficient. An understanding of the structures is valuable however. In the bigger picture, as your code evolves, understanding them will help you troubleshoot problems in other structures, and algorithm challenges as they present themselves.

I’m going to include the graphical method I used to print off the nodes of the DLL, so if you want to tool around with making one, you can have a way to print off what is going on in your lists in the shell/CLI/Command prompt.

Bonus code, Graphical

Example use:

With the DLL.py as the file that the Double linked list and node object reside. If you’ve named yours something else, don’t forget to change the DLL => yourfilename. Remember, the file must be in the same folder as the one you create below, or you’ll get
Import errors.

--code somefilename.py--

from DLL import * 

# create list
mytrees = DLList()
mytrees.push('pine')
mytrees.push('maple')
mytrees.push('palm')
mytrees.push('redwood')
mytrees.push('baobab')

mytrees.graphical()

--endcode--

As always, take it, break it, learn and may the spam be ever in your flavor.

-- Graphical method--

 def graphical(self):
        ##  graphical uses the prev, to go through the list.
        ##  so it's like an invariant check..................
        ## None = (/)
        ## [ link = node in list ]
        ## OBJ =  (data count)DATA?
        ##   [  prev  2 , third data,  next none ]
        ## so, [ <---2 , (3) DATA ,  (/)  ]
        length = self._length
        node = self.begin
        if self.begin == None:
            print(" EMPTY ")
        elif self.begin != None and self.end == None:
            print("\n\n")
            # [(/), (0) DATA, (/)]
            print(f"{node.value}=")
            print(f"[(/), (0) DATA, (/)]")
        else:
            node = self.end
            #I only modify length to keep track
            if node:
                print("\n\n")
            while node:

                # example, length is 3
                if node.next == None and node.prev != None:
                    # [ <--2 , (3)DATA , (/) ]
                    print(f"\t\t{node.value}=")
                    print(f"\t [<-- {length -1}, ({length})DATA , (/) ]")
                elif node.next != None and node.prev != None:
                    # [ <--1, (2)DATA , 3-->]
                    print(f"\t\t{node.value}=")
                    print(f"\t [<-- {length -2}, ({length-1})DATA, {length}-->]")
                    length -= 1
                else:
                    # [ (/), (1)DATA , 2-->]
                    print(f"\t\t{node.value}=")
                    print(f"\t [ (/), (1)DATA, 2--> ]")
                node = node.prev
                print("\n")

end notes

Part 3 will be discussing the swapping nodes and inserting them.
It may be a little bit, I need to re-write my swap methods. They are a bit spaghetti at the moment.

Double Linked Lists

Nellie — Thu, 05 Nov 2020 01:00:35 +0000

There is a lot of chatter amongst the tech community as to whether or not being able to build or understand a linked list is necessary in this day and age. Arrays, lists, objects and dictionary type data structures are built into higher level languages, even JavaScript, and we as developers don’t necessarily need to understand what is under the hood, just how to manipulate it.

I’m a believer in understanding at least some of what drives your vehicle. If you think you need blinker fluid, and really your antifreeze is empty, it can cause serious problems. Now if you have a mechanic on hand that constantly checks for these things, it may not be an issue, but I think it’s helpful knowledge, and can’t hurt to understand a little of how these structures work deep beneath the surface.

A reminder, I share all my code so you can learn from it. Feel free to copy and paste, destroy it, dissect it, manipulate it, and have fun. I would suggest having an intermediate understanding of Python if you wanted to attempt the Linked List without my starter code.

The Object

Python is considered an Object Oriented Language. Without going into a deep dive in this subject, think of an Object as a piece of Tupperware, or a blueprint. When it is created, and assigned values, Python wraps it all up into a neat little dictionary or it’s own data structure, and places all those values and contents at an address in memory. Once the object is created, it will remain while the code is being run. Once Python decides the object is no longer needed, it releases the memory space that object once occupied.

Items to look up:

Python Class
Python Object
Python Garbage Collection
Python self

For now, just think of these objects as blueprints, and when we build them and use them, python manages all the memory space they need and occupy. A neat little Tupperware bowl filled and labeled with whatever we want. The node is an Object, as well as the Double Linked List. You can play with the nodes, without the list to get a feel for what they are, and what data they are holding.

Think of the (self) as a way for Python to keep track of what belongs to what object. A way of deciding which things the class is allowed to alter within itself, or that other classes(objects) can access to alter inside of it. If the class has an attribute self.hat = ‘big blue hat’ we’re stamping that hat with a label that says it belongs to the object it was declared in.

Once they are created inside the list object, they are stored as objects in the Linked List. So one container holding another container. Or if you build a massive pile of nodes, think of the List as a cupboard, and the nodes neatly organized containers inside the cupboard. The class itself is how Python builds the objects, the containers, and they don’t exist except for as blueprints until we’ve told Python to go ahead and build them.

Then we have an accessible cupboard full of little Tupperware's we can use as we go.
What’s inside the nodes is data, what they are labeled with is an address that Python assigns to it once it is created from the blueprint.

The Node

You can think of the node as a data container. It will hold some kind of value, or even object, and the computer can look it up for you by way of your linked list. The node has two attributes that help make this possible. The previous, and the next links. These items, when the node is initiated, can be set to point to the next item in the linked list, and the one previous to it. Think of the next and previous as pointers, or directions for the computer. These links serve as a location getter as your machine needs to traverse the list, from back to front, or front to back.

A binary tree starts in the middle, and uses a similar system, but the items are placed in a value system instead of when they are entered by the human driver. In a binary tree the computer places the nodes in their new homes as the human enters them
based on how their data/or name ranks in the value system. The python binary tree will be in a future post.*


    class DLLNode(object):

        def __init__(self, prev, value, nxt):
            # the first node will have no next or previous
            self.value = value
            self.next = nxt       
            self.prev = prev

        def __repr__(self):  #[ <--- prev ,  DATA  , next ---> ]
            nval = self.next and self.next.value or None
            pval = self.prev and self.prev.value or None
            ##  previous node,  assigned value, link to next node 
            in list ##

            return f"[{repr(pval)}, {self.value}, {repr(nval)}]" 

            #SEE NOTE

NOTE: if you are not in a python 3+ version, the f-string will
error in anything below 3.
The f-string exists in 3+ but not in 2.7. If you can, always
run experimental code in a python virtual environment in case
things go horribly south, and to keep your running version in
check.

Python language in particular has a habit of introducing new
capabilities that are not backwards compatible. If you keep
having errors from code, and have checked everything else, see
if you’re using a new feature of a new version. Your older
version may not know what to do with it.

We start the list by giving it two attributes, and some functionality.

For a data structure, the most simple things to focus on:
How to add data to it : push
How to check it’s size: count
How to get a piece of data: get

The Push

The push will add new nodes to the list. There’s a little required knowledge to this process.
The list starts with an empty start(head) and end(tail) point. As nodes are added, the nodes will be placed on the end of the list. In order for this to happen, we have to change that end node, so it now points to our new data node.

In the very beginning, the empty place of the start node will be taken by our very first node. I’ve set my list up a bit differently than the directions given by the Learn More Python the Hard Way. I decided that in order to keep the list as decipherable, and tangible as possible, we should never have the end node, and the begin node be the same position, or address in memory.

The node being stored in memory is an object. It has an address that looks something like 0xp464739osdo000 (completely made up random digits). When python looks for that node, it looks for an address, and at that address is where our memory has our node stored away for future use.

I’ll give you some code, then explain in more detail.
NOTE: if you accidentally type

__inti__

instead of

__init__

Python will not error, but your code will not do what you think it should. At least in 3.6 and 3.7 I found this to be true.


    class DLList(object):
        def __init__(self):

            #  end holds the last node, and after the list is 
            # greater than 1 the whole list
            # through it's previous links

            self.end = None
            #  begin holds the first node, and the whole list 
            # through it's next links
            self.begin = None
            self._length = 0




        def push(self, obj):


            # if there is an empty list,  create the first node 
            # with no next or prev.

            if self.end == None and self.begin == None:

               newnode = DLLNode(None, obj, None)
               self.begin = newnode
               self._length += 1


           ## if the list has contents, I never want the begin and 
              # end to be the same node or address.
            elif self.end == None and self.begin != None:
                # get the address of the original node
                node = self.begin
                # create address for new node
                newnode = DLLNode(node, obj, None)
                self.end = newnode
                self.begin.next = self.end
                self._length += 1

            else:
                #[ <--- , DATA,  (/) ]
                node = self.end
                # list:   [<-node---, DATA,  (/) ] ,
                # [self.end, obj, None]
                newnode = DLLNode(node, obj, None)
                # at this point the list has at least 2 items... 
                # the begin is pointing to the next item
                # which if with 2 items is the end node.  
                # We only need to change the end node. Begin node
                # does not need to be altered.
                # change self.end next
                # [ <--*old link---, DATA, -- newnode -->  ]
                #  * old link*   it doesn't matter what this link 
                # is. It was set a long time ago.

                self.end.next = newnode

                # Now I set the end = to the newnode that is 
                # pushed on
                # self.end = [ <--- old self.end,   DATA,  (/)  ] 

                self.end = newnode
                self._length += 1

            assert self.end != self.begin

Explanation (Push):

One of the things I had trouble wrapping my head around when I started this project, was how the list kept track of all the nodes, when only the end, and begin were listed as class attributes.

Here’s the magic of the Linked Lists:
When we create a new node, and tell the other nodes where it’s address is, or link them to it, they are all a part of the structure now of the object, although not clearly visible, they are there, stored away in memory as much as if we said, x = ‘42bananas’ and stored that in the object never to be used again. The reason it’s not lost, is the begin node, and the end node, from the when we first push a node into our DLList, are holding a reference to the next, and previous item. (it’s location in memory).

The begin node and the end node are stored as attributes in the Python object’s dictionary, and as such, their links can be used to retrieve whatever they point to, the address or the variable or the object that is stored there. And since the next address is in there, so is the address it stores, so on and so forth until we get to the end node, the last node which also references all the nodes before it.

The doubly linked list is different from a single linked list, because you can start from the beginning (head) or the end(tail) and work your way through the data nodes. In a single linked list, depending on the direction it is built to store the nodes as they are added into the structure, can either be a Stack, or a Queue. Single linked lists only unpack, and retrieve the data in one direction. Either from the first to last, or last to first.

I have links to my old blog if you’d like to see the code for a single linked list. I’ll add that at the end.

The count

This method can be used in various ways, and in the end I decided to add the _length attribute to the list so time wasn’t lost by iterating through the entire node phone book just to count it’s contents. (Phone books were once used in antiquated times for looking up a person’s name, phone number and address. The names were listed in alphabetical order, and a person had to pay a special fee to be ‘unlisted’ in a phone book.) I found a use for this though, and a challenge you can set up for yourself is to use something like this count method, to print off the nodes in the list. It’s very useful for debugging and for my fellow visual learners, it helps a lot to see what’s going on.


        def count(self):
            count = 0
            node = self.begin
            while node:
                count += 1
                node = node.next
            return count

Explanation (Count):

The count method, which belongs to the DLList object, accesses the begin node by assigning it to a value,( node = self.begin).

The while loop will check it’s condition on each run. Python, if an object is None, will stop the loop. It’s equivalent to saying while true. Once that true becomes a false, the loop exits. Because our end node has a ‘next’ of None, when the node value finally reaches the end of the list, the while loop shuts down. So each loop, we add to our count, change the node to the next one in the list by grabbing it’s address, (node = node.next) and continue until we get to the end where next = None on that end node.

The reason this method is more expensive for running instead of keeping a _length count as you add or subtract nodes from the list, is every time we need a count, it will have to go through every node to evaluate the number of nodes. This could also be seen as O^n. If you have 300 nodes in your list, it will have to touch each item one time. With the _length, to get the size of our list, we access the self._length attribute once, and receive back our count.

The Get

Remembering we have a _length on this list, we can use this number for indexing objects in the list. While the get still loops through every item, it stops once it reaches the desired location, and we can have it check to make sure the index exists before executing the loop.


    def get(self, index):

            index = int(index)
            length = self._length
            count = 0
            if length == 0:
                return None
            elif index >= (length):
                print(" index out of range! ")
                # this should be an error for the real thing
                # raise IndexError
                return None
            else:
                count = 0
                node = self.begin
                while node:
                #print(f"while loop.{count}")
                    if count == index:
                        #print('get return value:')
                        #print(node.value)
                        return node.value


                    node = node.next
                    count += 1

Explanation (Get):

It’s very similar to the count method. It still has to possibly go through the entire list to get the value and return it. If for instance, someone was looking for the last item in the list, it would have to go through the entire list, comparing the index the user asked for to the current count value. Once it finds the match, it returns the value of that node, or the data we decided to store within our Node(object).

That’s all for the Double Linked list for now. The next post we’ll go over pop(), remove(), and shift().

I'm working with learning WordPress to create a site to hold my blog posts and migrate them from my old coding blog on blogger.
This post was originally mostly code, and little explanation in blogger. A rewrite was in order, and I hope to contribute more soon, but hopefully to the new site.

As promised:

Want to play a silly simple game with nodes?
(Drag and drop is not available on Internet Explorer)
https://nelliesnoodles.github.io/LinkedListGAME/

This one will also get a re-write and explanation if there is enough interest in it.

A Python Single Linked List:
https://camelcasenoodles.blogspot.com/2017/12/new-single-linked-list-python.html

Blue Collar Value: Work Ethic

Nellie — Tue, 27 Oct 2020 14:57:39 +0000

Definitions

Work Ethic: Work ethic is a belief that hard work and diligence have a moral benefit and an inherent ability, virtue or value to strengthen character and individual abilities. It is a set of values centered on importance of work and manifested by determination or desire to work hard. Social ingrainment of this value is considered to enhance character through hard work that is respective to an individual's field of work.
[Wickipedia link- https://en.wikipedia.org/wiki/Work_ethic]

Salary Employment: A fixed regular payment, typically paid on a monthly or biweekly basis but often expressed as an annual sum, made by an employer to an employee, especially a professional or white-collar worker.
[Google definitions]

Hourly Employment:
An hourly worker or hourly employee is an employee paid an hourly wage for their services, as opposed to a fixed salary. Hourly workers may often be found in service and manufacturing occupations, but are common across a variety of fields. Hourly employment is often associated but not synonymous with at-will employment. As of September 2017, the minimum wage in the United States for hourly workers is $7.25 per hour, or $2.13 per hour for a tipped employee. As a tipped employee, wages plus tips must equal the standard minimum wage or the employer is required to provide the difference.
[Wickipedia link- https://en.wikipedia.org/wiki/Hourly_worker]

How hourly employment affects the employee

I won’t be delving into Salary Employment, because as an employee and in management, I’ve never experienced it. My paycheck has always been dependent on the hours I spent at the job, with paid breaks, and without. The Blue Collar Employee is almost always hourly. With the given exceptions of tipped employee’s and those with incentive earnings, the blue collar worker will see a paycheck reflective of the time they’ve given see section on rewarded behavior for clarification. The job difficulty itself, whether it be working as a home health aide, or being a cashier at a register, may have no effect on the paycheck.

What about financial reward? Among other reasons, a blue collar worker may not see a raise because of excellent work, or quality perseverance. In a lot of the blue collar fields, raises are given on a yearly basis. Sometimes in the range of 3-25 cents an hour.

Roughly $1.20 - $10.00 a week, $62.40 - $520 a year.

The pay, as an incentive, isn’t what keeps employee’s coming back daily to their job. As an at-will employee, a person can lose their job for any reason (other than verifiable, provable discrimination, which is extremely hard to fight, and requires a good deal of money to take to court).

So what keeps the cashier coming to work, and doing their diligence to perform well? As someone with experience as a laborer and a manager, I can tell you that any worker can lose their job or keep them depending on company policy, and labor costs. As a manager, when you recognize a great employee, you do everything in your power to keep them on the team. As a team member, having a great co-worker can make even the most difficult tasks a little easier to complete.

Cause and effect, the reward of working hard

Overtime is most commonly given when an employee has accumulated more than 40 hours in a work week. A lot of blue collar folk depend on overtime to supplement the low wages they receive. The most valuable commodity for a blue collar employee? Their time.

A hypothetical situation:

Jan often works Saturdays to help the shop catch up on work that is overflowing by Friday. While Jan knows she will only see an amount extra on her paycheck relative to a full tank of gas, or a paying that extra large bill without as much financial stress, she shows up diligently to her job, prepared to do whatever it takes to keep in the graces of her peers, her boss, and by default the company. This weekend is her nieces wedding though, and has to say she can not work on Saturday.

The next week, Jan comes down with the flu, and despite her best efforts to convince herself to just tough it out and head to work, she calls in sick. Her company does not have sick days. But she works Saturdays, so she could make up for it. When she returns to work, the boss doesn’t ask her about Saturday. So she approaches the subject. She is told since she didn’t work last Saturday, the hours are given to a different employee.

While distraught and angry, she must continue on. Her fellow employee thanks her later for not pulling rank, because they have a child in need of dental surgery, and the overtime would help with the co-payment. Jan still does the job to the best of her ability, hoping that she gets the overtime back soon, but humbled by the idea that she hadn’t considered someone else may be in greater need of the Saturday pay.

Blue collar folks know the value of their time, they know humility, they know how to make sure things get done, and maintain a relationship with their corporation. Because the consequences of not being able to do that can mean losing a job, and losing the ability to afford that full tank of gas.

The body of work

Another thing Blue Collar folk often sacrifice with little payoff, is their bodies. If a corporation has a sign by the time clock that says “Employee’s are 200% responsible for their own safety”, they probably aren’t very strict about OSHA regulations, or the enforcement of safe working procedures. The default of these companies is to lay any physical injury on the employee’s habits instead of the unreasonable task the employee may have been assigned.

For example, A company has a team lift policy that says anything over 50 pounds must be moved by two people. But they only have one night shift employee working a job that regularly requires the employee to move heavy objects to complete the night’s tasks. The reason these companies get away with this, is they will lay it on the employee. They would argue the night shift should have to seek out someone else to help them move the objects. In many toxic work environments this just wouldn’t be possible because just like that one employee, everyone else is overworked and understaffed.

A blue collar worker is a problem solver. A blue collar worker knows how to navigate toxic environments, and stressful situations. A customer service employee may not be in direct physical harm, but they deal with any number of people throughout a day that would believe they are servile merely because of the job they hold. Customer service has to keep a quick wit, and a steady emotional pace through even the worst mob of Karens.

(A Karen: A customer that upon being dissatisfied in some way, which may or may not pertain to the place they are shopping at, will pursue a tactic of harassing, degrading and bullying the employee. They believe it is their right to treat employees in a way suitable to some imaginary station in order to elevate themselves and get whatever twisted satisfaction they were seeking)

Blue collar workers are adept and skilled at working through physically and mentally challenging situations. Day after day for little pay, they face the challenges thrown at them for that paycheck that will get them through the next week.

The value of a Sharp knife

Safety procedures don’t just protect the individual, but the whole crew. From the CEO touring the warehouse floors, to the hourly worker there to sweep every morning. The blue collar worker, despite a hazardous environment has to keep themselves vigilant even under the pressures of completing a job on time. In many industrial settings, a mistake can cost a teammate’s life, or your own.

Example [Heavy Machinery]:

Driving heavy machinery isn’t just like driving a car. On a forklift for example, the forks are a very real danger. On uneven terrain, if the forks are not properly lifted and tilted, they can hit obstructions. If they are too high, and someone steps in front of them from behind an obstacle, it could change a minor injury to a fatal one.

When moving heavy cargo, if the tilt and height is incorrect, it could lead to the tipping of the cargo, and the forklift with it. A forklift has many mechanical levers to control these forks, and everything is taken in account as the driver moves through an environment from point A to point B. Environment and load, weight shifts, angles, speed, tilt, all play a role in operating a machine safely.

A heavy machine operator has to be able to adapt to changing conditions quickly, and under any amount of stress. If that load tips, if that person steps into a blind spot, if the ground gives way, if the weather leaves the ground slippery, if the hydraulic line blows, if the load starts tipping. Quick and safe adjustments are made and required on a regular basis. Vigilance and knowing ones’ machine are requirements. They help the driver do a safer, more efficient job.

The 30 foot tall Front-loader requires careful precision, and observing your surroundings at all times. To drive a piece of machinery like the frontloader isn’t just a skill, but a duty to keeping yourself, and others in the workplace safe from harm. The blind spot on these machines is massive, and almost entirely around its base, where the five foot tall wheels could easily drive over a mid size sedan. Being considerate of the people in your workspace isn’t just a concept, it could be a matter of life or death.

Bob from accounting may decide to take a shortcut through the plant, and be unaware that large machinery has the right of way. The driver must always be aware that someone else may unknowingly wander into the path of danger, and be constantly aware of the fellow coworkers, and new changes in their surroundings. While safety protocols are there to protect all employee’s, some aren’t aware of the very real danger they are in if the rules are not followed. Or they may be Bob from accounting who was never trained to understand the yellow pathways are painted on the warehouse floor as a walking path to keep them safely away from heavy equipment traffic.

A cook can tell you the value of a sharp knife, and how dangerous a dull knife can really be. If the knives in the kitchen are always kept sharp, and maintained properly, a respect happens in the kitchen for these objects. The job is done more efficiently, safely and no one waves around a knife for giggles, or out of complacency. The other reason dull knives are more dangerous, is slippage. The more pressure you have to put on a dull knife, the higher the likely-hood the knife, or the chef’s hand can slip, causing a serious cut. As a related metaphor, blue collar folks have to remain sharp at all times. They have to find ways to keep their jobs safe, and their fellow workers safe, even if there are a few dull blades in the batch.

How do they do it?

Despite monotony, lack of incentive, or dissatisfaction with the task, blue collar employees will find ways to make the job they do fulfilling, find a way to take pride in their work, and strive to do their task ‘above and beyond’ what is expected of them. And they do this without a financial incentive.

Some jobs can be thankless, dirty, physically challenging, monotonous, and not provide much satisfaction. While the paycheck is the end goal as an hourly employee, there is so much more to a job than just paying the bills.

In all jobs, in all parts of the workforce, your time is your commodity. If, for example, you spend your days sorting through dirty smelly recycling, you’re also spending 40+ hours a week doing this very thing. Away from the comfort of your home. Away from relaxation, and away from the things you’d rather be doing.

A blue collar employee will find a way to attribute their own reward to any task. They like to take pride in driving that crane safely and skillfully. They want to do that weld with quality and stability. While a simple beed might meet minimal standards, they take the extra effort to form a weld that is less likely to fail under pressure. They’ve put thought and effort into going home proud of what they had done for the day. The paycheck pays the bills, but doing an exceptional job keeps them sane.

How does this all relate to Work Ethic?

If you as an employer are seeking someone with work ethics; look no farther than the employee who spent years in a blue collar job.

Blue Collar workers show up every day, to do a job with dignity and pride, even though there’s no financial reward to. Their environments can be hazardous, high stakes, and they may be under extreme pressure on a daily basis, but blue collar workers adapt and overcome.

Until you’ve worked over a broiler every weekend on a team to successfully complete the ‘dinner rush’, the visceral meaning of the words ‘We were slammed at work!’, may not mean the same thing. A great cook doesn’t just cook excellent food. They take pride in providing it on time, and to all the patrons, which may mean multitasking and working under immense pressure. Not for a bonus, or financial gain, but to go home, probably exhausted, with a clear pride in what they accomplished at work.

The blue collar employee shows up. They do a thankless task, sometimes even physically dangerous or mentally daunting task, and return every day to do it again. The blue collar employee shows up every day, day after day, and gives all they can.

They’re the cashiers that strive to have happy customers, the restaurant cook who wants every meal to be perfect, the forklift driver who has learned to be so skilled at driving and caring for their equipment, they can do impossible tasks with ease.

And it’s not for the paycheck. Did you notice the minimum wage in the descriptions at the beginning? While most places tend to pay 3-7$ over this per hour, most blue collar workers are still struggling with poverty. While the paycheck keeps them alive, housed, fed, there are still 40 hours of the week they have to give to a corporation to attain a bare minimum needed to survive.

Why do they still do a good job? Why do they show up every day? Why do they maintain quality workmanship, and customer satisfaction despite such a low payoff?

Partly because our society has taught the ranks of blue collar that their job can be forfeit at any time. And partly because without a work ethic, being exceptional at their duty, 40 hours is a great sacrifice, instead of time spent building pride in what they’ve earned.

Blue Collar drives the labor pools of industrial, service and healthcare fields (amongst others). These workers are essential to our society. They don’t work for fame, or admiration. They don’t work in these jobs because of financial gain.

I submit for your approval that a blue collar background can give great value as a new hire. Their experience and dedication to blue collar work tells you more about their work ethic, and determination than a college degree might. Blue Collar jobs are valuable, they are great people, and they deserve a chance.

Nellie Tobey

Image credit:
Photo by Elevate on Unsplash: Forklift driver, as seen from inside the empty trailer.

Photo by Johnathan Macedo on Unsplash: Cover image. A chef enjoying the flame.

Nevertheless, Nellie Coded

Nellie — Wed, 04 Mar 2020 04:25:33 +0000

But you'll break it!

I never touched computers much in my younger days, because I was told, literally that I would break it because I was a girl. I still hold a tiny bit of that fear, but it has changed.

I might break it because I didn't catch that error on line 52, and being a woman has nothing to do with it.

Before code:

I quit college after my first year due to the onset of Bipolar. It went through my life like a wrecking ball, almost taking me out of this world. After many years of battling myself, involuntary admittances, medication changes, and therapy, I made a decision. I decided I wanted to be a mom. I also decided I wanted to live. As my son grew so did my confidence that I was worth something in this world. I had lit my own fire instead of waiting for the darkness to end.

My Hello World ()

My first go at programming was around 2009. At the time there were free html files of Zed Shaw's Learn Python the Hard Way, and he even sent messages in a forum to people sometimes! I was the one who made it to near the end of the book having no idea what the $ symbol meant. Yeah, Hi Zed, look at me now!

Giving up for a time

I gave coding up for a few years after getting through the final Flask project of Learn Python the Hard Way, thinking I was destined to work in manual labor and was wasting my time (broken self: meet new self. YOU GOT THIS). After finally getting a job that equipped me to financially support my family with ease, I decided to play with Python again around 2013.

I started with a book about pygame, wrote a few games, and fell in love. This is something I could do, this is something I want to do. I viewed it as a hobby, not undertaking any serious amounts of time to it. Tragedy struck, and changed all my perspectives.

Code has become fuel for my flames.

After losing my fiance who passed of cancer in April of 2017, I moved me and my son to California with my sister and made some decisions. She has always been a huge source of inspiration to me. I wanted to code, I wanted in to the world she's been a part of for so long, and I needed to start me and my son on a new path. I wasn't going to let my worries and self-doubt stop me from trying to make things better any longer. Loss has a way of reminding you how much there is to fight for in life.

I still have days I want to give up, but then I head into my job which barely affords life in this trailer park, and it brings me fuel. Fuel to do something, rather then nothing. Fuel to chase this dream.

With every code that runs as planned, a piece of me is triumphant. With every bit of code that spectacularly fails, I get to learn something exciting and brand new. And I secretly feel powerful, like, did you see how I made that memory error happen!

With every project complete, and idea followed through, there is a burning inside that can not be extinguished. With every new thing I learn, or accomplish my future is getting brighter.

I'm going to keep the fire burning. One day soon hopefully, I'll get paid to do it, but until then, this is fun, this is rewarding, and I'm not giving up on my life any longer.

RAWWWWRR!

Lessons from Blue Collar-Teamwork

Nellie — Tue, 25 Feb 2020 02:46:38 +0000

What is a team?

On wickipedia:
A team is a group of individuals (human or non-human) working together to achieve their goal.

Working as a team, means the individuals all have the same goal, and are striving for accomplishing it. A team that has individuals who are not there for that goal, can make a team flounder and fail. An individual who goes above and beyond, can make the team flourish and succeed. It can get down right complicated.

A bit of Math

John Nash: Prisoner's Dilemma, Game theory, Nash's Equilibrium

In the movie, 'A Beautiful Mind', the story explains one of Nash's great breakthroughs with a scene at a bar. Three women walk in, and the men all wish to approach the blonde. If all the men work solely on their individual desires(getting the blonde), the likely-hood they all fail, (none of them get one of these woman), if far greater. But if they worked as a team, and each approached the non-blondes, they have a much greater potential to succeed.

This would require them to work as a team, and as individuals in the best interest of the team.

How does this apply in blue collar?

EVERYWHERE. Though many may not realize it in this way. If person (A) only works to their self interest, they damage person(B)'s potential to succeed. Much like the saying 'set up for success', and 'set up for failure' teamwork requires each member to have the intentions of seeing everyone succeed, and not just themselves.

How does helping my co-worker help me?

I would bet that everyone would in some way agree that if the whole team is successful, that each individual is also successful - despite any setbacks or failures that result from an individual's actions. In a healthy team, if slack happens, everyone picks up a line, and pulls to relieve that slack.

In the inverse of that, if a person only is interested in their own success, they would not pick up the line, and stay diligent to only their task. Or "it's not my job." There are plenty of situations where this is justified, and plenty where it leads to the failure of a whole team.

Sometimes, in the labor field, it can feel like no matter how much extra effort an individual puts forward, they never seem to get any further advanced, the team never seems to 'succeed'.

(success => reward)
Examples of rewards:
1) financial reward
*career advancement
*raises

2) job well done!
*acknowledgement of success
*congratulations

3) other compensation
*Extra days off
*Being able to go home early
*Pride in the job

4) Being a part of a great team
*Something to take pride in
*Contentment with the workplace
*Having more than a paycheck to go to work for

Management

Counter-argument: 'No good deed goes unpunished'. Person(A) constantly leaves behind messes in the kitchen for the next shift. Person(B) Diligently cleans it up and keeps it clean for the next shift. Person(B) may, or may not ever see a reward for their part in keeping the team successful. But they will be a part of keeping it from failing.

They shouldn't have to.

This is where the management and upper management comes in. This is your role in the teams success. Check with your team. See what can be improved, what can be implemented to create an environment where everyone is working toward that goal. If there are reasons someone is unable, or unwilling, see what can be done to make the goal more attainable, more sustainable, more applicable to that team member.

Some of the greatest leaders, or management I've had in life wanted not only their company to succeed or themselves, they wanted the individuals to succeed, the whole team to succeed.

This happens through safe practices to keep the team healthy, mentally and physically. This happens through communication and a true effort to see the needs of the workers met. This happens through elevating team members who go above and beyond, recognizing success, and implementing rewards for a team's job well done.

How it looks in action:

Person(A) needs a 10mm socket to complete the maintenance task.
Person(B) has the only available 10mm, but it is unused in the toolbox.
Person A asks B to borrow the 10mm to finish the task. Person B agrees, but needs it back immediately.

**Another article for another time: What role Trust plays in a great team.

Person A & B mention to management that more 10mm sockets are required for the team to be able to effectively and efficiently get the jobs done. Managements hears this, values this input, and trusts that the team is in need of this item, and works to get it ordered.

When it goes wrong:

Everyone is doing what is best for the team. What would happen in this line of reasoning if even one person refuses to do what would benefit everyone most?

Person A could just grab the socket and not tell person B, leading to person B delaying their task later in search of the missing socket.

Person B could refuse to let person A borrow it, delaying person B's repairs and causing animosity.

Person A & B could refuse to mention it to management, management could refuse to listen, trust becomes broken, Person A & B do not feel valued to management.
Each of these things would lead to dysfunction and limit the potential for success.

Conclusion

A team can fail, or succeed based on individual action, in-action, or refusal to commit to the 'best possible outcome for all'.

A team can succeed even when there are pitfalls or obstacles by reaching up, reaching out, and pulling a line that may not be theirs to pull. A team can succeed through the harshest and worst of circumstances, and they can succeed even when things look impossible, A team can be wildly successful when all members work for the same goal... If everyone is working for the success of their fellow team members.

We can do this, together.

Lessons from Blue Collar

Nellie — Wed, 12 Feb 2020 03:49:17 +0000

How soft skills can come from customer service experience

Customer Service, even in the form of a being a cashier at the local burger place, is valuable experience in any field. These are soft skills. These are hard earned and equippable skills, in any industry. Yes, Even Technology.

Let me explain some valuable things learned through customer service and it's many sub domains [quality, sanitation, safety].

There's a saying many will know: "The customer is always right."

My approach to this is to go into any one on one with a customer with the assumption that they are right, their feedback is truthful, valuable, and justified. They are human, same as me, and need/want to be heard. I've taken some abuse from customers, but I've also made some great relationships with amazing people. We are all human.

The key thing anyone can learn from this set of skills, is to relate to people who are seeking your input, or your time. Maybe this customer is having a really horrid day, maybe that one thing they couldn't find in isle number 7 was the straw that broke the camel's back. Going in with compassion, and a certain amount of letting them vent and trying to find a way to make their day less horrid is a tradable skill in any market.

Useful and valuable.

And a note to the would be customer, while it's our job to make your day better, easier and more convenient, or solve your dilemma; remember we're just humans too. We work for a company and in almost all cases have nothing to do with the policies in place, or have any power to change them. Don't abuse our position by using us as your emotional punching bags. This too is a skill we learn through customer service. We know what that feels like, and are unwilling or sometimes even incapable of doing it to others.

Useful and valuable.

Another one some may not know: "Clean as you go."

This is one I learned as a cook. Messes can pile up fast when it's dinner rush hour, and if you let it go, there could be an accident waiting to happen through slip and fall, food contamination, or just slow down the whole process from the clutter.

Example:
Instead of setting the dish that was returned and had to be re-plated at the conveniently located cutting board, (Telling yourself you'll get it into the bus bin later), put it in the bus bin now. It's easy to forget it's there, easy to miss-step and forget this was a used plate, and not a clean one from the stack. If it falls, gets knocked over and broken, that broken plate is now a huge time consuming thing because it has to be cleaned up immediately. Your food suffers, your customer suffers, your co-workers suffer because this is a team, and they just lost a key member to cleaning up the ceramic mess on the floor.

It may be an extra 10 seconds to walk it to the bin for the dirty dishes, but the potential hazard it can cause is worth every second to avoid. Clean as you go.

Another thing this teaches you is to avoid making the cleaning tasks at the end of the day become a mountain of debt to be worked off in perhaps a more stressful way. Just like code

Clean as you go, avoid the hazards and mountain of problems that will have to be cleaned up later. Your environment will stay less cluttered, less riddled with pitfalls, and a more sanitary place. These all also help a customer receive the best food they can get and a higher quality product.
Useful and valuable.

Here's one from my days in the recycling plant: "Get the big picture"

This applies to so many situations and circumstances. Just like 'the customer is always right', and 'clean as you go', there is a big picture going on that can be hard to see when you get focused on a singular task.

In the recycling plant, this was more of a safety guideline, but lets apply it to the customer service side.

-the customer is always right-

What is the issue? Is it fixable? If it can not be remedied, is it something that should be addressed by someone other than yourself? Is it a systematic problem that brought this customer to you? Is it something that should be, or can be easily fixed so that other customers do not encounter the same thing?

Maybe the issue is something good, maybe the customer wants to compliment a certain technique or product that they received. Recognize this, thank them, bring it to your team's attention so that they too see rewards of their effort.

-clean as you go-
As a cook: When that plate was brought back, what was the error with it that brought it back? Is the plate damaged? Is the plate cold, or hot? Was the food cooked in some way that displeased the customer, and could it be done better for every dish from this point forward?

As a baker: If a carton of rainbow sprinkles spilled on the floor, why was it spilled? Was it setting somewhere someone could trip, or it get knocked over? What kinds of hazard do those colorful bits of sugar present? What could be done to keep this from happening a second time?

Getting the big picture means asking questions, looking not only at one solution, but looking for the best solution. Making sure what you are doing for any given task encompasses the whole task, and how it impacts the things or people around you.

Useful and valuable.

In conclusion-

It takes a lot of analytical skill, human relation, and problem solving efforts to be in customer relations in all forms. To be of service to other people is a huge task to be taken on in meaningful and deliberate ways. I submit for your approval that customer service experience is highly related to 'soft skills', and are useful and valuable when applied to anything, even code.

How Lock out Tag out relates to commenting your code.

Nellie — Thu, 06 Feb 2020 06:43:07 +0000

I learned my first lesson of why a 'Lock out Tag Out' procedure is so very important at my recycling job assisting maintenance with our Balemaster 2000.

This machine baled cardboard, metal, almost anything. A giant metal head sitting at the bottom of a 40ft tall shoot would press forward with the power of a hydraulic line bigger than an adult human leg. It used 40,000 Watts to power motors, fans and a giant conveyor belt that could hold and move tons of weight at a steady pace.

This is not a complicated machine, but deadly under terrible circumstances, as I learned that day.

We were getting ready to change a fuse, one of the two that were linked to the 40,000 watts. The maintenance man was in a hurry, because the baler being down meant profits were being lost by the minute. As I stood next to him, he reached in to grab the first fuse ... The machines power button was in off position, but the power supply was not.

He luckily just received a jolt, and me a big static charge. But it was that day he taught me all about locking out power supplies, and why it's important, because he had forgotten and it could have been deadly for both of us.

We proceeded to pull down the breaker on the main power box, and on the machine and lock them out with padlocks. The keys to these locks he kept in his pocket. No one could remove the locks without that key, or bolt cutters. The power supply was confidently off. We could finish replacing the fuses now. Although I think we both flinched regardless when he reached for the fuses this time.

A lock signifies something is off limits. It's pretty universal, so we could be confident that anyone seeing the lock on the breaker box, or on the machine, would not simply 'take it off' without some kind of confirmation it was ok to do so. The tag on the lock stated what was going on, 'repair of baler in progress'. People were working on that machine. A tag dangled from each of the locks, big red bold letters, a warning label with written description of what was going on. This was not just locked for no reason.

At the paper mill this process was massive when the paper machine had to be shut down for repairs. Our locks even had our names on them. Every person working on that machine had a padlock on the master box, which had all keys to all systems locked inside it. Until everyone had confirmed their duties were complete and they were no longer in the path of the machine or it's systems, the machine could NOT be turned on.

Clear and precise communication that can not be misunderstood is important, it's not always easy, and is useful to all who encounter it.

Commenting your code:

It may not be life threatening, it may not seem like a big deal that someone knows and understands the intentions of a piece of code. There are some that will say 'well written code requires no explanation'. It's the same with lock out tag out procedures, except we deliberately put the items, tags, paperwork in place so that there is a miniscule possibility a machine's power is turned back on before it is safe to do so.

Even if your code could be read and written by the newest of coders, the intent, the purpose and the use of a piece of code should be absolutely clear. Maybe it is as simple as:

"An add function that sums two variables x and y."

But wait... are those variables integers? are they strings? are they floats?

revised: "An add function that sums up two integers x and y."

But wait... where are x and y coming from?

revised: "The add(x, y) function whose purpose is to add integer parameters x and y."

But wait...

revised: "The add(x, y) function whose purpose is to add integer parameters x and y returns a whole number, rounded up with python import math and round() methods."

Now that's a bit closer to being a LOTO(lock out tag out).

I'll admit, I may not go that in depth with a comment, but there is absolutely no harm done by doing so, and only serves to safe guard anyone who uses your code in the future.

Now lets take a bigger example. At one time I was trying out a python module called timeit(). I was running a python random function to produce a huge self coded list of double linked list nodes.

The times on my timeit were huge, slowing and almost crashing my computer. It was running hot and hard trying to do this process that I thought should be small and easy. I was calling timeit on my double linked list, just too see how fast it could run from start node, to end node.

What I didn't find in the documentation at the time was that timeit had a default, if you didn't specify how many times for it to run the test, it tried to run the test 1 million times. Me being a newbie, assumed it only ran one test when you used it, unless you told it to run more. I was building a 800 node doubly linked list 1 million times. I found out later, through some googling and digging about the default.

Again, not life threatening, it didn't kill my computer but it sure did cause me some grief and aggravation trying to find out what was happening. Not a comment per say, but definitely an item that should have been clearly and specifically stated in the documentation.

Lets make a bigger example.
I don't know how feasible it is that things like this happen, but I know mistakes happen in every industry, everywhere.

A piece of code is in a required system that runs the hospitals emergency generators. The power fails. Someone is called in to look at this code, and it is written so that only the person who originally designed the system understands what part of the systems it controls, and what part of the power supply it's connected to. There are no comments. Time matters, it matters how fast and how easily someone can fix and repair this situation. Maybe the tech squad sent in is completely brilliant and reads the code without issue. Maybe they can't. Maybe this old code was supposed to be removed a long time ago, but somehow it never made it on the list for an update.

Put your lock out tag out on your code. It may just be a matter of saving someone a little grief, it may save someone's precious time. It may keep a system accessible and fixable for years.

It may never matter, but why take the chance? Why not add a little safety to your code, leave it behind for others to easily engage with and understand. Practicing this step will keep you from leaving it out when it may really matter.

-Why not?