DaedTech

Stories about Software

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

By

Automated Code Review to Help with the Unknowns of Offshore Work

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, take a look at CodeIt.Right, which offers automated code review feedback.

I like variety.  In pursuit of this preference, I spend some time management consulting with enterprise clients and some time volunteering for “office hours” at a startup incubator.  Generally, this amounts to serving as “rent-a-CTO” for for startup founders in half hour blocks.  This provides me with the spice of life, I guess.

As disparate as these advice forums might seem, they often share a common theme.  Both in the impressive enterprise buildings and the startup incubator conference rooms, people ask me about offshoring application development.  To go overseas or not to go overseas?  That, quite frequently, is the question (posed to me).

I find this pretty difficult to answer absent additional information.  In any context, people asking this bake two core assumptions into their question.  What they really want to say would sound more like this.  “Will I suffer for the choice to sacrifice quality to save money?”

They assume first that cheaper offshore work means lower quality.  And then they assume that you can trade quality for cost as if adjusting the volume dial in your car.  If only life worked this simply.

What You Know When You Offshore

Before going further, let’s back up a bit.  I want to talk about what you actually know when you make the decision to pay overseas firms a lower rate to build software.  But first, let’s dispel these assumptions that nobody can really justify.

Understand something unequivocally.  You cannot simply exchange units of “quality” for currency.  If you ask me to build you a web app, and I tell you that I’ll do it for $30,000, you can’t simply say, “I’ll give you $15,000 to build one half as good.”  I mean, you could say that.  But you’d be saying something absurd, and you know it.  You can reasonably adjust cost by cutting scope, but not by assuming that “half as good” means “twice as fast.”

Also, you need to understand that “cheap overseas labor” doesn’t necessarily mean lower quality.  Frequently it does, but not always.  And, not even frequently enough that you can just bank on it.

So what do you actually know when you contract with an inexpensive, overseas provider?  Not a lot, actually.  But you do know that your partner will work with you mainly remotely, across a great deal of distance, and with significant communication obstacles.  You will not collaborate as closely with them as you would with an employee or an local vendor.

Read More

By

What Problems Do Microservices Solve?

Editorial note: I originally wrote this post for the TechTown blog.  You can check out the original here, at their site.  While you’re there, have a look at the tech courses they offer.

Do you find that certain industry buzzwords set your teeth on edge?  If so, I assure you that you have company.  Buzzwords permeate every professional space, but it seems that tech really knows how to attract them.  Internet of things.  The cloud.  Big data. DevOps.  Agile and lean.  And yes, microservices.

Because of our industry’s propensity for buzzwords, Gartner created something it calls the hype cycle.  It helps their readers and clients evaluate how much attention to pay to emergent ideas.  They can then separate vague fluff from ideas that have arrived to stay.  And let’s be honest — it’s also a funny, cathartic concept.

If you’ve tired of hearing the term microservices, I can understand that.  As of 2016, Gartner put it at the peak of inflated expectations.  This means that the term had achieved maximum saturation a year ago, and our collective fatigue will drive it into the trough of disillusionment.

And yet the concept retains value.  Once the hype fades and it makes its way toward the plateau of productivity, you’ll want to understand when, how, and why to use it.  So in a nod toward pragmatism, I’m going to talk about microservices in terms of the problems that they solve.

First, What Are Microservices?

Before going any further, let me offer a specific definition.  After all, relying on vague, hand-waving definitions is the main culprit in buzzword fatigue.  I certainly don’t want to contribute to that.

Industry thought leader Martin Fowler offers a detailed treatment of the subject.

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.

Now, understand something.  The architectural trade-off here is nothing new.  In essence, it describes centralizing intelligence versus distributing it.  With a so-called monolith, clients have it easy.  They call the monolith, which handles all details internally.  When you distribute intelligence, on the other hand, clients have more burden to figure out how to compose calls and interactions.

The relative uniqueness of the microservices movement comes from taking that tradeoff and layering atop it delivery mechanisms and the concept of atomic business value.  Organizations touting valuable microservices architectures tend to offer them up over HTTP and providing functionality that stands neatly alone.  (I make the distinction of valuable architectures since I see a lot of shops just call whatever they happen to deliver a microservices architecture.)

For example, a company may offer a customer onboarding microservice.  It can stand alone to create new customers.  But clients of this service, internal and external, may use it to compose larger, more feature-rich pieces of functionality.

So, having defined the architectural style, let’s talk about the problems it solves.

Read More

By

Unit Testing: Basics and Best Practices

Editorial Note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, have a look at their tools to help you track down and fix production issues.

A couple of year ago, I wrote a book about unit testing.  Now, I didn’t just sit down one day and decide to do it, and no big publisher commissioned me to do it.  The book started from humbler origins and grew somewhat organically.

It started as a series of presentations I did for groups new to the practice.  With more feedback and requests, it then grew into a blog post series and longer presentations.  Eventually, due to even wider demand, I made it into a book.

What was it that made this particular content so appealing, when no shortage of authors address this topic?  I feel pretty confident that it was the lead into the topic.  “You still don’t know how to unit test, and your secret is safe with me.”

When I started in this industry, only an avant garde fringe wrote automated tests for their code.  Over the last 15 years, however, that number has exploded, and the practice has become mainstream.  But “mainstream” does not mean “universal.”  Plenty of folks still do not have comfort with, or even exposure to the practice.  And yet, a form of peer pressure causes them to play that close to the vest.

So I reached out to these folks to say, “hey, no worries.  You can learn, and you don’t even have to climb too steep of a hill.”  I’d like to revisit that approach again, here, today, and in the form of a blog post.

Let’s get started with unit testing in C#, assuming that you know absolutely nothing about it.

Read More

By

Reader Question Roundup: Working at Google, Remote Freelancing, and Side Projects

I’m doing reader question Monday on a Tuesday once again.  But this time it’s not my fault.  You can thank organized labor for interrupting your reader question Monday with their US holiday yesterday.

I did this once before, and I’m going to dust it off and do it again.  You folks send me far more questions than I can answer at a pace of once per week.  And thanks for that!  It’s awesome.

The result is an ever-growing backlog of questions.  And, while I may start doing something ala John Sonmez with his youtube channel, where he answers a lot of reader questions as videos, for now, I’ll try to catch up a little bit by answering several in a single post.

On the docket today, an eclectic mix that hopefully you find interesting.  I’ve picked questions likely to be relevant to a decent cross section of folks.

Read More