You have nice things. Why are you unhappy?

 

The Boat Paradox: Why are you so unhappy?

Imagine two people down at the marina. The first beams, "I finally got a boat! Now I can get out on the water and fish whenever I want." The second person also has a new boat, but their satisfaction seems tied to something else: "It's not the biggest one here, but it's definitely nicer than Johnson's boat next door."

One seeks a tool for an experience; the other seeks status through comparison. This simple difference highlights a profound truth about our desires and our happiness, tied closely to a psychological concept called hedonic adaptation. Why does the first boat owner seem set up for more lasting satisfaction, while the second might be setting foot on a treadmill of wanting more?

Understanding the difference between desires grounded in absolute needs versus relative social comparison is key to navigating this treadmill and finding more durable joy in our lives.

Meet the Hedonic Treadmill

Hedonic adaptation, often called the "hedonic treadmill," is our remarkable (and sometimes frustrating) tendency to return to a baseline level of happiness, even after major positive or negative life events. That thrilling promotion? The excitement fades. The brand new car? Eventually, it's just transportation. We adapt to the new reality, and our happiness level tends to reset. This is why chasing happiness purely through acquiring more or better things can feel like running in place.

Absolute Position: The Enduring Power of "Does It Work?"

An absolute need or desire is grounded in function, utility, or enabling an activity for its own sake. The value comes from the thing itself and what it does.

Think back to our first boat owner. They need a vessel that floats, carries gear, and gets them to the fish. As long as the boat reliably fulfills this function, it provides satisfaction. Its value isn't primarily dependent on what Mr. Johnson owns.

Consider these other examples of absolute value:

• A Reliable Thermostat: It keeps your home comfortable day after day. Its value is in the consistent comfort it provides, not in being fancier than your neighbor's.
• A Warm Coat: In the dead of winter, its value is immense – measured in warmth and protection from the elements.
• A Simple Fishing Pole: Allows you to engage in the activity of fishing.
• Hobbies & Skills: Think about learning a skill like baking sourdough bread. The joy comes from the process, the learning curve, the smell filling your kitchen, and the tangible (and delicious!) result. The necessary tools – a Dutch oven, a lame, some starter – have absolute value because they enable this satisfying activity.

A key feature of absolute goods and activities is their potential for high "utility hours per dollar." A $150 warm coat worn daily through winter provides hundreds of hours of comfort. A $50 fishing pole can provide countless hours of relaxation or engagement over years. The sourdough starter, costing next to nothing, yields endless loaves. The satisfaction is often renewed each time the need is met or the activity is engaged in. This focus on function provides a buffer against the hedonic treadmill because the need itself doesn't necessarily change.

Relative Position: The Never-Ending Comparison Trap

A relative need or desire, however, derives its value primarily from social comparison, status, and being "better than" or "above average" compared to a reference group.

This is our second boat owner, whose happiness is explicitly tied to their boat's standing relative to Mr. Johnson's. If Johnson upgrades next year, that satisfaction is likely to evaporate, replaced by a renewed desire to catch up or surpass him.

Other examples include:

• Luxury Brands: Often, the high price tag is less about superior function and more about signaling wealth or status.
• The Latest Smartphone: Wanting the newest model because it's the newest, even if the current one works perfectly fine.
• Keeping Up with the Joneses: Feeling pressure to have a car, house, or vacation comparable to friends or family, regardless of genuine personal need or desire.

Focusing on relative position puts you squarely on the hedonic treadmill:

1. The Goalposts Move: Your neighbor gets a new boat, fashion changes, a newer gadget comes out. The standard for "good enough" is constantly shifting externally.
2. Adaptation Happens Fast: The thrill of having the "better" thing wears off as it becomes your new normal.
3. It Breeds Negative Emotions: Constant comparison can lead to envy, anxiety, insecurity, and dissatisfaction – the opposite of the happiness we seek.

The Real Cost of Chasing Status

The pursuit of relative status isn't just emotionally taxing; it's often expensive. Luxury goods and status symbols usually carry premium price tags. Their "utility hours per dollar" can be very low if the primary value is fleeting status rather than lasting function or enjoyment. We divert resources – time, money, energy – towards maintaining position rather than investing in things or experiences that offer more enduring, absolute value.

Finding Balance: Lean Towards the Absolute

It's human to notice where we stand relative to others, but we can consciously shift our focus.

• Question Your "Why": Before a purchase or pursuit, ask: Am I seeking this for its function, the experience it enables, or primarily to impress or keep up with others? Does this "nicer" version fundamentally improve the core function I need (like better fishing), or just look better at the dock?
• Practice Gratitude for Utility: Take a moment to appreciate the things that reliably work – the comfortable bed, the efficient appliance, the tools that help you create.
• Value Experiences and Skills: Learning, creating (like that sourdough!), and experiencing the world often provide deeper, more lasting memories and satisfaction less prone to direct comparison.
• Define "Enough" Internally: Set your own standards based on genuine need and function, not just external benchmarks.
• Parenting for Perspective: We can gently guide our kids too. Encourage them to think about why they want a toy – "What will you do with it?" versus "Is it just like the one Sarah has?" Help them appreciate the toys and clothes that work well, not just the newest or trendiest. Model valuing experiences and skills over accumulating status symbols. Focus on the function and the joy of play itself.

Conclusion: Choose Your Boat Wisely

The path to more durable contentment often lies in recognizing the difference between our absolute needs and our relative desires. While we'll always exist in a social context, consciously prioritizing function, utility, and intrinsic enjoyment over status and comparison can help us step off the hedonic treadmill. It allows us to find lasting value in a warm coat, a reliable tool, a fulfilling hobby, or even a simple boat that does exactly what we need it to do: help us fish.

So, ask yourself: What "boats" are you chasing in your life? Are they serving a real, absolute need, or are they just trying to look better than the one next door? Choosing wisely can make all the difference to your long-term happiness.

Spec-Driven Programming by Example

 Example Based Programming

I've been playing with an idea that builds upon the concept of "programming by example," but with a twist: spec-driven programming by example. Imagine a system where you define the desired data transformation through a simple, human-readable specification, rather than writing code directly.

The Core Idea:

Instead of coding, you write a specification in a markdown file. This specification describes:

1. The Function Call: A single function call representing the data transformation you want to perform.
2. Input Tables: A set of input tables, each with a clear description of its columns and data types.
3. Output Tables: The desired output tables, also with descriptions.
4. Example Cases: Multiple examples of input and corresponding output data. The more examples, the better, but even a few well-chosen cases can be incredibly powerful.

Example Markdown Spec (Conceptual):

```Markdown

# Data Transformation: Combine Customer and Order Data

## Function Call:

combine_customer_orders(customers, orders)

## Input Tables:

### customers

| Column | Type | Description |

|---|---|---|

| customer_id | int | Unique identifier for each customer. |
| name | string | Customer's full name. |
| city | string | Customer's city of residence. |

### orders
| Column | Type | Description |
|---|---|---|
| order_id | int | Unique identifier for each order. |
| customer_id | int | ID of the customer who placed the order. |
| order_date | date | Date the order was placed. |
| total_amount | float | Total amount of the order. |

## Output Tables:

### customer_orders
| Column | Type | Description |
|---|---|---|
| customer_name | string | Customer's full name. |
| city | string | Customer's city of residence. |
| order_date | date | Date the order was placed. |
| total_amount | float | Total amount of the order. |

## Example Cases:

### Example 1:
**Input: customers**
| customer_id | name | city |
|---|---|---|
| 1 | Alice Smith | New York |
| 2 | Bob Johnson | London |

**Input: orders**
| order_id | customer_id | order_date | total_amount |
|---|---|---|---|
| 101 | 1 | 2023-10-26 | 100.00 |
| 102 | 2 | 2023-10-27 | 50.00 |

**Output: customer_orders**
| customer_name | city | order_date | total_amount |
|---|---|---|---|
| Alice Smith | New York | 2023-10-26 | 100.00 |
| Bob Johnson | London | 2023-10-27 | 50.00 |

### Example 2:
... (More example cases) ...

The Magic:

The system would then analyze this specification and attempt to infer the logic required to transform the input tables into the output tables. The more examples you provide, the more accurate the inference becomes. In cases where the logic is clear, even a few examples might be sufficient.

A marketplace of coder could bid on projects, or give feedback that some logic is missing, etc.

Once enough test cases pass a webservice API spins up and can take real data. We email you the url and you configure your systems to feed it data, or forward it on to your engineering team, etc.

Why This Matters:

• Accessibility: This approach lowers the barrier to entry for data transformation. Analysts and domain experts, who may not be proficient in programming, can easily define complex transformations.
• Clarity: The specification serves as a clear and concise documentation of the transformation logic.
• Flexibility: The system can potentially handle a wide range of transformations, from simple filtering and aggregation to more complex joins and data cleaning.
• Iterative Development: Adding more examples allows for incremental refinement of the transformation logic.

Challenges and Next Steps:

• Building a robust inference engine that can handle diverse data transformations.
• Designing a user-friendly interface for creating and managing specifications.
• Handling ambiguity and edge cases in the example data.
• Creating a simple demo.

I've built a few prototypes, but I'm still striving for that "dead simple" demo that truly showcases the power of this concept. My current prototypes use python to parse the markdown, and then use some basic data manipulation libraries to try and match the input to the output.

I believe that spec-driven programming by example has the potential to revolutionize how we work with data. By shifting the focus from writing code to defining specifications, we can empower a wider audience to unlock the insights hidden within their data.

What do you think? I'd love to hear your thoughts and suggestions.

Function Oriented Code

Not an anti-OOP screed. Just some thoughts.

Maybe we want Object_s_ plural instead of singular. ObjectsOrientedProgramming

Methods are so good. Why should they limited to just one object?

class Rocket:
    def update(self):
        self.x += self.dx
        self.y += self.dy

Maybe we can say

def rockets_update(rockets: [Rocket]):

    for r in rockets:

        r.x += r.dx

        r.y += r.dy

Is that better?

I think it offers some advantages. We can now operate on a list of rockets, not a single rocket.

Is there a computer science quote about counts are either "none, one, or infinity"?

Why a list? 

Because a list can be empty. That means we have Options.

let rockets: Option<Rocket> = None;

or 

rockets: [Rocket] = []

...

Enums:

We love enums, but not in our params. 

Put enum in your objects instead.

Now our methods don't need to be so defensive.

def rockets_update(rockets):
    # defense!
    if not rockets:
        return
    # ok, safe to do rocket stuff

Can go back to being

def rockets_update(rockets):
    for rocket in rockets:
        # do rocket stuff

Not having rockets isn't a special case.

The Builder Pattern

Why not return our arguments too?

def rockets_update(rockets: [Rocket]) -> [Rocket]:
    for rocket in rockets:
        # do rocket stuff
    return rockets

Taking and returning a list like this makes writing tests so easy you might enjoy it!

given = [rocket(), rocket(), rocket()]
got = rockets_update(given)
want = [rocket1, rocket2, rocket3]
assert got == want

Maybe we can turn entire tests into single elements in the list (say rocket2) to test against.

Do people still read these?

fizz buzz, now with obscurity!

I saw that some 60% of some job applicants cant fizzbuzz.

Let's see my attempt.

#include <cstdio>
void fizzbuzz(){
    int th,fi,i;
    for(th=0,fi=0,i=0;i<16;++i,th=(i%3==0),fi=(i%5==0),!((th&&puts("fizz"))|(fi&&puts("buzz")))&&(printf("%d\n",i)));
}

int main() {
    fizzbuzz();
    return 0;
}

Can you tweak this so that multiples of 15 fizzbuzz instead of fizz\nbuzz?
http://ideone.com/VwmEEt

Follow my GitHub page

Here are the things I work on in my spare time.
https://github.com/shanecandoit

Many of the earlier projects where simply attempts at learning to use git. :)

Mages - a networked multiplayer game

Mages

How

We made this game using python, the pygame and twisted libraries. We collaborated using subversion and many emails. We created UML sequence and class diagrams. We wrote several user stories and used their functionality to organize our code.

The game is playable, the spellbook functionality is incomplete. The arena maps are customizable and read from a text file every game.

The game is turned based and can handle up to four players. Players can move and cast spells provided they stay within the limit of their action points per turn.

Watch

I show the documentation then fire up a server and client and demonstrate the gui and a single round.

Group Database Project - music manager

Database project

how it was made

Me and my teammates built this application using java and apache derby for our database. We collaborated using subversion.

demo and schema/uml

In the demo I add some songs, add them to a playlist, create and add tags, then delete them.

At the end of the video the schema and the uml diagrams are shown.

We implemented all the functionality in our design document and kept our schema and uml diagrams up to date.

We we happy to earn full credit!

Thanks to Andrew and Shun for the hard work and helpful feedback.