DaedTech

Stories about Software

Sep
24

By

Starting a Tech Firm in the Era of the Efficiencer

Category: You Asked For It Tags: , , | 2 Comments

For this week’s reader question, I’m going to cover a subject that I’ve covered before, but not for a while.  People have asked about this in a variety of media.


Also, a normal reader question, submitted through the site.

I was thinking about a boutique consulting firm. Wondering about your thoughts on that as a viable path forward, and the difficulty around ramping one up. Obviously I also need to find the right niche and was curious if you thought specializing in particular enterprise level software implementations (e.g. SalesForce) was a good idea.

And, frankly, a lot of people ask this in miscellaneous interactions that I have no way of capturing to quote.  So let’s talk about that this week.  Where are these efficiencer firms hiding?  How do we start tech firms that are efficiencer firms?  And so on?

What Is an Efficiencer?

Because this is a neologism of mine, you might rightly find yourself asking “what in the world are you talking about, crazy-person?”  Efficiencer is a firm that I coined in my book, Developer Hegemony.  I’ll offer some excerpts here, rather than re-invent the wheel.

I now owe you a definition of this term “efficiencer.” In short, it’s the name describing the service that we as software developers provide. “Software developer” is descriptive, but it suffers the fate of being entirely too procedural and focused on details. We perpetuate this problem by being, ourselves, far too focused on details. The value proposition that we offer the world, notwithstanding what we write on our resumes, is not “five years of Python, three years of JavaScript, etc., etc., etc.” The value proposition that we offer has deep roots in efficiency.

…

If you were to ask a lawyer about his core value proposition, he’d say that he provides expertise in the law: “I help you claim and defend your legal rights.” If you were to ask a doctor about her core value proposition, she’d say that she provides expertise in your health: “I help you live longer and have better quality of life.” But if you ask a programmer about his core value proposition, he will probably say something about knowing ASP and helping you build websites. “I help your company build nice, responsive design websites that function on a whole variety of blah, blah, blah….”

Wrong. Our value proposition is that we provide expertise in _efficiency_. “I help you have more time and money.” Or, at the risk of sounding a tad overly dramatic, “I help raise the standard of living.” Sounds pompous, but that’s what we do—eliminate jobs of drudgery and create ones of knowledge work. I’d say that time and standard of living as by-products of our work put us on par with those offering services around rights and health.

Read More

Jul
13

By

Growing the Ideas from the Developer Hegemony Book

Category: You Asked For It Tags: , , | 5 Comments

Happy reader question Friday, everyone.  Today, I’ll field a question about the Developer Hegemony book.  For any newer readers, I wrote this book over the last couple of years and published it to Amazon in early May.  For a briefer synopsis of its purpose and message, you can check out this announcement post.

The question was a lot longer than this (and contained some much appreciated kind words).  But I’ll leave out any personal details and the backstory and leave just the question (paraphrased).

Aside from joining the Facebook group on the “What Now” page and spreading the word via social media, is there anything else I could do to help you get these ideas to more developers?

For some quick housekeeping, here’s the page in question and the Facebook group, too (feel free to join!).  I appreciate the question, and I also understand it.  I mean, of course I literally understand the English language.  But I mean that I understand the necessity of the asking.

The book release coincided with my “retirement” from IT management consulting.  I went home, published a book, and dedicated my time to three simultaneous pursuits: a dev tools content marketing business, a specialized codebase analysis practice, and selling my primary residence in favor of what I think of as “cosmopolitan homelessness” (and moving).  I offer this not as an excuse, but as an explanation.  I’ve been distracted.

Me going cosmopolitan homeless following the release of the developer hegemony book.

The Developer Hegemony Book’s Promise and the What Now

The upshot of my flurry of activity has included not doing a lot to pursue or facilitate the book’s vision.  I’ve made occasional posts to the Facebook group and I’ve added some content to my Youtube channel about how to get a Tax ID and start a corporation.  But I haven’t exactly kept the pedal to the floor and started a movement in earnest.

So I’ll take on this question and the rest of the post from the perspective of “what would I do to advance the cause if days were 32 hours long and I had more time?”  After all, no one has more interest in advancing the cause than me.

I should also mention that the book contains my thoughts on how individuals and organizations can move toward Developer Hegemony.  I won’t rehash that here, opting instead to address the specifics of how to spread the ideas.

Read More

Jun
13

By

Starting a Software Company from Scratch

Category: Free Agent Developers Tags: , , |

When I reflect back on my free agent career, it strikes me that I more or less did everything wrong.  I mean, I don’t actually believe that when I look at it analytically.  But it does feel that way, knowing what I know now.  Starting a software company from scratch invites plenty of missteps.

In the lead into last Friday’s reader question post, I talked about starting this blog as a journal of sorts.  That’s a good example of what I’m talking about.

In the end, I built an audience, established a brand, and wound up in a good place.  But if I could go back in time 7 years and give myself advice, my path would have been more direct.

It goes beyond blogging, of course.

That was one example, but it applies generally to my entire approach to starting my software development/consulting company.  I did things that worked out, but it hardly seems optimized in retrospect.

You’re probably thinking that this applies to everyone.  Hindsight is 20/20 and all that.

And you’re right, which is exactly my point.  I dove in with severely imperfect knowledge, made a lot of mistakes, and it still worked out pretty well.

If you pursue the free agent life, you’ll flail, make mistakes, and have some false starts.  But you’ll recover, figure it out, and do fine, even if it sometimes seems like you’re drowning in the moment.

Flat Squirrels and Driving Directions

Perhaps you’ve heard an expression.

“Be decisive. The road of life is paved with flat squirrels who couldn’t make a decision.”

Don’t blame me for the macabre nature —  I didn’t make it up.

I like part of the sentiment, but I think it misses the mark slightly.

If you picture a terrified squirrel in the road, its biggest problem is thousands of tons of steel and plastic death bearing down on it.  It starts left, then moves right, then freezes and then… well, you get it.

Indecision costs it dearly, but only once it has a large problem already.

When starting a software company from scratch, indecision won't flatten you, but it will impede your progress.

This probably doesn’t describe you in most situations that call for more decisiveness.  We face paralysis by analysis, rather than paralysis by mortal terror.

Have you ever sat in your car, debating whether to take the highway or side roads during rush hour?  Have you ever sat there debating this for so long that you get to your destination later than if you had simply picked either option and started immediately?  (Come on, I bet you have.)

This makes for a better analogy for our lives, especially when it comes to starting something new.  We put off action out of fear of taking a sub-optimal path.

But, at some point, even a sub-optimal path beats sitting in your car fretting.

Read More

May
1

By

Developer Hegemony: The Crazy Idea that Software Developers Should Run Software Development

Category: The Life of a Programmer Tags: | 12 Comments

Well, today we officially launch the book, Developer Hegemony.  I’d like to thank everyone who followed along, offered feedback, bought books, and generally supported the efforts.  I’ve enjoyed the ride and I hope you all love the book.  Also, congratulations to the winners of the Thunderclap raffle: Justin Neff, Jim Wang, and Gintautas Miselis!  I will be sending free copies their way.  Thanks to them and to everyone that participated!

In the final days of writing Developer Hegemony and throughout launch preparation, I wrestled with an elevator pitch.  As regular readers know, you wouldn’t find “brevity” listed on my resume, even if making resumes was something I did.  And so I struggled.  But I think I have it now.

“Why aren’t software developers in charge of the software development industry?  Developer Hegemony explains why not, and it explains how we fix that problem.”

Today, I’ll explain the book by expanding on this elevator pitch a bit.

Who’s In Charge Here, Anyway?

So, if software developers don’t run the industry, who does?  To answer that question, understand the context in which most developers write software.  It happens in the corporate world, which consists of companies shaped like pyramids.

 

Reminiscent of military organizations, a tree-like chain of command serves as the scaffolding for most companies.  The CEO gives orders to a handful of C-suite members.  These people, in turn, give orders to a larger number of vice presidents, who then give orders to a whole bunch of directors.  The directors then give orders to hordes of managers, who pass those orders down to legions of grunts.  Finally, with the grunts, you arrive at the leaves of the tree and the bottom of the pyramid.

And those leafy grunts write the world’s software, carrying pyramids of management upon their backs.  So who is more important than software developers in the business of software development?  Literally gigantic pyramids of management.  Oh, and you can also toss in some people who technically exist in the same level of the reporting organization but have titles like “analyst” or “project manager.”

So the question shifts from “who is more important than software developers in the business of software development?” to “who isn’t?”

Read More

Apr
28

By

The Efficiencer’s Guide: Getting Started

Category: The Life of a Programmer Tags: , , |

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.

Read More

« Older Posts