DaedTech

Stories about Software

Apr
14

By

Gathering the Confidence to Leave Your Job

Category: You Asked For It Tags: | 4 Comments

It’s Thursday night, and I’m holed up in a hotel in Lansing, Michigan.  I figure there’s never been a better time to answer a reader question.  This one is about how to summon the confidence to leave your job.

The question is actually a rather lengthy one, and here is a redacted/obfuscated version of it (removing anything that could be identifying).

I have had my developer position for several years. I’ve been promoted, but I’m still not a senior developer. I have become extremely “silo-ed” in my skills, because those are the types of projects I’ve been assigned.  I read your statement that salaried employment is a bad economical decision for developers. The developer should be making $50 or maybe a bit more at $60. I get paid {a good bit less} an hour for 40 hours a week of expected work.  I feel the need to grow my abilities.

I watched your video on Pluralsight on how to propose practices. My manager bought into some,  but most of my coworkers are ignoring the new stuff.  My place of employment fires developers once they are called as a references for checking if they ever worked there.

I need a goal, something I can achieve to give me confidence to start pursuing other options. Something that gets me into a situation where people seek me for relevant development.

There are actually several questions and issues here to unpack, so I’ll tackle them in order of complexity.

Pay is Relative

First of all, when I talk about developers making 50 per hour/100K or 60 per hour/120K, I’m mainly catering to myself and ease of math.  100K is a nice, round figure, and 120K makes monthly finace (10K) easy to calculate.  These figures were slightly high in the Chicago-land area as of 2+ years ago, which was when I was last seriously hiring and evaluating pay there.

But, beyond that, pay varies a lot by geographic location, industry, filing status (nonprofit, for profit), etc.  If you salaried a developer working in San Francisco at 150K per year, he would probably need to move into a homeless shelter.  (I kid, but only slightly).  Pay that same wage to someone in central Kentucky and “should we install a second hot tub on the master bedroom deck” becomes a topic of debate around the marble dinner table.

All that being said, your wage was fairly low for a developer anywhere of your experience.  But don’t base your assessment of how low on my blog and what I know (I don’t pay much attention these days).  Base instead off of researching in your region.

We’ll Fire You for Looking…

Okay, this is where I offer the IANAL (I am not a lawyer) caveat.  This is based on my experience doing management consulting and working as a manager, much of which happened in at will states (this can vary by state and certainly by country).

If you’re a company, terminating employees is like playing Minesweeper, except instead of bombs, there are lawsuits.  You’re clicking along gleefully when suddenly, one day, BLAMMO!  Wrongful termination!  So you learn your lesson and you start looking at all of those numbers really carefully and insulating yourself against potential problems.

Minesweeper Read More

Apr
13

By

Are Your Arguments Falsifiable?

Category: The Life of a Programmer Tags: , | 4 Comments

Editorial note: I’d like to clarify something here upon re-reading this post.  When I refer to not engaging comments, I’m talking about in other venues (other blogs than mine, social media, and sites like reddit).  On this blog, I do my best to engage with everyone that takes the time to leave a comment, regardless of its contents.  Please don’t read this as any sort of deterrent to commenting — keep ’em coming!

These days, I’m writing for 6 blogs besides my own.  All of the posts get announced on social media and some of them wind up on commentary sites like Hacker News or Reddit, which means that there’s a lot of surface area, so to speak, for comments.  I make a good faith effort to respond, but I must confess that my response/comment ratio is declining amidst lots of writing and my consulting practice.

My failure to respond to a comment tends to fall into one of three categories.

  1. Never saw it.
  2. Saw it, made a mental note to come back and respond later, but “later” never came.
  3. /Sigh/

It’s this last, and admittedly enigmatic category, about which I’d like to talk today.

The Ones that Make Me Sigh

You’re probably thinking here that I’m talking about the occasional piece of random insult or profanity.  Perhaps someone leaves a comment on the site saying, “you’re a #&%$ing idiot.”  But no, it’s not that.  A comment like that (which is actually refreshingly rare) doesn’t induce much reaction in me one way or the other.  Just a half amused, half bemused, “well, okie dokie.”

OppenheimerChoking

The ones that make me sigh are comments that I think of as “specious definers.”  They are thoughts offered as correction and conversation advancement, but that wind up falling flat in a subtle way.  Make no mistake — these are thoughts offered in earnest, and I’m not complaining about tone or being corrected or anything like that.  Rather, I’m lamenting that I read, re-read, and re-read again, and realize that what I’m looking at is a near tautology.  It’s a non-falsifiable closed loop, to borrow slightly from Karl Popper.

Let’s get out of generalities and deal with a couple of examples.  Please note at this point that I’m operating off of admittedly imperfect memory, and thus paraphrasing.  I don’t know where either of these examples is nor even in what medium it was offered.  But please believe that I have no real interest in distortion here — the critiques are not objectionable.

Read More

Apr
10

By

Visualizing Your (Real) Architecture

Category: Reasoning About Code Tags: , | 6 Comments

Editorial note: I originally wrote this post for the NDepend blog.  Go check out the original at the NDepend site.  Take a look around at the other posts while you’re there as well — there’s a lot of good stuff to be had.

Diagrams of software architecture have a certain aesthetic appeal to them.  They usually consist of grayscale or muted pastel colors and nice, soft shapes with rounded edges.  The architects that make them assemble them into pleasing patterns and flowing structures such that they often resemble 7-layer cakes, pinwheels, or slalom courses.  With circles and ovals arranged neatly inside of rectangles connected by arrows, there is a certain, orderly beauty.  If you’re lucky, there will even be some fluffy clouds.

If you want to see an example, here’s one that has it all.  It’s even got a service bus.  Clearly, the battle for quality was over long before the first shots were ever fired.  After the initial conception of this thing, the mundane details of bringing the architecture to life would likely have been a simple matter of digital paint by numbers.  Implement an interface here, inherit from a framework class there, and Presto!  Instant operational beauty that functions as smoothly on servers as it does in the executive readout power point.

At least, that’s the plan.

Read More

Apr
7

By

Code Review Through the Years

Category: Language Agnostic |

What does a code review workflow look like, in your mind? Naturally, when I ask this question, you’re picturing life in 2015 with current tooling, work arrangements, and productivity tools. So when I say, “code review” you probably picture a whole lot more than peering at source code in some kind of file editor.

Maybe you’re imagining a multi-national, distributed, agile team working at different times of day. The team communicates using tools like Slack and various flavors of instant messenger (and, of course, the ubiquitous email). They no doubt use a sophisticated source control option, augmented with a variety of application management tools. Github comes to mind. And, that’s really just the start. Piggybacking on these capabilities for version controlling and communicating, the team probably employs relatively sophisticated heuristics for making sure all committed code gets a look from one or more other people, and they manage this complex communication with an equally sophisticated mechanism for allowing reviewers to zero in on exactly what has changed.

But perhaps the most beautiful thing about being a programmer in this day and age is that these impressive capabilities are pretty seamlessly managed. You can be sitting in London, where you make a series of simple, but cross-cutting, changes to a number of different source files. Then you can leave for the day, at which point a colleague in New York is notified that you have some changes to review. She can take a quick look, realize that the changes in which you’ve renamed a series of methods are extensive but low risk, and give you a thumbs up. She then kicks it over to another colleague in Los Angeles just for a quick second opinion, and delegates to him to make the final call. Once he takes a look and approves, there’s a mechanism to promote the code to a continuous integration environment, build it, run tests on it, and deploy it to production. Your changes are live the next morning when you come in.

We take this for granted, but, really, we’ve come a long way. Imagine what code reviews might have looked like in past eras of programming.

CarryingTooMuch

Read More

Apr
5

By

The Cost of Being Right

Category: The Life of a Programmer Tags: , | 4 Comments

I stopped in the gas station today to pick up a few sodas and iced teas.  It was a time-poor man’s grocery run here in Lousiana, where it was in the 80s today.  This expedition left me with a plastic bag full of sweating drinks, a soggy receipt, and a lesson about the cost of being right.

First off, let me just say that I was and am right.  About what you ask?  About the fate of my receipt.

The receipt wound up in the bag with the sweating sodas, where it became sodden.  This wouldn’t have happened if the clerk had done the right thing and handed me the receipt, or even the slightly less wrong thing and asked me whether I wanted the receipt in the bag or not.  Instead, she did the wrong thing, and stuffed it into the bag where it became waterlogged.  “Receipt’s in the bag!” she informed me cheerfully.  Ugh.

Here’s the problem.  I take all of my credit card receipts, fold them, and put them in my wallet.  When I get home, I record the credit card transaction in Quicken so that when I download actual transactions from the financial institution in question, I can compare and make sure there are no spurious charges.  This scheme requires a dry, legible receipt.

Now, I know what you’re thinking — this is a matter of personal preference.  I prefer being handed my receipt whereas you prefer to have it in the bag.  That’s an understandable sentiment, but I assure you that it’s wrong.  I have empirical thinking on my side.  If the clerk hands me the receipt and I want it in the bag, it takes me less than a second to stuff it in there.  If the clerk stuffs it in the bag and I want it in my hand, I have to hold up the line while I go rooting around in the bag, looking for it, only to find it plastered between two Diet Mountain Dews.  So, as you can now see, I’m right.

SoakedReceipt

By the way, I’m willing to keep up this line of argument until you get exhausted and concede that I’m right.

You might, then, think that I explained the error of her ways to the clerk.  Or not, if you know me well at all.  I didn’t.  I thanked her, smiled, and left the store.  Once home, I extracted my soggy receipt, did my best to make out the figures on it, and entered them into quicken.

You see, it’s not that I’m any less convinced receipt-handing is optimal (though I could be persuaded).  It’s just that being right about this isn’t important.  It’s not important enough to me to think any further on (after adding a note to use this as a blog post intro), and it’s certainly not important enough for me to comment on to the clerk or anyone else in my life.

Read More

« Older Posts
Newer Posts »