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
