People and Their Environment

People are influenced by their environment more than most people probably think.

Or at least, they're affected by their environment more than I thought they were.

I'm talking about the little, but significant, ways the environment affects people's behavior. I noticed this after my recent move to the middle of Queens. I started to notice some patterns in how people transport goods.

I grew up in a rural area. Most of my life, including time spent in college, was spent in a rural PA town. When we wanted supplies, we drove to a supermarket or to a Sam's Club; we loaded the car, drove home, and I'd make five or six trips between the house and trunk unloading supplies. Most of our transportation was car based; we were limited by the storage capacity of the car.

Then I moved to Manhattan for my job. In Manhattan it wasn't uncommon to see people pulling little carts behind them. The carts had two wheels and a stand-foot; the basket was basically a canvas-like bag, roughly three feet high with a clasp flap to keep items from flying out. IKEA calls them knallas.

These things are about as common in Manhattan as rolling suitcases. I never saw them while shopping back home; but they are very suited to life in Manhattan. Unless you have a lot of income, the average apartment is quite small and cramped, and the more affordable apartments are often walkups. The knalla rolling cart was big enough to carry a few bags-worth of groceries while being small enough to maneuver up steps and around sidewalks. They were common enough that you need not feel strange walking around pulling one of these rolly-carts.

Then I moved to Queens. I grew up in a rural town, where your neighbors were fields or trees. Manhattan was skyscrapers and pavement; everywhere you looked was a monument to mankind's craftwork. It was the polar opposite of my home.

Queens is another facet of NYC, one that you don't see in movies and television shows. It doesn't have the skyscrapers, but it is anything but rural. It's more along the lines of suburban sprawl; chain restaurants and malls interspersed among residential apartments and homes. While Manhattan was filled with skyscrapers, most of the area I moved to seems to have leveled out around five or six stories.

I noticed that the people here also pushed carts around; these carts are larger, though. Instead of canvas or plastic strapped to an inexpensive hand-cart frame, these are four-wheeled metal-mesh carts with probably twice the capacity of my little IKEA cart. I see these mesh carts around all the time filled with groceries and supplies; in some cases young children are sitting in them being pushed along by a tired parent; I never see the knalla-type carts.

It's a subtle change, but pervasive. It's like rolling into town and noticing that everyone is driving the same over-sized customized truck, or that every kid managed to afford a spoiler for their car in the high school parking lot. A group hivemind, if you will.

The strange thing is that this area of Queens is so diverse yet shares this little quirk.

But when you think about it, there could be a reason it makes sense. Back home your supply runs...groceries, or trips to bulk suppliers like Sam's Club...were limited by the car or truck you drove. In Manhattan, people tended to get more things delivered and actual shopping excursions were to places that were cramped to begin with; many grocery stores resembled what back home were convenience stores in size, or small bodegas. This area of Queens, however, you get access to full size Barnes and Noble bookstores, Kohls department stores, Staples, even a Costco. Back home is still very much a car culture and the shopping conveniences are geared for it. Queens and Manhattan have enough public transit that not owning a car is not so much a hindrance, but the larger stores (and sidewalk space) seems to be open enough...and the stores geared for...the larger capacity mesh 4-wheeled carts.

It's another little observation I've made about people and their environment since moving to the city. It's fascinating to me to experience things that I may have been told about before coming here but written off as rubbish speculation. Speculation until you come here and actually see what effects the city has on people. In the past I've summed the phenomena up as, "We used to laugh when people moved the country from a city and not know how to swim. What do you mean you can't swim? Then I came to the city, where the only pools you have access to are in places like Central Park or a school or a Y, and in many cases cost money to get access to. Kids can easily get the necessities within a few blocks of their apartment, and never actually move outside the city or even need to learn how to drive yet still function in society. And may the universe have mercy on you if your family isn't wealthy and you live in the city. That alone will cut your exposure to opportunities. Now it's not so surprising to have someone from the city move to the country and see them look around like it's a different planet. In many ways, it is."

Now I'm seeing the effects of pockets of culture within different areas. Shared community behavior, in novel things like common tools for helping you get groceries to your apartment. It's interesting to see how various areas share a common behavior and it's probably not even a conscious choice.

But what does that mean for other possibly linked behaviors by residents in certain areas? Are blighted communities breeding a particular mindset by residents? Do we have areas where stupid is not just common, but pervasive, where schooling is prevented not because the school system is inherently bad but the community mistrusts academic behavior? Do we have areas where there are so many people effected by a poor economy that poverty or lower-middle-class economic status is somehow encouraged among residents?

Maybe it's something to consider despite the idea that we are in charge of our own future and economic standing. Maybe we have our community influencing us more than we think sometimes. Take a look at your neighborhood and see how much you fit in. You may find that it's more of a mirror than you originally thought.

Critical of Approaches

It shouldn't be a surprise to anyone that I was working on my GoLang project when I found something that, although relatively simple, I still Googled for the exact syntax to use. I wanted to trim out leading spaces from a string.

Seeing as this was a programming related question I was in no way surprised when the link I was given led back to StackOverflow. The question was asked almost precisely as I had worded it, too. Nice!

However, the question had downvotes, and the first comment was somewhat snarky; "Seriously... you didn't google that, did you ?"

I'm assuming this is a reference to a question of whether the user had checked the GoLang documentation, since the Go language has quite a bit of (rather terse but straightforward) documentation on the standard and common library functions in the language. The poster said that he did, but didn't understand what the cutset was as referenced in the trim function.

The problem as laid out in the question was that the asker had a question while working on something and laid it out as he had searched for it (which apparently was really good for Google indexing, since I found it near the top of search results.) They had found the reference documentation and didn't understand something as it was worded there. Rather than ask about that step in the troubleshooting process, they backed up a step to the original question, and asked it. And was mocked for it.

It reminded me of a damned if you do, damned if you don't situation I've occasionally run into. Recently I've been paying conscious attention to asking questions framed as an end goal, and not framed as a step I'm on in troubleshooting or finding a solution.

For example, asking about changing a particular block of code in a phone server would yield a response of, "What are you trying to do?," and sometimes that would lead to a, "What you might actually want to do is XYZ." The person had  better way of achieving the results I'm looking for, or know of gotchas in what I was trying to change.

Framing the question in terms of a step along the path to what I think is the way to achieve a goal means I might be going down a rabbit hole. Working with someone more knowledgable means I might find a solution that benefits from their experience.

The problem is that learning the how of something takes more time. In many job situations, this isn't appreciated; you need to solve a problem and move on. You're kind of penalized if there's a perception that you're using company time to do something like "learning." I've had conversations on this vein with someone in the Geeking After Dark podcast, where I described a mentoring or learning program sponsored by an employer would be beneficial for an employees professional growth, but he argued that if it's not a benefit to the employer and took up work time it's not something worth doing. Learning has to take place on your own time, and it's commonly expected that employees improve themselves, even in a professional capacity, on their own.

So when do you seek learning how to fish versus the expectation of asking for fish? You're asking a question because you need to solve a problem, and you're penalized for trying to learn the how while the giver of the fish...in this case StackOverflow...has community members that penalize you for not asking how to fish.

Maybe there's not a straightforward solution to this, unless there are more people willing to give an answer while expounding on the solution so the asker has an opportunity to learn. All the poster really needed in this example was a restatement of the documentation in a more learning-friendly manner. Perhaps the asker isn't asking a how-friendly question. But that doesn't mean someone can't answer it as such.

New Programmer Insecurity: Multiple Ways to Implement

I've been working on my GoLang side project for awhile now, and since I didn't sit down and write a specific set of specifications I ended up making a few changes in implementation along the way.

When I get a chance to work on the program, I'll make a few changes, add a small function, test it, and set it aside until my next chance to work on it. Recently I realized I wanted to make a few changes in how the functions...function. But when the application is run, there's no appearance that anything has changed.

That got me thinking about another aspect of beginners programming; another reason I feel fear creep in at the prospect of an experienced programmer looking at what I've done only to scoff at the work I've done. I have been working with the idea that, "As long as it works, I must be doing something kind of right."

Let's take a simple example. The simple, cliche test for a programmer new to a programming language is to have it spit out "Hello, world!" For most languages this isn't all that hard.

I create a hello_world.go file and populate it with the following:

package main

import "fmt"

func main() {

fmt.Println("Hello, world!")

}

Using "go run hello_world.go" yields simple results.

Let's make a simple change. Here's the new code:
package main

import "fmt"

func main() {

var hello string = "Hello, world!"

fmt.Printf("%s\n", hello)

}

A quick retest does this:

Look familiar?

Let's make another minor change.

package main

import "fmt"

func main() {

var hello string = "Hello, world!"

fmt.Println(hello)


}

Run again:

Hmm...still look familiar?

Here's something only slightly more advanced in technique...

package main

import "fmt"

func sayHello() {

var hello string = "Hello, world!"

fmt.Println(hello)

}

func main() {

sayHello()


}

What does it do?

Let's bump it up one more step.

package main

import "fmt"

func sayHello() (string) {

var hello string = "Hello, world!"

return hello

}

func main() {

greeting := sayHello()

fmt.Println(greeting)


}

I bet you can guess what the output looks like.

See a pattern?

The point is that this same output came from several similar, but different, implementations of code. Which of these implementations is "better"? Is there a better way, if the output is the same each time? What if there's another method that "should" be used but I don't know about?

Those are the thoughts that makes sharing source code, for beginning programmers, more of an exercise in anxiety. 

"Look! This is pretty awesome, yeah?"

"Sure. But...why did you do this? You should probably have done this instead."

Is there a sound pride makes as it deflates?

Worse, I'm not sure there is a way to definitely find answers to what the "best" way to do something is. Some languages, like Ruby, encourage a "Ruby Way" of thinking about program design. Other time, as you gain experience while trying to make an application, you gradually learn about ways to implement a function in a way that makes more sense doing it in a particular way than another. Only experience will demonstrate this, and thinking about the design of your application will lead to epiphanies of implementation.

Regardless, there is no simple "This is how you do it" solution, only fumbling through, trying to understand what you're doing and spending time reflecting on how it works so maybe you'll realize a better way to do it. Or you'll paint yourself into a corner, stuck until you find you must refactor how you did something so you can fix the point you're stuck in and move ahead again.

As for my project, I continue to move ahead on it, despite fears of how crappy the code is once it reaches a release-level in my head. There are several more functions to get working before I reach that point. Once there, I'll be proud of it, regardless of how well it works compared to a company application or how crappy the code is, as long as it mostly works as I envisioned. 

Because really...what else can I do?