For people with a long and rich history of procrastination, half-assing and missing deadlines - like 90% of devs I hang around with - consider doing the opposite: do something with care and focus. Make it perfect to the best of your abilities and do it within the time limit. Consider all parameters, not just the technical. You might fail. Explore your emotional reaction to that.
Perfectionism is usually a cause for procrastination. In my experience the long and rich history of procrastination, half-assing and missing deadlines is usually caused by over-thinking, pre-mature optimization, wrong abstractions and analysis paralysis combined with deadlines.
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.
I've been taking this approach more recently. Something shipped is 100% better than nothing at all, even if it's 25% worse than if I whole-assed it.
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.
Agreed, but you have to be lucky to be not on a toxic team for that otherwise you are going to get a ton of comments by your peers in your Pull Request for trivial things that you left out even though you had clearly stated the scope before, just so that the peers can show that they are doing their job of peer reviewing. And later the ignorant manager questions you in 1:1 about the number of comments on your PR without actually reading them.
This is based on my recent experience.
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 would say to sync on this out of PR before to make sure you are aligned on it with reviewers so they don't have to waste time focusing on the wrong things and writing those comments in the first place.
I emphasize, because I share your tendencies. This is all personal btw, nothing to you personally.
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.
I'm kind of an overthinker and as a result sometimes a procrastinator. I recently took a long break from work and ended up working on "my dream software platform".
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.
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.
Yeah we have to very carefully recognise when advice does and doesn't apply to us. I absolutely do not need the advice of half assing anyting. It takes a lot for me to whole-ass things and I have to think of strategies as to how to get into that state sustainably. And I agree its more about not focusing and having a strong emotional reaction to difficulty and failure, not about being a perfectionist. I'm not sure I like the way that people talk about procrastinators being perfectionists. You can't be a perfectionist if you never even get to the stage of perfecting something. It always feels like a way to make us feel better about ourselves undeservedly.
Great, now not only my perfectionist hamster is speeding up trying to hit their "best result possible" goal, but I'm also stressed out of my mind for fear of missing the time limit.
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.
No offense, but if producing a result within a time frame is causing severe anxiety I think a more.. holistic approach is warranted.
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.
What does "mediocre" even mean? That's a relative and subjective statement. Why bring that in?
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%.
There is a simple test. Look at the result. Imagine someone else produced it. Would you think "This is very well done."? If not, it's "mediocre" at best.
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.”
I agree that my half-ass is more ass then most people I work with whole-ass. I'd love to work with more overachievers. Even just achievers would be great.
It is possible that those who whole-ass it generally have high standards and tend to release very little ("I'll link the github later, the code's messy") while 80 (or 90?)% of those who send it have lower standards making you go "who designed this $%^& thing".
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.
That is true. I guess this specific advice is meant for people who have such high standards (for better or for worse) that they could bring more benefit to the world if they half-ass more things.
I agree that telling everybody to half-ass more would probably not yield a net benefit.
Actually, I think 'half-assing' it is never good. But some people have a problem with perfectionism. I think in general one should have standards and the standards should be good enough to keep a code base in a permanent state of maintainability. And even to bring back maintainability to a bad code base in small increments. This does not mean attempting to do everything perfectly, though, because that just invites too much stress and what is 'perfect' anyway? I think the 'boy scout rule' of leaving a piece of code in a better state than you find it is good. Don't make things perfect, just make them a little better and next time they can become yet another bit better. Also, try to automate more and more manual steps, especially increase automated testing. Automating testing is necessary to ensure improvements are not actually regressions in disguise.
> Actually, I think 'half-assing' it is never good.
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?
You are correct that it depends on circumstances. My comment assumes working on a software project for a longer duration and also that the project is non-trivial.
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.
As someone who's struggled with starting projects from scratch multiple times over and not releasing anything for many years because it was never good enough, half-assing is not the mindset that helped me start shipping things. Rather, it was gaining an understanding about which parts of my code don't need to be perfect right now and also realizing that practically nothing is perfect the first time you do it.
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.
I recently prepared a small presentation to explain my job to kids in secondary school. I realized many of the products I have worked on are completely obsolete and most of them lie in garbage somewhere. Of course I still fondly remember that hard to fix bug, 10x optimization, smart code trick. But in the end little of it remains but in my own memories. In would say "half-ass it" and use "the other half" for some something truly useful. I am quite far from being able to do it though.
A hammer that isn't gold plated and wifi enabled isn't a half-assed hammer.
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.
I think the author was trying to point out that one way to triage or to identify what actually are the essential requirements is to half-ass it and see the results.
In school there were overachievers, who put as much as they could in a task the teacher gives to them and always chased the highest grade, and half-asses, who always scraped by with the least amount of work necessary. They did so mostly indiscriminately of the task. Which is the best approach? I think it's being both, with an extra step: first, for each task determining with agency what is the quality target you want to reach, and then half-assing it with everything you've got to attain that goal, and no more or less.
One problem stems from connecting full/half-assing with outcomes. If the person doing the assing is not feeling the fallout (if there is any, and often times, I agree, there is not) the evaluation of the assing will be off.
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.
For some reason this sounded to me slightly like filter-width/domain aware sampling vs point-sampling of inputs when resampling or translating information. When you said 'calculus' it made me think of it this way.. and actually I personally think that one can apply the principles of anti-aliasing (of signals when sampling or translating them) to everyday life.. ie: AA, IRL!
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!
as Homer Simpson said in the 90s: "if you don't like your job, you don't strike! You just go in every day and do it really half-assed. That's the American way."
i did this recently with laying ceramic tile. I had a wooden pallet left over from something being shipped to me so I added a flat sheet of particle board on top and then tiled it. I did not do a good job. But when it was over I had:
