Stories about Software


How to Politely Say No and When To Do It

Another Monday and another successful Reader Question Monday.  Usually I go with kind of a FIFO model for reader questions, but I bumped one that I’d just logged because it seems interesting.  It concerns how to politely say no and how to know when to say no with clients and prospects.  I’ve excerpted some of the question here.

 I have a problem I have run into and it has to do with when to say “no” to work.

I have the chance to work on a project where my gut says I should not, not only is the project at least two months, it is at a rate that is too low for 1099. There are also many issues with current infrastructure and architecture which the owner wants to bypass. I guess my point is how do I turn down the work gracefully. In the past I have taken on this type of project and worked 12 hour days for 9 months to get it done, obviously, I don’t want to do that again.

I guess my point is, it is really hard to say “no” but it would be easier if there was a way to vet possible work with others [who] are knowledgeable about architecture so perhaps a way to audit upcoming work to see if taking on the work makes sense. How do you weigh the pros and cons? How do you get second opinions that are good, not random?

When a prospect is proudly showing you a dumpy house, how to politely say no is a good skill to have.

Extracting Themes Around No

This is a common situation for an independent.  But it could just easily apply to anyone reading in the midst of a job search.  Or even in even less dramatic fashion — maybe your boss pitches you working with a different group for a time.

Some common, recognizable themes emerge.

  • Saying no to things is hard, professionally.  Our very wiring tells us to please, as illustrated by the phrase “the customer is always right.”
  • Saying no to things has real downsides.  For employees it can mean lost capital and for free agents, lost revenue and belt tightening.
  • We see red flags, but have a predisposition to proceed anyway and hope for the best.
  • It’d be nice if we could get some insider information to tell us whether to heed the red flags.
  • In general, a framework for sizing up work would be good.

How to Politely Say No

I should note that I did dedicate a chapter entitled “The Art of No” to this subject in Developer Hegemony.   That was more about how aspiring opportunists should steer themselves away from politically perilous situations, but some of the techniques certainly apply.

You never really want to just say a blunt “no” outright to a client prospect.  Even if you think working with them makes for a terrible fit or they’ve rubbed you wrong during discovery, you’re running a business.  You want a reputation for playing nice and being professional.  Here are some general ways to demur on a prospective gig.

  • Say no, but offer to help them find someone who will say yes.  In a sense, this isn’t “no” at all.  You could almost think of it as steering them toward a lower tier offering.  “This isn’t a great fit for me, but let me put you in touch with Steve, who…”
  • It’s not you, it’s me.  “Given the budget you’ve allocated for this and your engagement model, I don’t think I’d be a fit.  I usually direct projects like this and am used to incremental value delivery, and it appears you’re looking for an app dev staff augmentation.”  I suggest doing what I did here — subtly phrase it in a way that positions what they want as a budget offering.  This will prompt them to start making concessions if they really want you.
  • Say that your calendar presents a conflict for the work.
  • You can be direct and honest and just say that you don’t think the work is a fit for what you offer.  Careful here, though.  Direct and honest sounds like the best (and to some, only) option, but it puts a lot of clients and prospects in a defensive posture.  It may leave them with a bad taste in their mouths.
  • Or, finally, you can get them to say no instead.  More on this later.

Read More


DaedTech Digest: Static Analysis, Doco and Dependency Death Stars

Happy Friday, everybody.  I’m still figuring this digest thing out, so please bear with me.  But no matter how I iterate, what you’ll get is an aggregated link to posts that I’ve written for my Hit Subscribe business.

I’m thinking I’ll do picks each week as well as the digests.  You know how podcast panelists do “picks” at the end of a lot of podcasts?  I’ll give you some picks each week.  At least, unless this turns out to be a bad idea, in which case, I’ll stop.


  • Jogging without headphones.  For years, I’ve always doubled up on productivity by listening to podcasts or audio books while jogging, if not watching Pluralsight courses.  But recently a terrible pair of bluetooth headphones (seriously, don’t buy them — shop around for a competitor) broke, and I just went jogging with my thoughts.  It’s been a huge boost to the amount of creative thinking I do in a week.
  • I cannot rave enough about payroll service, Gusto.  If you need to run payrolls for your business, these guys make it seriously easy, even paying taxes for your automatically.  Before I switched, I’d been using Intuit’s online payroll, which was the user experience equivalent of a grizzly bear carrying a raccoon in a backpack and both of them are mauling you.  Gusto restored my faith in humanity.
  •  Every now and then, I get nostalgic for computer games from my childhood.  When I do, abandonia usually has me covered.

The Post Digest

And now, the post digest.

  • I write a lot of posts about static analysis, since it’s something of a specialty of mine.  Here’s another primer I did about it for TechTown training.  In it, I evangelized a bit, encouraging readers to look past the really dull name and see that underneath it lies a cool concept.
  • Speaking of static analysis, I wrote a post for NDepend entitled “Code Quality Metrics: Separating the Signal from the Noise.”  There’s a lot of reductionist code metrics out there, so I did my part to add some nuance to the world.
  • For SubMain, I wrote a post taking you through different documentation tool options that programmers have.  User manuals, release notes, and all the traditional stuff, but then also new approaches that generate documentation automatically, at least for a starting point.
  • In another NDepend post, I talk about a novel way to settle the inevitable squabbles among a development team.  Make your arguments, and then prove them visually, using automated tooling to paint pictures of your codebase.  My personal favorite for proving a point has always been the dependency death star.
  • And, finally, I wrote a post for Monitis trying to get a little more specific around the generalized and often hype-y term, “big data.”  This post took a longer view, tracing a history of the concept back to the early days of Java and .NET.



Become a Software Specialist with the Help of Your Resume

One of my aims with this blog is to help software developers take charge of the business of writing software.  And, while I love writing rants and diatribes, doing this requires a good bit of positively focused how-to sorts of things.  Today, I’ll charge at one of those: how to become a software specialist in a world of low status generalists.

To specialize, you need look no further than your resume.

But I’ll come back to that in a bit.  First, you need to understand the essential sales problem of the software developer, from a labor perspective.

Individual contributor software development is a terrible business model!

Before you pick up the pitchforks and torches, hear me out.  I realize you’ve earned a good living writing code for some product company or agency.  I’ve done that too in my life.

You can earn a good living this way.  But you can’t really conduct good business this way.  So when software developers hang out their shingles after years of salaried employment, things can go sideways from a leverage perspective.  Mostly, people in this position become contractor staff augmentations that look a lot like employees.  Why is that?

It’s because of an incoherent value proposition: selling code-writing-labor.

To make money as a business-person, you need a customer.  I don’t mean a nameless, faceless corporation.  I mean a middle aged guy named Stan.  Or maybe a hard charging woman in her early thirties named Ashley.  You need a buyer, represented by an actual human persona that you can picture and speak to.  And this person has to be able to afford your services.

Who is this person that can buy tens or hundreds of thousands of dollars of your labor?

The Case of the Split Persona

At this point, you’re probably picturing Stan as an architect or Ashley as a tech lead.  But those people don’t have tens or hundreds of thousands of dollars.  In terms of company money, they have zero dollars and zero cents, unless the company gives them like a $1200 per year training budget.  That doesn’t buy a lot of your app dev, does it?

You want a 3 to 12 month app dev gig, which goes on the market for $50,000 to $200,000.  Do you know who signs off on buying that?  A director named Sheila.  And do you know what Sheila will say if you come to her and tell her that you’re really looking to work on a Node.js-this and a React-that?  She’ll tell you that you need to talk to someone that reports to someone that reports to her.  She can’t remember their names off the top, but, you know what, just send your resume to HR or something.  (I’ve written more on this here.)

When you try to sell a keyword-heavy resume as your value proposition, you create an existential conundrum for yourself.  The people that understand what you bring to the table can’t afford you.  And the people that can afford you can’t conceive of what problem you purport to solve.

The only way you can make sales is to sell to a system — an algorithm involving various people and committees and whatnot.

And that’s a recipe for either going out of business or floating along through your “consulting” career as a pseudo-employee.

Read More


A Slice of My Life: What I Do, Why I Have Money, and How It All Works

It occurs to me that I spend a good bit of time weaving narrative into my posts.  I tell personal anecdotes to ground stories, and I add in a good bit of figurative language.  But it’s always fairly superficial.  I don’t generally get heavily into my own story.  As an introvert, this makes sense, since talking extensively about myself or receiving compliments feels awkward.

But I’ve received a number of requests over the years like today’s reader questions.  So today, for reader question Monday, I’ll talk about this subject.  Here’s the reader question.

I’m interested in how you’d describe what a week, month or a single engagement in your shoes is like. I know a couple of people who are consultants and see them going out to coffee shops, meeting with clients to socialize and making pretty good money. I’d like to read an article about what your routine is like. Nothing where you give away client specifics or anything. I just think others who read your blog are taking in what you write about, putting what they find is useful into practice but are left wondering in their head ‘I wonder what work is like for Erik?’.

Before I dive in, it’s worth noting a couple of things.  First, I have to address this at different times because my life has changed a lot.  And, secondly, it really depends on what kind of consultant you are, so I’ll speak a bit to experiences other than mine as well.

I’m predicting a fairly long post on this one, so buckle up.  I’ve always found that it’s the absolute most difficult to be brief when I’m trying to explain myself, as if I’m constantly mounting a legal defense or something.  Anyway, here we go.

Modern, Reclusive Erik, A Day in the Life

For the last six months, most of my days look pretty similar, weekday or weekend.  I usually wake up around 9 and shuffle to the kitchen for some coffee, preparing to sit at my computer.  Morning time is usually writing time.  This isn’t for my personal edification or for my books, but for my growing content marketing business.  That typically carries me through lunch and a little after.

In the afternoon, I’ll spend some time handling emails, corresponding with clients, and working on the businesses, but that usually stops at some point.  For the last six months, I’ve been living in a house on a lake, featuring usually great weather, great scenery, and generally great marrow waiting to be sucked out of life.  So I go outside.  I jog, I kayak, I do a bit of yard work, I fish, or I make a fire in the fire pit and just enjoy my surroundings.  The weather is getting a little suspect for that here in late October, but we’re getting ready to head south for the winter.  So I expect this routine to continue.

After enjoying life a bit, I eat dinner and then either call it a day or go back to work, depending on how I feel.  This is typically non-writing “deep work.”  Minimal distractions after 8 PM, so I can get in a solid block of concentration until I go to bed around 2 or 3 AM.  Sometimes I also write during this time window.  Other times, I’ll work on software for my codebase assessment practice or my own longer form content marketing.

Why Does This Matter?

You’ll notice what I don’t really talk much about here: consulting.

That’s because I don’t honestly do much of it anymore.  And that’s by design.  I have engineered and hacked my life deliberately and specifically to look like this.

When I do consult these days, the clients seek me out, and I agree only after a heavy round of disqualification.

  • Is it a short term engagement (a few weeks or less)?
  • Will it pay enough really to be worth it?
  • Can I do it from anywhere?
  • Is it a high value, high leverage engagement for the client?

A “no” to any of these questions and many more results in a “no thanks” from me.

I give you this vision of my life, mostly “retired” from serial consulting in order to set the stage for the rest of the post.  Consulting is fun, rewarding, interesting, and lucrative when you do it well.  But it’s also a treadmill unless you specifically make it not one.  It’s the career equivalent of an interest only loan unless you’re careful.

Read More


DaedTech Digest: Agile, Code Review Horror Stories, Test Smells

First of all, some housekeeping.  Back when I finally gave Disqus the boot, it reverted comment settings to WordPress’s defaults.  One of these was, apparently, to turn off comments after 28 days.

Sorry about that.

Backlink spammers notwithstanding, I welcome comments on posts new and ancient.  So I want to be clear that I did not do this intentionally.

Alright, now, back to business.  I’m bringing you the second installment of the DaedTech digest wherein I aggregate some of my posts instead of cross posting.  The feedback on this format has, so far, been positive, inasmuch as I’ve gotten it.  So let me know if you have thoughts one way or the other.

This is part of a pivot that I’m planning with DaedTech, for which I’m currently ideating a bit on a mission statement for the blog.  I’m thinking at the moment that the mission, going forward, will be “helping software developers become the boss of their software development.”  This could include opportunist plays to earn promotions in the office as well as help with side hustles and going free agent.

And Now, the Digest

But, I digress.  Onto the digest.  Note that these posts are ones that I wrote some time back.  I’m doing beefed up digests to catch up, and then I’ll start linking you to the various posts I’ve written for clients during the week.

Anyway, I think that 5 a week should eventually get us current.  But, if not, I’ll crank up the juice on these.  Man, putting these together, I realize that I write a LOT of blog posts.  I guess it’s no accident that I wound up founding a blogging business.