And you are here why?

/via http://turnoff.us/geek/annoying-software-3/ This one really gets my goat. Yes, I know, UX is hard etc. etc., but even a little bit of googling will come up with  some core principles for date entry . And of these principles, the one that should stand above all (for me at least!) is that  you should not require users to enter special characters to format dates. Oh, if you want to show people a greyed-out  / , that’s fine, go for it. But  making  them enter it? Ugh!

/via https://www.monkeyuser.com/2016/development-platforms/ When it comes to browsers, I’ve always found the “Too many display formats on Android” argument to be somewhat humorous, because, compared to the living hell that is doing anything on PCs/Macs Android is a bit of a walk in the park. For good or for bad, people tend to swap their phones out somewhat frequently. Ok, maybe not every year (cough), but you’re unlikely to find 5 year old phones out there. But theirPCs? Boy Howdy. Seriously, it’s not just that you can still find low-rez laptops for sale today, it’s that if you find somebody using a five year old PC,  it’s not even surprising! . And life gets even more entertaining when it comes to corporations, where they don’t just have geriatric computers, they even mandate fun stuff like “ Everything must work with IE11 ”. IE11! Which, the last time I checked, doesn’t support CSS Grids, PWA, and most other things that are —  finally!  — making for actually cool/useful we

A friend of mine has a restaurant in the East Village ( Grape & Grain  — you should go!). It’s a small thing, seating maybe two dozen people. The fascinating part is how the chef — Adam Rule — generates consistently great dishes despite his “kitchen” consisting of 3 induction plates and a convection oven, all tucked into a corner. I’ve seen him operating when • A group books the entire restaurant for dinner, and pre-selects the menu (“ Could you serve everyone clams for starters, then pasta, the sea-bass, and pavlova for dessert? ” • There are never more than a dozen or so in the restaurant, but as one couple leaves another shows up. This from 6pm to midnight • A dozen people suddenly show up, and proceed to order  everything  off the menu. And in all these cases, the food always shows up like clockwork, the entire party gets their pasta at the same time, newcomers don’t sit around waiting, etc. You get the point, the service is exactly what you would expect at a good r

/via https://flowingdata.com/2017/05/02/summary-stat/ If you don’t pay attention to your’ data’s distribution, you run the risk of focusing on the wrong thing entirely. The perfect examples here are  the datasets generated by Justin Matejka & George Fitzmaurice  (•), where, thought wildly different, each dataset has the same summary statistics (mean, standard deviation, and Pearson’s correlation) to 2 decimal places! To really belabor this point, absent knowledge of the actual distribution, you  shouldn’t  rely on baseline summary statistics. Take  averages  for example: 1.  Outliers can — wildly! — skew your averages. You walk to work 200 days a year, and fly cross-country to the HQ in Los Angeles once a year. What’s the average distance to work? 2.  On the other hand, you averages can — totally — hide your outliers. Your DMV processes 290 out of 300 applications in less than 15 minutes, but the other ten take greater than 2 hours. How satisfied are those last 10 people

TL;DR →   Version control for your data doesn’t mean s**t if you’re not versioning right up to the point you use it /via https://www.digital-science.com/blog/guest/digital-science-doodles-lab-life-and-experimental-reproducibility/ I’ve written about the  Reproducibility Crisis in Machine Learning  before. Without going into gory details (just go read  the post  instead), the field is a perfect storm that comes from combining huge — nay massive — data sets, jobs that take forever to run, pipelined workflows within these jobs, workflows running in parallel, and poor version control. “Poor Version Control → This one is the killer here. While you might (might! Admit it, you don’t!) have version control for your individual models and datasets, what you inevitably end up  not  doing is versioning  all  your tweaks in flight. It is, after all, easier to just tweak some of the data on the servers rather than copying all your assets up again. Or, it’s just faster to spawn a bunch of j

I’m specifically referring to engineering organizations here, so, if you’re in one, do you *actually* know where your budget goes? And no, I’m not referring to your  AWS data transfer costs , or your  RDS spend , or whatever. You see, as humans, we like stories. We like our world to exist in some sort of linear narrative, where effect follows cause, and everything happens for a reason. The problems with this line of thought are • We tend to internalize this, and when the world doesn’t work the way we want it to, we get caught with our pants down, and • We are particularly bad at noticing when the narrative changes. In this particular case, consider where your no-longer fledgling engineering team is spending its money. When you started off, it was just a handful of you, and money was tight (it always is tight, unless you’re Google  ). Odds are, you went through some sequence of the following pain points 1.  Can we afford to hire one more person?  Seriously, it was, about labor

Let’s take for granted that you’ve done the right thing — you’ve generously instrumented your system, and are actually paying attention to the metrics that you’ve generated (•). The question on the table is — “ Do you actually trust the metrics that you are generating? ” (Hint: You shouldn’t) Let’s look at something fairly straightforward, the request/response path as shown below You would think that the ResponseTime would be the sum of each of the processing stages, right? i.e.,  ResponseTime = 10 + 1 + 20 + 1 + 5 = 37ms ? But, since you shouldn’t trust your metrics, you 1) Also measured  ResponseTime  directly, and 2) Compared it against the what it should be, and 3) Charted/alerted on deviations and you found that the actual ResponseTime was, say,  52ms . That’s quite a difference, no? As to  Why  it was 52ms, let’s look at a bunch of possible issues 1.  Measuring the Wrong Thing : You actually instrumented something completely different. I know, that sounds goofy, b

/via http://www.commitstrip.com/en/2013/08/01/moment-de-solitude/ I — literally — have no idea how many different types of ToDo lists I’ve worked my way through in my life. Off the top of my head, I’ve used • Post-Its : with the inevitable breakage when they fell off the monitor without my noticing) • TextEdit : Oh the fun when the laptop crashed, and my list hadn’t been saved. • OneNote : All well and good, till I switched to OSX… • Trello : Huh, I’m spending so much time tagging and categorizing my ToDos, I don’t actually have any time to actually  do  them. • JIRA : That one time I  Kanban ’d my way to using JIRA for my ToDos. It was excessively silly • Keep : Surprisingly effective. Really. Go figure. • Email : Ah, the old standby. Give that I’m always hovering pretty close to ZeroInbox, email does work extremely well. And lord knows how many other things. That said, I’m currently in an  Email + Keep  kinda place. What about you?

/via http://turnoff.us/ You know how, when you go on vacation, it takes you almost an entire week to just unwind? How that second week is so much better than the first one, and how you spend it  actually having fun , instead of stressing about all those 47 things that might be going on at work? Well, weekends are like that too, in short form. If you don’t take the time to actually chill over the weekend, you’ll enter the next week with a bunch of pre-existing cognitive load. Which’ll just cycle into greater stress over the week, which cycles into even greater cognitive load the following week, etc. The bottom line — take the time off over the weekend. Don’t think about work. Try not to stress about that bug. Yes it’s not going anywhere, but then again, a clear mind will help immeasurably… And yes, this only applies if you have agency. Then again, if you do have agency, make sure that your team does this too!

If you’re building anything more complicated than, oh, a simple “ Hello World! ” app, odds are that you’re going to end up with dependencies (•). These dependencies can vary all over the place, from access to system resources (How d’you think the “ Hello World! ” actually got to your screen?), other components in your system, external resources, outside applications, and so much more. What’s worse is that • the dependencies might be under development too • even if they’re stable, you might not have everything necessary to access them (e.g., the auth framework to get at S3) • and even then, you might want to test specific responses that you can’t guarantee (it needs to always fail. Or succeed. Or randomly based on a PRNG) And that’s where  mocking  comes in, where you essentially fake your interactions with the dependencies, so that you can go about implementing  your  stuff without depending on, well, your dependencies. Which is all well and good, and actually kind of intuit