My blog posts are never complete when I hit the publish button

The best blog posts grow as they age, attracting great conversations in the comments and elsewhere. Sometimes comments offer praise (always wonderful and encouraging), but the comments I enjoy the most are those that offer alternate points of view, expand on my original thesis, or answer my call to action. My preference is to see the commentary and discussion of the article happen within the comments of the blog post—that way the original text and the interpretation of it by the community are linked. Comment threads on LinkedIn (and elsewhere) are essential, can continue for a long time, and go beautifully off the rails (here’s a nice example), but it’s the comments below the original blog post that are the easiest to return to months or years later. And as such, they are the ones that make a post evolve.

The best posts spawn great comments that become one with the original text. This is one of the pleasures of writing for a niche audience of passionate and knowledgeable people. None of my posts will get hundreds of comments. But a few times a year, a few thousand words of commentary will be added. And when that happens, it’s all worth reading. Here are some of my favorite recent examples from BIM Engine of posts with as much content in the comments as in the original post:

How I know not to waste my time

How to tell whether something needs fixing

Eduardo Rolón, AIA added a great comment to yesterday’s post Avoid unnecessary fixes: do not chase ghosts. It’s one of those comments that I read and instantly thought “that should have been in the post!” While outside of what I was focusing on (the concept that not everything that looks wrong is wrong), the comment was exactly where I wanted the conversation to go. As such I now look at that post and view that comment section as an essential part of the post.

Eduardo’s comment shifted the focus of the post by adding some sagely advice about not putting off fixes until later. He then followed up with some more good advice on Twitter that covered the gambit from how to set up your work in order to minimize problems to how to avoid making things worse when trouble arises. When starting a project, Eduardo is an advocate for setting up a base point and/or a structural grid that the project references (yes!) and then protecting that grid by locking the Layer or the elements themselves (also yes!). I think “10 steps to follow when starting a new file” is probably a post that needs to be written. And actually I just started it, jotting down eight quick steps. So maybe it’ll be twelve steps. Or eight.

Eduardo’s comments got me thinking about not rushing to fix errors, and just how important that is. How often do we see something wrong and crazily fix it, only to find out that it wasn’t wrong, but purposeful? Strangeness isn’t always an error or a mistake, that was the point of the previous post. But I didn’t go into how one evaluates whether something is or isn’t wrong. And if it is wrong, is it worth fixing? Let’s correct that omission. Here are ten points to ask yourself when you come across something suspicious in ARCHICAD.

Before you make that change, ask yourself:

  1. Is the problem superficial and internally focused?
  2. Will it affect the work of others: Internally? Externally?
  3. Do you understand why it is wrong? Are you sure?
  4. Did you cause the error? Do you know who did? Have you talked to them?
  5. What are the known consequences of fixing, or not fixing?
  6. What are the potential unknowns of fixing, or not fixing?
  7. What is the potential scope for unknown unknowns as a result of fixing, or not fixing?
    Seriously I love that Donald Rumsfeld quote.
  8. How long will the fix take? How much work will it disrupt?
  9. How easy will it be to revert the change if you mess up fixing the mistake?
    How confident are you in your backups?
  10. Leave things as they are. Go get a coffee, eat lunch, or otherwise distract yourself for a little while.
    Are things still dire and wrong?

What else am I missing? How do you evaluate these decisions? What is your process for determining whether something is or isn’t in need of fixing?

What you do when it is wrong

Another interesting conversation

The rest of the comments from the original post ignore Eduardo’s comment and instead go off on a tangent about Story -1 vs Story 1. It’s worth reading as well because it ties into a post by Rob Jackson (COBie 2.4, BS 1192-4:2014 and ARCHICAD 18/19 – Part 1: Instruction, Contact, Facility and Floor) as well as templates, best practices, and more. I love how interconnected posts of wildly different origins can be.

Are you following GRAPHISOFT North America on Twitter? Click Here to keep track of all the latest ARCHICAD News in North America. For more posts on troubleshooting in ARCHICAD, start here.


Submit a Comment

Your email address will not be published. Required fields are marked *

Looking to meet other ARCHICAD users? Why not come along to one of our upcoming User Groups!  VIEW DETAILS