I generally don't like these kinds of "X things you Y", but this one had a couple items that I thought was good, particularly this quote:

Some “leaders” believe that admitting when they’re wrong is a sign of weakness.

It’s not.

Stumbled across this one as I was looking at some old speech synthesis stuff.  Might come in very handy as I work my way through a pile of semi working commodore 64s.

How do you make sure the SIDs that are in the old C64 in your dad's basement works before attempting a MIDIBox SID, sammichSID or other similar project? (Or midway through the project your dodgy soldering skills makes you wonder if you just blew out your 50$ SID?)

It's always great to see how someone approaches their craft. We expect to see code in this day of easy to view, public repos, but it's even cooler that old source is being made available. Wonderful to see techniques used in these very memory and CPU constrained devices.

Last Sunday, the Commodore 64/128 Programming Facebook group was carrying on its business as usual when received an invaluable gift from Michael Archer – the source code of many Commodore 64 games he programmed between 1986-1992.

I always find it fascinating how great UX is an interplay of layers from the seemingly obvious to the subtle. All of this takes it’s shape by taking the user-centric view and understanding what that users will need from moment to moment and context to context.

This is exactly what I experienced in Tokyo, by receiving each information at the right moment, I managed to reach my final destination without any worries. Everything went smoothly without even noticing how much I was guided.

One of the most fun parts of attending the ISCA (International Society of Caricaturist Artists convention 2018 was watching the last part of their art fight where two caricature artists had to do a timed caricature of the other using an etch-a-sketch. Amazing what they did. Of course, me being me I had to take a look at what could be done with technology.

Even if you don’t want to duplicate the toy, the comparison of the displays is worth watching. We were really hoping he’d included an accelerometer to erase it by shaking, but you’ll have to add that feature yourself.

My company uses COBOL. While it's easy to write a click bait headline like the one above, it's much harder to actually replace or even replicate a lot of what COBOL and the systems that rely on it.

The third option, however, is the cheapest and probably easiest. Instead of trying to completely revamp the entire system, Döderlein suggests that banks take a closer look at the current consumer problems.

Just a great quote form a good article.  I see a lot of teams getting bogged down in trying to boil the ocean to solve problems, when a few smart moves can make a big difference.

There's a difference between being on the bleeding edge and being a successful follower. You don't have to keep inventing new things, but you do have to react quickly.

We've been using slack integrations with our git repos, Jenkins, Jira and are looking at integrations with AppDynamics and some extreme feedback items.  We found it incredibly helpful for our team members on support to create some custom Hubot scripts.  These tell support things like what time it is on the ship, what version of the application is deployed, how much memory and how many processes things like Apache, MySQL, and Node.js have.

As my curiosity grew with each ding, I began to wonder things like, What if there was a failure to create a new user? What if a user registered, logged in but didn’t complete the onboarding process? What is the result of our scheduled tasks? Now that the groundwork was in place, answering these questions was a piece of cake.

Big trip back in time.  I've got some pages I built from the mid nineties sitting around on my hard drive as well as the copy of "The Complete Idiots Guide to JavaScript" which I learned some basics on back in 1997. I think my biggest memory of this time period was doing an extremely complex site layout in tables and when modifications came into the layout spending a good hour or two reworking how the table was all set up.

Aspirant developers are told they have to learn HAML, LESS, CoffeeScript, React and whatever else fly-by-night bullshit Hacker News is spruiking. Honestly, I don’t care. I’ve tuned out at this point, and I’m not alone.

Which is why I love Glitch, from Fog Creek. We’ve written about this site before. Essentially, it’s a playground where you can remix other people’s code in a safe and self-contained environment.

A lot of people practicing Agile or Lean forget that what it primarily boils down to is a way to more quickly get value in front of customers, test their reactions and pivot accordingly.

Most organizations don’t test their innovation ideas with quick experiments to generate real-world evidence. Instead, they rely on in-house opinions, or conversations with lead customers to vet ideas. When data-driven experiments are run (like market surveys), they often take too long, cost too much or deliver little new insight to develop the idea.