Programming for Dummies

My programming skills are lacking.

I've been exposed to programming concepts. I've worked on various small projects in the past. I remember using POKE and PEEK on a Commodore 128d in C64 mode to make simple games...yes, I'm that old. But I've not used COBOL.

In that general timeframe I remember using various dialects of BASIC on the TRS-80 and Apple II (let's loop and keep adding one to the variable to see how high it can count and this is AMAZING!) Then there was QBASIC on DOS (let's loop and keep adding one to the variable to see how high it can count and oh my gawd this is SO MUCH FASTER IT'S AMAZEBALLS!)

By the time college rolled around I started using C++, with a little Visual Basic and PERL thrown in. I excelled, of course, in none of these. Once I had the degree in hand I felt I had reached a juncture; systems administration work, or pursue a more programming-focused path.

I'm not sure exactly why I chose the work I do. It might be because at the time I enjoyed working at the small ISP in the area, which had me working on repairing computers and working on administration-type work. From there I slid into systems work for the severely weird world of public education.

Neither of these particularly called for programming expertise, and coming from a rural area, there wasn't much call for technology jobs, let alone a programming career. And before someone says it, this was also before work-from-home was becoming acceptable in tech jobs.

The closest I've come to a need to program as a profession was teaching a few intro courses in Java and Visual Basic at a community college. That in itself is a learning experience. If nothing else it reinforced the idea that unless you've taught others a subject they had little to barely any interest in while you're accountable for their learning outcome, you really need to keep quiet your opinion on what teachers in schools deal with.

"But if you wanted to be a programmer, you would have done it on the side as a hobby!"

I suppose there are programmers for whom the bug is an obsession. Or the DEbug. Haha! I slay me!

But I think as with many things the need or interest in programming runs a spectrum. And I don't know where I am on that spectrum. I'm not a programmer and never claimed to be one...but I loved the feeling that came from suddenly understanding the solution to a problem in the logic of a program, or having the program cleanly compile and not explode with a runtime error. There's something magical about that "click" moment when the comprehension pours over your brain like chocolate syrup over a dome of vanilla ice cream. Yummy, yummy comprehension.

Plus I was creating something out of cold, pure logic. Everything worked by a set of rules hidden behind the interface presented to the user. It was an art. I was a brain damaged Picasso using bytes as a medium.

But when I considered doing something more ambitious I would freeze. True programmers were good. They always seemed to be ten steps ahead of my understanding. That learning curve wasn't a curve, it was a fucking mountain. The idea of trying to actually becoming fluent in a programming language was intimidating.

So I didn't.

Now I work for a web company in their IT department. You may have heard of us; we run a site called StackOverflow. Is this irony or a sign?

The urge to program is bubbling again. Of course the intimidation factor is ramped up even more; we have some extremely talented people working here, and programming tends to be a field dominated by meritocracy. Showing one of our programmers a code sample and asking for feedback would be like taking a bacon sandwich to a master chef and hoping the offense to his palette didn't leave him vomiting. Programmers are not known for gentle tutelage or taking an apprentice under his or her wing.

I think a second factor to my hesitance is a fear of failure. To take on a project or goal and fall flat on my face? Yikes! Whatever meager credibility I've collected over time would suddenly evaporate in a big cloud of stinky fail.

I've spent the past year having to deal with a few personal demons; nagging voices and doubts. I managed to go through my first year at StackExchange without getting fired (always a plus!) I decided to play a little more with that old programming bug.

If nothing else I should at least be reacquainted with that magical, "Holy shit! It compiled!," moment.

Posted with Blogsy

Handy Tool of the Day: How to Use Screen

What is Screen? From the man page:
"Screen  is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells)."

How is this handy? I mean, in Linux, you can already use several virtual consoles using alt-function key combinations. Most desktops today utilize a GUI, so you can open multiple terminal windows.

Here's where I ran into a good use case.

The quick explanation is that I had a large file in a remote location to transfer to my local computer. My local computer can see the remote system (with the large file) only if it connects via VPN. The remote system can see my local system through a forwarded SSH connection on my router.

The VPN connection, for reasons I haven't tracked down, acts flaky with my connection. I can connect to the VPN, but if I SSH into a remote system, the session seems to periodically pause or drop, with little reason why. From what I can tell, though, outgoing non-VPN'd sessions seem to work fine.

I need this file, so I connect to the VPN and use rsync over SSH to copy the file. The problem is that the session will hesitate or blink out, just long enough to cause my rsync to disconnect or go wonky.


A little more clever would be to tell the remote computer to copy to my local computer, since that wouldn't go over the VPN. I try that. SSH into the remote system via the VPN, initiate the rsync. But whatever affects my session over the VPN seem to kill my copy job once my terminal is affected.

This is where Screen comes in.

I connect to the VPN. Then I connect to the remote computer via SSH. Then I run Screen with the "screen" command. It looks just like a regular terminal.

The difference is that the shell is running within "screen."

I then start the rsync to my local computer, which is routed not over the VPN but over the public Internet.

I "disconnect" from screen by hitting control-a (control-a is a command that tells screen you want its attention) then "d" for "detach."

I'm dropped back into the base shell. The rsync is still running in the background.

I can exit from my session and drop back to my local computer. Later, I re-connect to the remote computer via SSH and get a list of running Screen sessions by running

screen -ls

...which will give a list of running detached sessions. I reconnect to the session using:

screen -r <session name>

...and I am reconnected, and can see what is currently happening with my running rsync session. If my SSH session is disconnected while in the middle of the screen session I can still reconnect and reattach as described above.

Now when my connection goes wonky, the copy continues uninterrupted! When I'm done, I can use "exit" to close out the shell, which should also close the Screen session if it's the last process in the session. Failing that, control-a k (for kill) should end that Screen window.

Screen can also create other windows using control-a c.  A new Screen window is created, and I can start another process there. I can switch among them using control-a n (for next) or control-a p (for previous.)

Alternatively, if you have more than a few windows created, you can switch with control-a <number> to jump to other sessions, numbered 0 through X. You can get a list (and select which to use) by hitting control-a " (yes, the quote sign) and from there use up and down arrows to select the session you want.

To summarize:
screen: starts the program
screen -ls: lists detached, running sessions
screen -r <session>: reattaches to a running session

While in Screen:
control-a d: detaches from a running screen window
control-a k: kill a running screen window
control-a c: create a new window
control-a n: go to the next window
control-a p: go to the previous window
control-a <number>: jump to window <number>
control-a ": list available windows and select from menu which to jump to
control-a ?: display help
control-a A: change the name of the session to something more meaningful for the lists

There are other options available as well, like naming your sessions and displaying a history; these are just a summary of the most useful commands to get started. The man page is your friend!

It's Been a Year: Personal Edition

That which does not kill us makes us stronger.

Friedrich Nietzsche 

Strength does not come from winning. Your struggles develop your strengths. When you go through hardships and decide not to surrender, that is strength.
Arnold Schwarzenegger   

Any crash you can walk away from is a good crash!

Launchpad McQuack 

What do you think when you read those quotes? What is the theme?

Are they inspirational mini-memes to get you through a rough patch in life?

Are they meant to keep you marching forward despite doubts?

I see them as a byproduct of our ability as people to rationalize a situation and change our perspective. I've been doing that a lot over the past year. Actually I've been on a quest to do this more for over a year. There are situations you find yourself in that you simply cannot control, and that yearning for control over our lives, that illusion that you have control, causes pain and anxiety.

I've been thinking a lot about that and seeking insight to help form a better relationship with this force of non-control. Our culture usually calls for blaming the individual for their situation; if you hadn't chosen X, you wouldn't be in Y. If you could go back in time and change A, then you would be in situation B instead of C. This is beautifully elegant when you assume outside forces have little to no influence over your actions and that your situation will sometimes nudge you into choosing X instead of a different course of action at the time.

But this isn't about blame. This is about perspective. Understanding why someone would choose X. And when the situation you find yourself in sucks, you can acknowledge that there are bad things about the situation, and the only responsibility you have is to try to minimize the suckage because at the time X was the best choice to make, and perhaps the best risk to take.

Coming to New York was a huge risk for me. On the financial side, I wasn't sure I could make the bills, even with a doubled salary; moving here also doubled my bills, after all, so most of the financial benefit was wiped out by the fact that I was even coming here. I crunched numbers over the course of weeks trying to come up with a best guess of what I could budget. If it weren't for my parents, I wouldn't even have been able to make the move, as the initial cost of rent plus deposits plus fees were staggering for me.

But more than that it was a personal risk. I am isolated. My coworkers, as much as I enjoy them and like listening to them and could potentially learn from them, are coworkers, not family. I'm not even sure to what extent they are friends, really, as only a small percentage of them have even expressed an interest in what I did over the weekend or how my family is doing. It is perhaps safest to call most of them associates or colleagues and leave it at that. And the city reinforces isolation; there are so many people here bustling about that New Yorkers seem to have their own psychological shields to prevent getting too "close" to other people even as they pass within inches of each other on sidewalks and in the subways. 

To paraphrase Samuel Taylor Coleridge, "People people everywhere, yet none will stop to greet." It's almost paradoxical how lonely a person can be while at the same time being surrounded by people. 

My family couldn't come with me. There was a practical reason; my wife was one year out of having her benefits vest, and if she left she'd lose a huge percentage of what would go into retirement; that would only add to the statistics of what is already a dour outlook on American retirement funds. One more year, she's vested, and "safe" for at least some kind of meager return in her golden years. 

My son shares his father's Aspergian tendencies for routine, and is established at his current school. Displacing him would not be easy. Coworkers reminded me that kids are resilient, and they can make the transition if they have to; but this isn't a case where he must move, it would be a move we made in part to simplify our own lives, so his limited stable of friends must be sacrificed in the process if we forced a move. In the end he would adapt, and at best he'd reflect on the change as a crash that he could walk away from.

There was another aspect to the decision; support. I move away, I'm alone. Alone, but suffering for a dream job. They would be back home, missing Daddy but still having a home, the pets (three cantankerous but attached felines, one of whom has a death wish by eating adapter and thin power cables...what the hell?) and extended family consisting of Grandma, Grandpa, and several aunts and uncles. If they move here, we have no one. No Grandma to call when the school says the boy is sick and running out of the office isn't practical, no Grandpa to ask for the loan of a tool for a household repair. The boy especially loves staying with his grandparents as he's not yet at the age where everyone more than two years above his own age isn't "uncool" to be associated with.

We have a house; we bought the house (and are paying on the mortgage) as a way to be property-owning members of society. Foolish as it may seem, for our parents and grandparents having a home meant a kind of investment in the future. We weren't quite ready to give up our home, as it's on a nice property and may provide refuge from the city down the road if or when circumstances change. What happens if we were to move the whole family to the city? Sell it? Rent it out? Hire a management company to take over the property? Put our things in storage, or sell them?

In the end we decided on me taking this job and moving to the city while my wife and son stayed back in the homestead. This was...is...a strain on us. But it gives us options. My son keeps his routine, his familiar surroundings, and his friends. My wife has her friends and my extended family around to help and offer support. She has her investment in her job. And I have a wonderful job where I work with great people and am exposed to a totally different culture and way of life. 

With this comes a price.

It seems every day I ask myself if I made the right choice. My son has asked on more than one occasion why I don't have a job back home, why I can't just stay there? Why do you have to go back to the city?

Ouch.

And I am more than slightly aware of the judgement that I'm a bad father because I'm not there. Not entirely absent, but absent enough that my wife has been effectively reduced to a single mother raising the boy. I still apologize to her for the separation of distance and duties; she reminds me that she was the one who encouraged me to do this. We have options now. And when the boy is older, when he can better understand, the city offers something our home doesn't; opportunities. Opportunities in the city are more of an investment than buying a house, if you look at the ingredients of success and our economy these days.

I try to look at the positive facets. Those quirks that irritate each other in a relationship, the annoyances that at the time drive you batty but when you're apart you almost wish to selectively have those irritations back? We live them.

The communication between you? Most people now take it for granted. Conversations over the dinner table went away with meals over the dinner table. Most people now don't have them. We have meals that compete with scheduling differences and television and bad habits. Even when you're together, in many cases you aren't; people seem to have a bad habit of playing video games or dicking around on their cellphones rather than actually focusing for more than a few moments on other people in the room. While I'm in exile we schedule some time to talk using Skype; I try to make a point of asking how the day is going, or what the boy learned in school. We may actually be ahead of many families today in communication. I'll be the first to admit that we've not perfected it; on more than one occasion we end up texting via skype or iMessage and probably slip conversation between other tasks, but still, it's a point to communicate and it's kept us ahead of the taking-others-for-granted curve.

My wife has pointed out that I get to indulge in my Aspergian routines. When I return to my apartment, things are as I left them. If they aren't, then I suppose I have a burglary on my hands, but for the most part it's true. She thinks that I become irritated when they visit and the apartment is turned into a whirlwind of clothes on the floor and food droppings from the boy. Which isn't true. I'm mildly annoyed, perhaps, but not irritated. I have peace and quiet, not animal fur on my clothes and the scent of litter box wafting through the air.

Which of course leads to more guilt...when I am not doing something I can go to sleep. Meanwhile my wife is trying to convince the boy to go to bed, and wake him the next day to go to school. She may think I revel in not having this duty. In fact, I feel quite guilty that she has to put up with this. My scolding of his behavior and admonishments are remotely dealt via a network link, with only the promise of punishment when we're together again. I'm well aware it's not fair to her.

These are my struggles. This is the crash that I walk away from, the situation that has not killed me. I am fortunate in that my wife has not held these against me, at least not to any degree I'm aware of. I'm fortunate in that my son is generally well behaved at this point and not a hellion; he can be a handful sometimes but not to a degree that my wife hasn't been able to handle. I have been fortunate in that my new job has smart, wonderful people that alleviate some of the stresses of my disjointed personal life. 

One of those managers, before I accepted the job, had expressed concern over whether I could take the job if it meant being separated from my family. I understood that from a practical viewpoint it would mean they were gambling I wouldn't crack and end up quitting in a short time; that would mean a wasted investment in time and money on an employee who flaked on them. "In the end it's just a job," he said.

But it wasn't. The situation wasn't one of simply walking up to someone with a happy, stable job and offering them the chance to leave their family, leave everything that was familiar, and instead gamble their future on a startup. It was a situation where the job was a dead end. It had management that didn't even seem to pretend to care about their employees, and even the public was encouraged to dislike them. Stress, toxic environment,...this was a chance for more, and the struggles I now deal with are the price to pay for that investment. 

I deal with the self imposed reminders of being a bad father for not being there. A bad spouse for not being at home after work. A bad person for those times where I feel almost comfortable, having my own routines not being interrupted by the needs of my son wanting to show me a new video game or YouTube video.

I deal with these by reminding myself that we have options opening up. I have a home three and a half hours away in the country, where I no longer take it for granted when we get home from shopping and I look up and see stars. I am more aware of my family when we get to visit each other. I'm far more aware of what it means to have a work environment that is challenging but also doesn't feel like they're keeping score in an effort to put you on the chopping block for mistakes. I've also been lucky to be able to try concentrating not on blaming people for situations but being more careful to consider other perspectives, helping me grow as a person.

Someday the situation will change again. And this current situation will perhaps have made me a slightly better person in the process.

It's Been a Year

I started working at StackExchange a little over a year ago. I was reminded of this when I realized yearly evaluations are fast approaching...a time when our work and personal growth would be examined to see how our careers are coming along.

This also marks the slightly-over-a-year anniversary of my first day at StackExchange. My first day was July 9th, 2012. I was terrified.

I suppose it isn't out of the ordinary for new hires to have the jitters. But for me, I think it was a little worse than average. I had literally uprooted from my home in rural PA only three days before, moving into a small apartment during what became some of the hottest weather that summer. I was still learning how to navigate the subway system and not familiar with finding the office building once I emerged from the underground labyrinth, and all the stories about mugging and robberies were dancing in my head.

...and that was just the challenge of showing up the first day.

Once there, I had to confront my own demons. Imposter syndrome, I suppose it's called. I had in part tried for this job...a job that I initially didn't get, adding to the pressure to make a decent impression...because it was co-founded by Joel Spolsky, who had an established track record as a leader in the business of software. StackExchange was a growing startup and this certified Internet celebrity had a desk fifteen feet away from my door. To say I find this intimidating is an understatement.

But Joel (or Jo-El of the planet Krypton, as he once quipped on an internal communication...one of several fond memories of the past year and one that illustrated that he was actually human, I think...) wasn't the only perceived job intimidation. StackExchange hires crazy smart programmers. I've always wondered if I had a talent for programming...a what-if scenario where if things had been only slightly different, could I have been successful as a programmer?

To even entertain the idea seemed preposterous. I would be starting from near scratch, since my software projects have been simple and of course atrocious; a simple system for managing user management and log checking at the ISP I was employed with and a few VB projects at the school where I was a sysadmin after that. The college project didn't even use proper error checking to sanitize input, although I at least acknowledged the security issues in my documentation.

But there were times I would write down ideas and read about creating a software startup. My shelves have several books on software engineering and succeeding in small business...so there was always a spark of an idea that never quite caught fire.

Now I'd be working with professionals...as in people I could never bring myself to show my own samples of yesteryear to for fear they'd question how I was hired. Their casual code slinging was yet another source of intimidation I had to overcome. In addition, some of them have software businesses on the side like GoRead and Alikewise.com.

I think there were times David and Kyle felt bad for me when my confidence would flounder. Sometimes.

Gradually I grew out of much of the intimidation and imposter syndrome. Not all of it; I still can't stop the wave of anxiety that hits when I'm near the big boss, fearing I'll do something to make a fool of myself or offend him. But I can approach the programmers' den without feeling that my presence is only tolerated.

Limiting the extent to which I doubted my own competence wasn't the only improvement. I spent much of the past year learning how things work, doing things the StackExchange way. It turns out that isn't easy in a startup when the policies and procedures are in flux. You have to learn how things are gone as well as why they are done that way; then you transition into influencing policies and procedures related to your field. I managed to do that. I'm actively refining our on boarding procedures for new employees and configuring their systems.

I even managed to add a little competence in Cisco. I track down systems on the network using MAC addresses and reconfigure drops to limit access to particular VLANs without supervision anymore...I know, I should have been able to do that sooner. In my previous jobs I didn't need to do it. We rarely had need to reconfigure what gear we had, and when we did, much of it was outsourced to a contractor. We were plenty busy without dealing with that. Now I'm making changes on switches where if something goes south, it'll cost us money and productivity.

Overall much of this year was managing to get my footing. Learning how things are done. And from there finding my niches.

I may someday get into video work; we can host presentations in our lunchroom space, and one time we hosted a talk when our primary AV person was, at the time, on a plane. I was flying solo with the equipment. The presentation went fairly well, and I went through the video to clean it up a bit (and obscure a slip of personal information during the show.) I really enjoyed doing that, as strange as it may sound. A sysadmin that plays with video? Well, I did minor in theater in college, after all. It shouldn't be THAT much of a surprise.

I met the founder of Wikipedia. Thanks to StackExchange, WikiMedia gave the company one ticket to see the Colbert Report the night he was being interviewed and I got the golden ticket!

My wife and I had an enchanting date night for the Christmas party. Utterly gorgeous night. We also had a Mandatory Fun Day at the beach last summer, except for one employee who managed to do major damage to his foot. Apparently sand can be extremely dangerous to walk on.

We've had employees move on. Some went off to join other startups; I feel really good for them when I see updates to their LinkedIn profiles. Some employees got married. It's interesting to watch people grow and change as the company grows and changes. And oh boy has it changed...growing like kudzu, until we needed to move to a new and substantially larger office space, and now even that space is starting to feel a little cramped as the need to double up in offices is looming.

That's pretty much been my professional life for the past year. The post is already long enough to not get into a year of my personal side, the part that gave the blog it's name. Perhaps that will be a topic for another post.

 

Posted with Blogsy

Everyone Should Learn to Program!...No

I have seen several articles and interviews published online extolling the virtues of teaching children the value of learning to program. Well, perhaps "children" is a little limiting. President Obama and mayor Bloomberg, among other celebrities, have urged everyone to learn how to code. I'm still having a little trouble figuring out why.

It seems this is justified by our increasingly technological world; knowing how to program is a way to better understand how our devices work. That may be a good way to understand our world, but it is hardly a necessary skill. Our technology is based on abstractions that make it unnecessary to understand even the most rudimentary building blocks of our gadgets, and most people revel in their ignorance of how the world works. Do you really need to know how the cellular network works in order to upload yet another photo of your lunch to Instagram?

You don't need to know how a fuel injector works in order to drive a car. Indeed, there are people...a disturbing number, in fact...that don't even know how to change a car tire, a skill that was at one point unthinkable for you to not have if you possessed a license. It was the pervasiveness of cell phone technology that led to the decline of the skill. 

The abstraction of the details of how technology works, enabling our ignorance, makes things easier for us to use. It doesn't take a genius to see that, left to our own devices, people rarely use time available when feeling bored to learn about the world. This is especially true if they have access to cat memes and Facebook. 

The other reason I've heard the argument for learning to code is the future job market. I suspect this is the likely origin of the sensationalizing of this coding campaign; it sounds like another opportunity to fix some aspect of our public schools (remember Classrooms For The Future? That was another boondoggle that funneled profit to companies for awhile to the detriment of students and schools...) while also hitting the key words politicians love to use when courting businesses. Programming jobs are projected to grow into the double digits in the not too distant future! Learning to program will get you a great job with a big paycheck!

Good programmers can earn a really nice paycheck. They can also earn a crappy paycheck. It really depends on a number of factors. Learning a programming language guarantees nothing; if you're good at it, you will probably increase your chances at having a good income, but frankly if "they" were really concerned about you making a good income the financial sector is the place to be. Wall Street financial institutions not only manipulated world markets, housing bubbles and drove wealth disparity to an all time high but they've done it with impunity while pocketing six-plus figures for their employees.  

Learn to program? Learn your math, kids. Learn to balance spreadsheets and learn accounting. It'll make a significantly higher paycheck than tracing conditionals and iterations through a loop. Even a doctor today is graduating with enough debt to offset a good chunk of his or her large paycheck for quite some time. 

Then there's the implementation of teaching kids to program in schools. I've yet to see this really done "right." Schools suffer from not knowing what they're really teaching. I suppose part of this is a lack of proper instruction to the instructors; often in situations like this a teacher is simply told they are teaching a topic for the semester and is tasked with finding a course book that fits the bill. He or she may not even have a background in the topic, especially if the course is not one of the core topics being tested on standardized testing. 

Did you have to take a typing course in school? I did. It was a lot of learning to touch type that eventually led into exercises on creating basic letters and memos. Today this has been replaced with teaching kids how to use Microsoft Word. Because, "This is what they'll be using in the real world."

Yeah, institutionalized product endorsement. 

Kids don't learn the basics of word processing outside of the particular product and version. It is demonstrated every time a new version of Word is released. Students...and often teachers...flip out when the interface doesn't match the exact expectation of what they have memorized. They learn how to do something through rote memorization. Which really isn't a good way to learn programming. 

Programming isn't something you just learn through rote memorization. It's problem solving. It's application of logical thinking. In an age of public education being equated with teaching to the standardized test, programming to solve practical problems isn't necessarily going to fit neatly into the de facto framework used by schools to teach kids. Too often schools teach kids to seek the answer without understanding the problem or the solution. 

...I suppose in a world where everything we use is an abstraction, understanding...knowing how to think and arrive at a solution...isn't really necessary to survive.

When I was pursuing a degree in computer science, there was programming involved. But it wasn't a programming course. The language was a way to illustrate the ideas. What's a loop? What's a conditional? What's a structure or an object or a stack? The language was secondary; the concepts could be done in a variety of languages or even pseudo code. The time it takes to become proficient in a concept was an investment made before becoming proficient in a particular language; indeed, focusing on a particular language implementation, with its own implementation and syntax quirks, could drive you batty. But the understanding of the fundamentals is what allows truly great programmers to pick up a new language when confronted with a new challenge. 

The real key to understanding that this initiative came from a non technical committee is the fact it urged everyone to program. Some people simply cannot do this. The wiring in their brains simply cannot wrap around some of the fundamental concepts necessary to apply the logic and syntax of a programming language to a problem. When someone proclaims that anyone can program, they are either ignorant or trying to sell you something. 

Ask instructors teaching intro computer science or programming courses. There is almost guaranteed someone that will drop the course because they just cannot "get" the difference between a FOR and WHILE loop. No matter how it is illustrated or explained or demonstrated, the concept escapes these students. 

In the end, the whole "everyone should program" media meme was nothing of substance. I should note that Bloomberg made learning to program a 2012 New Years resolution. Here it is nearly September of 2013 and I can't find any update online of so much as a "hello world" example from his office. What does that tell you?

Responsibility in the Workplace (or, "Hitting a DevOops")

Things go wrong.

That's a universal truth. We can make plans and anticipate problems, but in the end, "Best laid plans of mice and men" will occasionally leave you feeling as if you have little consolation outside the use of salty language and a desire to crawl into the corner of a server room for a few hours.

The important thing to remember is that it's the reaction to things going wrong that will be judged. The fact that something went wrong cannot be be changed; what's done is done.

In terms of the workplace, here are the steps I try to remember:

1. Take responsibility. Own up to the mistake, if it was your mistake (or your area of responsibility.) Was the task yours to maintain? Were you in charge of managing whatever went south? Maybe you just plain screwed up...you were supposed to order something, and you forgot, for example. Passing it off on someone else or implying it was someone else's fault you didn't follow through just makes you an unreliable douchecanoe.
2. Apologize for the mistake. Not in a passive, blame-shifting manner, like those idiots that make a passive aggressive acknowledgement that you're sorry that XYZ feels bad in a crafty attempt to make a non-apology. Apologize in a way that acknowledges your responsibility in the situation.
3. Once responsibility is acknowledged, let it go. Responsibility is one thing. Dwelling on it is just wallowing in blame. Blame will not help the situation. You now have a problem to solve. Focus on the problem at hand.
4. Rectify the situation. Identify what is wrong, and do what has to be done to make it right. This could be as simple as ordering what was forgotten (expediting the order, if possible) or maybe you'll need to find a workable solution with someone in a team affected by the problem.
5. Identify the source of the screw-up. Why did you overlook this? What factors contributed to it? Of course there are times when the problem stemmed from you making a silly mistake. Other times the problem came from a series of failures that maybe you couldn't reasonably foresee. The important thing is to ask yourself if there is a point where this failure could have been reasonably caught and mitigated before it became a problem.
6. Revise procedures. Maybe you need to add an item to a procedure checklist. Maybe you need to rely on organized lists. Maybe it's time to overhaul a workflow, or work with others in a team to create a check and balance mechanism.
7. Communicate the changes. Tell your manager and others affected by the mistake what will be done in the future so that this mistake will hopefully not be repeated. This shows that you're proactive and taking steps to learn from your mistakes.

This is a basic guideline I try to apply to workplace screw-ups. There are variations to these guidelines, but I try to keep the goals in mind when something goes wrong. Some businesses codify the spirit of these items with some form of post-mortem analysis of a situation, other businesses seem to leave it up to the individual to form some solution and move on, happy enough that the problem has been (hopefully) addressed.


In the end, the goals are the same.

• Acknowledge your responsibility and apologize
• Rectify the situation at hand
• Analyze what led up to the mistake being made
• Prevent it from happening again, if possible
• Communicate the changes you're making to prevent future mistakes going forward

 Life is messy. Things happen. Things go wrong. Acknowledge, and move on. Just...try not to let it happen again.

Notes for Giving (and Hosting) Presentations

Our office space hosts what we call "Town Halls," during which our remote employees and offices connect up to share information in a kind of giant shared Skype session without using Skype. Cameras, microphones, and connections are set up so we can not only send video of a speaker presenting company information but also the display of a connected computer.

We have enough space for projected employment numbers in our presentation space. This means we have a nice space available that was only being utilized for Town Hall meetings and company lunchtimes. Rather than let that space sit largely underutilized, we have had a few groups (and our employees) use it for after-hours technology presentations and meetups.

The setup is rather sophisticated, if I do say so myself and has largely been automated by an employee with a history of working with audio/visual equipment. For the most part, he has abstracted the complexity of the AV setup to a selection of one of a few presets on a tablet touchscreen, which can be further refined using a few interfaces on the same tablet. It's pretty slick, and he's still refining the macros controlling the interactions among the video, computer, and audio systems.

Some of the presenters for the talks have requested that events be recorded; normally the employee with AV experience is on hand for these events. That's fortunate, since he has intimate knowledge of all the plumbing that interconnects the systems and is in a very good position to improvise and fix glitches that can occur during the system's shakedown.

Recently we hosted an event where this same employee was not available onsite, and the role of recording the event fell to me, the backup systems person. On the plus side, I do enjoy learning more about recording and presenting events. It's a chance to scratch an itch for amateur video creation (I watch the how-tos from Ryan Connolly and his videocast series Film Riot and think, "That looks like it could really be fun to do...," until I look at Final Cut Pro and think, "This must be what a fighter jet looks like to an orangutan.)

Side note - If you have any desire to create sophisticated films, I strongly advise subscribing to Film Riot. Special effects and filmmaking tips broken down into easily digestible lessons, Film Riot makes me think that even I could make a half entertaining movie short. Perhaps. With the right software and decent camera...

On the other hand, it's still an incredibly complicated system that is separated by a few layers of abstraction so a monkey like myself can operate it, but if something should go wrong, I'm left scratching my head. Being kind of an anxious person, I constantly fear the breakdown of the abstraction layers, and this presentation night would have me flying largely solo.

The postscript of any event should be retrospective. What went right? What could have been done better? What was overlooked? How can I improve?

Even if things went awesomely, what can we do to make it more awesome in the future?

I'm not an AV person; my background largely comes from reading rather than doing when it comes to making videos and doing presentations. Therefore I'm a student with a lot to learn.

One good thing was that technically, this presentation went rather well. There was a glitch in the equipment where a camera wouldn't start up. While this wouldn't kill the presentation, it would have been nice to have this camera working; it was getting close to showtime, and the options were to fly without the camera and make do, or do a complete shutdown and powerup, risking that something wouldn't come back up in time (or properly) so close to the presentation start. I'm more risk averse. A less risk-averse coworker made the call to do the power cycle when I asked for input on the situation; it turned out his was the right call. It brought the camera up, and the rest of the equipment powered up as well, although the projectors gave me a bit of a fright as they wouldn't project right away to prevent damage to the lamps.

Eventually I'll need to find out if there's a way to individually power something up without having to do an automated shutdown and startup of the whole system.

There was also an issue with sound, where for some reason the notebook computer brought by the presenter refused to be heard through the headphone jack. I think it's related to his use of the HDMI output for video while the audio cable was paired with the VGA output on our system, but I need to consult with our AV designer to confirm it. Otherwise it might have been something strange with the way certain laptops deal with DRM restrictions. I'm not completely sure. The fix was simply using the notebook's regular speakers with a microphone placed over it.

I also have to remember that I need to be aware of the background. The system we have in place is optimized for presenting a town hall; that is, a speaker at a lectern, with two narrow spotlights aimed to highlight that speaker. The presentation that night had speakers that wanted to do something more of a fireside chat, out of the way of our lighting system. Our lights in the room also seemed to have a new lighting glitch that created a "disco" effect when we hit a particular preset; so we tried to get more lighting by keeping the solar and blackout shades open and allow more natural light into the space.

During the filming I realized that the camera resolution was just high enough that you can make out movement in buildings with open blinds. I'm not suggesting you could see lewd acts and the captured imagery was completely unintentional, but nonetheless all future video taken by me in our space will be done with our own shades down, regardless of lighting issues it may present.

Later on another speaker came up to present, and partway through I realized he wasn't miked. By far, my biggest fail; I should have interrupted the presenter and reminded them to put on a microphone. As a speaker, I will need to remember to check for a microphone if I wish to be recorded.

While recording the video it occurred to me that if you are presenting for a crowd outside of a comfortable circle, it may be beneficial to do a sweep of the backdrop for anything out of place or something that could be removed if it doesn't belong. The presentation was bookended by a social meetup; food and drink can easily be left out in plain sight. If your goal is to have a casual video by like-minded individuals, this may not be a problem. If you're planning on making something that may be incorporated into something larger, you may want to make sure the background and material are as vanilla as possible so the material will be more flexibly integrated.

Those were my own notes for my own reference. For a first solo performance at the tech side, I think it went fairly well. There are some things I couldn't really help (i.e., we don't have box lights, to my knowledge; I also need better knowledge of handling the transition arrangements of the two cameras and computer outputs to switch what's being sent to the recording system on the fly so there's less hesitation of what buttons to punch when, but that can only come with time. The addition of a mobile camera with transmitter would also give more flexibility in setting up shots and getting better footage, but I'm not sure it would be something we'll get budgeted anytime soon.) The items I did note...backdrop attention and insisting in the future that if you're not miked when you take the stage that you stop and get miked...are things I can improve immediately. Familiarity with the system will come with practice.

Regardless, it was an opportunity to learn more about an area with which I am unfamiliar, and I enjoyed it (once I stopped being afraid of it breaking on me!)

Stack Exchange: Moving Day

Several months ago Stack Exchange moved offices from 55 Broadway. I was with the small group charged with helping make the move; I spent part of the last day taking a few photographs and recording video on my phone.

Reviewing that footage brought a sense of bittersweet nostalgia. I took a couple of hours to assemble, render and upload a short video of the moving footage to YouTube. I readily admit it's not the finest quality in the world, but I still tear up a little when I think about it.

 

Things change as time passes on. What's interesting to me is that we live in an age when capturing small snapshots in time has become simple and mostly accessible to anyone with a phone.

Firefox: Where's My Bookmark (From the Console?)

I'm a slightly OCD type person. I'll check something several times over so the state of said thing is burned indelibly into my memory, and I can recall it later to that specific moment and not mix it up with some other similar time. For example, I'll check the refrigerator door before leaving the apartment several times to make sure it's shut, lest I worry on the subway that the fridge is acting as an apartment air conditioner.

Sometimes I end up with an irrational focus on something that shouldn't be a worry. I knew I had worked out some vacation time on the calendar, but for some reason I decided I wanted to double check it was actually entered into the private company vacation list. I needed the URL, which I had saved as a bookmark in Firefox on my OS X workstation. On my desk. Which was about 150 miles away.

That workstation didn't have graphical interface access open, but did have SSH. So how can I extract the address from the console?

I VPN'ed into the corporate network then SSH'd into the workstation. Next I navigated to the Firefox profile, located in ~/Library/Application Support/Firefox/Profiles/<something>.default.

Next I changed directories into ./bookmarkbackups. Is this automatically generated? I'm not sure. I just know there were several JSON files with dates in the filenames located in that directory.

As a quick and dirty operation, I dumped the text to my console then copy and pasted it into a text editor. The file was a list of titles, changed datestamps, URI's, etc...so a quick search within the text document for the name of the calendar turned up in the bookmark title lists. From there I copy and pasted the URI into the web browser...tada!

And that is how I pulled the address of a website from my Firefox bookmarks using the command line!

What is Documentation Done Right?

One of my new projects at work consists of revamping the checklists used when employees join and depart the company. My memory may be fuzzy...I actually have a horrible memory...but the incarnation that has been used was my own concoction from back when I joined the company nearly a year ago. For awhile, as each new person joined (or left) I would refine the action items so something overlooked the last time would hopefully not be missed the next time around.

It become something more than a checklist; it mutated into a checklist of action items with a set of how-to instructions under each entry.  We kept the final incarnation on an internal wiki system. A new person could tell that it was a dirty bit of work since the original checklist had a big old warning and link at the top telling the reader to go to another page that was updated and had more precise instructions on how to complete each step.

The finished list is one that I've been using for the past several months without much trouble. But things move on; more services are being added, the workflow for particular departments have added accounts they'd like added at hiring time, and as the company has grown the cross communication of who should be notified of what information for orientation has changed. The process has become on of the items that is a pain point, but only to the degree of an itch; people scratch it, are slightly irritated, but not irritated enough to warrant fixing the pain point...until next time, at which point the process repeats itself.

We also have a new system administrator in the team, and one of his central tenets to good systems administration practices is documentation, documentation, documentation. He's spent a good amount of time getting up to speed with our brand of Kool-Aid by revamping our internal documentation system; a side effect is reminding us of the technical debt we've created in our documentation practices. It's been a great motivator in getting my own checklist project updated. His work reminded me of something I'd lost sight of:

Your documentation isn't for you.

Adding new employees and disabling accounts had become something of my own niche. The documentation that had started out being a general list for anyone who would need to add employees became my own cheat sheet. The basics were there. But if someone new came along to do the job, the instructions didn't quite align with the exact steps needed to achieve the desired outcome. It was something I knew should be fixed but hadn't taken the time to do...until now.

To summarize a conversation Tom and I had one afternoon, "The goal should be to document and automate yourself out of the job. There's always something more to do."

My documentation wasn't really being used as documentation. It was a set of notes that I could refer to when trying to memorize the steps to reproduce a desired outcome. Gradually the steps became ingrained and the notes became more of a checklist that I would skim.

I also gradually gained a better understanding of what and why I was doing something. The documentation became burned into my head, and the notes masquerading as documentation fell into disrepair.

As I worked with the new and improved documentation I was surprised to see to what degree things were out of date. For example, our list of items to complete included provisioning a phone. We use Asterisk in-house, and each office has its own local server. Over the course of time, the newer offices had altered configurations for Asterisk, which automated more of the process and simplified the creation of accounts and phones.

I hadn't realized that at some point the New York system's documentation was out of date to the point of just being plain wrong; if someone else tried to follow those directions they would not have found anything resembling the sample entries they were supposed to follow.

I'm still in the middle of the checklist revamp. I'm trying to do it right, or at least better than before, which means it'll take some time; I'm doing an initial set of passes by literally documenting each step I take in creating new users and where appropriate I'm adding notes explaining why I'm doing what I'm doing.


Once I can follow the new instructions from start to end without a major hiccup, I'll identify points in the process where I'm missing information.  I'll look for things that are now consistent requests for modifications to accounts...such as, "Bob needs to be on <XYZ> mailing list"...and roll it into the initial setup procedure. Yes, this means having to communicate with people who manage various areas hiring new developers and salespeople.

Then I'll look for procedural refinements. For example, I've created a new badge for the user...who does it go to? Do I give it to the office manager? The new employee's manager? Do I hold on to it until the employee comes to me for it? We need to formalize this process so everyone is on the same page and knows, when asked for Bob's badge, where to look for it.

Once finished, I should have a list that is thorough enough for anyone in our technical staff to follow in creating a new employee entry with minimal mistakes.

An unfortunate side effect is how thorough it is becoming. I'm not completely through every step, and already the list and explanations is eight pages. Not the kind of checklist most people would like to deal with just to add an employee.

So what is the right way to do documentation "right?" The stuff I'm working on should be thorough enough that someone new to the job should be able to follow them, and the notes help augment an understanding of the thinking behind some of the steps. It should also pinpoint places in the procedure that need work, whether it's updating images rolled to machines or identifying where we might be able to potentially automate parts of the process. The problem is that this becomes less a checklist and more a procedural how-to, and as people become familiar with the process they start to ignore the checklist parts of the process much in the way billboards become simply visual noise I barely pay any attention to anymore when riding along the freeway.

Should documentation be adapted for more advanced users? Or should it keep some level of detail for people to refer back to, or for training newer users, despite meaning you may have to maintain various levels of documentation and keep them in parity?