Knowing When NOT to Work Hard

Last night I dreamed that I was called upon to give a lecture and I was unprepared. Apparently, though, I have some lectures that I give often enough that I’m able to pull one up on the fly, and my dreaming mind knows that I can always give the standard one I give to junior developers at some point: Be Intelligently Lazy.

Twenty-three years ago, I was working a full-time job doing data entry for a payroll processing company. This involved opening mailed-in timecards, “coding” them (sorting them into piles, basically), and entering their data into a Peoplesoft payroll system, with data entry done on Windows 3.1. After a couple months of doing this, I realized that I was typing the same thing over and over (each district manager had a markup rate, a name, a zip code, a phone number … and the fields probably went right in that order, actually), and it was incredibly boring and stupid, particularly when there was Windows Macro Recorder.

I set about assigning the 12 function keys to my 12 area managers’ information, typing in the information and tabbing through the entry fields as quickly as I could. When I was done and I’d written down which manager was on which key, I could type in the person’s name and their hours worked and then press F5, say, to key in the rest and press “submit” to send the timecard into the database.

My manager noticed this (well, I was probably excited and told her about it) and asked me to do the same thing for the other entry clerks in the group. A few days after completing that, the database administrator came to visit us, to ask what on earth we were doing, because the data used to trickle in all day long and now only came in before lunch (yes: I had cut the data entry time from 8 hours down to 3, for the entire group). When my manager told him what I had done, that was the end of my days as a data entry clerk: I was assigned to work in IT, working on macros in Excel or something.

So, yes: I became a programmer because I was intelligently lazy. That is part of what makes a good programmer: knowing when something can be automated. To be a truly effective programmer, though, takes a whole lot more experience in figuring out automation and figuring out when to automate and – more importantly – when not to automate. This is actually the real point of the lecture.

Your average junior to mid-level programmer will spend a ton of time automating things which could be done via brute-force. This is the classic trap of spending more time building automation than it would have taken to do it by hand. Building the skills to be able to estimate this takes a whole career, honestly. Knowing that you need to do this, though, is something that you can give to one another: simply print out the comic below and show people how to read it.

For example, I read this chart and know that every time I visit someone with multiple monitors, I need to tell them how to use the Window+Shift+Arrow shortcut. Why? Because your average person with multiple monitors will generally spend about 5 seconds 1) restoring an application window, 2) dragging it over to the other monitor, 3) maximizing the window … and they’ll do that at least 5 times per day. When you read those values into the comic above (5/day on the top axis, 5 seconds on the left axis) you get 12 hours spent in that activity over 5 years. In other words: every person I teach this trick will save 12 hours of labor over 5 years. That starts to be some real savings for the whole company, it takes me nearly no time at all, and it makes people really happy to learn as well!

This can also be useful for deciding whether to do projects, and help in deciding the importance of those projects (for example, if one person in your organization spends a day a month doing something that could be automated, that’s 8 weeks of savings over 5 years if you can automate it). That’s a whole other discussion, though it’s the same skill: so, maybe learn that skill, because making those kinds of decisions are important in moving into decision-making roles.

The other thing I tell junior developers in this talk is usually to get over the idea that there’s a perfect tool for things; the perfect tool is the one that gets the job done, and it may be that it’s clunky and kludgy but that doesn’t matter. I give the example here of how I use Excel to load data (I use Excel formulas to build SQL strings), or how I use Excel formulas to write C# code (I wrote some VBA code behind Excel & wrote some SQL code to feed data into Excel, which I’ve used to generate literally hundreds of thousands of lines of repetitive C# code), or how I use Excel formulas to write repetitive HTML (like, oh, a bunch of emails with different names & hyperlinks to their downloads). Even more importantly is the example of figuring out when to brute-force something (“Only 200 photos to crop? We’ll just use a photo editor rather than programming it. 40,000 photos to crop? Let’s write some Python and use CV2 to find the faces for us, so we can crop automatically.”)

There are plenty of examples to give, and plenty of tools that I use on a regular basis… but it basically comes down to using the same old set of tools because I know how to use them and because I’m efficient in using them. Yes, it would likely be faster for me to learn how to use RegEx … that is, if I knew RegEx way better than I do, I could be even more efficient than I am in Excel … but we come back to that chart and decide that it wouldn’t save me more than it would cost me. Likewise, if it’s only a few things & they can be hammered out using something simple, just spend the 20 minutes doing that rather than wasting more than that on building a tool for it.

Applying this kind of thinking to your own coding practice and knowledge acquisition is when you reach mastery: when you can look at a tool or language, determine how long it would take to master, determine how much time it would save you in the tasks you regularly perform, and decide whether or not to invest in learning it. That calculation is something which truly proficient programmers make on an intuitive basis, and which contributes to them sticking to the same things that have worked previously. If you’re conscious and intentional about it, though, it will lead you to some better decisions than, “oh, this is showing up on Hacker News, I should learn it!” That’s not to say that you shouldn’t learn new things (I’m dabbling in Python and convolutional neural networks these days), but that you should be aware that there’s a trade-off and it’s perfectly logical to decide not to learn the cool new tool / language.

So. That’s my usual talk on how to be intelligently lazy.

-D

Reappearances, Disappearances

Occasionally we’ll go through our blog links and check on all of the people we’ve maybe not heard from in awhile. Some of them have disappeared in favor of The Face Hook (sorry you’ve succumbed, Ms. Nancy), some have simply dropped out and don’t have any presence any longer (we miss you Chef Paz). Some have returned to blogging, though (Haalo is back, after a 4 year hiatus!), and others have started taking pictures again.

Portland 010

Welcome back, to those returning, and we hope those who have left will stop by to tell us where they’ve gone.

-D & T

New Website Hosting

For all of you out there who read this in a feed reader, apologies if you’ve just seen a whole bunch of our posts reappear: we’ve changed our hosting provider and gotten a new URL ( hobbitsabroad.com ). For everybody else, you’ll likely not notice any change, as all of the content that was hosted on Sonic is now hosted on LaughingSquid, at the new URL (well – you’ll notice that the site loads a million times faster than the old one, which is why we switched).

Mull D 72

Enjoy these boats, for your troubles.

-D

Technology Hiring Practices and Diversity

Stirling 311

I would like to talk about hiring practices in the technology field, in particular as those have an impact upon who does and does not get hired to work in technology. This is important because the tech industry talks a lot about limiting racism and sexism in their hiring processes (they’re ignoring age bias for the moment), but then the tech industry also talks about systems designed for interviewing candidates which are designed to result in high rates of false negatives. By “false negatives” they mean that more good candidates will be told that they don’t meet the needs or the requirements of the position – that they will err on the side of not hiring.

There’s fairly solid mathematical reasoning for why hiring this way does not make sense (read the extensive and geeky discussion on Hacker News). So, we have to ask, Why maintain this type of a hiring process if it results in poor organizational outcomes? And, if they’re maintaining this in the face of poor outcomes, we must further ask, What outcomes does this system actually have and are those outcomes the real reason for maintaining this type of a system?

Portland 142

I believe that this type of a system is designed to allow the bias (“culture”) of the organization to perpetuate. I believe that these hiring practices are designed to systemically discriminate, while pretending to be based upon merit. [side note: People are quite attached to the idea of meritocracy even in the face of proof that meritocracy actually results in worse outcomes for the organization (here’s a paper which proves that random promotions yield better organizational outcomes than merit-based promotions).]

When you design a system which yields false negatives, what you actually accomplish is to normalize the practice of making hiring decisions based upon gut feel and bias rather than upon objective criteria such as whether the applicant is really interested in the position or whether the applicant can do the job. That’s a big statement to make, but I think it’s proved out by the psychology.

Tversky, Amos - Preference, Belief, and Similarity, ch. 24

We can evaluate this in terms of prospect theory and the framing effect, which pretty much describes the landscape of this decision. The framing effect plays a role here because the decision makers approach the interview having been told that it is better to mistakenly pass up a good candidate than it is to mistakenly hire a bad candidate. This framing puts the decision maker into the mindset of loss / risk aversion, which tends to be vastly more conservative than does a mindset of possible gains. When evaluating problems in a risk-averse or uncertain mindset, people attempt to reduce that risk or uncertainty however possible. In this mindset, hiring someone of the same general profile as oneself provides an immediate reduction in risk, so basically guarantees that candidates who are different (diverse) will be excluded.

This is not limited to the tech industry, by any means – I’m certain that these same problems are pervasive in other hiring systems. In tech, though, the big players have all made noises about diversity, and yet have maintained a system of hiring which continues to yield the same problematic hiring decisions. The tech industry is supposed to be the best and brightest – they certainly tell us that they are – yet it cannot seem to figure out how to hire women or blacks or Hispanics (or people aged over 35). This tells me that the noises made by tech are basic cover for not really wanting to solve the problem.

Tech companies are happy being pretty much white (and a few Asian) dudes and do not want to change. Tech companies want to mouth the right words about diversity, to maybe hire diversity officers, but they do not really have any interest in being diverse. They have designed hiring systems which are systematically discriminatory, but subtly so, which is problematic because it is the systemic problems which are hardest to fight.

Finnieston Quay 72

I’m sure some of my reasoning in here isn’t as thorough as it could be. I don’t think that my reasoning is wrong, though – I think that the hiring systems of big tech companies essentially guarantee a lack of diversity, and that the companies are either uniformly ignorant of this or are happy for it to remain this way. Before you think that they’re ignorant of this, think about where psychology graduates go if they don’t become professors (hint: big technology companies, which is why everything tech is designed to be addictive).

Don’t Open Things!

Dear Everybody: don’t open things you weren’t expecting to receive. This includes links to google docs and not just attachments. Why? There’s a particularly nasty type of attack going around that tries to pretend it’s someone you know sending you something via email. If you weren’t expecting something from that person, why don’t you pick up the phone and ask them if they sent it?

Vacaville 205

If it’s as suspicious as the picture above, double-check before you click. Thank you.

-D

Public Service Announcement

This Public Service Announcement brought to you by incompetent web developers. Please note that putting a little sign that says “this site is secure” does not make that site secure.

insecure

When I click on the little informational icon to the left of the URL, I can plainly see that the site is NOT secured. Thus, anything entered on the page can be intercepted between my web browser and the server that’s supposed to be collecting the information. And when I try to go to an https:// version of the site, I get told exactly why the site isn’t secure:

insecure

That’s right: the site might have been secure, except that the certificates that the web developer tried to use to secure it were not registered to the website, but to some other website. Security doesn’t work that way, folks.

The PSA portion of this post, now: everybody should know to click that little icon, to the left of the URL, any time a website is asking you for information that you wouldn’t want to broadcast to every criminal in the world. And if you get told anything that seems like the site isn’t right, you should leave.

Personally, I contacted the site owner and told them to slap their web developer (literally: I told them that their web developer needs a sharp slap, for trying to play this off as secure when it’s not). In doing so I told them my name and email, but hey, that’s publicly available, so no harm. Other than that, though? Not giving them any of my information, and certainly not giving them my credit card number!

Be careful out there, folks. Just because the website looks slick doesn’t make it trustworthy.

-D

ps: I blacked out the name of the website, because this isn’t about them. I suppose it also serves to protect the incompetent, but hey, I’ve already sent them a nasty note, so there’s no need for public shaming.

Old Code Lives On

Stirling 307Occasionally I remember how old I am. Thinking about how I got into computer programming, I usually tell the story about how I was working doing data entry and got tired of the repetitive nature of the job, so automated a piece of it and ended up drawing the attention of the IT department as a result. (I still keep in contact with that guy, 20 years later.) Thinking about it, though, I realized that my start was a lot earlier than that. I realized this when reading an article on The Law of Accelerating Returns. Something in there struck me as being … well, wrong.

The movie Back to the Future came out in 1985, and “the past” took place in 1955. In the movie, when Michael J. Fox went back to 1955, he was caught off-guard by the newness of TVs, the prices of soda, the lack of love for shrill electric guitar, and the variation in slang. It was a different world, yes—but if the movie were made today and the past took place in 1985, the movie could have had much more fun with much bigger differences. The character would be in a time before personal computers, internet, or cell phones—today’s Marty McFly, a teenager born in the late 90s, would be much more out of place in 1985 than the movie’s Marty McFly was in 1955.

Now, I don’t know about you, but my first DOS-based computer resembled something like the PC3 “LunchBox” Portable Computer, and came to me in something like 1984. Of course, somewhere around the same time we were playing with the Commodore Vic-20 (came out in 1981), Commodore 64 (1982), and the Commodore 128 (1985). So, no, going back to 1985 wouldn’t be all that shocking. Yes, it’d be annoying to have to use a card catalog in order to find something, rather than asking teh interwebs. It’d also be strange not to have call waiting, or cell phones, but I can’t say that it’d be particularly troublesome overall. Nor can I really say the world was all that much different.

Stirling 308I got to thinking about how long I’ve been writing software (this time) because I’d been asked to pull together some screenshots and instructions for a database application I built back in 1998. This application is still running, 18 years later, and still the “system of record” for the company. This and a couple other systems I’ve written are still ticking over in some form or another (this one’s running on a virtual machine just to keep it alive, because nobody can get the software any more, and nobody really knows how to replace it – I had to install an older development tool just to convert it to what it would have been in 2003’s format so that I could convert it to the current format and have a look through things.).

In any event, I think it’s important to point out that yes, the rate of technological change is ever-increasing. On the other hand, there are these bedrock systems which keep on running that nobody is willing to replace because they aren’t broken – they still do their job just fine, and there really is no need to change them. (Have a look at this PCWorld article, for instance.) In parallel with these systems, old code keeps on ticking over, and continues to work (e.g., just about the entire Banking sector of the UK runs on COBOL, or the VA Hospital’s Electronic Medical Records system is .NET wrapped around Java wrapped around Delphi wrapped around a file-based storage system – so, your medical record is just a text file somewhere, when all’s said and done). Other, operating-system type foundations have also not shifted – there really are only 2 operating systems in use today, *NIX and Windows NT – and those have been around for decades – everything added to them is just window-dressing.

It’s only the surface of things which has really shifted – the core remains as it was 20 or even 40 years ago. Yes, computers are much faster. Yes, computers are way smaller, and in seemingly everything. But I just don’t see the level of technological change being all that huge even now, nor do I think it’s changing as rapidly as Kurzweil thinks. Or, rather, I don’t think that the entire ecosystem changes as rapidly as all that – it’s that the outliers are arriving faster, but their adoption depends upon their incorporation into the devices and technologies we already use, which is necessarily slowed by our very humanity.

Dolomites D 300So. Take the time to look back at all the computing you’ve done, and realize how much things haven’t changed, despite the new names and different packages. Ignore the window-dressing and really think about the technology and you may be surprised at how, really, things haven’t changed. Sure, if they implanted teh interwebs into your head you’d be hugely changed – and, yes, they’re working on that somewhere – but do we really see it happening in our lifetimes? I really don’t think so, because I really think that the rate of change is not solely governed by tech, but by the economics of the matter, and by our ability to incorporate that change.

-D

Surgical Success

Well, D. just went in and had the tubes removed a day earlier than planned, because one of them had come loose from its suture and was trying to either fall out or crawl back into his head. He’s quite happy to have them out – and to be able to smell and taste again! He’s very much looking forward to sleeping not propped up at a 45° angle!

He did take a picture or two of the nose with tubes in it … but we’ll have to wait ’til later to put those up – when all the swelling has gone all the way down, and we have a good compare / contrast for them.

-D & T

Small Pleasures

Skyway Drive 270Skyway Drive 272

A few weeks before D’s nose surgery, T got him this wee quadcopter. Its batteries last about 15 minutes, after which it needs to recharge for about 1/2 an hour. It is providing D with much enjoyment as he waits until Thursday for the splints to come out of his nose … after which he’ll be able to 1) smell, 2) taste, and 3) breathe better than ever.

The swelling of D’s face is mostly gone; we’ll see whether there are any changes visible to his nose when he gets the splints out, but we don’t think there will be.

-D & T

Post-Surgery

D. made it through his surgery (septoplasty and turbinate reduction) just fine, with no complications, and is now home recovering. In 5 days they’ll remove the splints inside his nose (!!!) and he should be able to breathe better than he ever has in his life. Maybe he’ll even be able to sleep on his back without snoring. And certainly he’ll be glad not to have so many sinus infections.

So, for the next week or so, it’s bland, soft food, and sleeping mostly upright.

But all is well.

-D & T