Au contraire! Almost all the time you spend doing the thing is actually doing the things required before the final completion of the thing. I've taken to calling this "the work before the work" and it's at least 90% of the work.
Example: I get asked at the start of a project to provide ModbusTCP comms mapping for a new control panel, so that the client can start integrating it into their SCADA system. It's just a spreadsheet, maybe 100 rows, how hard could it be? They need it right now, why am I telling them it'll take 6 months?
Typing the addresses and descriptions into the spreadsheet is 'the work', and it only takes an afternoon, but it can't start until we do the work before the work:
- To document the ModbusTCP mapping I need to the PLC program
- To finish the PLC program I need the electrical drawings
- To finish the electrical drawings, the electrical engineer needs the device list, datasheets for all the devices, and the functional spec
- To finish the device list and functional spec, we need to agree with the client exactly what we're building and what it's meant to do
None of these things are 'the work' but all of them are 'the work before the work' and usually nobody wants to do, to wait for, or pay for this work.
Yes in all the environments I've been in this is nearly the entire job. But I work in embedded...
Need to verify feature X - okay, let me just -
- Find the list of CPs needed
- Get a recent source tree
- Acquire a board
- Flash board
- Get CPs
- Manually assign IP and bring up SSHD to the device so I'm not working over serial
- Build and SCP the rebuilt thing to the device
- Find whatever byzantine command you need to run it to verify it
- Of course it doesn't work, ask your coworker
- Oh did you remember to flub the flabnabber? echo "1" > /dev/i2c5 then restart the flabnabber-daemon
- Run the fking thing and it works
- 3 hours has passed
Wow is working in embedded great. But I think that this is basically everything. The time isn't building the shelf, it's figuring out exactly which hinges are right for what I want it to do, it's measuring and measuring and sanding, it's multiple runs to home depot.
ALL of this _is_ "doing the thing". They are all prerequisites and as such are part of the task.
Somebody once said in light of this dilemma: Do things that don't scale.
This never meant: "It's fantastic if things don't scale". It means: "Trying to start by doing things that scale is probably bad". I mostly believe that.
I also believe that in order to bootstrap a viable system, start with system 1. The OP is partially sniping at people who creating all kinds of elaborate structures for systems 2-5, without attending to the first order of business, which is system 1. I've been guilty of this myself.
But it's easy to find dysfunctional organizations that focus almost exclusively on System 1, and it looks like grinding, hustle, "doing the thing", being stuck at CMM Level 1, and in my experience, it leads to burnout. So there has to be a balance.
Oh you are absolutely doing the thing in this situation, as in you're in the process of doing it, somewhere between 1% and 99% of the way there depending on the context. You haven't done the thing until you actually fully do the thing, it is true. But most of the work could be in this preparatory meta work, and of course it means nothing without the final all important step of doing the thing, but there you have it, doing the thing before having fully done the thing.
Redefining doing the thing into a complex process, where actually doing the thing is only one step of the process, and then other steps, is not doing the thing.
Well, to really know how things would pan out, you have to indeed do the thing.
And it happens that people will procrastinate with preparation. But as someone who does not and is fast at doing things I can tell you that if I want something done really fast preparation will be a good chunk of a projects time. If I want to toy around and the project doesn't matter that much, just doing the thing may do the trick.
Now the advice on that site aims to get people started with the actual work part and tries to do so by telling you preparation doesn't matter. That is not true. But it is true that people prepare forever because they are afraid to cross the threshold where they start translating grand ideas into concrete, protentially flawed reality. That means actually good advice would deal with the question where this fear comes from, how to address it and how to notice you have been preparing too long.
If you want to build a house, drawing the plans and finding the right location where to put said house is part of building a house. Or you could just mash bricks on top of each other in your backyard and then realize you forgot the foundation.
In his case, his domain shows up on HN periodically. Like simonw or tptacek, interacting with the audience is doing the thing in his case. Haha. But probably not for the audience!
But in any viable system, you also have the "meta-systems", Systems 2-5:
- System 2: coordination between multiple Systems 1 (which includes prioritization, communication, and exceptional conditions)
- System 3: resource allocation and process development
- System 4: strategy and risk management
- System 5: values and holistic organizational design
As a human, you are also striving to be a viable system. You can't only just "do the thing", you have to:
- prioritize which thing to do
- take notes and keep records to communicate between past and future versions of yourself
- make sure you have the requisite resources for doing the thing
- construct your environment and processes for long-term success (habits not motivation)
- consider what happens when the thing is done and how it fits into your larger strategy
- keep your head and heart connected to make sure you're doing the right thing
None of these things are doing the thing! But they're also rather essential for getting the right things done well.
[0] https://en.wikipedia.org/wiki/Viable_system_model