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.