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.

Bullshit.

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.

Overall

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

I AM ERROR

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.

I don't understand why you don't understand my Views

Drupal developers typically follow this pattern when they start to work with layout systems: nodes to blocks to maybe panels to Views. Now these are obviously intertwining and of course a lot of us jump into custom templates and Views-like modules that aggregate and filter content.

As a Drupal dev, looking at these elements the progression seems pretty obvious and is natural to content management. First you create content chunks, then you arrange more specialized content pieces, and finally you start creating lists and contextual filters of content.

Speaking with clients who are actually going to use your system, however, this progression to and use of Views isn’t as natural or intuitive.

For a lot of folks not in web development, pages of content are just that - individual documents that stand alone. They aren’t nodes, they definitely aren’t fields, and from there the concept of filtering nodes to access fields is a conversation that isn’t going to translate well between dev and non-dev. But particularly when using systems like Taxonomy or Nodequeue with Views, where curation is a focus, it’s critical that users understand the basic idea.

So what is the best way to get these ideas across?

Tech terms is obviously a non-starter. Referencing SQL or the index.php query system won’t help. Neither will the name “Views”. It’s just too general, and worse yet if a person has enough knowledge to understand what a “view” is within MVC, as it can be easily confused with templates.

Thus, keep terminology to “Lists” and “Filtered Lists” or whatever wording works best. 

The simplest way to explain Views from there is to explain that these lists are lists of pages that use their parts, and we can set filters to “go get” the pages we want and just get their “Title” for example.

Here again, saying “fields” and “content types” is not very helpful either. Likewise, when discussing filters, if you’re using Taxonomy, “label” or similar may work best since that’s more common in other SaaS platforms to do the same function.

From there, concepts like limit / count, pager and such are a little more familiar to most people involved who use the web.

The key point therefore is to step out of the Drupal lingo and start thinking in terms of what’s more common. If users reach the point where lingo becomes important, then it’s fine to switch over, but until then, communicating the key operational concepts is more vital than keeping things in Drupalesque.

 

Cheers to small books

Recently I picked up Thomas Schwarzl’s 2D Game Collision Detection. It’s a couple years old, and I already have books that are much more thorough on game development such as Mathematics and Physics for Programmers and Game Physics Engine Development, but I wanted a book that was as stripped down and direct as possible on its topic, which I needed a little boning up on.

And indeed the book did exactly what it said it would do and no more, a result that a lot of programming books in general fail to deliver on. Simple question - how do I solve the tunneling problem in collision detection? For Schwarzl it’s a couple pages, and for a lot of books their thoroughness in answering this programming problem can become less of a technical issue and more of a readership problem.

While I wouldn’t knock books attempting to provide a lot of knowledge for my page-buying buck, I would say instead that there is a space missing in programming literature, which is the small book, and in particular, the small specialized book.

I have a couple of algorithm books on my shelves (well, in stacks on my floor), but some of these, while serving as rich collegiate textbooks aren’t anything that can really engage the beginner or improve the intermediate developer.

By all means, I won’t return Sedgewick’s Algorithms, however, I would like to see books along the lines of 4 Sorting Algorithms that barely trump 90 pages. Books of this variety wouldn’t be intended to be the end of all of study, but could provide a low cost of entry into a new subject without intimidation, high cost or excessive detail.

Sometimes, you just want to be told in a few sentences what a bubble sort is without, for the moment, worrying about its O-notation compared to other algorithms. Similar series elsewhere - A Very Short Introduction, How to Read…, and every book on meditation - demonstrate the practicality and demand for reading of this type.

The You Don’t Know series focused on JavaScript from Kyl Simpson is a perfect example - meeting all these criteria: short, detailed in a specialized topic and not too much extraneous information. Want to know about closures thoroughly but JUST closures, well Simpson’s written that book.

As literacy in programming expands, I do expect that these types of books will appear more consistently and we’ll see a move away from textbook or language survey tomes and more about how to use languages involving very specific topics in a way that readers can quickly consume and then apply their understanding.

Course I guess I could start writing them myself...

Dumb Game

This weekend, after completing the ARDX Experimentation Kit for Arduino, I decided to think of the simplest possible game I could using a variety of parts provided in the kit. 

What I arrived at was Is It Even? - a game that challenges players to indicate yes or no to whether or not a displayed binary number is even. Now, for anyone who knows how to read binary, this is a pretty damn simple game. But the intent was to combine a few elements that would fit on the board that came with the kit. 

For knowing nothing about these devices, it was amazingly simple to put together the project, and the examples in the experimentation kit, more than Arduino C code examples, are very empowering to play around with. I highly recommend this kit for any beginners. 

Now if only I could think of something that isn't so useless. 

Pages