Half-Ass It
everythingchanges.us
everythingchanges.us
I would suggest to try to finish tasks with the bare minimum. Not half-assed but without bells and whistles. Important bells and whistles will come back anyway as their own tasks. Drive by sight and don't prepare too much for the final destination. The latter will change anyway and you will waste your time worrying about ifs.
It's been working, in that the 'leave room for others to step in' has worked well, and those others have filled the gaps with new and interesting ideas that I likely would not have done even had I whole-assed it. At the same time, those people weren't equipped to whole-ass something from nothing.
I have to admit that failing to produce a required result in time using the right abstractions and without “overthinking” is actually just that: failing. That’s why I mentioned all parameters, including time, social reality, etc. Using too much time is failing.
Producing results is a skill. Like mastering programming languages and system internals is a skill. We should approach it with honesty and reflection: we suck at that for now and it’s OK. We can improve.
Personally I found whitewashing failure with “I think too deeply”-type of arguments tends to maintain status quo instead of improvement. Because we deeply belief that it’s not actually failure, but it is.
I actually agree with “just finish”. It’s a good first step. Don’t furnish, but also don’t half ass.
Say you implemented a new function and missed some clear edge cases in the new tests. Or perhaps there's no tests written at all, because it was half-assed.
You will have to speak up in a peer review. I'd speak up just to have it written down. Perhaps you just forgot to `git add` that part, I don't know. It'd be professional negligence not to at least bring it up! If your reply is then, 'I'm aware, and didn't do this for reason X', that's perfectly fine, if reason X is at least slightly better than couldn't be arsed.
I'm still processing what I've learned from that experience but perhaps one of the important things I've learned is that even when I think things through I make similar mistakes to the ones I do when I'm stressed out. And I think that has made me more efficient because I can kind of shrug a bit at things I know are hard to get right on the first try.
I guess for some people fear works, but I'm more of a "carrot chaser" than a "stick dodger". Failing would mean that I'm both dejected for not getting what I want and frustrated because there's a non zero possibility my "best" is just mediocre for everyone else.
I'm also still over deadline and scared of being fired.
It’s not fear, it’s being real: can you do this, with the parameters given or not? If not, great, no problem, but don’t tell yourself you are a “perfectionist”. You might be, but who can tell if you never produce? You just can’t do it right now and that’s perfectly alright. Being honest matters IME.
You hit the nail on its head there: there exists the possibility that “your best” is actually mediocre. You better acknowledge that sooner rather than later if you wish to live in reality which I deeply suggest you want to at least attempt.
If you know wicked smart people like, say, T. Tao you will quickly develop the ability to accept you might just be mediocre and that’s OK.
Myself, I am completely mediocre and have a hard time hitting simple goals. There.
Are you mediocre in coding compared to 100% of the population in the World? Surely not, since most people do not know how to code. Are you mediocre compared to top 0.001% coders in the World. Unless you are not in the top there, and you are comparing yourself to them, then you are worse than mediocre.
Because you would only be mediocre compared to them if you are around the top 0.0005%.
Reminds me of Ira Glass:
“All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you.”
Mediocrity is most definitely not subjective. It is context-dependent, sure, but subjectivity is something else entirely.
I did not bring it in, the parent did and with good reason. It’s one of the causes of procrastination and fear.
No, make it good/working to the best of your abilities. Never aim for perfection, if you actually want to get out of bed and do things.
Your abilities will grow, and your techniques will develop.
If you want to know what "Perfect is the enemy of Good" really means... double down on perfectionism, and see you do nothing, or see your hires leave you.
People say my work is shit nowadays, but it's only because I'm trying to give them a chance to shine.
But, who knows, maybe that means I should do the exercise.
I agree that telling everybody to half-ass more would probably not yield a net benefit.
The first group needs to launch/release/send it faster (I'm likely in this group), and the second could benefit from higher quality standards.
All of these conversations are so bizarre to me. I have to imagine these basic labels like "half-assing", "perfectionism", everyone has their own little definition of those things, the circumstances are different, and really all of those things are more like spectrums. And in different scenarios very different configuration of how much "half-assing" is being done will have very different yields. You can make those absolute statements, and sure they could be the optimal truth in certain scenario, but there's thousands of permutations of different scenarios.
From the article itself "self-identified overachievers" - to me that doesn't even mean perfectionism. It could be that someone is just doing a lot, but half assing all of it. They could also be identified as an overachiever. E.g. they are always working, and delivering half assed projects, which despite being half assed are successful because there are so many of them, and few of them succeed because they were delivered quickly.
In addition if you are constantly working and "overachieving" you might start to half ass for just that reason, that you are mentally done.
If there's one truth that is somewhat accurate is that in most projects the 80% / 20% rule does apply, that with 20% effort you can get the 80%, and rest of the 20% will become increasingly difficult towards the perfection, where perfection is actually impossible to reach.
Is spending 20% effort to get the 80% and leaving it there half assing? Or is it 80% assing? Or 20% assing?
Regarding your 80/20 comment I would say that this is true regarding features. I.e., quality attributes that the external world sees. My comment is about internal quality. So, let us say we have the 80/20 mindset and determine that features A, B, C, D, and, E belong to the 20% that we want to deliver and features F through Z end up on the backlog, perhaps to never be seen again. With insufficient internal quality it happens that the first and second version of feature C actually do not work, but fortunately feature C works the third time. Then feature D breaks feature A, but this can be fixed. After that feature E breaks C again, distressing the customer to no end because this is the third time that they have to report that feature C is not working and they already were a bit irritated that feature A broke.
I now leave a bunch of TODOs in my code as a reminder to myself that yes, this isn't the best it can be, I'll come back and make it better when it becomes a bottleneck, but for the time being 80% of something is better than 100% of nothing. This way I'm able to move on and continue doing meaningful work rather than wasting time obsessing over minute details that almost nobody else would care about.
The first part of the job is it's own seperate kind of job, and that job is not to produce the end result of a year of work immediately, it's to identify the job, identify just what actually are the essential requirements and just what exactly is doable on what kind of time scale. Not one line of code.
Whole-ass the part of the job which is kind of like triage where you identify what is reasonable and what is out of scope, or out of the initial immediate scope.
Then you are not really half-assing anything. You fully attain the more correct goals.
Some of us probably still over-correct for it, but having this as part of your calculus is a more important part of being a decent human being than it might appear at first glance.
Probably sounds strange but to me, AA IRL is still a simple concept about preserving as much of the original signal in the target domain, even when changing sampling or representations from the source domain. I just think it is also a very interesting and relevant/applicable way to think about various aspects of human life too!
Seems to me like since various information is moving around, it would be good to choose the appropriate AA strategy based on the context's input and output filter domains! (At least as far as one can control this!)
Yes, AA IRL is certainly a bit of a fanciful idea (humans are not shaders/etc) but I think it's still a very interesting way to conceptualize things, and would love for HN to tear it to pieces some time!
1. respect for professional tile people
2. a sense of failing at a task
3.
(notice I also half-assed this comment)