DaedTech

Stories about Software

By

Why Expert Developers Still Make Mistakes

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, take a look at the most recent version of NDepend with an assortment of features around visualizing tech debt.

When pressed, I bet you can think of an interesting dichotomy in the software world.  On the one hand, we programmers seem an extraordinarily helpful bunch.  You can generally picture us going to user groups, conferences, and hackthons to help one another.  We blog, record videos, and help people out on Twitter.

But then, we also seem to tear each other apart.  Have you ever hesitated before posting something on Stack Overflow?  Have you worried that you’ll miss some arcane piece of protocol or else that you’ve asked a stupid question.  Or, spreading our field of vision a little wider, have you ever seen nasty comment sections and ferocious arguments?

We programmers love to help each other… and we also like to rip each other to shreds.  What gives?

Reconciling the Paradoxical

Of course, I need to start by pointing out that “the programming world” consists of many, many human beings.  These people have personalities and motivations as diverse as humanity in general.  So naturally, contradictory behavioral tendencies in the population group can exist.

But let’s set that aside for a moment.  Instead, let’s try to squish the programming community into a single (if way over-generalized) human being.  How can this person be so helpful, but also so… rude?

The answer lies in understanding the protocol of helping.  The person presenting the help is an expert.  Experts enjoy explaining, teaching, offering opinions, and generally helping.  But you’d also better listen up the first time, pay attention to the rules, and not waste their time.  Or they’ll let you hear about it.

In the programming community, we gravitate toward conceptual, meritocratic ladder ranking.  Expert thus becomes hard-won, carefully guarded status in the community.  Show any sign of weakness, and you might worry that you’ll fall down a few rungs on the ladder.

Read More

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

An Introduction to the Types of Cloud Computing

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 around at some of their other authors and content.

The folks at Gartner have something awesome called the “hype cycle”.  The cycle contains a “peak of inflated expectations” and a “trough of disillusionment”.  So, that alone gives it a pretty significant amusement factor.

But beyond the amusement lies an important insight into our collective psychology.  Those of us working in tech work in a booming and constantly evolving industry.  Because of this, we find ourselves bombarded with buzzwords.  These generate excitement at first and disillusionment later.  Eventually, they reach equilibrium.

Gartner uses this set of observations to advise companies about risk.  But we can use it to identify a term’s likelihood to induce buzzword fatigue and produce derisive satire.

Let’s get specific.  Do you remember a few years back, when “X as a service” really took off?  The world seized on the promise of the cloud.  Don’t maintain it yourself — have a service do it!  As the term rocketed up the peak of inflated expectations, everyone wanted a part of the cloud.

But then it fell into the trough of disillusionment, and satire ensued.  Twitter accounts offered “sarcasm as a service” to poke fun at the hype.  If you saw an offering for “everything as a service,” you had no idea whether it was serious.

Since this time, however, these offerings have ascended the so-called “slope of enlightenment” and established themselves as mainstream.  Actually, let me correct that.  They have established themselves as foundational to the modern internet.

Let’s now unpack this X as a service concept a bit.  In order to do that, I’ll offer a story in contrasts.

The “As a Service” Concept

Imagine that I own a small business.  In this capacity, I want to keep track of prospects, leads, and customers for sales purposes.  You can think of this as “customer relationship management” (CRM) software.

Back in the early days of my career (late 90s, early 2000s), you might have done this with Excel.  At least, you would have used Excel until it became too unwieldy.  Then, you’d have gone to Best Buy and purchased software that you installed from a CD.  Finally, you’d have installed the “client” on anyone’s PC who needed to use it while installing the “server” on some jack of all trades machine running Windows 2000 or something.  From there, using it was as easy as making sure not too many people tried to change things at once.

Fast forward a couple of decades and that seems… odd.  These days, you’d probably just navigate to something like salesforce.com and create a trial account.  Certainly small business owners would take this approach.  Larger organizations with more privacy concerns might still setup servers and install their own software.  But even the ones doing this would probably host a web app and have “clients” access it via browser.

This tale drives at the essence of “as a service.”  Stuffed into that small phrase, you find the large, important concept of “let someone else worry about it.”  You shouldn’t need to think about clients, servers, networks, and the like to have a CRM system.  Let someone else worry about it.  You just want to sign in via the browser.

This concept has become so important and so ubiquitous that it drives today’s internet.  But not all cloud, “as a service” concepts are created equal.  Let’s take a look at the major types of cloud computing, by conceptual level.

Read More

By

The Key to Becoming a Software Consultant

Recently, I made an idle threat on Twitter (shown below).  I was thinking of creating some content along the lines of how to go from being a software developer to a software consultant.  People ask me about this all the time, and it makes for an interesting subject.  I was also flattered and encouraged by the enthusiastic response to the tweet.

I’m still mulling over the best delivery mechanism for such a thing.  I could do another book, but I could also do something like a video course or perhaps a series of small courses.  But whatever route I decide to go, I need to chart out the content before doing anything else.  I could go a mile wide and a mile deep on that, but I’d say there’s one sort of fundamental, philosophical key to becoming a software consultant.  So today I’d like to speak about that.

Software Consultant, Differentiated

I won’t bury the lede any further here.  The cornerstone piece of advice I’ll offer is the one upon which I’d build all of the rest of my content.  You probably won’t like it.  Or, you’ll at least probably think it should take a back seat to other pieces of advice like, “be sympathetic” or “ask a lot of questions” or something.  But, no.

Don’t ever let would-be consulting clients pay you for code that you write.

Seriously.  That’s the most foundational piece of your journey from software developer to software consultant.  And the reason has everything to do with something that successful consultants come to understand well: positioning.  Now, usually, people talk about positioning in the context of marketing as differentiating yourself from competitors.  Here, I’m talking about differentiating yourself from what you’re used to doing (and thus obliquely from competitors you should stop bothering to compete with: software developers).

Let me explain, as I’m wont to do, with narrative.

Leonardo Da Vinci: Renaissance Plumber

By any reckoning, Leonardo Da Vinci was one of the most impressive humans ever to walk the planet.  Among his diverse achievements, he painted the Mona Lisa, designed a tank, and made important strides in human anatomy.  But let’s say that, in a Bill and Ted-like deus ex machina, someone transported him 500 years into the future and brought him to the modern world.

Even someone as impressive as Leonardo would, no doubt, need a bit of time to get his bearings.  So assume that, as he learned modern language, technology, and culture, he took a job as a plumber.

Leonardo Da Vinci as a plumber to help you understand the difference between software developer and software consultant

Let’s assume that you happened to have a leaky sink faucet, and you called Leonardo’s plumbing company for help.  They dispatched him forthwith to take a look and to help you out.

So Leonardo comes over and, since he’s Leonardo, figures out almost immediately that your supply line has come slightly loose.  He tightens it, and you couldn’t be more pleased with the result.

Read More

By

You Can Use GhostDoc’s Document This with JavaScript

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 GhostDoc for your code documentation and help file generation needs.

If you haven’t lived in a techie cave the last 10 years, you’ve probably noticed JavaScript’s rise to prominence.  Actually, forget prominence.  JavaScript has risen to command consideration as today’s lingua franca of modern software development.

I find it sort of surreal to contemplate that, given my own backstory.  Years (okay, almost 2 decades) ago, I cut my teeth with C and C++.  From there, I branched out to Java, C#, Visual Basic, PHP, and some others I’m probably forgetting.  Generally speaking, I came of age during the heyday of object oriented programming.

Oh, sure I had awareness of other paradigms.  In college, I had dabbled with (at the time) the esoteric concept of functional programming.  And I supplemented “real” programming work with scripts as needed to get stuff done.  But object oriented languages gave us the real engine that drove serious work.

Javascript fell into the “scripting” category for me, when I first encountered it, probably around 2001 or 2002.  It and something called VBScript competed for the crown of “how to do weird stuff in the browser, half-baked hacky languages.”  JavaScript won that battle and cemented itself in my mind as “the thing to do when you want an alert box in the browser.”

Even as it has risen to prominence and inspired a generation of developers, I suppose I’ve never really shed my original baggage with it.  While I conceptually understand its role as “assembly language of the web,” I have a hard time not seeing the language that was written in 10 days and named to deliberately confuse people.

Read More