I’m opting for the video format again for a couple of reasons. First, because I’m frankly having fun with it. And, second, because I think it works well for questions that I’d struggle to write a full length post about.
I know, I know. That seems hard to believe.
But, seriously, things like “how do I find an entry level Java development job” don’t really inspire me to bang out 2,000 words. And so they wind up just sitting in the backlog, gathering dust. I figure I might feel like writing about them later.
So I think this is a good compromise and a good way to do some topics justice.
This Week on the Round-Up
Now, without much further ado, I offer you a frame of the round-up. If you’re interested, the topics I cover in this video are as follows.
What do I do, as a consultant, when a line manager tries to micromanage me?
Name some better ways to find work as a freelancer than just blasting out “hey, I’m free” to your network.
How do you get a job as an entry level Java developer after getting your degree?
Give it a watch below, if you’re so inclined. I included a couple of movie clips in this one for variety. So kudos to anyone who gets the references.
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.
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.
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.
“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.