The Efficiencer’s Guide: Getting Started
You thought Developer Hegemony Week stopped on Friday? Nah. Today I give you post 6. It contains somewhat lighter fare, since it’s the weekend, but the show must go on. We’re doing really well on the Thunderclap campaign — 83% as of this writing. But that means I still need 17 more people to do the raffle. So, please help me out and spend a few seconds signing up!
In the book, I coined this term, Efficiencer. I also talked about it on the blog this week. Today, I’d like to offer what I’ll call the efficiencer’s guide (or, at least, the start of it). I’ve called out a number of idealized behaviors and philosophies, but haven’t given a lot of practical field advice.
For the purposes of the efficiencer’s guide, I’ll assume you work as a salaried software developer in some organization. This probably describes most of my audience, and it makes for a natural starting point in this journey. If you’re already a free agent or you don’t write software, don’t worry. You can still get some info here. I’m going to include reading materials and links, so I have something for everyone.
Defining Efficiencer
First things first. I won’t ask you to go do a bunch of homework. Instead, I’ll define this term again, off the cuff. I’ve described it in the book, but I invite you all to participate alongside me in kind of an evolutionary definition of the term.
I think of software developers (or engineers or programmers or whatever) as people who collect a salary to write code. I feel fairly confident that this definition has blown exactly 0 of your minds. But consider it maybe a bit more literally. You collect a salary to code… and, that’s it.
Therefore, you don’t worry about business considerations like sales or marketing. You generally don’t participate in discussions about why you write the code that you do. Nope, you just show up, get a spec or something, fire up your IDE, and get to work.
The efficiencer, on the other hand, does ask why. In fact, the efficiencer doesn’t do any work without understanding and approving of the why. You see, she doesn’t count herself a coder but an automation professional. She specializes in making you more efficient. That might mean writing some code, or it might just mean sending you a link to a COTS product that already does what you want. She doesn’t accept specs or story cards or requirements or anything like that. She listens to your business goals around cutting cost or increasing revenue, and she decides how that will happen.