College

Everybody seems to be nodding their heads these days about the degrading importance of college (myself included). This is in contrast to a some important facts: foremost, that the latest recession hit lower educated workers hard while barely touching those with degrees, especially advanced ones

I don’t doubt that it’s getting harder for college graduates to find careers. Part of this is that poor retirement strategies and a ten-year long bum market are forcing people to work longer. And of course, people love to blame the ineffectiveness of a liberal arts education.

A classic joke goes like this: “Oh, you’re studying philosophy. Maybe, someday, you’ll get a job with one of the big philosophy firms!”

It’s a good joke. I can judge this, because as a rhetorical theory major (okay technically the major was “English Literature and Rhetoric”) you spend a lot of time analyzing texts and concentrating on the soundness of arguments and the efficacy of communication as both a medium for transfer of information and of intent.

In essence, I have a bachelor’s in joke assessment. And I’ve a 15 year career in commercial software development.

Now, I wasn’t just a lit major. I spent four years of my college career working in the computer labs as a student consultant; helping other students understand how to use software programs, debug code assignments and venture into the nascent internet. I took, pretty much every semester, science and mathematics courses. Originally, my design was to switch into the Watson engineering school at Binghamton University.

That is, until I’d taken a few courses there. Consider: it was 1999, and the internet was a powderkeg. Java was storming the castle, making OS and processor architecture obsolete. Relational databases were all the rage; the LAMP stack was busy being born. Amid this, the Watson school taught one class each on “systems,” databases and web design. Nothing on DHTML. And to get there, you need DiffEQ, Multivariable Calc, logic design, x86 assembler, algorithms, physics 1 and 2…

Now, I agree a student should be well rounded. But here we’ve got a curriculum a decade behind the times, instructing students in the basics of specializations they’ll need a PhD to make a dent in and that they’ll otherwise never use.

So I didn’t bother. I parlayed my consulting experience into a little summer job, slacking off and building websites for $15 an hour. A king’s ransom at 21. In three months time, I knew as much about the realities of software development as a CompSci grad student, and four languages they didn’t even teach at school (Java, JavaScript, T-SQL and ColdFusion). Plus I was $7000 richer.

I stuck with my Rhetoric program because it was fun. I didn’t excel at it, metrically; my most important semester I averaged a C-. But I got so much value out of those classes! It was in a rhetoric class where I first learned how to read an audience; in others how to debate with courage something only partially understood and in still another how to accept criticism graciously. I learned that a group can be a curse, that personal excellence matters little if the others choose to brand you as a screw up. I learned how to read texts, quickly, and how to react critically to them. I learned how to inform, how to persuade, and how to avoid being persuaded. I learned what to say, and how not to say it. When to leave my personal beliefs at the door and when to push them to comical extremes.

In short, I learned people: how to communicate with them, and to them, depending on the need.

Anybody who’s advanced beyond the ranks of Junior Software Birdman understands software turns out to be less about Big O notation and proving NP completeness, and almost entirely about communication. Making sure requirements are correct and estimates appropriately aggressive, convincing PMs to push back on customers, making cases for the time to Do Things Right and understanding the unstated requirements being placed upon you. And always reading, reading, reading! Books, tweets, specs, blog posts, white papers, slide decks, code itself and, occasionally, TFM.

The Cardboard Architect (#3 in a series)

Photo Apr 01, 3 34 00 PM

Oh hell he’s got that crazy look in his eye again.

Part of this job is learning how to think like a computer. Or worse, like a stack of computers, communicating with each other faster than you can possibly comprehend on a variety of channels and protocols, each with its own quirks. You need to be able to place yourself, mentally, in a stream of data as it’s being processed and understand the interactions taking place. Minor details can cause big changes in interactivity.

At the same time, you need to be able to model users, model your coworkers, anticipate their usage patterns, desires, constraints. You need to understand these touchpoints, because they’re how the quirks get introduced in the first place.

I recently had a system break down because somebody put the wrong kind of slash in an <img /> tag seven years ago. He used IE and it worked. Our test engine uses Firefox and it didn’t — but the img was a spacer, being used for an onload hook that performed a no-op. So the fact that Firefox couldn’t render the image, and thus didn’t fire the event, was never picked up. (Blah blah unit test your javascript, I know I know.)

Anyhow. We accidentally fixed the image problem with a system upgrade, which immediately caused 45 tests to fail. Because over the years, lots of devs had copied and pasted the broken code. And, assuming it worked, lots of operations had been inserted into that hook. When they didn’t fire, some people just left them in there as they thrashed about trying to hack the system into a working state.

This made no sense whatsoever. Here we’ve got two systems with identical HTML, one is all kinds of broken, the other works fine. It made no sense that this would be possible. I pulled half the office over to my desk to illustrate this and people agreed. It wasn’t possible, but it was happening.

When I figured out the answer — an upgrade of a gateway was causing the incorrect slash to flip and identify a resource, firing a glut of unwanted javascript with that newly enabled onload hook — I was nowhere near a computer. I was driving my car, exploring the problem through thought experiments. I was so excited I had to pull over and email everybody involved.

Cop shows have a trope about thinking like a criminal to catch a criminal. Sometimes, in this job, you have to think like a poorly programmed system to fix that system. It can make you crazy. It can make you giddy. And damn it feels good to figure these things out.

Dumbo’s Feather

Is your new tech successful because it's great, or because it's new?

Is your new tech successful because it’s great, or because it’s new?

In technology education, or what passes for it in today’s world of blog-tweets and youtube sync’d slide decks, signal-to-noise ratio is only part of the problem. The larger problem is signal degradation. Today’s hot technology, the one that’s doubling productivities around the world, is tomorrow’s dead dog rotting in a gutter, and the pace seems to be quickening. And whither the legacy codebase?

Every dead technology started the same way: somebody had a problem and they fixed it. Pleased with themselves, they told somebody else. Eventually, an evangelist heard about it, and they told everybody who would listen. Developers heard; most ignored it but the truly curious ones tried it out. Some of them agreed — this is the hot new thing. They applied it to a project, the project worked, and suddenly the hot new thing is making IPO millionaires out of guys writing LinkedIn articles about their cuture wearing sketchier beards than mine.

Then out of nowhere, our new technology isn’t new anymore. It’s missing X or too full of Y, doesn’t scale, isn’t elegant. Suddenly this once great technology is a doorstop, and anybody gauche enough to program with it is an industry pariah, delegated to cleaning up messes in the machines that made other people rich.

I wonder how many technologies have their reputations built on what I call the Dumbo’s Feather effect. You remember the story of Dumbo — baby elephant discovers, by virtue of waking up on a telephone wire, that he might be able to fly. But he has no faith in himself; after all, the idea is preposterous. Until, that is, he acquires a “magic” feather —  a placebo totem that gives him the confidence to grow from doubter to pachyderm Icarus.

Developers, like all skilled professionals, naturally mature. As their skills increase, their productivity improves. But this doesn’t protect them from failure. It’s inevitable — you can’t program without making assumptions, and some of them are going to be wrong. Not to mention the other inevitabilities of software, like flip-flopping customers, pushy bosses, shoddy analyses, short schedules. And in the digital space, where only the developers know what’s going on, obviously it’s their fault.

A developer can’t help blaming themselves for software failures, even if nobody else does, and even if it’s not their fault. A sensitive dev remembers every great idea scrapped, every beautiful implementation sullied by haste and hack and every production failure in a class with their @author tag. If only they’d been precognitive, clairvoyant and had infinite productivity!

And for many, this feeling of failure compounds; it begins to weigh heavy. It makes the developer risk averse, sometimes to the point of being afraid to do anything bold. And that’s a problem. A developer without confidence is supremely unproductive, refusing to make any assumptions, and turning every decision point into a meeting.

Then new technology comes around. And hey — says in this one blog post that it’s specifically designed to fix the problem the developer’s been dwelling on all this time. So he checks the documentation — say, hello world looks easy! He types it up, compiles after only a few tries! He stays up all night trying different permutations. He posts in the forums, reads everything he can, visits a conference, and is most careful not to repeat the mistakes he made on that OLD technology.

And when that first big project on the new technology hits production — a rocky release, to be sure, but who cares about that, it actually worked — it becomes the star. The elephant flew, and it was the feather what done it.

Confidence. It’s essential to every stack. Even a battle hardened skeptic like me needs it, sometimes, and the allure of a new technology brings with it an awful lot of confidence building. Sometimes, it’s even enough to overcome the interruptions, the missteps and other inherent risks in adopting it. The rest of the time — hack it, patch it, decay sets in, and it’s on to the next new tech.

The Cardboard Architect (#2 in a series)

Image

Photo Apr 01, 3 34 00 PM

The architect has just discovered an unexpected change to an integral design you did not discuss with him and will now require six weeks of work to repair.

Keep in mind: these are all real expressions, captured just moments after the event described. In this case, two competing implementations of functionality were produced to handle two distinct and only accidentally related business cases. The original goal was for the more flexible set, which mirrors other configuration in the system and can be deployed in real-time, to become the standard and for a basic set implemented in compiled Java classes to be replaced. Once the pair had run concurrently in production for long enough, it would clear the need for the second business case, so it didn’t matter that it wasn’t flexible. However, I was shocked to discover developers pursuing customer on-boarding automation had replaced all the carefully constructed logic in the flexible configuration files — with hard links to the java classes!

Through the benefit of hindsight and about 3 fingers of Albany Distilling Company’s Coal Yard Rye, I realized why this had happened: the java configuration, by virtue of a simple set of static requirements, had a really straightforward API and beautiful, self documenting implementations. The flexible configuration, which reused a complex, non-intuitive DSL and implementation from an earlier project, looked a mess. And while the automaton didn’t care about the legibility of its output, the clean and concise java classes had much higher appeal to its developer.

It’s flattering, really. When it isn’t maddening. And hey, maybe we’ll buy back those six weeks with the tool!

The Cardboard Architect (#1 in a Series)

Image

Photo Feb 22, 1 51 57 PM

The architect is not impressed by your proposed solution, and is trying not to downgrade his assessment of your skill level.

The “cardboard architect” is an exercise wherein you present an idea out loud to an inanimate object and in the telling are both practicing and honing the argument. It is, frankly, a silly idea that nobody practices more than once or twice, sheepishly. However, as I am generally known for wearing my design opinions on my sleeve, not to mention all over my face, I thought it’d be fun to put together a set of stock facial expressions for common software scenarios that might be encountered in an actual design review.

Collect ’em all!

How to learn how to program

20130324-012425.jpg

First of all: don’t be scared! You can’t break a computer by trying to program it. Oh sure, it’s possible to break a computer…but not for YOU as a beginner. And who cares anyway? The computer was made to serve you, somebody plunked down good money for it to do so, and if it isn’t serving you right, then it’s already broken. Programming should always be seen as a way forward, and any frustrations or missteps along the way merely part of the journey. You will break programs, and then you will fix them, better than before.

Programming is like writing: you need to have an idea and an intended audience before you can get started in earnest. This will help identify the platform and the language you will be writing in. There is no such thing as a “best language” — every computer language is a set of trade-offs distinct from other languages with different trade-offs — but there are better platforms and languages for specific tasks.

What’s a platform? Well, that’s the environment in which your program is going to run. It’s usually a program itself, such as an operating system, a device, a server, a virtual machine or a web browser. Programs written for one platform might not be portable to another and each has its own input and output restrictions, so it’s a pretty important choice. An easy way to start might be to write a program that lives in a web browser, or one that is interpreted by your computer’s operating system on the command line.

Which language should you learn? Well, it doesn’t matter all that much – all languages are very similar if you don’t know anything, and if you do any programming of real merit you’ll probably learn a dozen or more in your lifetime. A journeyman programmer should be able to pick up a new language and be productive in it in a couple of days, though mastery takes years. But you’re going to want to pick a language that works with your target platform, one that a lot of people know about, and preferably one whose platforms and tools don’t cost much. There are toy languages, like Logo, and academic languages like Eiffel. They’re fine for learning specific techniques, but there is no reason not to get started immediately in a language like JavaScript (for the browser), Powershell or perl (for the command line) or Java (for lots of things). These are low barrier to entry languages with free platforms and lots of great free tools and you can get seriously paid working with them.

What about academics? Well, math is pretty important, specifically algebra. Most computer languages owe their lineage to algebraic equations, and you will be building lots of them. Higher math, like trigonometry or calculus, is exceedingly important for some very rare programming tasks but for basic programming, algebra is it. I wrote my first program in second or third grade, so if you’re at least as smart as a sixth grader you’ll do fine. English is fairly important, as many programming languages use English commands in their grammar and many programmers use English in their variable names.

Some understanding of how computers function at a physical level can help you understand what’s going on, but you could get this from a book, like How the Internet Works. At the most basic level, though, you’ll need to know the following things about computers:

  • What a file is and how to manage files using your operating system.
  • How to open programs, use their menus and switch between them
  • How to copy and paste and other editorial functions.
  • How to undo mistakes

To get you moving in your language of choice, you’re going to want a guide. For the languages above there are excellent online resources, so you can just start Googling or Binging until you find one you like. You can also pay to be taught the language, either at a school or at a technical training company like New Horizons. Your best bet, however, would be to buy or borrow a book. Try to get a thin one that makes sense to you — no two readers are the same and that’s why there are so many tech books on the same subject. The Head First series from O’Reilley press are great examples of books that are like nothing else, attempting to teach the same subject using multiple techniques at the same time. Personally I find them insane.

So. Armed with courage, a platform and language choice, a guide, some basic academic skills and an idea, you’re ready to start learning programming. Here’s how you do it:

Program!

Write the examples from the book, then change them to do something else. Notice how each change to the program or to the input changes the output. Notice how the system complains or fails when you do something wrong. Figure out how to fix it — now you’re debugging! See something you don’t understand, a message or a command? Google it. Ask a friend. See if you can change the program around to make a different message. Try removing the command, see if thins don’t get worse!

Install some tools to help you program better. Read more books. Look at other languages and translate your knowledge. Learn some task specific languages like SQL or R. Read some blogs. Read Code Complete, the Pragmatic Programmer, Clean Code, Effective Java. Become a software developer, a software engineer, a software craftsman, a software designer, a software architect, a software artist. Read more books! Go to a “No Fluff Just Stuff” convention. Go to a user’s group.

Programming is easy! Learning to program is easy! And pretty much everybody can do it.

Software, on the other hand, is hard.