Tag Archives: tech

Upgrading to Windows 10

I upgraded to Windows 10 this weekend on the only Windows system I use, my gaming system. I had it on good authority that the games that I’ve been playing occasionally were well supported (pretty much Guild Wars II) and that it was an improvement over Windows 8 (which, unfortunately, came on my system and I was too lazy to downgrade it).

Overall, I’m pretty happy with it. They got rid of the fullscreen start menu replacement in favor of a much more user friendly option that is a natural extension of what they had right in Windows 7. There are, however, some pretty significant privacy concerns, so right off the bat I did the following (most of which I document here in case it’s not exhaustive and for later reference):

  1. Privacy Settings
    1. General: Turned all off
    2. Location: Limited to only those apps that I want to see my location
    3. Camera: Limited to only those apps that I want to have camera access
    4. Speech, etc: Turn off “Getting to Know You”
    5. Contacts: Turn off “App connector”
    6. Calendar: Turn off “App connector”
    7. Feedback: Set to “Always” and “Basic”
    8. Background Apps: Turn off all but apps I actively use and want running in the background (Twitter, Dropbox, etc)
  2. Wifi
    1. Wifi Sense: Turn off “Suggested” and “Contact” connection
  3. Cortana
    1. Turn off Cortana
    2. Turn off search suggestions
    3. Turn off popular news
  4. Edge
    1. Save passwords: off
    2. Save form entries: off
    3. Do Not Track request: on
    4. Search suggestions: off
    5. Block all cookies
    6. Media licenses: off
    7. Page prediction: off
    8. Set Chrome or Firefox as default browser then never open Edge again

When to Hit the Gas

In my last post, I alluded to a set of criteria that I use to determine whether or not it is reasonable to ask a team to work significant extra hours—such as going over 45-50 hours in a week or working a weekend at all. What I didn’t do was describe the composition of that criteria.

I typically am looking for three factors to be met; so when I’m determining if it is appropriate to ask for the additional work, I look for:

Is there a defined, specific, goal? This doesn’t mean “finish the project,” as that is the sort of down-the-rabbit-hole trap that ends up dragging teams to an early exit. This means “we have these clearly defined tasks with clearly defined success conditions that must be done.”

Is the goal possible? My criteria used to be 2-items in length, until I was at a job that delighted in giving clearly defined criteria that were clearly impossible. Nobody should be sent on a death march.

Is the duration and severity reasonable? Saying “we have a clear, specific goal of working 80h weeks for no more than 2 months to do these 100 items” might be sufficiently specific and plausible, but the duration and severity virtually guarantee that quality is going to be thrown out entirely.

These are not the only factors that I consider—length of time since last the developers involved have been asked to do this, how did we get in this predicament in the first place, is this a reasonable thing to ask to get us out of the predicament; these are all also considerations to varying degrees—but the above are the primary drivers of my decision making.

In practical terms, this is handled as a conversation. By way of example, on projects for my current employer, working considerable extra time was brought up in two distinct situations on two separate occasions. In both instances, I sat with our senior management team and walked through the above thought exercise.

In one instance, it was determined that while the scope of work was relatively well defined and possible, the duration of the overwork would be such that it was very likely to destroy quality. It was also likely to have a significant impact on the development team as a whole. In that instance, we decided together that it wasn’t worth the risk, and found a plan that would yield more reliable results.

In the other instance, while the same risks were very much present, the volume of work was more reasonable and we all felt comfortable in using over-work as a strategy.

In both cases, working together first with my management team then with my development team was an essential piece of the decision making process. It has been my experience that this criteria has both served as a gatekeeper for preventing burnout and low quality due to overwork, but it has also served as a educational opportunity for all involved every time it has come up.

Corporate Integrity

Today, I tweeted the following:


It was brought to my attention that the last two tweets in my message were unfair to companies that are trying to do better in many ways, but are trapped by past performance and slow-moving internal politics.

I disagree, and I’ll explain now what I explained then…

Until recently, I did not have a good name for an element of my approach to the world in which I have long taken considerable pride. A friend pointed out that the name for it was “integrity,” in the sense that I reliably adhere to a code and to my values. In short, if I say it, I do it, to the best of my ability (and, of course, the converse is also true). I try to be a “man of his word,” even when doing so causes me significant difficulty.

I think that we spend an awful lot of time at our jobs trying to explain away why our codes don’t apply in one circumstance or another; especially when we’re talking about our corporate values rather than our personal ones. Perhaps profits are down and we’re just trying to get through this one ugly time then we can practice our values again. Sometimes we just don’t have the political clout yet to enforce our values, but given some time, we’ll earn it. Most often, though, it’s just not time yet—but soon, soon it will be time!

I would argue that that is bullshit; a code that you only follow when it isn’t being tested isn’t a code. If I don’t steal because it’s too easy to get caught, my code of conduct isn’t “don’t steal,” it’s “don’t get caught stealing.” Likewise, if my dedication to quality is such that I forsake it when it would make me unprofitable, my value isn’t “deliver maximum quality,” it’s “deliver the best quality you can without hurting profits”—which is really just a long way of saying “deliver good enough.” I value my integrity BECAUSE of how difficult it is to maintain when it’s being tested, and as a customer, I value the integrity of companies that do the same for me.

So when I say “my team won’t work extended hours unless it meets a very particular set of criteria,” I mean PRECISELY that. It is too easy to have your values outshone by every exception and edge case that comes up—and it becomes increasingly easy each time that you do it. In practical terms, this means that I walk a very fine line at times between having my team made no-longer-my-team by virtue of a very abrupt demotion or termination; and I walk that line knowingly because I WILL follow a set of strictures that I know is correct and best for both my team and my business. If I lose my job or my team, I will do so knowing I did the right thing, and I will find an employer whose values are more similar to mine in the future. I have been lucky my nearly 20 year career that this has not actually happened—I suspect that this is at least partially because I actively select companies whose values are in alignment with my own, and I am very quick to leave if I find that no longer to be true.

It is also incumbent upon me, though, to assert my integrity—to honor my code if you will—in a way that makes it easiest for my company to help me follow my values. I spend tremendous amounts of energy in educational efforts in all organizational directions to PROVE the value of these points of view, and I spend even more energy in ensuring that my values benefit both team and company; there’s no point in making a stand that leaves us all the former employees of a former company at the end. Integrity, be it personal or corporate, is profoundly exhausting, challenging, and—as a result—rewarding.

So, do I think it is unfair to say that your actions when things are challenging convey your real values? Absolutely not—in fact, I’d turn the question back to you, if you think that it’s unfair. Is your integrity sufficiently important as to make your actions match your values? And if not, why not?



The David Foster Wallace of Software Development

I was trying to describe to somebody what it is that I do in relatively specific terms—a task that proved to be immeasurably more difficult than it should be—and I was casting about trying to find some way to convey what it is that I actually accomplish. I know what I do, I’m there for pretty much all of it, why would it be so difficult to summarize in any meaningful way (or, more to the point I guess, in a way that is meaningful to people that don’t do the same thing). After a series of increasingly embarrassing false starts and fumbled trail-offs, I staggered into a description that I feel is pretty close.

I am a story teller.

When I teach, I teach through metaphor and anecdote. Facts are fun—I love them and they are necessary—but facts don’t teach, they inform. Building a connection to facts, that is how we learn. That is how everyone has always learned (give or take a few). So rather than spew a list of concepts, methods, or algorithms at my class, I teach by using stories to build those connections. I tell stories about how I used this function wrong and it yielded a comical result. I talk about how mis-application of some idea ended in tragedy. We, as a class, explore examples of certain algorithms in our daily lives. We weave stories in order to build context for the facts in our minds and so that we can retain them.

I’m no less a story teller when I develop software.

When developing software, I have to be a master storyteller if I want to do a great job. I can’t tell the story, I have to help the customer—the end user—tell their story. I have to elicit from them how they think they do work; then I have to dig deeper and get them to convey how they actually do work. Through anecdote and informal chatter, I draw out context for otherwise disjointed facts like “I want it to be busier” or “the old way was just too clustery.”

Once I’ve helped the user build their story, I build my complementary story. I take what they have taught me and spin it into my own tale using code and graphics and requirements documents. I deal it back to them like a serial novel—pieces at a time in a way that allows me to gauge their reaction and keep their interest engaged. By the time they have seen the story in total, there should be precious few surprises (and among those precious few, only good ones) but a great deal of satisfaction with the denouement.

This is why it pains me to see the artless, engineering way to do requirements analysis. I cannot do my best work as I slog through a checklist of context-less questions and categorized facts. I need connection, and so does the client. In my experience, we are all infinitely better off sitting down together and listening to one another’s story with a checklist as a backstop to ensure that all bases have been covered than to rigidly adhere to a few hours of discovery done in a conference room.

So I’m not a software developer. I’m not an educator, a father, a manager, or a leader. I’m a story teller; I suspect that your software developers are yearning to be one too. Do yourself a favor and help them get there.

There’s No "U" In Women in Technology

As a regular reader of tech news and various forums, I am regularly witness to articles addressing women in technology—and let me begin by saying that I am profoundly grateful for that. It wasn’t terribly long ago that the very idea that a woman might participate in a STEM field was absolutely shocking. Even as recent as my time in high school some 20 years ago, home economics was for girls, shop was for boys, and computer class was for nerdy boys with poor hand-eye coordination. This shift, from then to now, only happens as a result of this ongoing conversation that happens in the media, on the web, and in our offices.

I am concerned, however, with the narrative that we follow in discussing the shortage of women in technology. We discuss (ad nauseam, some times) who these women are and what they do. We bicker about why they are insufficiently represented and about whether or not there is a pay disparity. We even discuss what women can do to address the gap—like they’re the only part of the equation. Here’s the thing, if we’re going to resolve this, there’s work that’s going to have to be done on both ends of the equation. Certainly, women are going to have to (continue) to do some heavy lifting to continue to stake out their place at the table—but shouldn’t the rest of us consider what we should be doing, too? So that’s what this is, this is the conversation we can have as men as to how we fix this gap…at least part of it.

The most important thing that we can do is to stop pretending that trying to fix this gender divide is a thing we are grudgingly having to do for “them.” I’ve worked around developers more of my life than not at this point, and there is no doubt that we are a supremely homogeneous group. Homogeneity stands firm between a team and progress. The more alike the membership of the group is to one another, the more the group becomes a feedback loop for itself; inflating the importance of its own ideas and confusing concensus with popular opinion.

It is in our best interests to fix this thing. We need our ranks to be filled with as diverse and broad a subset of the human experience as we can manage. Adding women to the mix is just one way, but it’s an important one, and the fix begins easily enough. We can cover serious ground by making one these two simple fixes:

Stop making your space an unsafe one

Imagine, for a moment, a person you do not want to have sex with. I don’t mean someone you find hideous or repellant, mind you, just someone that is completely physically unattractive to you. Perhaps you even enjoy the person’s company, but dating or sex? No way!

Stop picturing me, that’s uncalled for.

Now, imagine that they are participating in a development project with you. They are a member of your team and you see them in-person and online on a regular basis. You are in pretty close to daily contact. Oh…and he or she will not stop hitting on you. Now, I don’t mean that this person is aggressively forcing him or her self at you; that would almost be actionable. Instead you are subjected to all of the flirty behaviors you aren’t interested in. They make jokes-that-are-clearly-not-jokes, they sit too close, they check you out in obvious ways, they invite you on dates-that-aren’t-dates-that-really-are-dates; and they do all of this relentlessly. Take a second, actually picture it.

If you are like me, you are already a little bit uncomfortable, because almost all of us have been in this situation at one point or another and we know how awkward it is to be stuck here. This is not something you are comfortable calling harassment, but he or she won’t take a hint and there’s nothing you can do about it without coming away feeling like a heel.

Now, imagine one more thing for me…imagine that you weren’t even sure that you belonged on this project at all. Imagine that you already felt a little out of place, and THEN all of this happens. How long before you decide that this particular project just isn’t the place for you? How many of these places will you decide aren’t for you before you think that this entire industry just isn’t the place for you?

Listen, from a purely practical sense, it’s a simple concept: the only circumstance wherein you immediately and clumsily hitting on a female on your team is going to end *well* is if she is into you, is looking to be hit on, and doesn’t mind your ham-handed style of flirting. Only if all of these three are true does this end even close to well. In all other cases—if she’s not into you, if her intentions happen to be (*gasp*) focused on this project rather than your libido, or if she would just like to spend some time doing this without having everyone trying to climb into her pants—all you are doing is alienating her. That hostile environment that we just described, that’s what you are creating. The best of the likely outcomes is that she quietly puts up with all of this while tries to focus on this thing that she is actually here for, but the most realistic scenario tends to be that she just goes away.

Start making your space a safe one

The fact of the matter is, even if you stop hitting on all of the women as they arrive in your group, your fellow men in technology are probably still doing it. The next step is to make your work spaces safe, inviting ones for everyone that you wish to attend, including women. It is easy to put together rules and regulations that legislate spaces into safe and inviting ones—and when the space is a place of employment, you almost certainly should do so—but merely putting rules together isn’t enough. The sort of off-putting behaviors that legitimately sends women the message that they don’t belong is notoriously difficult to pin down with any degree of specificity in real life situations.

Social pressure, however, is an amazing thing. Let’s face it; this sort of behavior is truly embarassing to be caught doing. Relentlessly pestering a woman for a date—or doing all of the show-off, plumage-flaring behaviors meant to draw the attention of one’s desired mate—these are humiliating things to be called out on. Use that fact. When you see someone singling out the female in a group for attention, call attention to it.

It doesn’t have to be overt or in front of an entire group of people. In one of my classrooms a year or so ago, I had a very attractive student in a web programming class, one of perhaps 2 female students in a class of nearly 20. She was very good—if not top of the class, then very near it—but that didn’t stop one male student from offering outside-of-class help. After observing a few such offers, I finally had to intervene…

Me (directly to the student): Hey, are you offering additional help?

Student: Yeah…

M (to the class): Hey gang, S is offering to help those of you who are struggling. It’s really cool of him to offer, so, take him up on it.

At the end of class, alone…

S: Hey, I didn’t mean that for the entire class

M: Oh, I’m sorry, I just figured that since offering to help just her is sort of creepy and stalker-y, you must have been making it kinda a general offer.

At this point, the student and I had a brief discussion as to why it is frowned upon to do what he did, why it might be creepy, and why it wouldn’t be allowed in my classroom. Who knows if this ‘teachable moment’ had a lasting impact on him, but at the very least he ceased hitting on this young lady in my classroom. She had one safe space to learn, at least.

Now, there are probably dozens of other things we can do—right off the top of my head, I suggest not letting our impostor syndromes manifest as uber-aggressive know-it-all posturing, for example—but this is a start. Simply recognize how essential it is for all of us that we fix this, then start fixing it by trying not to be a douchebag and pointing out to your friends and co-workers when they are being douchebags. Perhaps we can end this boy’s club that someone created for us. I know I, for one, don’t want it anymore.

Weak Data Typing is Weak

When I’m teaching PHP or Perl, a conversation invariably springs up early in class related to loose data typing. The format is almost always the same…a student with some moderate amount of programming experience in a strongly typed language (C or C++ generally) is elated to find they can just stuff anything into a variable. When I opine that this is a terrible and dangerous flaw in the languages, the argument proceeds down the lines of “it’s so much easier” or how “archaic” my point of view is.

Listen, weak data typing is not easier; it’s sloppier, which is not the same thing. In fact, that sloppiness often makes things harder! This weekend, for instance, I whipped a quick little script together for a friend that would parse an automatically generated XML file and make a series of corrections for him. In mid stream, however, I was stymied by a troubling little bug…one of the fields would occasionally cause a crash.

As it turns out, XML::Simple was reading a blank tag (that the program generating the XML erroneously output as <tag></tag> rather than <tag />, but I digress) and rather than storing it as a null string, it opened up a new, empty hash.

Of course, it is stupid of the initial app to output the XML in that format…and yes, XML::Simple was being idiotic for not noting that edge case…but these are the exact sorts of real-world situations that strong data-typing would have prevented (or, at least illustrated earlier).

I spend an enormous amount of time looking at other people’s code whether it be working for my ‘day job’, for a consulting contract, on open source projects, or examining the work of my students—an a single, unifying theme in loose data typing is that it is a gotcha that is often terribly difficult to track down.

So instead of adopting the burden of explicitly casting your data from type to type, you adopt the burden of searching for edge cases to prevent…to my mind, not easier.

RE: The New Job

So I’m rapidly coming up on the end of my first quarter at the new job, and I’ve been planning to post my thoughts for nearly two months now. As it turns out, the past several years of being busy doing full-time school, teaching, consulting, convention planning, and raising a family was merely a warm-up for being really busy. Writing has, as usual, suffered.

So how am I liking the new gig? I am in love with this job. I was decidedly nervous at the prospect of making a return to so many things I hated in the past. I hate having a rigid work schedule—for me, programming is a creative activity, and I need to write code when I’m feeling creative. I hate writing code for other people—the last six or seven years have afforded me the ability to be selective about which clients and jobs I would take. I dislike working with project management teams—most project managers are not terribly good at the ‘managing projects’ part of the job. Finally, programming professionally is terribly time-invasive—employers have always demanded ridiculous hours and I’ve exhausted tremendous quantities of energy fighting on behalf of me and the teams I’ve lead for the right to sub-60-hour work-weeks and vacation time that involves actual vacation. While the interview process left me comforted, I was still pretty concerned about the possibility that I was walking back into the same situation again.

I needn’t have worried. In (almost) all respects, this couldn’t be more different.

In the first phone interview I took leadership roles off the table, choosing to focus on developer positions. While being “only” a developer meant a sizable cut to my salary, it still represented a comfortable paycheck; more importantly, managing a team of developers always came at the cost of being able to write code. (It turns out that the organization is flat enough that the leadership role probably wouldn’t have been bad either, but I still think that my decision was correct.)

The Company

The schedule is exactly what I need. Extremely flexible hours with a generous attitude toward working from not-at-my-desk. Provided I am reachable, make my meetings, and get my share of the work-pie done, the when and where aren’t all that important. For me, that means that I can go in very early and knock off a bit earlier as well. I can work and have time for family to boot! Madness!

I do not avail myself much of the opportunity to work remotely, though, because I genuinely enjoy the culture at work. I am used to seeing work cliques: the managers are upstairs, the project managers in that section, the creative folks all over there, front-end folks on one side of the office, back-end on the other…minimal interaction. It was like several companies working in the same building throwing work at each other.

It’s going to sound a bit cheesey, but here we really are just a single, big team. I really love the producers (which I still keep calling PMs) in my division. They are, by and large, the best group of them I’ve worked with. Working closely with the front-end folks has really boosted the quality of the work I put out, and the work that we generate as a team.

Even amongst the software engineers, the culture is more to my liking. I despise being on teams where everyone is working super hard to make sure that nobody thinks that there is something that they don’t know. It is needlessly stressful and makes for worse code. This is…whatever the opposite of that back-biting, paranoid place is…that’s what this is. Everyone is quick to answer questions; and they’re quick to ask questions too. As a developer, that sort of environment—the sort where a group of programmers will get together and all try to figure out some pesky quirk or weird behavior—is precisely the sort that I thrive in.

The best example I can think of to describe the culture here: early in my second month, my supervisor was on vacation for a week. We all put in some significant hours that week. Early one morning the VP of my group was walking by and just stopped and asked how I was holding up. He had seen that I had a posted some pretty big numbers to client work that week, and just wanted to make sure I was holding up okay.

Just like that…”Hey, how’re you holding up?“

And that’s the rule, not the exception. My whole supervisory chain is amazing. They communicate, they listen, they go out of their way to ensure that everyone knows that their contributions are appreciated. They are all genuinely concerned with people as well as product.

The Work

Frankly, I really enjoy the work. I hate working on a single project *FOREVER*. It gets SO BORING. Here, I have around 10 projects on my plate at a time in various stages of completion requiring different amounts of attention; and they’re all different beasts. Right this second I have a few projects preparing to launch, a few more that have launched in the last week or so, a few that are just beginning to gear up, two that I’m doing recurring maintenance on, and a smattering of small things that are currently in other hands and I’m working support on.

I am constantly engaged in programming that makes me think, in problem solving that keeps me interested, and in writing code that is honing an edge back on to some rusty Perl skills. The work was the part that I was most certain I would just be tolerating…I couldn’t be happier to be wrong.

That said, the one downside at the moment is that there is a LOT of work. I mean, a lot. Like, given my history of busy-ness, believe me when I say that this is the most busy that I’ve been in many years. We are short staffed, and while we’re trying to hire, they are pretty strict about making sure that those they hire are going to be a good fit for us. In the interim, it has made for some long, long weeks. It should be an indicator of how happy I am here, though, that I’m throwing out some 70+ hour weeks (while going to school) and still in love with this place. I end each week exhausted, but happy.

And there’s light at the end of the tunnel…help is on the way, and hopefully more help beyond that too.

Wow, I just skimmed what I wrote so far…could I be giving this place more of a hand-job? I’m going to stop now, so I can get back to work. I’ll try to get something less stream-of-conciousness posted at some point. Just know that I’m very happy with my choice. I feel useful, engaged, and appreciated.

And tired…lots of tired too. :)

Making my Transition

“It’s hard to take responsibility for your own transition…”
—Tina Fey in a Nerdist podcast interview

Today I left a job that I really love—a safe, comfortable job teaching at a local community college—to embark on a risky journey as a software engineer at a local firm. I am truly ridiculously excited about the new gig; the culture is comfortable, the people I met are bright and engaging, and the work sounds like a fun challenge that is right in line with my interests and strengths. It’s scary…the last time I did ‘corporate’ development, I was miserable for a host of reasons (most no longer applicable) …but I am really geeked about this.

It is bittersweet though. I love the school, teaching, and my colleagues, and today when I left, I was actually a bit emotional. I have worked there in various capacities for 6 years; I have never worked anywhere uninterrupted for so long. The choice to leave was a hard one to make, because there is momentum in sitting still where you are happy and comfortable. In the end, two things made the decision for me: first, everything great in my life has been the result of risks, so it would be foolish not to take chances now. Second, I will continue teaching my evening course in the winter semester.

In all, it’s an exciting time for me, and Monday starts an adventure that will surely be even more so…

Tablets, Laptops, Oranges, and Apples

The generally argumentative Internet has, of late, turned its bickering sights from name-calling about PCs vs Macs (my least favorite argument, since Macs ARE PCs, but I digress) or iPhone vs Android (how is this even a fight? I love Android, but for an end-user, it’s a ridiculous choice still) to an even more apples and oranges comparison. We are currently arguing about whether tablets or laptops are better.

(Spoiler alert: the answer is “if you’re asking this question, you don’t understand computing enough to participate in the discussion that follows,” but it’s plausible I’ve just become cynical in my old age.)

Let me being by saying, I used to carry a laptop, and it was annoying.

If I was going anywhere outside of my home, before I walked out the door I had a decision to make: do I take the laptop or do I leave it behind. This was a non-trivial decision with a lot behind it: do I spend 5 minutes breaking down my system wherever it is set up and throw it into the laptop bag? Am I going to have a place to keep it where I’m going, or is its not-inconsiderable bulk going to be hanging from my shoulder all day? Is it going to sit in my car waiting for a break-in? Am I even liable to use it? Am I going to have time? Is it worth bringing the laptop at all?

In the face of these questions I often chose not to bring it. A flash drive with important programs and a Dropbox full of important files often served as a replacement for lugging 5 to 15 pounds of laptop, bag, peripherals, and accoutrements.

When I did bother to even bring it, I just didn’t bother to use it in most cases. Oftener than not if I wasn’t leaving to go to work, the time and space required was greater than I was willing to invest. After setting up camp, I needed to extract my laptop from my bag (and depending on the state of my power and my plans, my power brick and mouse), power it up (and hope that it suspended reliably last time…a crap-shoot on Windows and Ubuntu), open the files that I am planning to work on, and get to work. If everything went optimally (a rarity that involved a confluence of events including a full battery, a reliably suspended operating system, work spaces already configured for how I was planning on working at the moment, files already opened, the Internet already configured, the sacrifice of a lamb to our dark lord, three cups of coffee, and a partridge in a pear tree), I was out 5 minutes of setup. In the mundane version of events referred to as ‘reality’ I was generally out closer to 10 or 15 minutes and a few ounces of frustration and annoyance.

Compare that to my new work flow. I have doubled the size of my laptop with a ruggedized case and it still fits comfortably in a small bag that I carry with me always1 roughly the size of a smallish purse. No decision needs be made; it is just going with me. If I am going to work, I’ll grab my briefcase too which—even with keyboard, peripherals for presentations, a mouse, and all of the paperwork I might need—is still lighter than my laptop was alone.

If I decide to do some work, I can pull out my tablet and work without even setting down my murse2. If I need to type a LOT, I can do so by pulling out the keyboard too, which still all requires approximately the same amount of space as my laptop. Getting to work is nearly instantaneous. I can go from thinking about what I’d like to work on to actually working on it in under a minute. In a WORST case situations (wherein the things with which I want to work are on the cloud but haven’t been synced to my system, I’m not connected to the Internet, I need both keyboard and mouse, my battery is low, and I have to reboot my tablet), I still am working in under 5 minutes. That is pretty damned handy; so handy, in fact, that I find myself working to fill small breaks in my day far more routinely than ever before with a laptop.

“But Jer,” I hear you saying, “I am a(n) $x!” where $x is some nominal job description that conveys an inherent inability to use tablets. “Tablets are useless to me for my job!” To that I respond with the following:

  1. Depending on what your value of $x was, you might be right. It is also not an airplane, so if your $x was ‘pilot,’ you will find that the tablet will certainly fail to fly us to far away lands. It is also not a large truck, so it will not transport merchandise from warehouse to store. It is not even (despite obvious similarities) a spatula, so it will not help you flip burgers at the place of employment wherein you first learned your rhetorical and debate skills. It happens to be a tablet. It is best used for tablety things.

  2. You also might be surprised about what a tablet can actually help you do. If your concern is that it won’t run the software you need, that is often easily worked around. For example, I am a software developer: it has taken me a trivial amount of time to push my C, C++, or Python development to remote systems that I connect to through SSH and VIM.

    When developing in PHP, Perl, Javascript, or other web languages, I SFTP files to and fro. When developing in .Net or Java, I VNC to my desktop. True, if I were principally a Java or .Net developer, I would probably carry my laptop far more often…VNS is a stopgap, not a real solution. If you are a developer that requires a specific, GUI development environment, you might need to read response #1.

  3. If your big problem is input speed, I have found that with or without a keyboard, inputting isn’t a considerable problem for me. Using Swift Key or Swype, I can generally program at pretty close to my standard speed—most of the time I spend coding is burst typing while thinking…even an on-screen keyboard handles that well. When I am grading papers or corresponding, the on screen keyboard or voice recognition tends to work very well for me.

    When writing long-form (as in blog entries, term papers, etc), the external keyboard becomes necessary. It, unfortunately, slows my 110+ word per minute typing speed considerably: I type at a mere 60-80 WPM on my external keyboard. Amusingly, 60-80 WPM is closer to my long-term sustainable typing rate anyway.

    Often, I have to do finish work on a desktop; this is true whether I began the coding/writing/correspondence/grading on a tablet or a full system. I need editing, that is a given. If you have read this far, you already know that.

    If your needs cannot be served by any of the above, you might need to re-read point number 1

Regardless of how well it works for me, the tablet doesn’t fix everything. It is not a gaming rig…my occasional forays into gaming will not be satisfied without my laptop. It’s also not a power house; if I’m going to really dive into work, I want multiple monitors—each with more real estate than my paltry mobile screen provides. In either of those cases, desktops are ubiquitous enough at this point, though, that I can almost always find one where I’m going to be working if I need to…and I rarely need to.

Are tablets for everybody? No, don’t be stupid. Neither are shoes, cars, glasses, or pine nuts. Are they sufficient for most people? I’ve found that to be true (of tablets…but also of shoes, cars, glasses, and pine nuts). Most people’s needs can be boiled down to consumption, correspondence, and creation—in descending order…on a STEEP curve. A tablet works well if your needs fall into that pattern; hell, it could work if your needs do not, but can be made to emulate that pattern. If your creation, however, is of a sort that does not lend itself well to low-power, low-end devices (media creation, .Net programming, etc), then you might want to give tablets a miss for a while.

All I know is that the power supply on my laptop fried half a year ago, and I still haven’t bothered to get it repaired. I’ve missed having the laptop about twice since the beginning of the summer. I should probably get on that. Your mileage, as they say, may vary (but what they don’t tell you is…that’s because you’re doing it wrong!)

1 A side benefit of carrying a tablet, I now carry a purse…women have this SO DAMNED RIGHT. I don’t know how I survived without it in the past. I now have pens, sharpies, membership cards, headphones, etc with me at all times

2 M(an) (p)urse. Also referred to as “manbag”, “why I’m not masculine”, and “chuck”