I'll be picking up the book this article sources, "Fully General System For Learning To Do Hard Things" by David MacIver. To a small degree I've always done this as I learn and try new things. I really like the idea of finding an analog to the hard thing that you already do and slowly changing it, mastering it and iterating on it until you've mastered that hard thing.

So it’s not a guarantee but rather a structured plan to follow if you’re not sure how to start mastering the hard. He offers two approaches—one process if you already know what success looks like and one process if the definition of “success” is more subjective. In both cases, you’ll follow these steps:

I've been looking to build one of these as a project. I love the idea of it... there's a ton of potential in the concept for an awesome product.

Smart mirrors have been around awhile, and the most prominent version comes from Michael Teeuw. The idea is pretty simple; you’ll build a frame and box. Inside the box, you’ll place one-way glass (often seen on TV in police dramas), a monitor, a Raspberry Pi, and the cables necessary to power your setup. Michael and other contributors have created an open-source Magic Mirror platform you can install. Once installed, you can customize it to show your calendar, weather, news, and more. Installing the software is easy—it requires just one line of code.

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.