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

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

By

Preemptively Identifying Dead Seas

Today, I’m going to try to tie various strands of my life together into one lanyard of efficiency.  I haven’t done a reader question for a while, so I’ll change that today.  In this post, I’ll offer a terminology nod to dead seas, a now-defunct term that became one of my favorites.  The best context I can now offer lies here, in a post of mine, summarizing it.

A few months back, I made a post on NDepend called, “What to do When Your Colleague Creates Spaghetti Code.”  In this post, I described a caricature that I randomly named Bill, who you might recognize as sort of a quintessential expert beginner.  I subsequently received a reader question about this subject.

How can I tell if the company interviewing me has a “Bill?” (i.e. “How can I preemptively identify expert beginners?”)

Well, I’ll take a crack at that.

Expert Beginner Primordial Soup

I think that a meaningful examination of this question requires us to look at the conditions that give rise to such archetypes.  In the original series/book, I cover part of it.  The organization must draw sort of a neat little box around the techie group and then put an advanced beginner in charge.  From there, the concoction needs to simmer in a nicely insular environment, in which the budding expert beginner receives no real negative feedback, second guessing, or industry exposure.

But this assessment focuses entirely on the software development organization.  An ensconced expert beginner reigning over some miserable, backward fiefdom requires “the business” as an accomplice.  Simply put, it requires the operational laziness to allow your business to be ruled by an unaccountable “expert” operating with utter opacity.

Expert Beginner Hut

Imagine you started a pizza shop and hired a pizza chef to run the kitchen.  Then imagine that you completely delegated the cooking to the chef, as you should.  Life treats all of you well for a while and you develop some business.

But now complaints from customers start to come in about the taste and presentation of the pizza.  “My pizza was incredibly salty and all of the pepperoni was isolated to three slices!”  When you bring this problem to the chef, he tells you that such is life when it comes to making pizza—and, also, get out of the kitchen.  You don’t taste the pizzas coming out or look at them or launch any sort of investigation when his pizza chef assistants serially quit, muttering about his incompetence.  You just count the inbound trickles of revenue and assume that’s as good as it gets.

Read More