Who should learn to code? Everyone.

I believe that everyone deserves the chance to learn how to code, if that’s what they want. And maybe that desire for equality’s based in my nerdly values, but it’s something that’s important. I’ve been supporting Girls Who Code for some time now, and they do real good work closing the gender gap in the tech and engineering sectors. Women in tech is an effort I’ve been supporting pretty frequently.

Speaking of coding, a coupla weeks ago Tim Heaton, who’s involved in Morristown community service, sent me an email about what’s going on with tech in Morristown, NJ. Tim’s email inspired me to ask  him to write a blog post for craigconnects…

Who should learn to code? Everyone.

Bill Gates :“Everyone in this country should learn to program a computer.”

Cube jockey: “The Everyone Should Learn to Program” movement is wrong because it falsely equates programming with essential skills like reading, writing, and math. In my 30- year programming career…… ”

Thirty years?

Thirty years ago there was one phone company. Michael Jordan was a freshman at NC. President Ronald Reagan made GPS available for civilian use. The McNugget was born. And the Apple IIe was introduced — one of its amazing features was that it could display lower- and upper-case letters!

Thirty years ago it was really difficult to learn a computer language. Running a program often meant getting up in the middle of the night for your allotted run time. Programs were boxes of punch cards. Machines talking to machines was sci-fi. A phone was something shared with neighbors. To this day a computer to my dad (an ex-IBM programmer) is a room-sized monster, nothing else qualifies. A PC is just a typewriter. A mobile phone is just a phone.

Career programmers don’t think just anyone can do it.

They will tell you that you need 10 years of coding experience to know enough to be “worthy.” And this was certainly true 30 years ago. Then it took a whole day to run a program, now it happens every time you turn on your phone. Most importantly, the open source community and free online learning sites is a true paradigm shift that has broken down the knowledge barrier.

In medieval times, the Guilds were founded to stifle competition by restricting knowledge. Today it is the same. Fortifying this false barrier in technology is the notion that jobs requiring even minimal skill need certification (with apologies to some of my favorite professions): Bar-Tending, Physical Trainer, Project Management or Database Administrator. The Guilds during the Middle Ages protected their members for the same reason as today’s: Job security. However, developing your ideas into a product doesn’t mean being chained in a cubicle for 10 years or lugging around a stack of cards in the middle of the night. Coding is no longer difficult. The open source movement has seen to that.

To the modern programming Guilds, I agree that it takes years to understand what others have written in the millions of lines of enterprise code. I’m not suggesting that everyone should be a programmer anymore than I would suggest that anyone could be a concert pianist. The difference is that developing useful applications with code is much, much easier than learning to play the piano.

So, if anyone could code, why is learning to code important?handel

Because being creative is not enough in today’s workplace. To be successful you must be able execute your ideas. And you have a far better idea of what is useful than the tradition-bound, 30-year career programmer – or some dude in Chennai for that matter .

A modern analogy may be found in music. Is the artist Pitbull a musician? If we could ask Friedrich Handel’s opinion – maybe not, and if we could shoot him back to Handel’s time – definitely not. Today however, Pitbull is a multi-platinum artist. Same thing with technology. One doesn’t need to be a computer prodigy to be a successful technologist, one needs to know how the technology works well enough to write a song or build an mobile application.

A note to Handel: I don’t think much of Pitbull’s music either.

It’s more important to understand the market and communicate with people, in both music and technology, than to write beautiful composition or code. Most of the successful people in technology are not great coders, but they understand enough to execute their ideas. To the career programmers – the cubicles are yours. To the executors of ideas – the world is ours.

Rosetta Stone or Code.org? – One final note.

The most amazing thing about computer languages is that, like music, they are universal. Whatever I create in computer code is understood by everyone else in the world, immediately and simultaneously. Multilingual education forgot to include the universal language: Computer languages.

Who should learn to code? Everyone who has a problem that needs solving.

Teach yourself and join the effort to teach kids how to solve problems: Code.org

 

Guest Blog Post by Tim Heaton

heaton

Big Idea 2014: How to Fix Washington’s Approach to Tech

Much of the business of Washington is based on getting info around, much of the good news has not been reported, and I’d like to get the word out to make things better. This is the short, oversimplified version, based on 37 years of direct observation in both private and public sectors.

This is mostly about doing software based on actually listening to people and then acting on feedback, with a focus on the “ground truth” and what we can learn from that.

I think it was 1969 when some guys at Bell Labs started inventing something called Unix. It was a simple, very effective operating system, which could be ported to most any computer, since the source code could be checked out by outsiders, then adapted. It was in the spirit of what we now call “open source,” but the code was AT&T proprietary, limiting its use. Key to its effectiveness was that it was built in modest increments, by people who’d use it, both at Bell Labs and at the universities and labs who built Internet tech.

Note those elements: Built with real humility, talking to people, piece by piece.

Back then, software was most often developed starting with requirements or specifications docs. These were written by managers or people in marketing, the popular kids, who didn’t so much as talk to the people who’d run the software.

Once the docs were written, they tossed it to the people who’d write the code.

If the software actually got developed, it would frequently be late, over budget, and sometimes bought by no one except people who had to. (That’s like a lot of Federal software projects.)

In Washington, this is called the “waterfall” approach, since the docs are kind of tossed over some barrier which limits the ability of coders to talk to people, and which meant the software was frequently built as a big, complex monolith.

gov
I saw this approach used to develop the first operating system for the IBM Series/1 minicomputer, great hardware, in the late seventies. Whenever I asked why the software was so hard to use, I was explicitly told by the developers that usability wasn’t a requirement. (I’m not making this up.)

Bell Labs asked us about porting Unix to the S/1, and my recommendation is that we could do better, but why fix what’s not broken?

Turns out that a modest, maverick effort at IBM Research resulted in S/1 Event Driven Executive, which I feel was much better than the official product. For the matter, two versions of Unix were built for the S/1, both too late.Otherwise, the history of the whole industry could be different.

Years later, Linus Torvalds figured that Unix was pretty good but too proprietary, so he started building what’s now called Linux. It’s pretty much a Unix clone, but it’s open source in the sense that anyone can build stuff on it.

(Special props to Linus, who initiated this global, grassroots effort. Linus, like Jimmy Wales and Craig Newmark, is not an Internet Billionaire.)

That worked in a really big way, and much of the world runs on Linux, not only servers but our phones. Specifically, the Android operating system is a tight version of Linux, and it runs on hundreds of millions of phones. Even though developed in a large corporate environment, Google, it’s a pretty modest effort, based on what people need, rather than the imagination of the popular kids.

For the most part, government software is done using the waterfall approach, in isolation from the people who’d use it, even as much of private industry has moved on. However, there have been efforts which go against that grain.

Long ago, clinicians at the Department of Veterans Affairs realized they needed a really good health records system. Without permission, they built something called VistA, built by the people who use it, ground up. It’s perhaps one of the largest, and most effective health records systems around. No waterfall requirements, just a very modest approach.

Now, Veterans Affairs got the Veterans Benefits Management System, VBMS, just in recent months. It hasn’t been reported, but the piles of paper you see at VA offices has been disappearing dramatically after they were scanned in. Vets’ claims are just starting to get processed this way, and it looks good so far. We need to get Vets Service Orgs like the American Legion, Vets of Foreign Wars, and Disabled American Vets directly involved, via the Stakeholder Enterprise Portal, or vendor software via Digits to Digits.

VBMS development involved a lot of waterfall stuff, but much more recently, VA people are actually directly listening to people on that and acting on that. If vets, VSOs, or VA workers find a problem or have a suggestion, they contact contact actual humans to get stuff done.

Terminology: the antithesis of the waterfall approach is usually called “agile software development.” I’m not very smart, and the version of it that I’ve practiced is this:

repeat forever:

  • listen to people
  • do stuff based on that

Please permit me to call that “agile”; seriously, I’m kinda simple-minded, that works for me.

(Seriously, people can contact for specifics. I’ll act in my capacity as the official VA “nerd-in-residence”, hold me to that. Email craig@craigslist.org)

So, here’s the deal:

  • small, modest efforts by programmers get stuff done, they can ask for forgiveness later.
  • listen to the people who use the system.
  • even systems started by the waterfall approach can become much more agile, with commitment from the boss.
  • open source approaches get stuff done, often a lot better than proprietary approaches. Can cost less, get done faster, possibly more reliable and secure.

Programmers who get stuff done this way, well, we’re nerds. The alternative to the Federal government’s waterfall approach to software development? Get the popular kids, for the most part, out of the way, and let the nerds get stuff done.

Photo: AFP/Getty Images

Blog at WordPress.com.

Up ↑