Why I Taught Java

When I taught my first programming class this past year, I decided to teach the class in Java. My co-workers at the time gave me a bit of flack for this. I should be teaching Go or Python or something with a little better reputation.

Java was looked at as the C++ killer as I remember when it first came out. It go overhyped, is the bane of everyone’s desktop with near daily updates it seems, and it isn’t the prettiest language compared to more minimal programming styles.

So why bother teaching it? Particularly if it is semantically dense or harder to read?

Platform Accessibility

Java is free, it’s IDE’s are free, and they supposedly work on all systems. Sure, web programming has this quality too, but Java introduces application style development to students that’s different from the web and emphasizes further the use of object-oriented programming.

Furthermore, it provides an introduction to library packages and it gives students the chance to type something and see something happening that’s not the command line.

Compilation and Typing

These are two concepts that we could say aren’t really that big of deal, but they are conceptually necessary for students to grasp. Programs are typically compiled and by just introducing this requirement you can illuminate the critical concepts of a compiler, build pipelines and the different varieties of code that takes you all the way down to the ones and zeroes.

Likewise, typing, while not a huge issue for non-space critical systems like a laptop, inform students how memory allocation works, why people care, and how programs are designed with memory in mind.

It’s more semantics, but a class is supposed to teach concepts as well as practical programming. Those concepts make the practical lessons more effective.

It’s Hard

I believe there’s a certain level of work that’s necessary for a concept to stick with students. The more details, the more attention is demanded and the really important practices of programming tend to become ingrained in the process of memorizing minor details like the labels for different types.

Think about it - when you’re learning typing you are repeatedly thinking about variables and what they really mean, which then lays the groundwork for more complex data types like arrays and finally designing your own types with classes.

It’s Useful

However, they are ready to look at vendor specific-language like C# with a much greater baseline than previously because of Java. Likewise, other languages like Ruby, JavaScript and even something like Arduino programming are all going to look pretty basic and a relief, picking them up with a lot more speed than having to work the opposite way.

I’m sure this sounds like a dad telling shoveling snow builds character. But I’ll take it - when you need to teach novice students, programming too requires character building.

Intuitive vs Powerful

When I describe a certain piece of software, I'll often add to the end of my description that the tool in question is either intuitive or powerful

Simple comparisons like Photoshop vs Preview, Trello vs Jira, Excel vs Google Spreadsheets are demonstrative of these dual principles. Something that is intuitive is easy to pick up, everything to be used is present on the screen, and does a few things well and quickly. In contrast, something that is powerful, has loads of features, complex and detailed minutiae even to do a simple task like saving, and of course, gives you complete control of whatever your subject is.

Generally speaking, most of us don't buy a $600+ copy of Adobe After Effects (well, you can just use Creative Cloud...) if MovieMaker will suffice. We don't need those extra widgets, we only use it every so often and therefore, why pay that much.

After reading Chase Buckley's "The Future is Near: 13 Design Predictions for 2017", specifically prediction #9: Age-Responsive Design, I'd like to suggest software that exists in a specific user instance that lands on a spectrum between the intuitive and powerful. This is software that evolves its complexity based on your use, skill and demands. 

In this case, your software wouldn't necessary be like ever other user's experience. Take a simple example - if you only need the Sum formula in Excel, perhaps you only have a couple options in that formula. Or maybe your Kanban board in Jira looks and interacts a lot more like Trello, and doesn't need to know business value for task unless necessary. 

Naturally, this would mean that our software would be a lot bigger. However, taking Salesforce for example, already a massive system, it seems possible that a large majority of users would like a single interface that evolves with their business needs but begins much simpler. In fact, we know this is the case because of products like SalesforceIQ CRM. 

Unlike Salesforce's divided software products (at least on the front end), I'd suggest a UI that is singular but varied. 

Take a more basic example - this is a Drupal site, I've done Drupal development for years. I would love it if I could put a Drupal site in at least 3 modes - Tumblr-like, Wordpress-like, and finally full powered Drupal. The majority of your super admins in Drupal are typically looking for a strong product, but mainly use it for blogging. Yeah, I could create user roles and customize the experience - specialized content entry forms, menu navigation, and permissions grokking - but I'd love a switch and for the evolving UI to be a conceptual core to Drupal's interface.

Overall, I see three reasons that would push this concept into a mainstream software platform (most likely SaaS). First, a broad base of user types; second, an existing demand for complexity by a core base; third, strong stratification of user types. All you need from there is just to make the UI that works for your types, in the same way as Buckley describes in his article, we can clearly design for different age groups. 


Rummaging around YouTube the other day, I went and looked back over the Google Zeitgeist videos. 

I easily get swept up in these videos, as they are obviously designed to trigger your emotions from the previous year. However, comparing 2014's video (above) with 2011's - 

 - I'm a little disappointed. In 2010, Google's software is the navigator of the video and the experiences, by 2014, the software takes a back seat to treated images. 

When first seeing the 2010 video, I was personally very motivated to improve my software skills, as it was one of the first demonstrations on how much software could impact your life and more richly experience it. Google (or rather Google's advertising crew) show this experience through its dull interface, which our shared experience of using the software. 

Now, it appears that Google is hitting on those triggers I mentioned above and associating itself with anything that happens, which takes away from the software experience. 

Joel on Software

I was introduced to Joel Spolsky’s writing a few years ago when I was learning how to interview and to run a software team. His most famous article, “The Joel Test: 12 Steps to Better Code” may appear pretty basic now, but all the things Joel was recommending were written in the year 2000 before Agile, Atlassian autobots, Chef / Puppet, Jenkins and Vagrant / Docker were considered essential to even a trivial software project.

I admire that a lot. But I wondered if there was any reason to still read Joel on Software, for the first time since its publication eleven years ago.

As it turns out, absolutely.

Early on “The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)” was a fortunate starter. While I knew what character sets were and have explained to students how a character eventually gets printed on your screen, when I started reading this article, I also had happened upon an annoying character map bug with my website. The article’s history and breakdown of how indecipherable characters appear in your emails, gave me a lot of background to know what the heck I was actually debugging the site.

“Painless Functional Specs” is an excellent pairing to the hundreds of pages of Agile methodology I have read, and that have become a generalized gospel - have faith in Scrum! I’ve learned that while, you emotionally should be flexible to change, use Kanban, take time to refactor, once projects reach a critical mass, you really do yourself a huge favor to have done a chunk of planning up front. In Joel’s belaboured case, specs are not sacrosanct, just starting points, and are what most folks today would consider paper prototypes. I have not done this for many spec projects, and I have a lot incomplete Github.

Finally, in “Don’t Let Architecture Astronauts Fool You,” Spolsky writes - “Remember that the architecture people are solving problems they think they can solve, not problems that are useful to solve.” In the age of exploding frameworks and write-code-without-coding Shangri-la’s, we are, to some degree, only reinforcing existing structures and problem approaches. Not really creating new solutions. Time savers like Rails, Angular, Unity and such are fantastic and a great entry point for those entering particular programming spaces. But as Joel points out - don’t expect a revolution because we’ve gone up one abstraction layer.

I’d add that, there’s tons of great historical information in the book that could only be written by someone living in those times contemporaneously, especially related to industry developments, old (bad) practices in software companies, and even a couple knocks at Duke Nukem Forever’s release cycle.

Ultimately, Spolsky comes off a big like the software version of Anthony Bourdain. Rough on the edges, highly critical, but overall has the best intentions for creating create software and improving people’s lives with software and work lives developing it.

Getting Start with...Curse

I have had loads of books in my life with the titles all along the lines of “Getting Started with…”. These’ll be the genre of programming instructional books that will educate you in something in 24 hours, the weekend, 21 days and so forth. This is where most beginners in any given language get their start.

They’ll be some variants in there - “Beginning…”, “Head First…” - but they’re all essentially the same thing. Learn programming basics, learn the syntax, and learn a couple patterns.

I owe these books a lot and for the most part, picking up a language after knowing a few others, these can cut to the point pretty quickly if you want to skip over the familiar topics. However, within them lurks a danger.

Programming for the most part is kinda boring and requires a definite commitment that isn’t very glamorous, getting back pain and eye problems for the most part. The lure of these books is that you’ll save a lot of time by using this effective self-teaching book and get right to the good stuff, and theoretically a promotion or something.

However, at some point for beginners programming is just going to be hard. And this is where the problems can begin and my book purchasing in the past exploded.

When programming got hard, it was very easy to look at this book from O’Reilly or Sams and think: “The book’s not right. Or the book’s not right for me. I should get another one instead.”

The issue is that certain concepts, varying from person to person, are tough for people. And these ideas, let’s say classes, are pretty ubiquitous and you just have to grind through them. The book isn’t the problem, the learning is. But combine that “Java is easy guys. Let’s have fun” attitude in most of these accessible books, and you’ll end up feeling like an idiot or frustrated with the book.

Surely there’s some bad instructional books out there, but that is less likely the case unless we’re talking Apress.

So beginners, trust me, at some point just sit down and push through your chapter that’s giving you trouble. You don’t need another book, a simpler book, Code Academy or whatever. You just need to try repeatedly, and save a couple bucks in the process.

Get over frameworks.

Years ago I was looking for an answer to a pretty simple CMS question, I believe on WordPress, and not surprisingly, I found an answer on StackOverflow related to whatever random query question I had.

One of the comments stayed with me. In more or less words the user said - “I agree with this solution. Though I usually write my own CMS from project to project so I don’t have to mess with this stuff.

Aside from the useless vanity that this added to the conversation, I was and remain still pretty shocked at this response. 

Certainly on the surface, it’s a bit of trying to show off, but it unfortunately fails. At the initial time, I thought, in my inexperience, “Wow, I wonder how you would make a system like WordPress from scratch."

Today, I’m reminded of Joel Spolsky’s article - “Things you should never do, part one” - shaming folks who casually and often with pride throw out “old” code as if it had rusted. In the article, Spolsky observes that, yeah, learning someone else’s codebase is harder than birthing your own, but provided codebases, whether from a legacy project or from a package CMS framework, have one advantage - they’ve been tested and have loads of bug resistant lines in them.

While I was willing to admit pretty early on that it was a waste of my time to write link functions or SQL sanitizers, when it came to the front end I was pretty adamant that I was not only an expert, but my code was better than dealing with a front end framework whether in for JS or CSS.

Of course I used jQuery and CMS provided JS libraries, but I scoffed at Angular, Ember, and particularly Bootstrap. After all, I didn’t want a site like everyone else, and my service connections would be simpler if I didn’t have to write them around a controller and factory object.


Now look - I love to learn how things work, to get to how a sorting or searching algorithm works, and just feel like I could maybe build something from scratch. I like to think I could butcher a pig if necessary from my years in the kitchen. 

But if you actually are trying to build something - an application with intent, meaning, and users - then there is absolutely no reason to waste your time writing an email validation function or creating your own binding system. If software is about expression, you aren’t expressing yourself. You’re repeating others.

Is there any shame in an architect using a plumber? Does he or she have to design all the pipes? Sure maybe in some cases - but I seriously doubt any architect is crafting their own nails. 

So using front end frameworks like Angular / Ember and Bootstrap as sounding boards let’s dispel a couple ideas (mainly my own) about using frameworks:

I’m cheating myself and not learning because I’m just putting together someone else’s stuff like Legos.

No. In fact the opposite, you are learning how to tackle the problem that your application theoretically solves. Ideally, this is the hard part and unique problem space that you and NO ONE ELSE has. 

Again, if you want to try and make Pac-Man from scratch to learn how a game engine works, by all means, but when you sit down to make your 8-bit art action clone, which is so unique, the thing that you need to focus on is delivering the product. No one is gonna pat you on the back because you wrote an engine from scratch if no one ever plays the game.

I have to undo a bunch of stuff and the framework just gets in my way.

No, just no. If you so chose to use the ‘btn btn-default’ from Bootstrap to style your <button> then you have about 10 CSS rules to override. Furthermore, nothing in the framework is going out of its way to make all buttons do this style. Even if you get an annoying rule like:

strong { font-weight:normal; }  // THIS IS REAL

Just override this. Likewise, you are welcome to not have the application owned by any controllers if you so chose. Even with a server-side framework, you can always plop users into the folder you need and work around routing if so be it. Wanna Drupal site with a Blog powered by Wordpress, and a help section run by Rails then a custom “About Me” page - you can do this.

Oh geeze, there’s always just another framework I’ll have to learn.

Yeah, no shit. That’s called technological progress. Sooner you get over this, the better. There’s a pile of languages to learn, but understand that most languages / frameworks / build tools and so on are related to others and are usually designed to solve a specific problem. They are a tool.

Maybe employers will plaster that you need to know every JS framework under the pale blue moon, but that’s hiring managers trying to cover their asses. You will use the framework that is most appropriate to your problem space, and knowledge in one will most likely support skill acquisition in another.

For example, I worked with Ember professionally for a little bit and ended up loving it. However, when I approached my next spec project, I chose Angular instead as it better integrated with Rails and had a slightly lighter touch than Ember in my opinion. 

What if I need to customize something?

Knock yourself out! You may need some wild form interaction such that Bootstrap isn’t going to cut it. Cool - just use its grid system. Or dont! Need some JS that doesn’t work well with JS frameworks’ Promise system or data binding? Not sure how that would happen - but yeah, go ahead.

One Small Caveat

With a lot of module development particularly with Drupal front end tools, I have seen a giant mess of code that was nearly impossible to undo to make work for my clients’ needs and I’ve had to do basic stuff like Slideshows consistently.

This mainly happens as a lot of modules are created with the following thought in mind: “Hey, I built this really specific tool for my company. Let me make the colors look like Garland, kill the logo and BOOM! open source.”

Totally fair, but where content entry and front end meet, symbiosis is necessary. Often this is what is missing - the front end is provided and then content entry is jammed into there like adding cocktails to a light salad lunch.


Get over it random guy from StackOverflow years ago - use the tools to save time and customize as you need, focusing on your problem / domain space more than your ability to craft something by hand.

Think about it - a custom car may look cool, but damn, I certainly don’t want to be in an accident in one. Use tested software to make your products survivable in the wild.  

Don't forget cooking is an ingredient

“People are very used to cooking,” and want to feel productive and make something, but say they don’t have the time. “They always say they wish they could cook more but feel like they don’t have the time for it.”

Munchery CEO and co-founder Tri Tran told TechCrunch in a blog post today on Munchery’s new service to provide ingredients and recipes delivery in addition to their pre-made meal service.

I hate to be this guy, but come on, there’s more to it than that.

I’m not criticising Munchery’s service, in fact it’s a fantastic idea, particularly for couples or families looking to do something together around food that’s more than picking up takeout. People do want the experience of cooking, and the service takes the overhead out of shopping and specifically choosing what to eat from the endless options at the grocery store. Or as Munchery calls it - the “so-called grocery market.” Who says that? Were grocery stores somehow a contentious topic? Does pushing against competitors require political devaluation? Anyhow...

Plus people don’t seem to know how to portion things like onions and rice if they don’t cook a lot. And that’s really the trouble with this service - most folks don’t know how to cook well, particularly when stacked against other competitors.

This is essentially take out at the end of the day, and an expense in money and time with reduced service. Flavor from the raw vegetables / grains / proteins aren’t the only ingredients. Your teriyaki down the street tastes so damn good because the cook there has grilled more chickens that people he’s met in life, and the grill itself, charred with the flesh of thousands of thin chicken breasts, isn’t something you can whip out for date night.

Damn - generally people don’t even know how to brown meat. I’m not trying to be a critical, it’s  true, check your meat the next time you pan fry something. The recommended heat and fry times from your Munchery bag aren’t gonna help much either unless you have the test kitchen the recipe was prepared in.

Part of the reason people don’t have time to cook is typically because they don’t know how to cook effectively. So unfortunately there’s gonna be some disappointment. After all, a home cooked is more than take-out deconstructed. 

Holograms Interact with the Environment and Each Other

...But just not you. Better writers than I have already taken on the subject on the importance of physical feedback in game and digital interactive in Codename: Revolution, specifically targetting the failures of the Kinect versus the Wii. 

But personally, I can't see this demo:

And not think about a section of Errant Signal's review on Watch Dogs


So elegant

I’ve already written on the excellent Platform Series from MIT Press, and since discovering the series, the platform that I have been waiting for is the one that meant the most to me growing up – the Nintendo Entertainment System.

I AM ERROR by Nathan Altice finally dives deep into the hardware architecture and the expressive capabilities derived from the chips in the NES. I bought the book immediately, but surprisingly I wasn’t that engaged as I thought I would be.

ERROR is an excellent book, incredibly detailed, and well-researched with a breadth of topics from hardware development in Japan, assembly coding of music, and ROM hacking across the internet in the early 90s.

These topics aren’t why ERROR didn’t pull me in. Instead, it’s a victim of the series own success. Racing the Beam, the inaugural title from the series covering the Atari 2600, is also amazingly detailed particularly in the translation of games concepts through the examined hardware architecture to actual expressive gameplay.

ERROR mirrors this same level of translation, which is after all the intent of the series, and while the NES has a lot more going on, the ah-ha nature of the translation described above is much clearer in Beam and more accessible.

ERROR moves around a lot more, and specifically is concerned with the idea of “translation” given that the NES is also known in its home country of Japan as the Famicon. The book’s goal from the introduction is to determine how many perspectives on translation we can take when studying the NES, and it’s a brilliant thematic idea.

But, the hardware isn’t as interesting in this case if you have been following the series, and honestly, for a person of my acumen in the realms of PCB and chip technology, was a little over my head at times. That said, maybe one day I’ll appreciate it a lot more.

In contrast, two other titles in the series - The Future Was Here and Codename: Revolution - took their platforms, the Commodore Amiga and the Wii respectively, and while touching on the hardware, explored other aspects of expressive interaction with the machine beyond its hardware to a point where the hardware was only a stepping off point.

It’s like getting really into the details of how strings and pickups on a guitar interact, whilst most folks would only be concerned with “what does it play?”

Future primarily covered the expressive gaming and the demoscene provided by the new multimedia computer, and Revolution discussed what it meant for software and hardware to interact in a physical space. Sure, hardware had to be mentioned to start these conversations, but again, they are our baseline for further exploration of artistic and human ideas transformed into a digital medium. In this way, the books remind me a lot of 10 Print’s vignettes on maze generation code.

Fairly, I should backtrack on my criticism, which only comes from an embarrassment of riches. The intricacies required to program games cleverly on the NES are amazing, deserving a nod of respect to those developers, and are a rich primer on how graphics programming developed into a higher level of complexity than the Atari. Likewise, the chapter “2A03” on the sound chip architecture in the NES would be my first recommendation to anyone interested in sound chip programming and nice slice of humble pie for any contemporaries who currently do it with any degree of ego.

Finally, the chapter “Tool-Assisted,” while a titled after popular tool-assisted speedruns (and I’d note as well glitch fun), has a wonderful and well-explained history of hardware emulation, digging deep into IBMs history, that for even a software person not interested in games, is interesting on its own and of emergent importance for emulators used in production / development environments.

Overall, I’d recommend buying the book if you have been reading any of the Platform Series, as it is likely the most well-researched book as of yet, and if you have not read any of these titles and are not a hardware nut, reading Racing the Beam and I AM ERROR back-to-back would be excellent combination to get you started on that path.

Silicon Valley Season 2

Silicon Valley is funny. Mike Judge has a lot of cred in finding the absurd in the modern middle class and suburban, which as the shows executive producer, this style is expertly done with Valley. The show has always done a great job of actually telling jokes, and finding the humor from character motives rather than tacking what they could shoehorn in.

I really liked season one of this show, and I liked season two, which recently wrapped up its run on HBO.

Unfortunately, the show is already showing fatigue. The show’s plot revolves around the continual fight of Pied Piper versus the CEO of Hoolie attempting to gain control of Piper’s middle-out data compression algorithm through any means necessary as the staff of Piper try to secure funding to fully launch their product.

The problem with this setup is that it is completely episodic and random – "Oh look, Hooli is pulling some bullshit legal tactic, oh now they’re doing something else I already forgot about because it’s brushed off as soon as it happened, WHAT? our angel investor is a crazy person and now he’s doing weird eccentric thing X, which as with Hooli we’ll discard as a memory and plot thread when the credits roll."

It’s not a story that actually builds, and because of that, when the Piper crew eventually succeeds, I don’t really have a sense that they were up against much, but just annoyed throughout the season.

In contrast, season one actually built towards the Tech Crunch Disrupt, and involved more than outside annoyances - the relationships of the team, transition to a real company, and competition. A lot more intuitive, and as an audience member you can anticipate conflict and what you would expect from a growing company.

Which all of that totally sucks as this season actually had more heart.

Richard’s pep talk that the team was there and existed to “build epic shit” alongside Jared’s maudlin speech that he has had the best time being at Pied Piper even though it involved so much stress, which takes something really commodified, the start-up, and actually gives it some warmth.

There’s a lot of folks in Silicon Valley and here in Seattle less concerned about what they are passionate about, and more concerned with what will sell, and this is more insidious than some huge company like Hooli. It’s an internal and intentionally adopted destruction of one’s dreams, rather than an antagonistically driven defeat.

The Piper crew appears to genuinely want to do more for people, and the speeches delivered by Jared and Richard legitimize this drive contrasted excellently with Belson’s comment that “I don't want to live in a world where someone else is making the world a better place better than we are.”

I look forward to season three, but I hope that the humor and conflict can grow from these heartfelt motives in order to find insight within the laughs.