Tag Archives: past

Page 81

Posted on by
Reply

One of the things that has always fascinated me is human memory; how we create them, what sticks, what doesn’t and how it evolves.

Many people think that human memories are rather static. The truth is that’s far from the truth.  As we saw in the 1990s is easy to form false memories and easy to conflate them.

One detail that is interesting is that human memories are a bit like DRAM in a computer.  In essence when we recall a memory, we have to basically read out the memory space and write it back.  One of the side effects is this can actually help strengthen memories.  However, it also means when it’s written back, other memories can be conflated with it and a new, slightly different memory is formed.

There’s two main ways of remember something that stand out to me as I write this.  Repetition and what I’ll call “sudden shock”.

Many things we need to repeat until we remember them.  An example is a child learning their times tables. There’s really not much context and really only rote repetition will cause these to sink in.

At the other end of the spectrum are the memories that are etched in our minds. “Where were you when Challenger blew up?”  “How did you first hear about 9/11?”  If you ask someone of the right age, they’ll know exactly when/where they were and probably recall vivid details.

If you ask them where they were on the 3rd shuttle mission, they’d probably have no clue.  The same is true if you ask them what they were doing on 9/9.

In between are more general memories. Memories of childhood that don’t necessarily have a specific timestamp or even importance.  I recall playing in some woods behind my house growing up, but there was nothing really significant about the time or place. I have no idea why I have that memory.

I mentioned above that memories can be modified or manipulated. There’s some work on treating PTSD this way; helping patients recall specific events under controlled circumstances and essentially rewriting the memory into something that doesn’t cause an attack. (Propanolol is one drug being experimented with to do this.)

Strangely there’s one memory of mine that persists that while not a real issue is sort of pointless and annoying to me.  It’s “Page 81”.

What’s that you ask? Many years ago (let’s just say before I was a teenager I think) I was staying at my cousin’s grandmother’s house.  On the bookshelf they had a copy of Jaws 2. I started reading it but had to leave before I could finish it. Since I knew I’d be back the next summer I decided to remember what page I was on. I repeated the page number to myself over and over again. And to this day, I can remember, I was on page 81 of Jaws 2 when I stopped reading.  Of course decades later I have no idea what happened in pages 1-80 so the memory doesn’t do me much good. But there it is. It’s still there. Page 81.

As a note, most of this post was based on memory (I had to look up the name of the drug) so some details may be wrong.

Page 81.

 

 

Survivor Bias

Posted on by
Reply

I’ve been so busy lately I haven’t had a chance to write anything.

Of course part of the problem isn’t having ideas to write about, but time to write about them.

I think perhaps I should focus more on writing SOMETHING, even if it’s just a short post, than trying to write the Great American Blog post.

In this case I’m going to actually post a link to a great article on survivorship bias.  This is the sort of article I wish I had written myself.  As I’ve mentioned part of my point here is to get one to think about HOW we think.

The story of the bomber survivors was first related to be by a good friend in college, but without a source. Now at least I have a source for it.

In a similar vein, and the article touches upon it, people will talk about how great the older homes in weather prone areas were built because they’re standing decades after they’re built despite hurricanes or floods or blizzards. These folks completely miss the other 90% of homes from those eras that didn’t survive.

Years ago, my father bought and rehabilitated what we believe to have been the oldest house in town (in fact technically it was older than the town and probably where the town charter was signed.)

There really wasn’t anything about the construction that stood out that made it survive. Just luck at this point.  A single fire at any point in time could have made the second oldest house in town the oldest.

In closing, this article doesn’t represent most of my thoughts over the past 6 months only the ones that survived to the publishing stage.

Employee Loyalty

Posted on by
Reply

I’m in the midst of trying to put together an idea for a new company.  This is something I’ve wanted to do for years.  The hardest part of course is coming up with the right idea.  I think I’ve got that.

But as equally important to me is building a company that I would be proud of and that will attract good employees and retain them.

Years ago, I was consulting at a local software company, performing their IT functions.  They were a large customer of mine so I spent a lot of time there, enough that I was almost like an employee.  Only I wasn’t treated as badly.

I recall one day sitting in a company meeting where the CEO and the CFO patiently explained to the employees why their expense checks would be paid as late as possible.  You see, it was better for the company’s balance sheet.  But don’t worry, the employees would get their money, eventually.  They then basically gave a morale speech that boiled down to, “We’re not sure why everyone is complaining, you should feel lucky to have a job!”

As a contractor I had a much easier way of making sure I got my money when it was due me.  I could simply stop working.  A quick call to the CFO would get me paid.

This late payment of employee expenses combined with other issues basically killed morale at the company.

At the same time, my wife was recruiting for another software company across town and one of my other customers was across the river.  Both were recruiting.  It was amazing how many people jumped ship from the first company to either of these two companies.

One day I was at the company across the river doing some consulting.  They had recently recruited a developer from the first company.  Earlier that day he had submitted an expense check.  Now, like any reasonable person, he would have been content waiting until the next payday or some other reasonable amount of time for his expense check.

Well later that day, I saw him walk out of the finance person’s office with his expense check in hand.

A single act bought his loyalty more than any pay raise or speech about morale could have.

I want to make sure my company (assuming it takes off) can treat its employees with the respect they deserve.

A Bright Idea and State of the Art

Posted on by
Reply

I think everyone likes to talk about “their first program”.  I suspect though it’ll become a less common topic with future generations, just like most kids don’t recall the first book they ever read.

My first program calculated things in Celsius if you provided the Fahrenheit temperature.

I was probably 11 when I helped write it.  It was stored on paper tape and ran on the local high school’s minicomputer (probably a PDP-9 but I honestly have no idea).

It wasn’t a long program, it was probably in FORTRAN.  Again, that is so long ago, I can’t recall the details.  And it wasn’t a very impressive program.  Heck, these days you can do it in a Windows CMD script as one line. (well two for clarity, SET F=212, SET /A (%F%-32)/9*5)

I wrote more complex programs in High School (by then had moved up to Turbo Pascal) and made my first money programming in FORTRAN while in college.

Things had improved from paper tape to floppy drives to hard drives.  Writing programs and debugging programs for the most part became faster. But generally anything more complex than basic input and output through the screen and keyboard was still tough to do and time-consuming.

About two weeks ago I had an idea for project.  I was on the road at the time and didn’t get a chance to sit down at my desktop until last week.  In less than 24 hours I had prototyped the idea and tested it.  The program involved a website, a database, doing some lookups, writing to the database and a bit more.  Even just 10-15 years ago it could have easily taken me 4 or 5 times as long to do something like that.

On Thanksgiving Day, my son wrote a program in a language called Scratch http://scratch.mit.edu/ that would take input, make it circle around then settle on the screen.  The more times you entered text the bigger the resulting “wordle” spiral would grow.  He wrote it that morning before our relatives showed up.  It took him maybe an hour or two, including debugging and overcoming some initial limitations.

He’s been writing programs in Scratch (and other languages) for years now.  I doubt he remembers his first program since writing programs now has become about as easy as using a computer.  I’m sure he doesn’t remember his first time using a computer like I do.  He writes programs at age 11 that in many ways are more complex than anything I wrote in my teens.

The state of the art has certainly changed and it’s made the world a better place all-around.  Languages and frameworks make developing faster and easier than ever before.

Though at times I’ll admit I miss the days of FORTRAN.

Order of the day

Posted on by
2

I’m in the middle of designing a db schema for a project I’m working on.

As I was sitting in my car, waiting for the light to change, I remembered a mantra of SQL design.  And what is funny is I often see this fundamental aspect overlooked or even in at least one case, intentionally ignored: namely tables do not have any intrinsic order.

Almost all of my experience has been using MSFT SQL Server, so my thoughts will be based on that, but the general idea is true.  Beginners to SQL will assume “if I put the data in in order, it will come out in order.” Now if they’re a bit more than a beginner, they’ll even test that.  And lo and behold, they’ll probably find their assumption is right when they test it.  Then they’ll put the code and schema into production and find that suddenly things aren’t working right.

They’ll wonder why it worked on their machine, but not on production.  Generally there’s two reasons.  SQL Server is very aggressive about caching, so there’s a chance it’ll read the data out of memory in the order they put it in.  In addition, if it does have to read it off a disk, it’ll most likely do it in a single-threaded manner, following the primary key and the data will come out as expected.

On production though, between the time the data is inserted and later read back, the cache may look very different.  But even more so, a production machine is liable to have multiple disks and multiple CPUs which means multiple read threads will occur and SQL Server will then put the data together in the faster way possible.  Suddenly it’s no longer in the order the programmer wanted it or expected it.

Now, if you’re writing a quick ad-hoc query to get some data out quickly, that’s probably ok.  I’ll admit I do a lot of queries without an order by when I just need to quickly get some data.  But if it becomes time to productize the code, I’ll use an order by.

As I mentioned at the top of this post, the lack of an Order By seems to be a fairly common mistake made by folks new to SQL programming.

But what about the case when it’s intentional?  Years ago we were rolling out some new code and in the code there was a query that did a query against a table.  In theory the table would only ever have one row.  The programmer decided with one row no order by was necessary.  However, as always theory and practice don’t always match and I asked what would happen if there was more than one row?  His answer was to use a “TOP (1)” in the query.  So I asked him what would guarantee he’d get the top row he wanted.  He said he didn’t think the problem would ever arise and resisted using the ORDER BY “for performance” reasons he said.

Well since I wasn’t his manager, I wasn’t about to fight this particular fight.  But I did make a note of it.

Sure enough, about two years later (a year after he had left the company) the page that used this query started to return the wrong results.  A quick look and a quick addition of an ORDER BY and all was well.

It’s always the little things.  And that’s the order of the day.

Simplicity

Posted on by
Reply

Over the years I’ve been involved in a number of web-based companies.  All had great ideas for their business model.   One had one of them had a great idea for classified ads.  It had the latest in taxonomic matching and advanced search capabilities.  If you were looking for a Mustang, it could tell direct you to ads for cars or horses depending on context and other factors.  Its search capabilities were ahead of the time.  It had pretty much every bell and whistle the newspapers asked for and that the design folks could think of.

Then Craigslist came alone.  Craigslist was free (at least compared to newspaper classified ad sites where the newspapers typically charged.)  It had no taxonomic matching.  Its search capabilities were and still are bare-bones.  In fact, it very much relies on the user to narrow down and define searches.

But it succeeded where the other product failed for what I believe one very simple reason.  It was simply blazingly fast.  It didn’t matter if it returned bad results the first time.  It was so fast the user didn’t mind typing in new search parameters and narrowing down their search.  It was faster than any of the “advanced” newspaper classified engines I saw.  Sure, they might try to do a better job of returning results, but the honest truth was, in most cases people would end up doing multiple searches anyway trying to narrow down their search.  And in the time it took to do 2-3 searches with a typical website, Craigslist allowed the user to do 10-15 searches.  Time was money and people wanted to do things quickly.

Over the years with numerous sites I’ve seen the design get in the way of the end-user.  The truth is, 80% of the time, people will use 20% of the features, but they want those 20% to be as fast as possible.

So, keep it simple and keep it very fast.

One of these days though I’ll relate the story of the 3,000 mile Steinway search.