DaedTech

Stories about Software

By

Making Money through Tech Blogs

It’s reader question Monday again.  Lately, I’ve been talking a lot about entrepreneurial topics or about topics related to Developer Hegemony.  But today, I’ll answer a different flavor of reader question.  This one is about tech blogs.  Or, more specifically, it’s about how owners of tech blogs should price things.

I was recently asked by a well known company to review a product of theirs on my site and they offered to pay me for my efforts.

I actually said I’d do it and then they could pay me what they thought it was worth. I’m not sure that was the best idea as I haven’t heard back from them!

I find researching products and writing about them is the best way to learn and getting paid to do it would be a bonus. As you frequently blog for various sites, how do you price your services out? How do you invoice them? What else do I need to know to get started in this area?

Thanks for your time and your blog posts.

Well, first of all, you’re welcome.  Thank you for reading them!

Given that I’ve done a fair bit of tech blogging over the years, and that I’ve founded a tech blogging business (we’re looking for authors!), I can certainly speak to this.  To do that, let’s do this.  I’ll walk through the progression of money making opportunities that you’ll likely encounter as a tech blogger.

Making money through tech blogs can make it seem like money is pouring out of your monitor.

Read More

By

Starting a Tech Firm in the Era of the Efficiencer

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

By

Deploying Guerrilla Tactics to Combat Stupid Tech Interviews

I’ve realized something about my situation.  I work for myself, building businesses and still, occasionally, consulting at times.  But of course that’s not news to me.  Nor is the fact that I’ve moved out to a quiet, remote place where I wear T-shirts exclusively, fish a lot, work when I feel like it from a room in my house, and often cook dinners over a fire in my backyard.  The realization came from marinating in that lifesyle for a while, and then noticing that I have absolutely no reason to pull any punches with my opinions.  No affiliations, no politics, no optics to manage.  So why not have some fun expressing those opinions, provocative or not, as DaedTech posts?

Today, I’d like to take on the subject of tech interviews.  Of course, talking about the deeply flawed hiring process isn’t new for this blog.  But I’m going to take it a step further by suggesting how we, as individuals, can try to fight back against Big Tech Interview.

The seed for this came from an idle internet clicking sequence that brought me to a blog.  The company to whom the blog belongs, Byte by Byte, offers the motto, “your one stop shop for acing your coding interview.”  Below that, it says, “master the coding interview game”  (emphasis mine).  It struck me then.  Yes, of course.  It really, truly is a game, and a stupid one at that.  But let me come back to the cottage industry of Princeton Review for tech companies later.

The History of the Job Interview

For this history, I’ll offer an excerpt from my book, Developer Hegemony, describing the history of the job interview in general.

In 1921, tired of hiring college graduates that didn’t know as much as he did, Thomas Edison made up a giant trivia questionnaire to administer to inbound applicants. According to Mental Floss, questions included “Who invented logarithms?” and “Why is cast iron called Pig Iron?” If you look at the sorts of questions that modern day tech companies seem to think they’re cute for asking, courtesy of cio.com, they include such profundities as “Why is the Earth round?” and “How much do you charge to wash every window in Seattle?” If you mixed Edison’s and tech companies’ questions together, you’d be hard pressed to tell the difference.

To summarize, almost 100 years ago, an aging, eccentric, and incredibly brilliant inventor decided one day that he didn’t like hiring kids that weren’t his equals in knowledge. He devised a scheme off the cuff to indulge his preference and we’re still doing that exact thing about a century later. But was it at least effective in Edison’s day? Evidently not. According to the Albert Einstein archives, Albert Einstein would not have made the cut. So the biggest, trendiest, most forward thinking tech companies are using a scheme that was dreamed up on a whim and was dead on arrival in terms of effectiveness.

But surely it’s evolved somehow. Right? Well, no, at least not in any meaningful way. In this piece from Business Insider about the “evolution” of the job interview, we can see that what’s actually changed is the media for asking dumb trivia questions. In Edison’s day, interviewers had to get cute face to face. Now they can do it over the phone, through a computer screen or even via a mobile app. Who knows what the future will hold for the job interview; they may be able to beam the stupid directly into your cerebral cortex!

Google Looks Critically at Tech Interviews

In the book, I cover a lot more ground than I can or will here.  I lay out a case for how uniquely pernicious this interview process is for tech.  It artificially depresses software developers’ wages and manufactures job scarcity in a market where demand for our labor is absolutely incredible.  But let’s seize on a different point for this particular post.

I have specific styles of modern tech interviews in my sights as worse than others.  Specifically, the whiteboard interview, the trivia/brain-teaser interview, and the “Knuth Fanatic,” algorithm-obsessed interview.  These serve mainly to make the interviewer feel smart, rather than to reveal anything about candidates.  But don’t take it from me.  Laszlo Bock, former head of Google HR, said this:

On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.

And also this:

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess.

Read More

By

The Decline of the Enterprise Architect

Happy reader question Monday, everybody!  Unlike last week (exigent circumstances) and the week before (US holiday), I can actually bring you one on Monday.  I’m trying hard not to pull a muscle patting myself on the back.

Anyway, today’s reader question has to do with the enterprise architect position.  Specifically, what do I think of it?

It’d be great to hear your thoughts on [the enterprise architect], I’m sure there’s more than an article’s worth on that subject.

Simple enough.  So let’s talk enterprise architect.

Prior Art on Enterprise Architects and Regular Architects

I have, in fact, talked about the architect position before.  It’s hard not to when you’ve blogged for as long as I have and as much as I have.  The architect role is almost as ubiquitous as the software developer role.

I once talked about the architect role as a pension plan for developers.  The pyramid shaped corporation creates a stigma that staying “just” a programmer means failure in a career development context.  So even as organizations (mercifully) move away from the “software as construction” metaphor, the concept of architect persists.  It persists because it gives companies an organizationally meaningless way to let someone be “more” than “just a developer.”

I’ve also made posts about the needless division between reasoning about software at a holistic versus granular level and about moving beyond this distinction and the construction metaphor.  These probably weren’t quite as provocative, and they didn’t dive into the toxic role of the pyramid shaped corporation in knowledge work.

But it appears I’ve never specifically talked about the enterprise architect.  Well, let’s do that now.

The Impressive Enterprise Architect

What is an enterprise architect, anyway?  Well, presumably, it’s someone who trades in enterprise architecture, which is like architecture, but more enterprise-y.  Let’s ask wikiepdia.

Enterprise architecture (EA) is “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.”

Wow.  Pasting that into the WYSIWYG made my Flesch Ease of Reading score plummet by 20% as I’m typing this.  That alone probably makes it enterprise-y.  Plus, it plugs in “utilize” as a synonym for “use,” so you know it’s official.

If we unpack — eck, who am I kidding?  There’s no unpacking that rhetorical peacock.  Enterprise architecture is, truly, using a comprehensive approach to practice conducting analysis, design, planning, and implementation to develop and execute architectural patterns and practices that guide organizations through changes related to business, information, process, and technology utilizing various aspects of the enterprise to identify, motivate, and achieve said changes.”

Crap, there goes another 15% off of my readability.  Now only people with tattoos of Gantt charts can read this post.

So what is enterprise architecture, and what, then, does the enterprise architect do?  Well, whatever else they do, they apparently seek to make sure no one ever asks them what they do again.

Read More

By

Consulting for your Current Employer: Make Your Boss Your First Client

Alright, like last week, this week’s reader question Monday occurs on Tuesday, but this time because I was traveling all weekend until getting home Monday morning at 3 AM.  So I basically just walked in the house, laid down and went to sleep, rather than logging in to publish.

Today, I’m going to talk about consulting for your current employer.  Er, well, consulting for your current-but-soon-to-be-former employer.  How do you flip your current salaried gig into a consulting arrangement?

Here’s the actual reader question.

You mentioned in a post that when you started freelancing full time, you negotiated a contract arrangement with the employer you were leaving. I was wondering if you could go into how you framed that conversation and if there were any special circumstances that allowed you to do that. Thanks!

First of all, it’s now been a pretty long time since I did that.  My recollection is thus rather hazy, but I think my specific situation will not prove overly helpful to most reading.

That position was an executive leadership role.  Leaving one of those voluntarily, with an offer to consult, tends to have a high chance of success compared to leaving an individual contributor role.  They needed my help with things like hiring my replacement, transitioning responsibilities for my direct reports, and that sort of thing.  And, I doubt most of you reading this advice (or the reader asking) are leaving CIO/CTO roles.  So I won’t focus on that.

Instead, I’ll draw on my career experience and lengthy organizational consulting history here.  How can a software developer convert an employer into a client?

Captive Shops

Before you set your master plan in motion, however, stop to consider something.  What do you want your freelancing to look like?

In Developer Hegemony, I talk about how corporate opportunists should view themselves not as employees, but as companies of one.  For instance, most people don’t think anything of volunteering to work 45 or 50 hour weeks for no extra money.  They assume it’ll all take care of itself come annual review time.  (It won’t.)  But if you regard yourself as a company of one, then this behavior looks like you agreeing to give a client a 25% discount on your services for no reason.

If you’re a corporate employee and not in the habit of viewing yourself this way, I suggest you start.  It’ll help you avoid sucker culture. And it’ll give you interesting perspective, such as the fact that you’re really a service provider with exactly one client — namely your boss.  And that client exerts total control over your financial well being.  This makes you a so-called captive shop — you’re a captive of an 800 pound gorilla client that can crush you on a whim.

The question to ask yourself when you contemplate going freelance is whether or not you want to stay that way.  Seriously.  Because this will determine how you approach making your transition.

The Tom Hagen Strategy

In the movie The Godfather, Tom Hagen is a lawyer that represents the Corleone crime family.  In one scene, he explains his livelihood to another character’s dismissive challenge of “who the hell are you?”

I have a special practice. I handle one client. Now you have my number. I’ll wait for your call.

As lawyers go, Tom Hagen is a captive shop.  He puts his fate entirely in the hands of the Corleone family, who treats him as a de facto employee.  If you want to go this route (at least to start), then you have a specific strategy for converting your employer to your client.  It has two core components:

  1. Make yourself indispensable.
  2. Offer your resignation, but with a budget-neutral pitch to stay on indefinitely as a contractor.

Read More