Start With a Soldering Iron

Close followers of TheHackerCIO will know that he's in major retooling mode. Fresh back from Karate in Japan, he's retooling not only his Kata, but his technology. He's donned the white belt for a fresh look at tech from hardware up.

From the basics. The fundamentals.

It was increasingly clear from last year that I needed to get hardware back in my life.  Sitting in our CIO and CTO offices, listening to our classical music leaves us far too detached. We need to get physical, physical. We need to get to the hardware. At the AT&T Hackathon several months ago, the hardware hackers impressed and inspired me with the "wearables" they concocted.  And now, it's easier than ever to get involved with Rasberry Pi -- whatever your age -- and do some interesting hardware/software projects that interact with the environment in interesting ways.

I wish I still had the URL to an essay I read years ago about how to become a "guru" at programming language X. [I no longer remember the exact question, or language, and Google hasn't helped source it]

The advice given, I'll never forget:

1. Start with a soldering iron ...
2. move on to mastering operating systems ...
3. now learn networking ...
4. and assembler ...
5. Start working up the High Level Language Stack. A lot of optionality here. Perhaps:
    C
    Java [forget C++]
    Python
    Lisp

Which short-list gives us a good basis in procedural, and then functional languages. Maybe throw in Prolog for a declarative language.

There are other considerations, of course, but this makes a good overall syllabus. And it's more or less the program I'm embarking on for the next good while.

Bought an Asus laptop as working fodder for the review: I'll start by picking up the new-to-me windows 8 touch-screen nomenclature and interface, then re-partition it to become a dual-boot ArchLinux and Windows box.

I already learned that, unsurprisingly, as CDs and DVDs are increasingly scare on laptops, recovery disks in Windows are now just USB sticks. And, they only take 512M, which easily fit on the 7G stick someone was nice enough to give me at the SCALE 12 conference last month. All of this is good to know, and once again, helps keep everything real.

Keeping It Real,

TheHackerCIO

Swag and Sewing Machines

Pictured above is only a tiny sampling of the thousands of dollars worth of Swag: induction mats for telephones, headphones, brain-wave sensors, smart-watches, and all kinds of other sensors and cool gadgets had to be given away to the developers at the AT&T Developer Summit Hackathon.

It's a tough job, but someone has to do it.

TheHackerCIO is willing ....

But it's amazingly tiring: we spent nearly three hours listening to "lightening talks" and pre-qualifying them for the hardware give-aways. The contestants had to "show connection", as the lawyers call it, between what they were developing and the hardware. It wasn't enough to say, "I'm kind of developing something that sort of helps out in some nebulous, undefined way." When we got those, we had to turn the contestants away.

They need to firm up their concept. The Swag is there to support the development effort. Anything left over, would be given away, of course. And some judges were easier going than others. TheHackerCIO was pretty easy. There was another pre-qualifier who was a real bad-ass.

This Hackathon is centered around wearable technology. Sometimes you have to see this kind of thing to catch the vision. Or at least it's much easier. It always seemed toy-like to me, before. But now, I'm starting to get it.

At first, I was startled to see this machine at a Hackathon:

But if you're doing wearable technology, it makes perfect sense.

I Remain,

TheHackerCIO

Put "Hackathon" on your New Year's Resolutions!

You can hardly expect TheHackerCIO to restrain himself from plugging Hackathons. So I'm going to take the advent of a new year as an opportunity to re-shout the truth:

If you work around technology (or want to), 

You need to go to a Hackathon this year!

Do it! Plan for it Now!

Maybe a couple. Or more.

I've been increasingly impressed with what I've learned from Hackathons.

The biggest and most unsettling thing I've learned from Hackathons in 2013 is that there are a whole new slew of agile techniques and frameworks out there that allow an order of magnitude faster development speed for production of an MVP.  In comparing the 2013 competition to the prior years event, development velocity was stunning.

In one particularly telling example, a contender failed to attract a developer after his initial presentation on Friday evening at 6pm. On Saturday afternoon, at a time when I would have told him he might as well join up with another team or go home, he pivoted to a completely new idea, attracted a co-developer, and they not only completed their demo-quality MVP.

They won second place.

Now that would have been utterly unthinkable the year before. In 2012, I remember the CloudHero team valiantly struggled, hoping to add one last feature prior to the final presentation.  As they worked, I stood outside the door, ready to signal them the moment they were on. Inside, a dedicated team member stood poised to hit the enter key, thus issuing the VCS command that would wipe out any work and leave them at the last stable demo. This had been a 48-hour effort.

In 2013, many teams had a near-demo quality version of their MVP up the first night before they went home! Now it's increasingly more common to see 1 day hack-nights. The whole pace of code development is now able to be performed more rapidly. This kind of environment is really important for Startups to know, and consequently for CTOs to be aware of. But you can't really know this if you don't have your finger on the pulse of the development world. Just taking my own example, as good as I am, I would have wrongly advised that 2nd place contestant!

TheHackerCIO uses this as a technique for keeping current with rapid and agile trends. It makes him better at technology recommendations to early stage Startups. It helps him to know what new technologies, frameworks, and packages should be put onto the list for play during the year and eventually, hopefully, to master.

It helps focus the mind of the technologist on every aspect of the startup experience. And it's not just for developers. I could write volumes about this, and no doubt I will post quite a bit more about it this year!

But for now, resolve to do a Hackathon this year. I beg you. For your own sake. So you don't become irrelevant. Maybe I'll start The Great Hackathon Challenge, to encourage everyone to do a Hackathon.

Hackathons weigh heavily on TheHackerCIO's mind right now, because he is about to go to the AT&T Developer's Summit Hackathon. It's this weekend, in Las Vegas. You should at least spend some time reading about it. All the winners from the AT&T Hackathons are invited to the big event at  the beginning of the year, to compete for the final prize. I'll be a judge at this Hackathon, but I'm hoping to give mini-presentations and advice to the contenders, to help them maximize their chances and do the best they can! I'm an inveterate Sensei! And, I can't even apologize about that. I love to teach and help. I love to see success and improvement. I'm selfish that way. But judging should be a new, fresh perspective. I'll provide more details after I get up there in Vegas, since once more, I have to hit the road ...

I Remain,

TheHackerCIO

Everyone a Hacker

TheHackerCIO has been too busy, so he missed out announcing this on Monday.

This week is Computer Science Education Week. As part of it, everyone -- are you listening, recruiters, marketers, and business development specialists? --  is encouraged to spend an hour learning to code.   Details about the Computer Science Education Week are here.

And the actual video lesson for the "Hour of Code" is here, courtesy of Khan Academy.

And with Everyone a Hacker,

I Remain,

TheHackerCIO

No One Get's Out Of Here Without Hacking!

No child of mine will leave my house without having learned the gentle art of Hacking! Started just this week with my 15 year old daughter. I got her a copy of the Head First Programming. By the way, this series cannot possibly be over-hyped. It is far and away the best series of technical books there is, and I buy anything they produce, because the read is fun! I even got Head First Algebra and Statistics!

The book is a gentle intro to Python for newbies. I'm far from being a Pythonista, as everyone here already knows. TheHackerCIO hacks Java. And a little Clojure. But Python seems cool. Might be even better than Java. I find my heart strangely warmed by philosophies such as "One right way to do anything." I'm a little unsure about the meaningful whitespace, but I definitely want to learn a bit more Python.

And what better way than to do so with your loved-ones? That way you can share the Joy of Hacking with the whole Family. Coding is a life-skill. You can construct cool programs for the rest of your life to make your life better and further your values.

So, chapter 1 it is. I'm sure further reports may hit my blogosphere! The Family that Hacks together, Stays together. Strengthen Your own family: get them hacking!

I Am

TheHackerCIO

Why the CIO Must Also Be a Hacker

I was shocked at a gathering of CTOs this year. In discussions about coding, I was the only one who still did so! I was visibly shocked and verbally unguarded about it, and it didn't go over to well with the gathering.

I asked them how they could stand not to code. They replied that there wasn't time to remain coding. I asked them how they could avoid making the time. They claimed that other pressing matters simply made it impossible.

One added that it had been five years since he last coded.

In that moment, TheHackerCIO was born!

Not physically born. That was many years ago. Not even born as a Hacker or coder or developer, for he was all of these thing from many years ago. But born in the sense that this moment crystalized a principle very fundamental to his approach, personality and career which is best encapsulated in the persona of TheHackerCIO.

It's also part of his boutique consulting firm DNA: Codojo; where the model is that of a "coding Dojo" approach, where people collaboratively work together learning, practicing, perfecting skills.  A Dojo, of course, is a "place where you learn the way," and in such a Karate studio, a decent Grandmaster will tell you that "basics," are of critical importance. You start off learning them. You perfect them. And you never stop. Never. Ever. No Karate master ever stops working on his basics.

Neither must a technologist ever allow himself to be drawn away from the basics. He must remain a Hacker even while he learns the skills necessary to achieve CTO or CIO status. To be a decent CTO or CIO you must be a HackerCIO.

If you stop Hacking, from that moment forward your career is already dying. It's just a question of time before you are completely irrelevant.

And so it is for this reason that I Remain Faithfully and Forever ...


TheHackerCIO

Next in the series

Creating Tomorrow's Legacy Code Today

"Creating Tomorrow's Legacy Code Today" was the humorous motto of a group I worked with at a major financial institution, Feral Hangman. 

• Yes, the name of this client has been changed to protect the guilty.
• No, this was not official
• Yes, there was a high Dilbert Index at this client

A Dilbert Index is a way of determining the level of pathology found in a company. The higher the number of posted Dilbert cartoons, the greater the likelihood that this is an unheard message to the management. Or a protest.

The point is that code becomes a legacy the moment it's written. But why is this so? And how can it be mitigated?

Michael Feathers introduced a novel definition of legacy code as "code without tests," in his Working Effectively with Legacy Code. But inheriting a large code base in a strange language without any author to consult is still scary, even if it is accompanied by a regression test suite. Here's a thought experiment. This same financial institution (see above) found a portion of crucial code in production which was written in assembler, somewhere between 3 and 5 decades ago. There was no source code. Would this have been eliminated as a problem if only a test suite had been available?

The problem with code is that it is an enormously mental activity. My copy of Coders at Work is loaned out, so I can't quote the source, but one of the interviewees claimed that what made a top coder was the ability to hold the entire program in ones' head at one time. This is a huge achievement. And it's difficult. One phone-call can destroy it.

But the further problem is that when you do have this Wondrous Vision everything is crystal clear about how your program works and why you did it in this particular way and how all the tricks, tactics, and techniques fit together to do it elegantly.

But this vision is a perishable good!

And, therein lies the rub. When the vision is present, it is beyond pointless to write it down. Plus, you're under delivery pressure and documentation/explanation is not the primary deliverable.  But the vision decays: geometrically. Inexorably. Heck, we said before that a mere phone call can destroy it! But time eventually kills it entirely and all those explanations that were so clear become murky, unclear.

Almost every programmer has experienced this. You go into some code you wrote last year and wonder, "why did I do that in that way?" And this may take quite some time to resolve.

This blog is too long already, so discussing possible mitigations will have to await the future. In the meantime, ...

I Remain,

TheHackerCIO

Error is a Problem

Today, TheHackerCIO is back to hacking. And he's ticked off. With all the improvements to coding languages; with all the frameworks dedicated to improving productivity and accelerating development by shortening the build-cycle, why, oh why haven't error messages improved any over the last 30 years. You still get presented with merely a cryptic message when you offend the parser. Let this posting be a manifesto for improving programmer productivity! Let's build a language/environment where the abstract message is tied to the actual concretes that produced the error. Let's see, side by side the elements of the parse tree that are no good, and the line numbers where these are involved. if there were some recourse to the actual originating and intermediate steps that led to the error it would be a serious advance over the standard operating procedure of pasting the error into Google along with "Stackoverflow" as search term.

I Remain and hope to Remain for some time Hacking, As ...

TheHackerCIO

All Work and No Play Makes Jack a dull Hacker

Play is contagious. But that's not a problem, when the play is a Framework.

http://www.playframework.com/

Play works in both Scala and Java, but you have to be very careful to pick which one you want correctly without mixing/matching, or you'll get into errors. Monday, TheTechnology-Radar-Group had a presentation from Alexandros Bantis on Play with Scala.

Tuesday night, our local Java User's Group got another presentation from Alexandros on  Play with Java.

One question surfaced, which is still being discussed: Given that Grails can easily produce a CRUD application, using Active Record as in Ruby/Rails, is this time-saving capability available in Play, or are they orthogonal approaches? Stay tuned for details!

Two Play sessions, in succession! What a fun month for the Hacker side of ...

the one who remains faithfully,

TheHackerCIO

Coding Play Makes it Fun

Coding is always fun and sometimes play. But "Play" is also a framework. It's a fun framework, so Alexandros Bantis demonstrated at last nights Technology Radar Group Meetup.  His hands-on tutorial on the Play Framework and it's Akka messaging infrastructure, was delivered as a GitHub Repo of code demonstrating the use of Play both in Java and Scala.

Theoretical points of interest were how "Actors," "Futures," and "Promises" make life easier for the developer.  The Actors are implemented by a messaging infrastructure -- I gather that this is built into Play, via the Akka package, which is incorporated into Play. Play is a bundle of lots of cool technology into a bundled rapid-development stack. I particularly liked the way Play uses Websockets to monitor the code and incrementally compile it as needed, so that the hacker doesn't need to reboot a server (as with Tomcat, in the bad old days) in order to see his new code changes at work. Just a refresh of the browser and you can see what you have done -- whether it be good, or ill .... :-) In the modern code development world, jRebel is getting built in out of the box!!! And that's a good thing.

Another extremely cool point was how in Play even your HTML get's bound up with Static typecasting. So you can catch all the nasty errors up front even though you're developing client-side display. I'm not quite sure how it works in Java, but in Scala the type of the parameters to be passed seems be combined into a function. And if you pass a faulty type as an argument, low and behold, the browser reveals your type-error.

Finally, the evening was rounded out by a presentation of TechStacker by Rick Parker. A Heroku hosted tool written by a friend, this handy little site is a first stab at creating a crowd-sourced tool for the evaluation of software products. Rick is already using it to do his own evaluations, which are part of his day-job, and I'm certainly going to start putting in materials and experimenting with how Social Networks can be part of software evaluation. I might even go do the Play framework as my first eval on TechStacker! If you want to join in on this, please join in and sign up at http://tech-stacker-staging.herokuapp.com/dashboard

By the way, please don't complain to me about the TechStacker UI. Rick admitted that it's the worst imaginable. But hey, we'er geeks. We'd rather have a command line anyway, right? Who needs GUI?

Thanks to everyone for making the evening enjoyable as well as enlightening.

I remain faithfully,

TheHackerCIO