DaedTech

Stories about Software

By

Securing Yourself a Better Title

Tonight marked the vice-presidential debate and the start of the baseball playoffs.  With two spectator sports on television, I thought I’d draw some inspiration and answer a reader question about office politics.  This question came to me from a reader whose problem tracks back (in my opinion) to need for a better job title.  And it came in lengthy format, checking in about 1,100 words!

For the sake of both poster anonymity and brevity, I will summarize with as little information loss as possible.  My summary is as follows.

I finished a CS degree and took an entry level position.  From there, I took a job that involved writing code — automation around Selenium to be used by a QA group for testing.  I believe this mimics the role of Google’s “Software Engineer in Test.”  That said, the conferred upon me the title of “QA Engineer.”

For two years, I enjoyed the development work in this role and made inroads toward an advancement.  Before that happened, however, my company shuffled departments, and I found myself in a new part of the company, under a new boss.  This new boss only saw me for my title, rendering my progress moot.

I approached him about my situation and he agreed to put me on a more classic development team, but on a “probationary” basis.  He said that he’d consider a formal change in six months if I could work on defects and get my fix rate up to a certain number per week.  Six months later, at a review, he said that I had made definite progress, but that my rate of X per week was just not QUITE high enough and that we could talk again next year at performance review time.

What are my options?  What should I do next?  I feel that I’ve now fallen behind people of a similar, salary-wise, and I feel stuck in a rut.

GlumGuy

Title Matters

Let me start by offering a quick bit of context.  Recruiters and people offering you jobs with bad titles will tell you that titles don’t matter.  Don’t listen to recruiters and people offering you bad titles because titles do matter.

They matter because a job title counts as what I’ll call passive bargaining material.  When you navigate the waters of your career, you will have negotiation points where you look for more salary or benefits or whatever.  The actual negotiating constitutes the active component of this dance, and that matters.  But so does the passive portion: your previous/current title, salary, benefits, etc.

Don’t believe me?  If you’re a developer, cold-apply to a bunch of dev manager or director gigs.  No responses?  Try adding a fictitious 5 year stint as “Director of Software Engineering” to the top and try again.  Bet you get at least a few calls.

Read More

By

Software Architect as a Developer Pension Plan

I’m pretty sure that I’m going to get myself in trouble with this one.  Before I get started and the gnashing of teeth and stamping of feet commence, let me offer an introductory disclaimer here.  What I am about to say offers no commentary on people with the title, “software architect” (a title that I’ve had myself, by the way).  Rather, I offer commentary on the absurd state of software development in the corporate world.

The title “software architect” is silly (mostly because of the parallel to building construction) and the role shouldn’t exist.  Most of the people that hold this title, on the other hand, are smart, competent folks that know how to produce software and have the battle scars to prove it.  We’ve arrived at this paradoxical state of affairs because of two essential truths about the world: the corporation hasn’t changed much in the last century and we software developers have done an utterly terrible job capitalizing on the death grip we have on the world’s economy.

Architect

A Question of Dignity

I’m not going to offer thoughts on how to correct that here.  I’m doing that in my upcoming book.  Today, I’m going to answer a question I heard posed to the Freelancer’s Show Podcast.  Paraphrased from memory, the question was as follows.

I work for a small web development firm.  I was in a meeting where a guy said that he’d worked for major players in Silicon Valley.  He then said that what web and mobile engineers offer a commodity service and that he wanted us to serve as architects, leaving the less-skilled work to be done by offshore firms.  How does one deal with this attitude?  It’s a frustrating and demeaning debate to have with clients.

This question features a lot that we could unpack.  But I want to zero in on the idea of breaking software work into two categories: skilled work and unskilled work.  This inherently quixotic concept has mesmerized business people into poor software decisions for decades.  And it shows no signs of letting up.

Against this backdrop, “major player’s” attitude makes sense.  Like the overwhelming majority of the business world, he believes the canard about dividing work this way.  His view of the unskilled part as a commodity that can be done offshore smacks of business wisdom.  Save the higher-waged, smart people for the smart people work, and pay cheap dullards to do the brainless aspects of software development.

Of course, the podcast listener objects.  He objects to the notion that part of what he does fits into the “cheap commodity” category.  It “demeans” him and his craft.  He understands the complexities of building sites and apps, but his client views these things as simple and best delegated to unskilled grunts.

Why the Obsession with Splitting Software Work?

It bears asking why this thinking seems so persistent in the business world.  And at the risk of oversimplifying for the sake of a relatively compact blog post, I’ll sum it up with a name: Taylor.  Frederick Taylor advanced something simultaneously groundbreaking and mildly repulsive called Scientific Management.  In short, he applied scientific method principles to the workplace of the early 1900s in order to realize efficiency gains.

At first, this sounds like the Lean Startup.  It sounds even better when you factor in that Taylor favored more humanizing methods to get better work out of people than whacking them and demanding that they work harder.  But then you factor in Taylor’s view of the line level worker and you can see the repulsive side.

The labor should include rest breaks so that the worker has time to recover from fatigue. Now one of the very first requirements for a man who is fit to handle pig iron as a regular occupation is that he shall be so stupid and so phlegmatic that he more nearly resembles in his mental make-up the ox than any other type. The man who is mentally alert and intelligent is for this very reason entirely unsuited to what would, for him, be the grinding monotony of work of this character. Therefore the workman who is best suited to handling pig iron is unable to understand the real science of doing this class of work.

Basically, you can split industry into two camps of people: managers who think and imbeciles who labor.  Against this backdrop, the humanizing angle becomes… actually sorta dehumanizing.  Taylor doesn’t think grunts shouldn’t be whipped like horses because it’s dehumanizing, but because it’s not effective.  Better ways exist to coax performance out of the beasts.  Feed them carrots instead of hitting them with sticks.

Depressingly, the enterprise of today looks a lot like the enterprise of 100 years ago: efficiency-obsessed and convinced that middle management exists to assemble humans into bio-machines that needn’t think for themselves.  Nevermind that this made sense for assembling cars and textile manufacture, but not so much for knowledge work projects.  Like the eponymous cargo-culters, modern corporations are still out there waving sticks around in the air and hoping food will drop out of the sky.

Read More

By

My Realizations about Software Consulting

I consume a lot of audio books.  Most recently, this habit led me to listen to a book by Allen Weiss, called Million Dollar Consulting.  The title yields the book’s premise in deceptively simple fashion: a guide to building a seven-figure-per-year solo consulting practice.  Sound crazy?  Two and a half years ago, when I went into business for myself full time, I would have thought so.  Now, it sounds pretty doable to me, if that’s your thing.

BigPileOfMoney

This isn’t to say that have a million plus dollar per year consulting practice — just that I understand how someone could achieve what he’s talking about in a way that I couldn’t have back then.  Listening to this book gave me cause to reflect on my free agent journey, so I thought I’d write about that today.  (I know there are some who’ve wanted more of these posts anyway)

When I first took the free agent plunge, I had a fairly vivid picture of how it would work.  I was leaving a job running an IT department, and what I sought was a practice where I helped solve targeted technical problems for a portfolio of clients, rather than solving all sorts of organizational problems for a single entity.  I wanted both to diversify and to become more project-focused.

The Neophyte Techie Free Agent

Beyond that, I didn’t really have a firm grasp of the path to growing profit.  At the time, I assumed that technical consultants did what members of app dev groups did, but for much higher pay (due to transience and achieving better results).  That is, I might do a mixture of application development, architectural consulting, training, mentoring, troubleshooting, etc.

I’d start out charging, say, $100 per hour and then let supply and demand drive up my rates as I pleased more and more clients.  This, I reasoned, was the path to bill rates exceeding $250 per hour.  And, why not?  That seems to be how so-called app dev consultancies work, offering blended rates and billing out their principals and super-awesome-folks at $250/hour.

At the time, I remember chatting with John Sonmez of Simple Programmer.  He and I knew each other through the blogging community and through Pluralsight.  He’d made a similar career play a year or two earlier than I had, so I picked his brain about his journey.  He told me something quite memorable, in that it proved prescient, but was inconceivable to me at the time.  “I want to get away from trading hours for dollars.”  Huh.

Read More

By

The Business-Personal Value Continuum

While out on a jog recently, I found myself listening to an episode of .NET Rocks, in which the discussion covered the surprising percentage of developers still using Winforms and the general topic of using licensed controls written by third parties.  This started a train of thought in my head that might end in mild controversy, but I think it’s worth exploring a bit.

Two profiles (well, more like caricatures) of developer came to mind, standing in stark contrast to one another.  First is this Winforms developer that is more or less cobbling together spare parts to build applications. He uses a WYSIWYG editor, employs some kind of “database form wizard” to bind a GUI widget directly to a table, plops a slew of obscure third party controls into the code, and ships some kind of Franken-app not actually involving much code.  The second profile rounds out the dichotomy and consists of the foundational crafter.  This person builds her own tools and controls using low level language constructs and the command line, and assembles these works of art into ever-higher layers of abstraction until shipping a hand-crafted app.

If I’m running a business, give me the first person.

Undoubtedly, the crafter harbors a better, more fundamental grasp of the principles of computer science, and she undoubtedly offers the most versatility.  If she can build a compiler, use that to build a text editor, use that to build a source control system, use that to build a web server, and use that to build the sexiest, popping-ist, UX-friendliest website you’ve ever seen, she is the most employable, most full stackable programmer ever.  The business will never encounter a situation beyond her grasp.  But who cares, if the business just needs a checkbox added to a battleship gray, outdated Windows application?

Female Artist

I practice test driven development.  I rail against the evils of copy and paste programming.  I counsel clients on the dangers of technical debt and feature slow down.  I advocate wholesale for clean code.  And because of all these things, I understand that every single line of code you write is an incremental business liability.  So why would I take the cobbler over the crafter?  Don’t get me wrong — if I had to pick one of the two of them to write a given module, I would take the crafter.  But for approach, I would take the cobbler because the cobbler makes most of the code someone else’s problem while the crafter makes it all my problem.

What I really want is someone with the chops of a crafter and the reluctance to write more code than necessary of a cobbler.

Read More

By

Sources of Inspiration

A while back, I got a reader question that was extremely short and sweet.  It was, in essence, asking me about success that I’ve enjoyed.  Given that this is a subjective concern and that I wince at the prospect of self promotion (I’ve learned this is probably a matter of being an introvert), I’d rather deflect this and talk about things that have inspired me over the last number of years.  This post is about those sources of inspiration.

First, though, the reader question.

How did you get to where you are?

To answer that properly would require a good bit of introspection of the form, “where, exactly, do I think that I am.”  I’m not really prepared for that, not because I don’t like introspection, but because I’m pretty content with my life in these terms at the moment.  My life suits me well, but I wouldn’t presume to suggest that it suits others well.  This presents me with the challenge of answering the question, but without the typical, self-help template of “here’s what I did as a blueprint, and you can do it too!”

I think what would go better than that is to talk about some serious sources of inspiration over the last several years.  That way, rather than focusing on what particular things I’ve done, I can focus instead on what I’ve been trying to do and why.  This, I feel, will leave you in a better position to evaluate whether you want to understand “where” I am and whether you also want to be there.

For you mythology buffs, this is Sysiphus actually making it to the top of the hill.

In terms of format, I’m going to talk about four books that have helped me formulate and refine my more recent approach to life.  Using a good bit of wisdom from these books, I’ve gone from working as a software engineer to being an independent technologist.  My work is asynchronous, entirely remote (with some travel), and generally varied in nature.  This makes for a fun mix and it lets me live a pretty low key, mobile life.  All of this is no accident.

So, without further ado, here are the books that have contributed significantly to inspiring my choices.  I’ll describe them briefly, and then the impact they had upon my life.  Keep in mind that these are not in chronological order of my reading of them, but rather in the order I think makes sense to introduce them if you’re looking to pursue a similar path to mine.

Read More