DaedTech

Stories about Software

By

Find Clients and Win Them Over

Ah, the mission to find clients.  Critical for any business, obviously, but especially daunting for the newbie solo consultant or freelancer.  Today’s reader question solicits advice on how to tackle this.

I like your ideas for future topics. I’d love to see more on how to find and win clients. Not just general marketing, but actual sales.

Now, please forgive some introductory digression here.  But I honestly can’t conceive of how to talk about sales without talking about marketing.  Reason being, your marketing (or lack thereof) will heavily influence your sales strategy.

Personally, I don’t do a lot of sales.  At least, I don’t do them in the traditional, numbers game sense.  When I look back over the last couple of years, almost all client-facing work started with clients seeking me out.  The only exceptions included past clients, where sales looks a lot different.

As you might expect, this dynamic heavily influences my sales discussions.  I’m almost always in a favorable negotiating position, not really needing the work.  And the mission to find clients?  I haven’t historically needed to do that a lot.  All this because of my years-long investment in personal branding and marketing.

I say this not to brag, but to illustrate the degree to which your marketing affects your strategy for identifying prospects and pitching to them.  And now, I’ll seize an opportunity to stop talking about myself and start talking about the general would-be freelancer/consultant.  But I will have to talk a bit more about the marketing (though not in the how-to sense).

The Silly Market for Software Work

If you put on a marketer’s hat and look at people selling software development labor, you’ll have a hard time knowing whether to laugh or cry.  I saw this site, recently, called “Code Fights.”  Assuming I understand its charter correctly, it perhaps epitomizes the bizarre market for our labor.  The site encourages you to compete with tens of thousands of people for extremely similar work.

We don’t think anything of this when it comes to finding generalist programming jobs.  But recall how I’ve talked about generalist programming not being strategic.  And if you want to go into business for yourself, you can’t afford to tilt at algorithm trivia and programming competition windmills instead of being strategic.

Think of it this way.  Imagine that someone came to you and solicited your advice on starting a business.  Would you say the following to them?

Here’s what you should do.  Take something that tens of thousands of other companies are doing, and do that.  It’ll be hard to differentiate yourself, but don’t worry.  There’s this website where you can practice by playing games…

It’s so preposterous that I’m going to stop right there because I’m actually laughing as I type it.  In the business world, you don’t respond to market competition this way at all.  Instead, you seek to differentiate your offering in a way that plays to your strengths.

Read More

By

The Hidden Costs of Slow Websites

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at all of the different monitoring solutions they offer.

The world seems to conceive of a curious bubble separating IT from “the business.”  More so than just about any other pursuit in the commercial world, people think of IT as some kind of island.

It thus becomes easy to conceive of IT goals existing in a vacuum.  “We should optimize the database so that it becomes better.”  “We should make this software work on all platforms.”  The part about “… because that will help us make money” seems never to materialize.

Agile methodologies like Scrum seek to address this separation by encouraging tight interaction between IT and business interests.  Doing this closes the loop between technical actions and profit motives.  “We should make this software work on all platforms in order to increase revenue by 50%.”

If we look at the world of company websites, we can find the ubiquitous argument for faster page load times.  “The site should load faster.”  Today, I’d like to make the business case for why we want this.

But I’d like to dig a little deeper than the most obvious cost.  To understand that, consider articles like this one.  Users tend to bounce in the face of multi-second page loads.  As a result, slow performance could cost a high-throughput giant like Amazon billions of dollars.

I doubt that news shocks you.  So, instead, let’s take a look at more subtle ways that your business can lose money via a slow site.  Let’s examine hidden costs of slow websites.

Read More

By

How to Freelance: The Low-Risk Path from Software Developer

Ah, the eternal opportunistic question: how to freelance?  You work as a software developer, making $100K per year or something.  This is a great wage, and so you have a great life, sitting pretty high up atop Maslow’s famed hierarchy.  But then you figure out that Steve in your group is actually a contractor, and a little later, you figure out that they pay Steve $70 per hour.  A quick google search for “work hours per year” and fast math tell you that Steve makes $145,600 per year (so you think, anyway).  Suddenly, you feel less like a prosperous citizen and more like a sucker.

How to Freelance like Steve and make big money

How can I get some of that Steve money?

Not far behind that thought comes another.  I should become a contractor!  And then, finally, we get back to the titular concern: how to freelance?

The Reader Question and Some Housekeeping

As regular readers may have deduced, I’m doing a reader question today.  And, as regular readers may have noticed, I haven’t done reader questions (or DaedTech-only posts) in a while.  Please forgive me on that count.  I spent a lot of writing energy on my recent book launch and then even more on starting a tech company blogging business.  With all of that writing, I’ve had trouble mustering spare writing cycles the last few weeks.

But I’m turning a corner on that and launching the first of what will be a series: “reader question Fridays.”  I’m making the vision of this site more and more oriented around the Developer Hegemony vision (software developers becoming the bosses of software development), so please fire away with questions.  I take all comers, but I’ll prioritize questions that speak to the subject of software developer agency.

Anyway, I’ll paraphrase the reader question.

I currently work as a salaried software developer.  I think I’d like to figure out the freelance thing, but I’m not sure.  It’d mean a lot of risk to quit my job and hang out my shingle, so I’m wondering what you advise to make this a less risky transition.

I actually wrote about a related topic recently.  But that question more concerned my personal background and how to become a consultant.  Freelance software development is not, in my opinion, consulting.  I refer to people who do that as software pros.  Firms pay consultants for their opinions and they pay software pros for their labor.  I draw the distinction here because software pros need to worry a lot less about specializing and niching — at least at first.

But forget about the taxonomy and let’s look at how to become a freelance software developer with a low risk playbook.

Read More

By

Software Craftsmanship is Good Business

Tonight, I logged into my site and saw a picture of someone’s colon, compliments of everyone’s favorite NSFW advertising engine, Disqus.  (Read more about this here).  Enough is enough, so I switched commenting engines.  Please bear with me and let me know if you have issues with comments.

On a less aggravating note, please enjoy post number 4 of Developer Hegemony week!  Pre-launch activities are progressing nicely, and I’m looking forward to the launch.  If you’d like a free paperback copy of the book, remember to sign up for the Thunderclap.IT campaign so that we can get to the sharing threshold — we’re halfway there, but I still need your help.  It only takes a second.

I feel as though I’d like to balance the scales a bit.  Lately, I’ve made a lot of realpolitik posts about how organizations cast software developers as grunts.  This is true, but also depressing.  So let’s talk about the uplifting alignment between well reasoned code and success in career and business.

Raw Programmer Skill and Diminishing Marginal Returns

First of all, I should point out that I talk a good bit about the diminishing marginal returns of programming skill, both in posts and in Developer Hegemony.  And I stand by that.  To understand why, I invite you to do a thought exercise with me.

I’m pretty sure that most of you programmers reading, if you were so inclined, could go out and find a new job within a few weeks.  And, what’s more, you could probably negotiate a 5% pay increase to switch.  Did you suddenly become 5% better at programming?  Or would you acknowledge that programmer pay doesn’t necessarily correlate simply with programmer skill?

The industry isn’t meritocratic.  Of course, the industry is also not anti-meritocratic.  Rather, if programmer skill and programmer pay had a mutual Facebook relationship status, they would choose it’s complicated.

I would further reinforce the point about diminishing returns.  Go from zero to decent programmer and you might go from 30K per year for non-degreed work to $90K per year for programming.  Go from decent to highly skilled, and you can climb to $120K, which feels less life-changing.  Beyond $120K, your increased skills help you not a lick at puncturing the software developer’s glass ceiling.  Diminishing returns on skill investment.

Good vs Valuable

But don’t despair.  Winning programming “contests” and algorithm trivia jousts won’t pay off, but that doesn’t mean that you can’t make your software career pay off.  You just need to understand what businesses value.

So far, all we’ve done is figure out what they don’t value.  Namely, they don’t value journeyman idealist pissing contests.  The company will say, “it’s great that you can write a compiler on the back of a napkin and have it work flawlessly the first time it’s transcribed and run, but I only want that within the Software Engineer IV salary band.”  The company doesn’t value this prodigious industry cred the way your peers do.

And why should they?  If the company sells cable modems, how does that compiler help them?  “I can see that you’re quite good, but we don’t find this valuable.”

The trick then becomes establishing yourself as valuable.  And, while valuable and good have a deeply intertwined relationship, you cannot simply interchange them.  I submit that the software craftsmanship ideal offers you a ready-made playbook for turning good into valuable.

Read More

By

Managing Risk via Static Analysis

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original here, at their site.  While you’re there, take a look at the features of NDepend and download a trial, if you’re so inclined.

When software developer talk about static analysis, it’s often in the context of craft improvement.  Ask most developers in a group about static analysis tools and you’ll get a range of responses, many of which will be fueled by some degree of passion, resulting from past experience.  From here, the conversation will tend to dive into the weeds for any non-technical stakeholder that might be listening; if you’re not a programmer, you probably don’t have much of an opinion as to whether or not cyclomatic complexity of 5 is acceptable for a method.

As a result, static analysis tends to get pegged heavily as a purely a matter of shop.  The topic tends to be pretty opaque to management because developers present it to them in terms of “this will make us better and the code better.”  Management that trusts the developers will tend to agree to the purchase with a sentiment of, “okay, I’ll take your word for it.”  Management that is more skeptical says, “maybe next year if our numbers are good.”

I find this to be a shame because it’s a lost opportunity, even when management agrees.

Static analysis most certainly is a way for developers to improve their craft and their codebases.  But, in the hands of an architect or team lead that truly understands the business and works well with management, static analysis can be an excellent tool for managers, even if the use has to be a management-architect team effort.

How so?  Well, there are a lot of ways, but the one I’d like to mention today is risk management.  As the title would imply, managing risk tends to be the purview of people whose title is manager.  Sure, the developers have responsibility for this, but their primary charter is to build stuff — management exists specifically to engage in planning activities, including the crucial concern of risk management.

How does this work?  Well, I’ll show you, and I’ll do it by explaining the sort of highly technical things that static analysis could catch in highly non-technical and readable ways.  These are all going to be operational risks — static analysis can’t help you if you’re building the wrong product or badly under-staffing your projects.  But it can help you avoid landmines in your software.  If you’re a manager, allow me, for the moment, to serve as your “business-savvy architect.”

Architect

Read More