DaedTech

Stories about Software

By

DaedTech Digest: Analysis Rules, Singletons, and Log Aggregation

Happy Friday, DaedTech readers!  Time for yet another installment of the DaedTech Digest.

I didn’t do one last week because of the US holiday.  For those of you not from the US, there’s this holiday called Black Friday that everybody celebrates by getting together and eating turkey the day before and then subsequently bludgeoning one another in retail stores the next day.  Out of respect to this noble tradition, I held off on making a post.

At any rate, it’s been a busy couple of weeks in my world.  We’ve migrated south for about 5 weeks and are living in a beach town on the Gulf of Mexico.  This photo below is a shot of where I’m working from today as I type this post.

So life is good.  With that in mind, let’s get to picks.

Picks

  • The jury isn’t totally back yet on this, but we’re trying out FreshBooks for managing Hit Subscribe‘s books.  And, so far, it’s great.  And it integrates with other favorite Gusto besides.
  • I’ve been listening to an Audiobook called How to Measure Anything, and enjoying it.  Any consultant worth his or her salt spends a lot of time figuring out how to quantify problems and solutions, and this is definitely helpful.
  • The folks at a site called Data Camp reached out to me about the study I’m doing over at the NDepend blog.  They seem to be developing a cool offering for teaching people about data science using Python and R.
  • I also pick time off.  I work very much on my own schedule and generally not full 8 hour days anymore.  But I also do tend to work 7 days a week.  Last weekend, Amanda and I played tourist and did nothing but explore the Gulf Coast, buy fresh seafood off of piers, dine out, explore new cities, and walk through state parks.  This was nicely restorative.

DaedTech Post Digest

  • In my consulting (and even long-ago salaried) travels, I’ve encountered a lot of myths about code reviews.  I wrote a post for the SubMain blog in which I looked at some of those.
  • I wrote a post for NDepend, in which I explored a topic probably not many have.  What’s the role of static analysis in your testing?   These things might seem orthogonal, but I think they actually have an interesting relationship.
  • Also for SubMain, I did a post in the CodeIt.Right Rules Explained series.  I examined why you should avoid single line if statements, why you shouldn’t base your enums on weird underlying types, and the problem with explicit rethrows.  All of this in C#, BTW.
  • In a post that went a little viral and predictably resulted in people calling me a know-nothing incompetent, I wrote about what the singleton design pattern costs you.  This was for the NDepend blog, again.  (But I’d have the last laugh later, when I would actually study it empirically and prove myself mostly right — stay tuned for that in a future digest.)
  • In a much less controversial post (because they don’t enable comments), I made the business case for unit testing on the ASPE blog.
  • For Scalyr, I wrote a post about log aggregation.  What is this, why would you want it, and how does it help you?

And, that does it for the digest round up.  Have a great weekend!

By

Become a Software Specialist with the Help of Your Resume

One of my aims with this blog is to help software developers take charge of the business of writing software.  And, while I love writing rants and diatribes, doing this requires a good bit of positively focused how-to sorts of things.  Today, I’ll charge at one of those: how to become a software specialist in a world of low status generalists.

To specialize, you need look no further than your resume.

But I’ll come back to that in a bit.  First, you need to understand the essential sales problem of the software developer, from a labor perspective.

Individual contributor software development is a terrible business model!

Before you pick up the pitchforks and torches, hear me out.  I realize you’ve earned a good living writing code for some product company or agency.  I’ve done that too in my life.

You can earn a good living this way.  But you can’t really conduct good business this way.  So when software developers hang out their shingles after years of salaried employment, things can go sideways from a leverage perspective.  Mostly, people in this position become contractor staff augmentations that look a lot like employees.  Why is that?

It’s because of an incoherent value proposition: selling code-writing-labor.

To make money as a business-person, you need a customer.  I don’t mean a nameless, faceless corporation.  I mean a middle aged guy named Stan.  Or maybe a hard charging woman in her early thirties named Ashley.  You need a buyer, represented by an actual human persona that you can picture and speak to.  And this person has to be able to afford your services.

Who is this person that can buy tens or hundreds of thousands of dollars of your labor?

The Case of the Split Persona

At this point, you’re probably picturing Stan as an architect or Ashley as a tech lead.  But those people don’t have tens or hundreds of thousands of dollars.  In terms of company money, they have zero dollars and zero cents, unless the company gives them like a $1200 per year training budget.  That doesn’t buy a lot of your app dev, does it?

You want a 3 to 12 month app dev gig, which goes on the market for $50,000 to $200,000.  Do you know who signs off on buying that?  A director named Sheila.  And do you know what Sheila will say if you come to her and tell her that you’re really looking to work on a Node.js-this and a React-that?  She’ll tell you that you need to talk to someone that reports to someone that reports to her.  She can’t remember their names off the top, but, you know what, just send your resume to HR or something.  (I’ve written more on this here.)

When you try to sell a keyword-heavy resume as your value proposition, you create an existential conundrum for yourself.  The people that understand what you bring to the table can’t afford you.  And the people that can afford you can’t conceive of what problem you purport to solve.

The only way you can make sales is to sell to a system — an algorithm involving various people and committees and whatnot.

And that’s a recipe for either going out of business or floating along through your “consulting” career as a pseudo-employee.

Read More

By

The Programmer Skill Fetish, Contextualized

I am currently considering something of a content pivot for DaedTech.  I haven’t really decided anything for sure yet, but I’m leaning toward putting cross posts into digest format once per week and then doing fewer posts, but ones that are more focused on developer empowerment and the efficiencer dream.  Your feedback on this is entirely welcome in the comments or on Twitter or Facebook or anywhere, really.  I’d honestly like to know what you think.

I mention that because I think I need to refocus a little on some hypotheses that underpin all of this.  In the time between writing Developer Hegemony and now, I’ve found myself distracted by changing my lifestyle, selling a house, starting a couple of businesses and, well, life.  But throughout that time, I’ve given some thought to what I ought to offer people with this site.  Should I continue (against the advice that I offer everyone else blogging with purpose) to keep the blog as a chronicle of my many thoughts?  Or should I orient it around a theme in which I help people solve some kind of problem.

And I’m leaning toward trying to solve a problem.

So back to the hypotheses.  First one that I’ll mention is that programmers should specialize and seek options outside of full time employment.  (Not as in immediately making it your goal to escape the rat race.  Rather, make it your goal to have options outside of serving at the pleasure of some single employer.)  The second one, following from that first, is that we focus on programmer skill to the point of fetishizing it.  And, we do this to our detriment.

The Known, But Unheeded, Career Wisdom for Programmers

Let me lay out a few points that surround the issue.  None of these will probably be especially new to you, but taken together, they’re interesting.

  • You often hear some variant of “part of being a great developer is knowing when NOT to write code.”  In other words, being really good at writing code helps no one if you code up a useless product.
  • Successful “entreprogrammer” John Sonmez, in promoting his “Soft Skills” book, often talked about how he wasn’t successful because he was the best programmer, but because he learned the material that he was communicating in the book — strategies for business and dealing with other people.
  • In most organizations, it’s not necessarily the “best” programmers that wind up with higher pay and vanity titles like “senior,” “tech lead” and “architect.”  It’s generally the longest tenured ones.  Long time readers will remember my writing on this subject.
  • Businesses and non-technical people often don’t listen to the “best” developers, often because those developers take pride in spewing jargon and being indecipherable.
  • We can’t even define “best” programmers.  Do a google search on it.  Page one alone promises more than 100 answers.  These include technical knowledge, but also things like “positive attitude” and “good communication skills.”

Put all this together, and you have an interesting picture.  The business world and the greater non-programming world in general values one thing.  Programmers, when we get together, value something different.  We’re fully aware of how outsiders value us, but we just can’t resist the impulse to compare ourselves to others with code competitions, programming challenges, data structure interviews, and claims that we’re “10x” better than others.

The Skill Fetish, Explained Indirectly

This brings me to what I think will be the fun part about writing this post.  I want to use a metaphorical story to help bring context to why we do this, and how shotgun-blast-to-our-own-feet it is.  It’s easy enough to sit there in the waiting room of GiganTech, waiting to see if they deem you better at O-notation than the other 430 applicants, and get caught up in all of this.  It becomes normal.  So I’m going to draw a parallel to a different line of work.

I did this to an extent in Developer Hegemony, but as part of a larger point about journeyman idealists.  Here, I’ll get more direct.

The teenage gym rat makes an interesting metaphor for our preoccupation with programmer skill.

Read More

By

Add Custom Content to Your Documentation

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 not only to help you with comment management and generation, but also to help you construct automated help documentation.

For the last several years, I’ve made more and more of my living via entrepreneurial pursuits.  I started my career as a software developer and then worked my way along that career path before leaving fulltime employment to do my own thing.  These days, I consult, but I also make training content, write books, and offer productized services.

When you start to sell things yourself, you come to appreciate the value of marketing.  As a techie, this feels a little weird to say, but here we are.  When you have something of value to offer, marketing helps you make interested parties aware of your offer.  I think you’d like this and find it worth your money, if you gave it a shot.

In pursuit of marketing, you can use all manner of techniques.  But today, I’ll focus on a subtle one that involves generating a good reputation with those who do buy your products.  I want to talk about making good documentation.

The Marketing Importance of Documentation

This probably seems an odd choice for a marketing discussion.  After all, most of us think of marketing as what we do before a purchase to convince customers to make that purchase.  But repeat business from customer loyalty counts for a lot.  Your loyal customers provide recurring revenue and, if they love their experience, they may evangelize for your brand.

Providing really great documentation makes an incredible difference for your product.  I say this because it can mean the difference between frustration and quick, easy wins for your user base.  And, from a marketing perspective, which do you think makes them more likely to evangelize?  Put yourself in their shoes.  Would you recommend something hard to figure out?

For a product with software developers as an end user, software documentation can really go a long way.  And with something like GhostDoc’s “build help documentation” feature, you can notch this victory quite easily.  But the fact that you can generate that documentation isn’t what I want to talk about today, specifically.

Instead, I want to talk about going the extra mile by customizing it.

Read More

By

Valuing Behaviors that Indicate Organizational Mediocrity

Hello!  Once again, I’m feeling pretty excited to be doing some actual free-form writing on the blog.  As best I can tell, I typically write an average of about 1,500 words per day.  And since many of those no longer go toward my (now draft complete) book, they can go toward other things.  For instance, sharing my thoughts on organizational mediocrity.

Over time, I’ve observed a growing list of organizations in action.  Usually, these heavily involve tech, or else I wouldn’t get a phone call.  But the actual purpose, shape and size of these places varies considerably.

All organizations tend to share some common ground, however.  For instance, at any kind of scale, they tend to form themselves into pyramids.  They also tend to make rules targeting their lowest common denominator.  But today I’d like to focus on a different, subtler commonality.

Organizations trend toward mediocrity by valuing apparently beneficial behaviors.  I’ll chalk these behaviors up as locally maximizing; they make tactical sense and create strategic messes.   Companies and society both value them in individuals.  But, counter-intuitively, encouraging them in your organization paves the road to hell with good intentions.

Read More