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

Sep
21

By

CodeIt.Right Rules Explained, Part 6

Category: .NET Tags: , |

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, follow the tag to have a look at the rest of the series.

Let’s do another installment of the CodeIt.Right Rules Explained series.  Today we have post number six in that series, with three more rules.  As always, I’ll start off with my two personal rules about static analysis guidance, along with an explanation for them.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

It may seem as though I play rhetorical games here.  After all, I could just say, “learn the reasoning behind all suggested fixes.”  But I want to underscore the decision you face when confronted with static analysis feedback.  In all cases, you must actively choose to ignore the feedback or address it.  And for both options, you need to understand the logic behind the suggestions.

In that spirit, I’ll offer up explanations for our three rules without further ado.

Read More

Sep
20

By

Are You Aggressively Trying to Automate Code Review?

Category: Language Agnostic Tags: , , | 1 Comment

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at their automated analysis and documentation tooling.

Before I talk in detail about trying to automate code review, do a mental exercise.  Close your eyes and picture the epitome of a soul-crushing code review.

You probably sit in a stuffy conference room with several other people.  With your IDE open and laptop plugged into the projector via VGA cable, you begin.  Or, rather, they begin.  After all, your shop does code review more like thesis defense than collaboration.  So the other participants commence grilling you about your code as if it oozed your incompetence from every line.

This likely goes on for hours.  No nit remains unpicked, however trivial.  You’ve even taken to keeping a spreadsheet full of things to check ahead of code reviews so as not to make the same mistake twice.  That spreadsheet now has hundreds of lines.  And some of those lines directly contradict one another.

When the criticism-a-thon ends, you feel tired, depressed, and hungry.  But, looking on the bright side, you realize that this is the furthest you’ll ever be from the next code review.

It probably sounds like I speak from experience because I do.  I’ve seen this play out in software development shops and even written a blog post about it in the past.  But let’s look past the depressing human element of this and understand how it proves bad for business.

Read More

Sep
19

By

Fixing Your Snarled Dependency Graph

Category: .NET Tags: , |

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look at NDepend’s features for helping you visualize your codebase.

I’ve written before about making use of NDepend’s dependency graph.  Well, indirectly, anyway.  In that post, I talked about the phenomenon of actual software architecture not matching the pretty diagrams people draw in Visio.  It reminds me of Helmuth von Moltke’s wisdom that no battle plan survives contact with the enemy.

Typically, architects conceive of wondrous, clean, and decoupled systems.  Then they immortalize this pristine architecture in Visio.  Naturally, print outs go up on the wall, and everyone knows what the system should look like.  But somehow, it never actually winds up looking like that.

Architectures of Despair

I think we all know what it winds up looking like.  Or, at least, what it can look like.  Sometimes the actual architecture only misses the mark by a little, around the edges.  But other times, it goes sailing off in the wrong direction, like a disastrous misfire at the archery range.

When this happens, we have metaphors for the result.  Work in the industry long enough, and you’ll hold your nose and describe a codebase as a big ball of mud.  You might also hear descriptors involving tangled Christmas tree lights or spaghetti code.  Maybe you’ll hear about a bramble bush or something.

The specific image varies, but the properties do not.  All of them describe something snarled, difficult to separate, and unpleasant to work with.  They indicate complexity without intent or purpose.  And when that happens, deadlines slip and defects proliferate.  Oh, and the people working in the codebase become miserable, now regarding those Visio diagrams as cruel jokes.

All of this stems from a core problem: a tangled dependency graph.

Read More

Sep
18

By

Deploying Guerrilla Tactics to Combat Stupid Tech Interviews

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

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

« Older Posts
Newer Posts »