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.
There are many ways to do the thing. There are many more ways to not do the thing.
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.
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.
Ah dammit I always forget the flabnabber.
10/10 authentic embedded development experience.
Permission denied.
> $ sudo bash -c 'echo "1" > /dev/i2c5'
I forget every time
It can be really difficult to strike that productive balance.
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.
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.
The item is all done. I'm waiting for the action.
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.
For some types of work, the work we call prep work is 90% of the work and most of what determines how well the finished product turns out.
Painting is a good example. You can grab a bucket of paint and paint brush and start “doing the thing” by slapping paint on the surface. Your paint job is going to be very poor and fail early relative to a professional who properly sands, cleans the surface, preps the work area, and does it right. You might save some time now by skipping straight to doing the thing, but you might also lose more time later when you have to repeat the job because the paint is peeling or you’re cleaning up a paint mess that spilled on to another surface because you didn’t prepare.
But then telling people about a new product could also be doing the thing.
There’s definitely something to be said for defining what the thing really is being an important part of doing it, but that can also spiral out of control into not doing the thing.
I think thingness is more of a variable property of the current thing you are doing. Than a binary is or isn’t the thing.
All we can really do is regularly check how much the thingness of the current thing is aligned with the main thing’s thingness.
If you need to read something to get the thing done you are doing the thing. If you already know everything to get started but still read another article you are procrastinating. If you need to sand this part to do a good job painting it, then you are doing the thing. If you just continue sanding with no benefit you are no longer doing the thing, you are now just delaying the next step
I catch myself doing this. I will put off writing a job requisition by spending time on code. I will tell myself, "ugh, I'm just not in the right mental state to write a job req right now. Let me focus on some code until I'm ready." Which never works. I end up getting into a code flow state and that's all I work on for the rest of the day, or until I get interrupted by a meeting.
And then I get back from the meeting and say, "I got interrupted, I should just finish what I started and then I'll write the job reqs." And that never happens. I always pick up yet another coding task instead.
The only way I am ever able to get through admin paperwork is to just admit to myself I hate it but it has to get done, it has to get done right now, no amount of procrastiworking is going to make me stop hating it, so I should just get it over with so it's not sitting like a lead weight in the back of my head. And then when 5pm rolls around, I won't hate myself for letting yet another day go by without having the job reqs written.
But right now it's the weekend.
- Start things. If after actually trying the thing I am truly not in a conducive mental state for the activity I can quit. Mostly evidence for this bad mental state is repeated mistakes at things I can already do. I think starting also weakens procrastination habits because you know you’re going to experience the thing you’re avoiding anyway even if you end up quitting part way through.
- Focus on whether it is a bad mental state for the activity rather than “the right” mental state for the activity. Most mental states will be good enough for most tasks. You don’t need code flow to code, even if you want it and it helps. You just need to not be in a state where you can’t figure things out or you keep introducing bugs.
- Completely reject my feelings about doing the task. If you’re in those feelings the task is a lot harder and the procrastination lies a lot easier to believe. It doesn’t matter in the short term how you feel about tasks you have to do.
- Constantly question the veracity of procrastinations lies. “Is this true?” “If it is true what can I do about it right now?”
- Reward myself after completing the task if I don’t get any kind of internal satisfaction naturally.
Things that have caused me to screw up various paint jobs:
- not color matching white paint to my existing white paint, causing a visible color difference
- buying the wrong kind of brush for my paint
- buying cheap brushes and then needing to dig hairs out of the paint
- not priming, which caused me to have to do multiple layers to get good coverage
- buying cheap paint, which together with not priming, caused me to have to do multiple layers to get good coverage
- buying too little paint because I did not estimate carefully and then having to pause mid-job to go buy more paint and extending the total time to more than a week (because I did not have time to finish the job the next day)
- not buying and putting down floor protection which caused a lot of extra time in cleanup and never actually getting the paint out of the crevices in the floorboards
- not taping out the windows and doors which slowed down painting and required a lot of just-in-time cleanups
- taping out carelessly with poor-quality tape, causing paint to get under the tape, and defeating the purpose of taping
- not changing clothes before a tiny paint job and needing to throw away a very decent t-shirt because metal paint does not wash out well
- buying very expensive paint for a rough paint job in my garage because I did not spend a minute to think about the final effect, and wasting a bunch of money for a poor effect
To avoid each of these mistakes you have to spend time not-painting. It's time well spent.
I've tried doing a work breakdown, and watching a pro do it, it seems roughly 0.75 units of time for prep, 1 unit of time for painting, and 0.5 units of time for cleanup. I did not count the time for researching and buying, but once you add commute, it's easy for it to be 0.5 unit of time, depending on size of job. Roughly 1.5x-2x of not-painting to 1x of painting.
You can make many software-development analogies to painting.
If we're mature experience painters, all of these things not-painting things are still "doing things".
The important part is, that the greats never were okay with just 80%. Their goal is usually to make the best work they can and that means improving on things they have previously done. That doesn't mean the project needs more work or resources. It means it makes best use of the work and resources available while delivering something that satisfies the masters quality standards.
Also: In some cases 80/20 mediocrity does in fact not cut it and it is just an excuse to do less work and not to think hard about things.
I'm a perfectionist miniature painter by hobby. I love the stories floating around about how quantity can lead to quality (photography, pottery): https://austinkleon.com/2020/12/10/quantity-leads-to-quality...
In most of my hobbies I feel like my growth and talent is limited by lack of volume, not my care or attention to detail. It's hard to let go and use one color instead of three, or not fix a flaw in model part nobody will ever see. I'm sure other people have the opposite challenge.
Coincidentally I teach (medialab) at one of the most recognized art universities in Europe and have a MA of fine arts and my mother is a painter. In my judgement the most overlooked (or most underrated) skill when it comes to painting is perception. Being a good painter aside from the manual skill has a lot to do with seeing or being able to see, even if you're not doing figurative paintings.
Painting more and more different things can be a good way to raise your own perception skills. It is also important to revisit old works occasionally. Ideally you will immediately see what was wring (or good) with them, something you may have not perceived back when you did it. This is proof that you leveled up.
How do you like those 80% Boeing aircraft with optional parts that may or may not come away in flight?
At work I got asked for a feature a while back. We tee shirt size estimates and I said it was an XL. I came back a week later at our next planning sync and said I was going to work on it that day and we’d have it tomorrow. PM was very confused and worried about committing to an XL task in 24 hours - but I’d spent probably 3 days of the last week planning, doing requirements, writing up a spec sheet, weighing up against alternatives etc, and came up with the “simple solution” that we could smash out in a few hours. All of that time was “doing the thing”.
(Well, most of it. Some of it was just naval gazing and wondering if it really could be that simple…)
Painting is a good example
While I agree with your point, I believe this post is just psychological pep talk aimed at people like me (and probably the author) who dance around in endless preparation/postponing because they can't bring themselves to do the ting. It's generally an emotional issue: You are afraid of messing it up or of the consequences of the thing etc.
I wish I didn't but I need that kind of pep talk in my life
Preparing the work area isn't. If you can get away without doing it (like if you can move the piece into some area you don't need to prepare), you should.
1. Ticket
2. Feature branch
3. Write unit test
4. Periodically merge from main.
5. Implement to get tests to pass
6. Push changes
7. Create PR
8. Wait for PR feedback
9. Address feedback and repeat
10. Close and merge PR
11. Automated CI deploy
12. Integration testing as needed
13. Close ticket
14. Include in next prod release
All of these are good things. But the overhead is significant. And there may be times when you want to do spikes that forgo some of these.Quick and dirty does not work in all environments.
It's all part of doing software development on a team that has embraced the trappings of agile, at any rate. Less clear that any of these steps are actually essential to quality.
There are teams who use a workflow that looks more like push-to-merge-queue -> if-tests-pass -> deploy-to-prod, and in my experience this results in significantly higher velocity (provided your e2e tests are actually sufficient to prevent outages).
A lot of it depends on whether you have a lot of customers and revenue you are putting at risk by making quick and dirty changes (mandates more process) or coming up with an MVP (quick and dirty might be beneficial if you can iterate faster).
I am also creating a jira ticket because 11 months later when another engineer is trying to figure out if the code they're staring at is still actually valuable or if they can rip it out safely, they are going to use git blame to find the pull request where the thing was done, that pull request is going to mention the jira ticket, and the jira ticket is going to reference the design document that justified why we did the thing. If we don't do those things, that engineer is going to yank that functionality out and something way over there is going to break without anybody realizing it broke.
Your mileage may vary. Some teams make the PRs detailed enough that they don't have to fall back on jira. Other teams try to encode this information into unit tests (that helps but it's circular reasoning; the unit test will tell you that somebody at one point thought that this was important enough to verify that it keeps doing the thing; they won't tell you why the thing matters or what customer wanted the thing or whether the thing was the thing we did before we pivoted to doing the new thing cuz the old thing didn't make money).
Probably because "nobody is paid for doing that".
It may not be doing the thing, but it enabled the thing to be able to be done at all. Cheers to the precursors, the planners and the annotators. Through you, more things are done.
Exaggeration is a common technique employed in human language for emphasis.
I know there are some things you need to start to really understand what’s going on, but as much as possible I’d rather mull over things a lot and gather information and clarify my thinking before doing the thing.
B: Isn't that just the wrong way?
A: Yes! But faster!
Sometimes we see our task as being, "do C," and we forget the "B" and "A" that come before.
Maybe you can't do "C" without discussing it ("B") or researching how others did it ("A"). In these cases, we shouldn't simply think the thing is "C"—the thing must first be "A," then "B," and then, "C."
If we forget this, we're bound to think "C" is the only thing of value, that it should take an hour and not a week, or that people doing the "A's" or "B's" to enable the "Cs" must be doing nothing at all!
Just yesterday I was helping a family member install roofing. The roof was done up to slats, the roofing was big metal sheets, should be done in an hour. Except we spent good five hours on various little details before the first sheet was going up. And you cant exactly not do those, at least if you want the roof to stay there, and the weather to stay outside.
I'm well compensated not because I'm good at googling things, but because I have a proven track record of being good at googling things. If a junior was able to produce the same results they wouldnt be paid more.
As Jobs said “real artists ship.”
Most people don't and blindly stumble going after short term to mid term reward. Then later life crashes them hard, except for the lucky few.
And the truth is, now some people have many more luck coupons to spend than others.
"Build a house," is a thing, but at which point of the dreaming, designing, planning, permitting, architecting, financing, contracting, acquiring, installing, verifying, reworking, coordinating, inspecting, styling, unpacking, cleaning, landscaping, repairing, upgrading, and waiting, are you doing it?
Perhaps each discrete thing is itself a thing, and when you do a thing, or transition between things, is the matter needing clarifying.
If you are coordinating on how to do a thing, you are doing the thing, as long as the thing is coordinating on how to do the next thing. This "coordinating a thing" is a discrete thing we should not confuse for any other thing.
TFA's examples are unforgiving in that they suppose there is only ever one thing and all else should be nothing.
Doing a thing involves doing it, but it's very unlikely that doing a thing will involve exactly one atomic movement. So you have cutpoints at doing the thing.
So to do the thing you first have to decide to do the thing. You have to decide what the thing is, or at least have enough of a vision of the thing to take the first step at doing a thing that might look like the thing.
So "doing the thing" involves a lot of doing things that aren't the thing, but without which you won't get towards the thing.
In other words: sitting down and writing down what the thing is _can very well_ be part of doing the thing.
There's a sort of philosophical point too, about whether the thing is what you think it is. Plenty of people have had the "I thought this feature was going to do X, you thought it was going to do Y, and we all realised the mismatch very late in the process".
I think both visions of the world are valid, and things you can keep in your mind at the same time to deploy as needed.
Naivety has its perks.
The point is: don’t stop at learning how to do the thing.
Actually do the thing.
But many learn how to do the thing, and still never do it.
Not what your boss and your bosses’ boss wants you to do, instead of doing other things you can do to maximize value for shareholders in some arbitrarily chosen amount of time
But thinking of how you wouldn’t have permission to get ready to do the thing in a business context, also, isn’t doing the thing
But doing the wrong thing, poorly, is also not doing the thing. To avoid that, you need to do some of the things that the post mentions.
That concludes my morning dose of Zen.
I’m currently kicking off my second attempt to fix this by talking to a psychologist about it. But I am not very hopeful. Still searching for the root cause. I have all the ground works set to having a good life, except that I am incapable of moving to start that damn thing.
Where is my interest in stuff gone? Why do I prefer my couch over just typing "git clone" and play with some new tech? Why is my 3D printer sitting dusty in the corner even though I was one of the first adopters? Why is the act of hand-craft wood working, that I am dreaming of since forever and would now be able to do, impossible for me to start?
My motivation is high. My brain thinks whole projects through. I start fixing things in my head. But I am not even capable of dumping all that planning into an speech-to-text-LLM to build an actual design document out of it.
It feels like I played everything through already, so no point in starting that thing.
What the fuck is my problem?
I may have fun during the thing, but beforehand it's mostly trying to plan for what might go wrong, and afterwards it fades to the satisfaction of checking something off of a list.
Best way to to train yourself to win again. Start, finish, and celebrate a 1h task. Then half day. etc
Finishing small things like cleaning dishes is no problem for me. It gives some sort of gratitude, but most likely not what bigger tasks would give.
There is nothing wrong with planning/scheduling/marketing/whatever. But a LOT of people use all that as excuses and never actually do the thing.
If you are the kind of person for whom which those are useful, great. Or if you have the self-displine/self awareness to do all that stuff and still follow through, great. But some people just need to do the fucking thing or they never will.
Source: I'm one of those people.
Nonetheless, these are good points.
When expressed that way, I must differ. Reproduction per se is the least interesting part of human life. Talking about reproduction is much more interesting ... wait, I think that's called "literature."
Sometimes it’s even harmful to doing the thing.
But sometimes it’s exactly the right thing to do.
Know when you need to oversimplify and when not and you’ll know Zen.
And when you know Zen you’ll do exactly the thing.
As simple as it is, just remembering this is enough to make me go do the thing.
And on that note, back to the thing.
I distinctly recall it becoming a bit extreme in the last chapter(s).
As an university level educator that helps students with mostly technical projects (so stuff neither I nor them have ever done): This fear is very common. But what I dislike about this advice is that preparing the thing is often in fact a necessary step of (A) deciding whether the thing is feasible and worth doing and (B) a part of what is needed to do the thing. Drafting the general layout and data flow and UI for your software can save you hours later. Having a good and fleshed out concept for a game may tell you if it is even worth putting years of your own time into it, what resources you will need, a research essay on different ways to detect motion may e what makes or breaks the result of your interactive art installation etc.
So preparation is necessary, but true experience only comes from going beyond the preparation phase. Feel it is impossible to start? Usually that means there is something that you feel insecure with. E.g. your game might need an inventory system and while you have a great idea how it should look and work, you have no idea how to actually program it. And if that small part of your task looks impossible, it makes the whole task appear extra-impossible.
The best way to deal with this is usually tackling the problem head on and make it a proof of concept. The problem is you can't program that inventory, and there are many ways to go at that particular problem, but if you can get a draft inventory going that means your biggest worry is taken care of. That means dealing with the hard part first, even if you tell yourself it is just a proof of concept that won't land in the final thing is a good approach. Divide and conquer. The whole thing seems impossible? Break it down into smaller steps thst seem more managable.
I had a colleague make a passive aggressive comment about it being really cool how I put together "obvious" stuff. Well, it is obvious. At the same time, I have never seen him do this "obvious thing".
Doing the thing is being a performer. Making the thing happen somehow is called leadership. It's all about doing the thing, and not just seeing and understanding the thing - that's the easy part.
When you do coding, you are only writing instructions for a computer about how to do something. So it is not actually doing something. When a computer runs your code, it is only telling some hardware to pass current through some circuits. Again it is not doing something. Current passing through circuits is not physically moving anything through the wires or metal. So again it is doing nothing.
Writing “$thing isn't doing the thing” 13 times isn’t writing an essay.
That aside, I thought this was going to be about products that fail to fulfill their advertised purpose.
Helps me get pumped up or whatever
It also goes hand in hand with the Cult Of Done Manifesto really well: https://medium.com/@bre/the-cult-of-done-manifesto-724ca1c2f...
These people defo do not have kids…
Go have some kids, then lecture me about how to get things done.
[0] Please just let this slide.
> Making a to-do list for the thing isn't doing the thing.
Clearly defining and understanding the thing or, as they say, understanding the problem is half the solution. Real life experiences totally crash the OP statements.
And yeah you probably are. Only in retrospect will it be knowable if it was worth it or not. Perseverance is necessary but rarely sufficient.
As I like to put it: not having a plan is not a plan.
Until then I daydream of how I will make it and how it will fit together.
If I never get round to it then that time will have been wasted. But if I do, all that daydreaming will have been useful mental prototyping.
But was it «doing the thing»?
This post is foolish and self-destructive.
If I trace backward from the ideas that earn me money and prestige today, every one of them is rooted in playful or apparently unproductive behavior.
In my book, doing research/understanding the domain is a crucial part of "doing the thing". Often reading about how to do the thing makes you reconsider doing it at all.
Corollary: Don't put off until tomorrow what you can do today, put off until the day after tomorrow, maybe by then it won't be necessary.
Understand how to do the thing
Do the thing
Write down fresh documentation about the thing
To be fair, for me, not making the list is even less like doing the thing, in terms of how frequently it leads to the thing being done!
Don’t agree. Planning steps is part of doing the thing.
If you're gonna build a house, building scaffolding is not a waste of time.
Which I think misses the point - which is there are times when you’ve already done enough research, but you’re afraid to act so you procrastinate. i.e. not doing the thing.
- Ignoring that all people are different does not make you an expert in human psychology
- Discovering what procrastination is (and still failing to name it or provide actual coping mechanisms) does not make you an expert in human psychology
- Failing to recognize elementary human behavior does not make you an expert in human psychology
- Utterly neglecting the act of double creation (first imagine, then create) does not make you an expert in human psychology
- Being energetic and with only a few tasks at hand and writing off everyone else as lazy does not make you an expert in human psychology
- Writing a post about human psychology does not make you an expert in human psychology
I would continue my list, but gotta go. To do... , you know.
Not doing the thing would be: planning to write a blog post, tweeting that you're going to write a blog post, reading articles about how best to word your blog posts, watching some YouTube videos as inspiration, etc.
I think the advice here is an anti procrastination advice: do the thing, don't just think about doing the thing.
Now, let’s dream of doing some things!