First Week of Programming Re-Introduction

As I type this I'll be wrapping up about a week playing with a programming mini-project. I'm scheduling it to come out much later than that, of course, which is why I'm saying quite specifically, "As I type this..."

I'm sneaky like that.

I originally wanted to work on a project using Ruby on Rails. I've been reading Why's Poignant Guide to Ruby during off-time and occasionally during lunch at work, but the practical hands-on project I've been working on is written in Visual Basic .NET.

Yeah, I know, Visual Basic. I already explained why in a previous blog entry.

What have I learned this first week?

I'm still re-familiarizing myself with details of how things work in VB and Visual Studio. I'm no doubt making some tasks harder than they need to be; a side effect of practical inexperience. Re-learning...not as bad as learning, but frustrating when you know you've done something before but just can't remember it.

It doesn't help that I'm not focused for periods of time on the project. I tend to work on it for an hour or two a day, after coming home from the office. I get home a little late, I watch something while having some dinner, then work on the project, go to bed later than I should, wake up, yawn, and wish I had gone to bed sooner. Repeat.

The last thing I really learned was that Joel Spolsky was right; write a spec.  Or for a small one-person project, take the time to plan out what you're doing. I have been doing the seat-of-pants approach to this mini-project, primarily focusing on "here's what I want it to do, and to do that, I need it to do X,..." then I tried to create X. Then identify the next obstacle and work on that. I didn't know if I was really going in the right direction so much as I was creating a series of fixes that may or may not repeat functionality or at least overlap.

That's pretty much the project summary. A lot of re-familiarization and a hint of re-planning with a few drops of wishing I could dedicate more than an hour a night to it. Is this how most software projects work if it's not your day job? Because for me it gets just plain frustrating (in addition to the frustrations of running into logic problems and figuring out why something just doesn't work.)

Blogsy: Blogging on the Go

I enjoy blogging. I never claimed to to be great at it and I don't have a substantial number of readers, but I find the practice of writing to be cathartic. Sometimes it's even helpful, as I forget the keyboard shortcuts to applications like Screen and OH HOW HANDY I posted them on my blog.

I also find myself traveling around quite a bit. I probably find myself on a bus back to my home in PA once a month, and that bus trip is between three and four hours long.

Ugh.

Sometimes I fill the time with podcasts or reading. But other times I want to feel more productive. Writing a blog post entry scratches that itch nicely.

Of course there are a few problems.

I tried using the laptop. Being a bus, there really isn't a lot of room to get situated with a laptop, but I've managed to do it. The next obstacle I commonly encounter is internet access; I don't have a cellular hotspot device, my phone doesn't support tethering and even if it did, you're either unfamiliar with traveling through PA or wildly optimistic to think cell coverage would work without frequent drops. Some of the buses offer wifi, but they are still tethered to the cell network and prone to dropping out; that is, when they have wifi working at all.

My wife bought me an iPad Mini as an early birthday present. I thought, "It's small but not too small, I don't mind the keyboard, maybe there is an app to blog on the iPad..."

I thought there would be many. There weren't. The ones I did find weren't that great.

I stopped searching when I found Blogsy.

Blogsy worked with Blogger (required!), let me access photos on my iPad (handy!) and format my text (nice!).

Best feature for me: no Internet connection required (perfect!). Blog posts could be composed locally and uploaded later, meaning the crappy bus wifi wasn't an issue (unless I needed to research something or test links for a post...that got a little irritating, but was hardly Blogsy's fault.)

Another bonus: Blogsy can access many other sites to link content to your posts (when there's Internet access, of course.) The right side of my screenshot has an iconic display of services like YouTube, Facebook and Picasa in addition to the local photo storage.

Another feature some users will appreciate is access to the raw HTML with the swipe of some fingers. So far I've had to use it to tune the positioning of some tags for links, but if you like exact control over the appearance of your posts then this is a surprisingly handy feature to find in an iPad blog editor.

New users can be easily overwhelmed with the interface; Blogsy has PLENTY of documentation available as well as training videos and FAQ's, both on the website and linked within the app.

In my usage of Blogsy I've had two consistent issues. One, the publishing date setting doesn't seem to like to hold the date while I'm editing. It's FANTASTIC that I can still control when the post goes up, as I'm often queuing posts to appear over the next several days, but the Publish Date setting seems to like resetting to "Auto" instead of the specific date and time I set.

The second issue is the disappearance of my text behind the virtual keyboard as I'm typing. I'm not sure if that's a Blogsy thing or an iPad thing; can the app detect when the cursor is disappearing from view? I end up having to pause and scroll the page so I can review what I'm typing.

Feature requests? It would be nice to get some stats off the blog using Blogsy. For example, how many views has a particular post received? Perhaps the authors of the app want to focus on Blogsy as a posting editor more than a blog management platform, but when the app already has nice touches such as the word count I think statistics would be an equally nice touch.

Bottom line, if you enjoy blogging and occasionally want to write while at the park (as I am doing with his entry) or some other location where a laptop is a hindrance but your iPad is handy, give Blogsy a try. It's inexpensive and has more features than many bloggers would end up using while being compatible with every popular blog platform out there!

 

Posted with Blogsy

What's Wrong With Visual Basic?

A blog post entitled "To my daughter's high school programming teacher" has been making rounds online. I was curious about it after several retweets in my feed, so I read it.

There are a few things that the letter addresses. My background in the education system gives me a slightly different perspective, but I won't bother getting into the more popular issues it raised. It's already being repeated and rehashed online and all over. So much so she already issued a few updates and a followup post. It would be pointless to rehash the brogrammer culture, even though in this case it's more of a high-school moron culture.

The thing that kind of stood out to me was item number four on her list of suggestions for high school programming; I hope Ms. Endsley doesn't mind me borrowing from her blog here. Her suggestion read: 

"Don't be boring and out-of-date. Visual Basic? Seriously?? Yes, I know I said I'm not writing to complain about your choice of programming languages, even though I'm still scratching my head on this one. The reason I mention your choice is that it doesn't help you make a good first impression on new programmers. I have no idea what my teen learned in your class because she wasn't excited about it. Without touching your minuscule class budget, you can offer a range of instruction with real-world applications. With resources like Codecademy, for example, students could try a variety of programming languages, or focus on ones they find interesting. Have you considered showing kids how to develop a phone app? Program a Raspberry Pi? Create a computer game? Build a website? Good grief, man — how were you even able to make programming boring"

First, the choice of programming link goes to an article where the author downplays learning VB because a search on Dice.com shows few jobs with VB experience in the title. Cobol is gone with the dinosaurs. The first thing to make me pause in his article was the statement that new programmer job-seekers need to focus on web development skills, then followed up stating that Java was more important than Javascript. I'm not a professional programmer, but something didn't quite add up there. I'd love to hear what people in the industry think.

Second, if you're going to do searches for programmer jobs, let's look to the pros at the StackOverflow Careers site (note: I work for these guys.) A search for "Visual Basic" turned up 263 jobs out of 1689 job listings, or about 15.5%. Not great, but it's still out there and in use.

StackOverflow.com has over 53,000 questions tagged "vb.net" out of 5,700,000. That's slightly under one percent. Yikes! On the other hand, the "ruby" tag has 82,400 questions carrying that tag. Java has 478,000, and Javascript has 443,500. Erlang, 3,700. Clojure, 5,800. Not quite the results I expected after reading the article from the Dice.com author.

Then again, you could use something like the TIOBE index for measuring language popularity (don't know why the author didn't use that to begin with...) Java was at the top, followed by C, C++, Objective-C, then PHP, and C#. Visual Basic was 7th. Then Python, Javascript, Ruby at 10th, and down at 13th place was VB.NET. The fact that "(Visual) Basic" was 7th while "Visual Basic .NET" was 13th would lead me to believe there are a lot of VB5 and VB6 applications out there that will continue to need maintenance.

Third, Rikki goes on to point out that her child...and I left out the huge amount of exposure to technology she described earlier in the post...was not excited about the class, and it's because VB doesn't make a good impression. Let's try a variety of languages!

Really? I'm not even sure how this would practically play out in a school setting. You have a teacher who probably isn't programming savvy. If he were, he'd probably be a programmer, not a teacher, considering the education environment today. But this is mere speculation. The programming classes I knew in the districts I worked were typically business or math teachers, primarily, and programming courses came from a course book. The teacher simply doesn't have time to work in a multitude of languages and have it not devolve into a nightmare in terms of keeping up with the student's work.

These are high schoolers. Most of them don't know anything about programming. And they are suddenly open to the choice of all these languages, as proposed...how would they know what's "good?" And it's not like they have four years to choose what they want to dabble in. They probably had to fit it into a semester. And actually accomplish something.

Which brings me to the next point...the first steps of learning the language is boring. Or a pain in the ass, depending on how you're wired. You can't do much with any language without understanding the basics (no pun intended); loops. If-then. While. Functions. Methods. Maybe getting into objects. You want to write a novel, but first have to understand what nouns and verbs are, and how to construct a sentence, then how to construct a paragraph, and somewhere along the way learn how to construct a narrative.

And some of these kids...these are just kids, most of them taking the course to fill in some credits in all probability...won't be able to quite grasp how loops work. Or a function. It'll be tough for them, if they even keep trying; often they give up, or just screw around in class, not caring that they're making it harder for other students who may want to actually learn.

If learning the programming concepts is hard, and learning the syntax is hard, that is still a bit of a cakewalk compared to learning the IDE. Visual Studio is complex. It's got tons of features that beginners won't even touch while making something that is still moderately useable. You could spend a week just exploring all the things Visual Studio brings to the table. But when you are looking for a professional job in programming, Visual Studio is the key tool behind any company using the Microsoft stack. Because of this, you can get tons of examples and help when you have a question.

But it is yet another item that takes time to learn, and for a beginner can get in the way. Not only are you learning concepts and the language, you have to learn to model in your head how event-driven programming works, and how your code ties to specific GUI elements on the form.

I've read that languages like Python and Ruby may be good for beginners. I used Python before; it was nice in many respects. But on the other hand, when learning concepts, you end up with a lot of programs that run at the command prompt. You learn some of the logic behind how to do simple tasks, and the command line is fine for that. Languages like Ruby and Python are great because you install them and can edit them from any text editor. Does that really excite kids though? Learning the concepts but not having anything fancy or graphical to show for it? Maybe you need to install a framework to enable a quick website creation. Then you get to introduce them not just to the language, but to the framework.

"I'm learning Ruby!"
"No, you're learning Rails, and was exposed to Ruby."

 The fact is that in most schools, programming courses are little more than "install Visual Studio Express and follow the exercises." You can criticize the teacher if you want, but there are constraints in budgeting, time, and what the class can be expected to achieve in terms of getting projects done and graded. Nothing prevents the kids from learning more outside class time, and I'm really betting the class is just an introduction, not a training course for a career.

And what of a career with VB.NET? Is it really so horrible? Dot-NET applications are, as I recall, compiled down to a Common Intermediate Language, regardless of the syntax behind them. The Visual Studio family of languages ends up with CIL and are tied to those .NET installs you have to update on your home computer. Is there a performance difference if these kids used something like C# over VB?

I did a quick Google and discovered that I apparently had this question before. It even attracted an answer from Jon Skeet. Basically, no, it doesn't really matter once it is compiled down. You use the language whose syntax you're comfortable with and works for the job at hand.

A little more poking around the sites (for Programming and StackOverflow in the StackExchange network) seems to show that VB.NET has more bias against it not because it is necessarily inherently bad, but because of its heritage. Another irony to the "Why would you choose VB.NET to teach beginners?!," given that BASIC was meant for beginners. It's in the name. Beginners All-purpose Symbolic Instruction Code. While VB grew to something that little resembled the initial language, many professional programmers apparently came to hold disdain over those that would use VB and its ilk, because VB encouraged people who couldn't program to make programs. Similar to hatred towards AOL'ers in the early days of home Internet access because it brought the hopelessly non-technical into the realm of geeks.

That stigma apparently continues today.

I had used VB, among other languages. And as I previously alluded to in a blog post, I decided to make learning a new language a project. I started reading a guide on Ruby; mainly to immerse myself in a bit of the culture while starting to absorb some of the "Ruby way" of doing things. But Rikki's blog post kind of made me want to try something else to get into the beginner's programming mindset. I started working on a project in VB.NET. I'm still reading the guides for Ruby, but I want to see how far I can get on this other project.

I'm sure it wouldn't be a popular choice among real programmers. I'd be the target of disdain and derision, if any programmer read this and took the time to criticize my choices. The only ones I really fear showing anything to are my coworkers since they are working with C# and I'd actually value their opinions.

But I'm not a professional programmer. I don't have years of experience with full time programming. I'm coming to this with just enough experience to know terminology, the basics of a few languages, and eyes fresh enough to have a perspective professionals have probably lost. I suppose the end product will speak for itself, if there is one.

And if it sucks...which it probably will...maybe the next one will be better.

Also, if you are a programmer and have some insight as to why VB.NET is not something to subject new programmers to (using reasons that are rational), I'd love to hear them.

Program Design Pride

Everything associated with your company name says something about your company. I've always associated this with "branding" or "marketing," although I'm not sure if those are proper terms for it.

Small businesses often don't think they need to pay much attention to properly marketing themselves. I grew up in a small town where just opening a restaurant or new store was enough to get some attention.

SOMETHING IS DIFFERENT! WE MUST GO THERE TO FIND OUT WHAT THAT PLACE SELLS!

What many businesses fail to understand is how much little details can matter. I cringe when I see blatant typos on business signs. If they care that little about the sign board in front of their store, how much care must they take in their product or service? I know it's a fallacy to think that because a restaurant can't spell today's special properly it means they can't properly prepare it in the kitchen, but of all the things you have control over in running a business, a sign with programmable or movable lettering ranks rather high on the ease of quality control items.

Small businesses in my home town often have this problem. But more shocking are businesses with literally seven digits (at least) of profit flowing that make similar mistakes when creating an application to interact with their customers. I'm not talking about spelling errors but rather simple interface issues that leave me scratching my head wondering who thought this was a good idea. Some blatant earmarks of crappy design:

• The application is obviously an interface to your website. As in, you made an "app" that scales a mobile version of the website. If I want that I will bookmark your site. A bank I do business with seems to do this. When I have a problem with them, the application is another on the list that bugs me as I get wound up to talk to customer service.
• The application was designed for iPhone. Literally. As in, I launch the app on an iPad and the interface comes up as if the display is the size of an iPhone, rather than properly scaling to fit. That same bank app, as well as a healthcare company, both do this; fortunately they have a "2x" button to scale them to twice the iPhone size. It looks cheap and crappy. Don't do it. (Be sure to say the "fortunately" with a sarcastic tone in your head.)
• Make notifications obvious. My Google Hangouts app pulls this crap on me all the time; the icon wears a big numbered notification alert badge, I open the app, and I find no obvious reason for the notification. I click around, reading random requests and old chats, exit, and the same damn number is still there. WHAT ARE YOU TRYING TO TELL ME?!

Not being an iOS developer, I don't know how hard it is to fix these kinds of issues. As a fairly technical end user, I can say that in my opinion it makes the product look cheap and shoddy. Do they simply think their customers aren't worth the effort? Why did you bother making an application if you're not going to make it usable and high quality? I wonder if you didn't just throw something together by outsourcing the job just so you can claim to have something your competitors have.

I also wonder: what do the developers think? Were they forced into compromise, or were they hired as outsourced guns that don't care a whit for the company brand?

 

Posted with Blogsy

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.