Profile cover photo
Profile photo
Michael Curry
Taking the world by Drizzle
Taking the world by Drizzle


Post is pinned.Post has attachment
What's up?

Leroy, visiting.

#chorkie #dogphotos #leroythechorkie 

Post has attachment
Hollywood, analyzed: 

Post has shared content
“We have a Raspberry Pi in space. It was one part engineering, and nine parts paperwork. When the paperwork weighs more than the payload you’re ready for flight.”

Post has attachment

Post has attachment

Post has shared content
One for the toolbox...
#Rescatux is yet another #GNU/Linux distribution that is focused on the rescuing of other operating systems. It works in live mode and offers a rich set of tools to address a wide range of problems in #Linux and even #Windows.

Post has attachment
Bugs make me sick.

Bugs hurt.  Customer-facing* defects cause me physical discomfort.  Been this way pretty much from the beginning.

My first programming job: Construction estimating/job costing/payroll software written in DEC BASIC on RT-11.  In 1981.

We sat in an open warehouse with shared desks sticking out from each wall.  No cubes, no offices.  Noisy.

Customers were about as non-technical as could be.  Electrical and mechanical (piping/plumbing) estimators used our products to automate the process of costing out a job based on giant blueprint sheets.  Or their accounting department used our software to do payroll and accounting.  Our software and hardware made their jobs much easier.  

We tended to customize our software to each customer’s needs (for an extra fee.)  And because of tight memory and disk space constraints, we didn't have the luxury of maintaining a single code base that could be used for all customers.  Pretty much everyone had a slightly tweaked, nonstandard version of the software.

This was barely beyond the stone age of affordable small computer systems.  Before the IBM PC.  Before Mac.  Only a few years after the MITS Altair 8800. Before spacious 5MB hard drives.  Before exception handling and on error goto linenum arrived in our little corner of the world.  Before automated testing was readily available.

Customized source code was stored on 5 1/2” floppy disks.  In a file cabinet, in a folder with each customer’s name on it.  No CVS.  No Subversion.  No Git.  No code reviews. No lint.  No static code analysis.  We used editors like TECO and ED to edit source code.  High-level debugger?  Sorry, pal.  Better luck next time.

9600 baud serial terminals glowing green or amber phosphor.  Noisy dot matrix printers.  Customers didn’t have expensive 300 baud modems connected to their systems.  Nor did we.

Software distribution?  We mailed fresh floppy disks bearing typewritten stick-on labels to customers.   We typed the labels ourselves, on hulking, clattering IBM Selectric typewriters.

Our company didn’t have a QA or customer support department for the first several years I worked there.  

The way it worked was simple.  We tested our own code.  And if a customer called with a question or issue with the software, they were connected directly to the programmer who was most directly responsible for the software.  Which meant: if you worked on that customer’s software package in the recent past, you got the call.  And, generally, this meant you stayed on the phone until they were able to resume their work.

If there was a customer work stoppage (the program was broken from the customer POV, with no viable workaround) we had no choice but to walk the customer through hand-patching the code, over the phone, by telling them how to bring up the BASIC interpreter, load the program code, and make the changes by using the interpreter's line editor -- you directed the customer to type one space one space zero space (not oh) space x space equals sign space one space two space three space period space four space five return.  And some customers might not understand that by "SPACE" and "PERIOD" and "RETURN" you really meant "press the [SPACE] or [PERIOD] or [RETURN] key" on the keyboard.  Tedious.  Painful.  Frustrating.  You name it.

So I learned.

I learned to visualize large passages of code with my eyes closed.  I could imagine what the user was seeing on his or her screen, as we performed this primitive, painful pair-programming remote-control exercise.

I learned if I didn’t want to spend countless hours on the phone this way, I'd better be as sure as sure can be that I've covered every line of code before declaring “it works!”  – this included code delivered by others long before I touched anything.  I learned to go on bug-hunting expeditions, before bugs were reported.

I learned there are no shortcuts.  Double check. Triple check.  Then check again.  On a personal level, you’d be cheating yourself if you don’t.  On a professional level, you'd be cheating your company and its customers.  

I learned the quality of my software deliveries (and those of fellow developers) had a direct and serious impact on the quality of another human being's day – their ability to get their work done – their ability to earn money.  On the company's reputation – and its bottom line.

I learned to choose my words carefully, to craft visual elements and interactions (UI/UX before it was called UI/UX) with as much thought and care as I can muster, because this also has a major impact.

I learned to distrust processes that isolate developers from users.

I learned to dislike business models with captive customer bases, because it makes it easier for one side to ignore the pain.

I learned that being close to your users is the best way to stay honest.

I learned more than I ever thought possible about empathy: I gained a profound appreciation for the damages caused through developer carelessness or defective processes.

That’s why bugs make me sick.

* "Customers" can include internal customers.  Substitute users, clients, consumers, fellow developers or whatever term you prefer.

(graphic from wikimedia -- by GNOME Icon artists)

#empathy     #quality      #testing   #software

I recall seeing a stop-motion animation of stick figures battling and interacting with real-life walls, office furniture/desk, scissors, letter opener, etc.  I think it was using yellow sticky-notes for character backgrounds, moving them across the scene as the animations did their thing..

I thought someone had posted it here on Google+ a few years ago.  I've looked everywhere but haven't been able to find it.  Anyone know where I can find this?

Post has attachment
Don't let the perfect be the enemy of the good
Oh, and while you're at it, don't let now be the enemy of later.

Photo creds
"Challenger explosion" by Kennedy Space Center - Licensed under Public Domain via Commons 

Tyler Durden: The things you own end up owning you.
Michael Curry:  The things you code, end up coding you.
Wait while more posts are being loaded