DaedTech

Stories about Software

By

Should You Take a 100% Pair Programming Job?

Pair programming.  Understanding of this topic may vary among the readership.

Some of you might have the vague notion that it means two programmers working together… or something.  Others of you might have a more solid grasp of particulars and a vocabulary that includes terms like “driver-navigator” and “expert-novice.”  And, a few may even understand the full origin story of pair programming as a core plank of the eXtreme Programming (XP) approach.

Hey, Look, a Pair Programming Reader Question

I’ll soon return to that origin story.  But first, let’s look at why I’m talking about this at all.  I’m actually gearing up to answer a reader question:

I was interviewed by a company that [does] full pair programming.  I hate the idea of spending all my day with somebody looking at me writing code.  What do you think about it?

So to clarify a little here, we’re talking about a company that subscribes, full stop, to the XP rule that “all production code is pair programmed.”  For all intents and purposes, this means that dev teams pair program 100% of the time as a rule.

Should you take a job at such a company?

It’s honestly hard for me to say for any given person since my advice would be so very tailored to your individual personality and preferences.  So rather than immediately give a thumbs up or down, I thought maybe I’d explore the topic of pair programming more broadly.

Since my publication of Developer Hegemony and subsequent departure from a traveling consulting/training life, I’ve made this blog increasingly one about software developer empowerment.  Today, I’d like to look at the subject of that pair programming through that relatively uncommon lens.

I want to examine not whether pair programming is a Good Thing (TM), but whether it’s a good thing for you, as a software developer.

Read More

By

Reader Question Round-Up, Video Edition

Alright, it’s time to come to account for my haphazard posting performance of late.  I attribute this to a couple of factors, and I list these not so much to make excuses but to explain myself.

  1. This has historically been a blog about software, consulting and software consulting.  And I neither write much software nor consult very frequently these days.
  2. Due to the unexpected (but awesome) success of our content business, I trade in blog posts all day, most days.  So, for me, writing blog posts is sort of like a pastry chef knocking off of work and coming home to crank out a gourmet coffee cake.  (Or, a bad one, depending on your taste in bloggers)

All of this is to say that I’ve had a bit of blogging malaise of late.  So my posts have come intermittently and without much in the way of social promotion.

To Blog-Post or To Video?

On the flip side, I’m exploring new content media, largely as R&D work for Hit Subscribe.  This has led me to do a good bit of work in video, which is surprisingly fun.

Now, as any long time readers will recall, video isn’t exactly new for me.  I spent a year or two on a Chess TDD odyssey with something like 20 hours of screencasts in the book showing folks how to test drive code.  And, before that, I made 4 video courses for Pluralsight.

But I hadn’t touched the medium outside of screencasts, and I hadn’t even done that in a year.

Well, now I have.  I’ve started posting videos to Hit Subscribe’s Youtube channel (check it out if you’re so inclined — I’m doing a “time to joy” series where I explore how long it takes to get going with dev tools and techs).  And I’ve found myself enjoying it more than I thought.

So I figured I’d spice things up a little back over here at DaedTech by starting to clear out my prodigious reader question backlog, video-style.  Here, in the frame below is the result of that — a video-edition of the reader question round-up.

I’m planning to do more of these, at least until I blaze through my backlog.  But I might do other videos as well, centered around the theme of this blog which seems, these days, to be developer empowerment and related topics.

And here’s where I’ll leave things.  I think the biggest driver for content here, whether written or video-recorded, will be your questions.  I love talking about software, consulting, and developer empowerment topics, but I don’t live them day to day anymore.  Thus I won’t have all that much to say unless prompted.

So please, fire away with any questions, in the comments, in the comments of the Youtube video, or wherever.

By

Org Chart Types: A Guide for the Aspiring Consultant

Org charts and org chart types.  How companies structure reporting relationships.  The stuff of Dilbert cartoons and tales of disaffected corporate woe, but also the glue that holds most organizations together in some semblance of order.

A Reader Question about Types of Organizational Structure

I’m overdue for answering a reader question, so let’s answer one about org chart types.  This arose out of a post I wrote a while back about how to become a management consultant.  In that, one of the pieces of advice that I offered was to become well versed in different organizational types and structures.

This led to a pretty natural reader question.

After reading your post on becoming a management consultant, I’m wondering if you have useful resources for tackling three of the areas you encourage learning:
1. Business Organization Structures

I’ve elided the second two things he asked about because speaking to all three would make for a pretty disjoint blog post.  So today, it’s all about the org chart.  (Not to be confused with organizational structures like LLC, S-Corp, etc, which I won’t talk about here).

So let’s define the actual purpose of org charts, and then walk through some of the most common examples.  I’ll structure this post by how a company might adopt these structures at different points in its maturity.  But first, I’ll speak to the philosophical why.

And I’ll try to do it all while striking a healthy balance between cynicism and exposition.

Read More

By

Readers Often Ask Me, “Should I Write a Book?” Here’s My Take

“Should I write a book?”  Someone asked me this today, and I rattled off an answer.

But as I was doing so, it occurred to me that I get this question frequently.  Probably a few times per month, at least.  And this makes sense, since I’ve written a few myself and I’m in the content business.  Heck, one of those books has even enjoyed more success, commercially, than I ever anticipated.

So, no-brainer, right?  Get out the digital quill, put on your frilly Shakespeare-style writing shirt, and let the art flow through your keyboard?

Answering the Reader Question, Should I Write a Book?

I’ll spend the post answering the question, but I can give you a pretty short answer and then let you read on below the lede, if you’d like.  The answer is, “ehh… maybe.”

I think writing a book can be a great exercise in personal growth.  I also happen to agree, at least anecdotally, with the wisdom that “everyone has at least one book in them.”  But that doesn’t mean that you should just sit down and start typing.

Should you write a book?  The short answer is this:

Yes, but only if you can articulate exactly who will read it, how, and why, and then you form a plan to make sure that happens.  If you do that articulation and that planning, and still want to write a book, then go to town.

So there you have it — the short answer.  The longer answer, and the remainder of this blog post, is going to by the justification of my thesis.  And, by way of support, I’m going to explain how I lumbered into writing a book in exactly the wrong way.

Think of this, then, as not just advice I’m giving to the various readers who ask about this, but also advice I’d give to myself 5+ years ago.

Read More

By

If We Solve the Software Generalist Anti-Pattern, Who Writes the Code?

I am, strangely, not an expert in my own history.  Chronicling my own exploits through digests and Prime Photos have helped somewhat in this regard, but I nevertheless struggle to remember the sequence of my life.

So I think it was 2015 when I was writing about the tales of Emma in Developer Hegemony.  And I think it was a few months later that I first dreamed up the strange neologism of “efficiencer.”  I think, but I’m not positive.

What I do know, however, is that it was a few years ago now.  And I also know that my thinking has evolved somewhat since then.  So I’m going to answer a couple of reader questions today with the benefit of having acquired additional experience since writing the book.  I’ve moved away from management consulting, started a business, and helped a lot of nascent product companies with marketing and positioning.

I haven’t really made any reversals, so if you bought and enjoyed the book, don’t worry that I’m disavowing any points in it.  Rather, I’ve refined how I think so-called efficiencer firms should market themselves.  And, as you can probably infer from the title, it should categorically not involve any whiff of generalism.

Let’s Look at the Reader Question

Alright, so what have readers asked me?  Well, quite a while back (2017, in fact — yes, I have a long reader question backlog), someone asked me this.

The efficiencer model looks a lot like management consulting except the consultants here can do the automation as well. What has changed to make this path more suitable for developers to follow?

And, more recently, someone asked me a question in response to a post I wrote about how any firms that sell custom app dev are selling staff augmentation.  I see a logical progression for software developers, for the most part, moving from staff to staff augmentation to, well, efficiencers.  This prompted the question.

Say we work for an efficiencer firm, and we avoid writing code for pay. In the end someone needs to write code; who is that? Are we back to architects vs. programmers & UML handoffs? Or is this an interim solution?

So we have a question that is literally about who writes the code, and another that, at its core, really asks how software developers can be taken seriously offering consultative expertise.  All of this feeds into the general theme of the division between expertise and labor, and who should furnish each.

Read More