andrewstellman

> Don’t force it. I’ve gone weeks without writing anything. It happens.

I'm a reasonably prolific author (six books, two of them have fourth editions coming out in the coming year, all published by O'Reilly). Aspiring writers ask me for advice pretty regularly. (I'm happy to share, if anyone's interested and has questions.) One thing I always tell people is to read Stephen King's "On Writing: A Memoir of the Craft" -- people dismiss his work because he's a horror writer, but in my opinion he's one of the best writers of the past century. This book is full of excellent advice to writers, especially aspiring book writers. I found it valuable to my own work, even as an author of technical books.

Most of Batnick's advice in his post is excellent, but I strongly agree with the advice not to force it. This excerpt from "On Writing" sums it up better than I can:

> Once I start work on a project, I don’t stop and I don’t slow down unless I absolutely have to. If I don’t write every day, the characters begin to stale off in my mind—they begin to seem like characters instead of real people. The tale’s narrative cutting edge starts to rust and I begin to lose my hold on the story’s plot and pace. Worst of all, the excitement of spinning something new begins to fade. The work starts to feel like work, and for most writers that is the smooch of death. Writing is at its best—always, always, always—when it is a kind of inspired play for the writer. I can write in cold blood if I have to, but I like it best when it’s fresh and almost too hot to handle.

(King, Stephen. On Writing: A Memoir Of The Craft (p. 153). Scribner. Kindle Edition.)

I recognize that feeling from my own work -- again, as a writer of non-fiction, technical books. I think it's an excellent model for anyone looking to write.

First of all, very interesting piece. Excellent writing – that's really great to see! I think you touched on a lot of really good points.

I've got some feedback about your section on agile. I think it does a good job of summarizing ineffective agile adoptions. But there are a lot of teams that get extremely good results with agile, and I'm not sure your piece does them justice. I've spent the better part of the last decade – and my last two books – helping teams get from ineffective to effective, and I've seen agile work really, really well on a lot of teams.

I do think this is a very accurate picture of agile on a lot of teams, possibly the majority of them:

> The few that really had read up on it seemed incapable of actually dealing with the very real pressures we faced when delivering software to non-sprint-friendly customers, timescales, and blockers. So we carried on delivering software with our specs, and some sprinkling of agile terminology. Meetings were called ‘scrums’ now, but otherwise it felt very similar to what went on before.

But if you ask someone on an effective agile team, they'll generally have no trouble describing exactly what they do.

One problem that plagues ineffective agile teams is agile zealotry, and I think it's really good that you called it out:

> It’s no coincidence that the Agile paradigm has such a quasi-religious hold over a workforce that is immensely fluid and mobile.

This is a real problem with a lot of newly minted agile evangelists. They're excited that they found a new way of working that goes a long way to help with their headaches, and feel like they've found the silver bullet for every team's problems, but take it too far and demand that everyone around them immediately change to the way they think the project should run. Honestly, I've been there myself. We grow out of it, so be patient with us! :)

So while these what you wrote describes the state of agile on a lot of teams, it's not an accurate picture of agile when it's working well. I think Jenny Greene and I did a reasonably coherent job of giving a big-picture view of agile in the first chapter of Learning Agile – if anyone's curious, you can read that chapter for free on Safari: https://www.safaribooksonline.com/library/view/learning-agil...

A few more things.

I don't think it's fair to use an image of Scaled Agile Framework, or SAFe, (https://en.wikipedia.org/wiki/Scaled_agile_framework) as an example of overly complex, "un-agile" agile. For those who don't know, SAFe is a framework for scaling agile to work with multiple teams across an enterprise. Like all tools, it can be used effectively or ineffectively. It has a lot of moving parts because it needs to work with enterprise PMOs, but it's actually built on sound and simple principles. And it really does work when everyone brings the right mindset. And on a team that's working at a company that uses SAFe and working on an effective agile team, day-to-day life definitely does not look like that picture. It looks a lot more simple, like life on any other effective agile team.

In Learning Agile we caution agile coaches that a common warning sign that people on their team are having trouble when they think that agile is the same thing that they've always done, just with a few minor name changes. Here's what we write on page 376:

> “This is exactly like what we’re already doing, just with a different name.” > This is one of the most common reasons that people reject agile methodologies. They’ll find ways to keep doing what they’re doing today, and just choose new names for them that match agile practices they’ve read or heard about. This can make all of agile seem trivial—and even wrong, if they’ve decided to give the agile name to a practice that failed for them. In fact, if you do a web search for a term like “agile sucks” you’ll find people who have done exactly this, denouncing agile as “hype” without substance because it’s just another name for old waterfall practices. They’ll even call agile an “obfuscation” of simple, commonsense software development. As a coach, you need to recognize that this isn’t done with malice or ill intent; it’s just a natural reaction from someone who’s never actually seen agile (but thinks he has). Your job, as a coach, is to help your team understand that agile really is different from what they’re doing, and that it doesn’t suck.

I wanted to call this out, because I suspect some of the people you asked about agile have fallen into this trap, since you mention that your view of agile mainly comes from talking other people:

> When I quizzed people who claimed to know about it their explanations almost invariably lost coherence quickly. The few that really had read up on it seemed incapable of actually dealing with the very real pressures we faced when delivering software to non-sprint-friendly customers, timescales, and blockers. So we carried on delivering software with our specs, and some sprinkling of agile terminology. Meetings were called ‘scrums’ now, but otherwise it felt very similar to what went on before.

This is a good description of an extremely common failure mode for agile adoption. In Learning Agile we give it a name: "better-than-not-doing-it results" – "we followed the rules of an agile approach like Scrum, and a few things got better, so we're a little better off than we were before and it was worth doing it... I guess?" The team went through the motions, but things don't really seem all that different. It sounds like the people you quizzed have this experience.

So:

> So I’m cool with it. Lean, Agile, Waterfall, whatever, the fact is we need some kind of common ideology to co-operate in large numbers.

This is correct! Absolutely!

It's worth pointing out that the agile world has done decades of work on this problem. When people on really effective agile teams see things like the Agile Manifesto (http://www.agilemanifesto.org), they see guiding principles – "common ideology" is a good way to put that – that tie together different agile approaches to getting people to work more effectively on teams.

When people on less effective, "better-than-not doing it results" agile teams see the same thing, they think, "That's a bunch of touchy-feely BS. Just start programming, motherfer." Then they run into the same problems that teams always run into, and end up thinking that agile doesn't work, and it's just another name for the same thing everyone always does.

One more thing:

> I started hearing the word ‘Agile’ about 2003. Again, I don’t think I properly read up on it… ever, actually. *

If you'd like to read up on it, I'd be happy to have folks at O'Reilly send you copies of Learning Agile and Head First Agile. I'd be really interested to know if they address some of the issues you wrote about. If you'd like that, use our contact page (https://www.stellman-greene.com/contact-us/) to get in touch.

If you get a chance, go to Amazon.com and leave a five-star review for each of those books. It seems like a small thing, but you'd be surprised about how each additional review with five stars helps, even a one-sentence review. They all definitely deserve it!

I hope you're not implying that I don't have good presentation or don't teach well! I'd obviously disagree with that. And I definitely think that the Head First books mentioned by others in their responses do a great job with both.

But I notice that you said "suboptimal," and then made this point:

> - page 1: the clipart of the man and woman and the thought bubbles do not reward the user with quality knowledge in relation to the space they take up

I recommend against judging the "optimality" of a book based on the amount of information that it packs into the smallest amount of space. Maybe instead of the amount of space taken up by the teaching, consider using the amount of time and effort required by the reader. Pages are cheap, especially in an electronic medium. A page like the one you mentioned is really quick to read and absorb.

Also:

> - page 19: the clipart of the tourist with the arrows and thought bubble does not actually teach a networking concept

I haven't read Head First Networking, and I don't know the authors, Al Anderson or Ryan Benedetti. But from a quick read, it's clear that that picture is part of a larger story (in this case, about tourists and an airline) that the authors are using as a teaching tool. Stories are a very effective teaching tool.

This should make sense if you think about it. Think about the last textbook that you read. Can you remember the major points that it made, in order? You might be able to, but most people probably can't do it accurately. Now think about the last movie you watched. It's much more likely that you can remember most or all of the major plot points and in the right order, because they're part of a consistent story.

Our brains are wired to remember stories, just like they're wired to remember places, faces, and emotions. The Head First books use stories to take advantage of this effect, not dissimilar to how people use memory palaces (https://news.ycombinator.com/item?id=2395739) to improve their recall.

Yes, telling stories (especially visually) takes a lot of page space. But readers absorb them quickly -- in my experience, it's a very efficient and effective way of teaching. The Head First books that I've read (and hopefully the ones that I've written!) do a great job of that.

It's easy to dismiss one of our Head First books as less-than-serious if you're not used to the format. There are a lot of pictures. There's a LOT of whitespace. There's redundancy; we'll say the same thing more than once. And most of all, when we do our job right they're not boring -- which, to many people, reads as non-serious. But we find that when people approach Head First books with an open mind, they find that it's actually a really effective way to get a lot of information into your brain quickly and easily.

We also know that while a lot of people love the informal and highly visual format, some people just can't stand it. There are some people who just want a dense, concise, terse book that they can absorb all at once. Readers like that just won't like Head First books. That's why every Head First book starts with an introduction that says who the book is for and who it's not for. Coincidentally, my coauthor, Jenny Greene, and I just did an interview on Dave Prior's "Drunken PM" podcast, and the first question he asks us is about this "Who this book isn't for" section: https://www.projectmanagement.com/blog-post/34188/Head-First...

Short, shameful confession: I had a similar reaction to yours when I first saw Head First Design Patterns; I dismissed it out of hand, ostensibly because there were some less-common design patterns from GoF that it didn't cover, but really because I just didn't "get" the format. A year later, when our editor at O'Reilly floated the idea of writing Head First PMP, I went back to it and really read it, this time with a much more open mind (for example, I actually did all of the code exercises instead of just reading them). I realized why I'd made my earlier mistake in dismissing the book -- and gained a lot of respect for how much work Eric Freeman, Elisabeth Robson, Kathy Sierra, and Burt Bates had put into it. They were really careful about what they chose to cover, and covered those topics really thoroughly. They give you several different chances to "get" each concept, showing it to you from different angles so that you really absorb the full context. They put a lot of care into managing the pace of the book so it's a steady stream of learning and not a flood. They repeated things that needed repeating. And it all works. Really, really well.

I thought I'd understood design patterns pretty well before I really read Head First Design Patterns. afterwards, I was actually better at using them in code in real life. When I'm not writing books or training teams, I'm writing code both professionally with teams and as outside of work. The incredible quality of the content in their book helped me understand design patterns better.

Jenny and I strive to bring the same care to our Head First books. I think we've done a pretty good job of including quality content that's worth our readers' time; I hope they agree.