It’s no secret that I dislike working with JavaScript. Maybe I’ve just grown accustomed to strong-typed languages with great tools for static analysis. Plenty of my bad experiences with JS were the result of bugs/typos I introduced and not a direct fault of the language, but many of them could’ve been caught ahead of time…

All of that being said, I’ve actually enjoyed playing Screeps. Basically, it’s a massive multiplayer online game where you program (using JavaScript, TypeScript, or other transpiled languages) how your objects in the game will behave. It’s a bit like an ever nerdier version of Minecraft :)

It hasn’t made me love programming in JS but it has at least kept me from being annoyed about it… I’m too busy solving (in-game) problems to dwell much on the language… which is probably a good thing…

I love learning. Even when not successful at applying it all, I generally get at least something out of it.

Recently, I’ve been learning a new language. Rather than a new programming language, though, I’ve been trying to learn Russian. It’s something I’ve attempted in the past, using Rosetta stone and Pimseleur CDs (none of which were pirated copies, I swear…). It helped but ultimately didn’t provide any sort of lasting success.

As I researched different ways to tackle it this time around, though, I stumbled upon Gabriel Wyner. My inner-geek really enjoyed the way his methods all tend to have evidence-based researching supporting why and how they work. Things like spaced repetition systems, using the International Phonetic Alphabet to help properly learn pronunciation early on in the process, learning concepts in the other language rather than simply ‘translating’, etc.

I found podcasts he had been interviewed on, read his book (Fluent Forever), and decided to back his Kickstarter campaign.

All of this was interesting to me, but at the time I didn’t think there were any obvious tie-ins with software development. I recently watched a talk by Edward Kmett called “Stop Treading Water: Learning to Learn“, which changed my thinking on that…

It covered similar topics as Wyner, but from a computer science and mathematics perspective. Definitely an interesting talk.

By the time I had finished watching it, I was able to see how some of the techniques I’ve been using for learning Russian can also be applied to learning other development languages or even just solving problems in languages I already know.

Of the takeaways from the talk, there were two concepts that stood out the most as being applicable for me. The first bit of advice is to dive deeper whenever returning to a topic. That way, concepts and methodologies remain fresh and are easily-accessed when needed. It’s sometimes easy to just go for the ‘quick win’ of solving a specific and moving on without spending much time understanding how that solution is working behind the scenes at a lower level. The second takeaway is that even though you should be willing to abandon things once a solution is determined not to be appropriate, it shouldn’t be abandoned simply because it is hard. I know that’s some I sometimes struggle with…

Whether it is my original system-generated username from Prodigy in middle school (MMFD70D), my dad’s license plate from when I was in elementary school (LDV-34G), or completely seemingly-useless bits of details like the manufacturer of the urinals at the office (Sloan), my brain just tends to soak it all up.

Over the years, people have praised my ability to remember things…

Sometimes I feels like quite a blessing. But I feel like it is also a bit of a curse.

Because I could rely on my memory, I didn’t really have to apply myself in school. As long as I could remember enough concepts and terminology, I could squeak by without really having to put in much effort.

Looking back, I regret taking that path of least resistance.

Don’t get me wrong… I definitely appreciate having it as one more tool at my disposal. Thanks to my memory, I can keep track of a lot more moving pieces during projects than most folks, which is a huge boon for my productivity and efficiency.

It just might have been nice if I hadn’t been able to use it as a crutch while I was in school… Still, though… Can’t change the past… And even if I didn’t put in all of my effort into education early on, who’s to say I would be in a better position at this point in my life if I had? I have an awesome wife, an adorable daughter, and things are good. Maybe I need to remember that more…

Back in September of last year, I wrote a little about Special Publication 800-63 that NIST had drafted (which was later finalized and released in early 2017).

One of aspect of the recommendations that I think a lot of services/companies struggled with related to preventing the usage of credentials that had previously been in a breach, leak, or other sort of compromise.

It seems like that would be very difficult to do well, without having someone at your company spending a bunch of time on the darknet markets, downloading the latest leaks. And then what do you do with the data once you have it? Even if it’s only stored internally and accessed behind-the-scenes, having that sort of information lying around just seems a bit risky (and that’s coming from someone with a VERY high risk tolerance!)

Thankfully, Troy Hunt saves the day. He already has done the hard work of collecting the data, anyhow. Not only does he already have an insanely-large stockpile of leaked credentials, but he now SAFELY exposes those password hashes so the rest of us can benefit from his work.

There are no usernames, email addresses, or other identifiable information. It’s just a list of SHA1-hashed passwords. The thinking goes that even if a specific email address and password combination wasn’t part of the credentials that were leaked, if anyone else used that same password and had their credentials compromised, that password should be considered ‘no good’ and shouldn’t be used.

That may be a bit overkill for some sites, but especially for sensitive information (such as medical or financial data), it’s probably worth being a little overly-paranoid…

Anyhow, he has RESTful API that lets you send over individual passwords (SHA1-hashed or, if you are feeling way too trusting, in plaintext) and you’ll know whether or not the password is in his list. Personally, though, take the storage hit and download the whole database, so you can do offline processing.

I’m still not sure how I’d utilize this… since it could easily generate a visceral knee-jerk reaction from some users… who might not understand the password may have been from a compromise unrelated to them and that it wasn’t a compromise of the current system they are using… It might be worth waiting to see what sort of traction it gets in the private sector and what sorts of UX conventions get used by the more mainstream sites. Either way, though, it definitely is helping things head in the right direction.

As I’ve touched upon in earlier blog posts, I’m a big fan of working on skills that allow you to ‘level up’ as a developer. It is also something I typically struggle with, so maybe that’s why I keep coming back to it…

For much of my life, I’ve been lucky when it comes to computers… Even from an early age, it all just sort of ‘clicked’ for me. I loved being able to create things and the idea that if I told the computer what to do — in just the right way — it would do it. It became addictive. I would obsessively work on a program until I could finally get it to work. In middle school, I even wrote programs that would solve my math homework (generally with a brute force approach because ‘n00b’).

Anyhow, I think it’s partly because of that early luck I had… and figuring out I could be good with computers without putting in much effort… that I never really dedicated myself to really trying very hard. If something I wanted to learn (like assembly or C) because too difficult, I’d just give up and find a way to accomplish what I wanted a different way. As a general rule, that’s a horrible attitude to have… but it also was somewhat beneficial in a way, too. Even later in life, if something seems a bit too much effort, my first impulse is generally to see if someone else has already solved the issue, if there’s a NuGet package that does what I want, if there’s an open source library for it, etc. Other developers I know seem to use every opportunity they get as an excuse to re-invent (re-implement?) the wheel. I mean, I guess it’s good if you are capable of making your own file system, internet protocol, or whatever… but with very few exceptions, I can’t think of any reason why a business would want you to…

So I guess there are different extremes…

I am aiming for a middle-of-the-road approach… I just want to keep my skills up-to-date, be aware of market/industry trends, and get at least a little experience (whether through my employer or on the side) with newer technologies and frameworks so I can more effectively do what I’m good at — solving problems.