无法被操:技术债务的低估原因
Can't be fucked: Underrated cause of tech debt

原始链接: https://jesseduffield.com/Can%27t-Be-Fcked/

在当今这个快节奏的世界里,开发人员经常需要在他们的技艺中平衡生产力和诚信。然而,对于许多软件工程师来说,一个常见的澳洲表达“CBF”(不能被敷衍)似乎是正确的。这个概念表明,有时动力会让我们困惑,导致编码实践不够优化。尽管人们普遍认为“过早优化是万恶之源”,但高技能的开发人员通过严格关注细节、仔细调查问题以及实施实用解决方案,持续展示卓越的思维方式。虽然他们的奉献精神使他们与众不同,但其他人也容易受到分心、拖延和犹豫不决的影响。为了克服懒惰倾向,个人应该认识到技术债务的影响,并在承认人类局限性的同时努力保持高标准。通过接受诚实的自我反思而不是虚假的伪装,我们可以培养更大的职业成熟度,并倡导一种重视真实性和质量的文化。最后,了解个人毅力的限制并允许自己偶尔放松,可能导致技术在情感坚韧方面的健康平衡。总之,CBF,对技术警觉的不情愿解毒剂,提醒我们要采取合理的界限,保护身体和心理健康,同时不影响整体软件开发体验。

根据上面的文章,很明显,讨论软件工程师之间的懒惰问题需要谨慎考虑,因为它具有主观性和潜在的误解。虽然有些人认为真正的懒惰可能导致较低的产品数量或较差的执行努力,但其他人则认为被认为的懒惰可能表明情感反应或影响一个人对任务的动力和承诺的心理挑战。总的来说,确定在各种背景下什么是懒惰或仅仅是分心可能证明是有挑战性的。一些人倾向于关注懒惰的负面后果,强调它消耗能量储备并鼓励技术债务积累。相反,其他人则强调懒惰的好处,例如保存精力和减少压力。最终,决定是否承认自己或他人中的懒惰可能取决于个人的价值观和优先事项。
相关文章

原文

Can’t Be Fucked

Aussie slang for not wanting to, or not having the energy and motivation to do something.

“Man, i really can’t be fucked changing the channel, let’s just watch Springer.”

- Urban Dictionary

I used to think that if I could just learn a bunch of things about programming, that would make me a better programmer. Sure, the learning I’ve done so far has made me a better programmer, but the person I was striving to become was a little more… admirable.

Whether it’s at work or in my open source travels, I routinely come across developers who are the real deal: they’re conscientious and judicious in an unwavering way. They set a standard for themselves and do not compromise on it. Whether that’s a deliberate thing or whether they’re just built that way, it’s humbling to witness. If there’s a flaky test, they investigate it and fix it. If there’s a bug they spot in the wild, they make a ticket, and maybe even fix it then-and-there. If a new feature doesn’t gel well with the existing code, they refactor the code first rather than hacking the feature in. They’ll dive as far down the stack as necessary to get to the bottom of something. None of these things are necessary but great developers know that if they don’t address a problem early, and properly, it will only cost them more time in the long run.

‘But,’, you say, ‘premature optimisation is the root of all evil! Duplication is better than the wrong abstraction! Don’t be an architecture astronaut!’

The developers I’m thinking about already know of all those takes and have internalised them long ago. They know that sometimes ‘good enough’ is the right choice given the constraints of a project. They know that sometimes you need to cut scope to stay on-track. They know that sometimes it’s better to wait to learn more about a domain before rearchitecting a system. And yet in spite of those constraints their output remains golden. These are hard working motherf*ckers whose diligence and perseverance put other devs to shame.

Other devs… like me.

Sometimes, I just CBF. I spent months (part time, of course) building out an end-to-end test system for my open source project Lazygit, and every day I think of all the regressions that system has prevented and how much harder it would be to add that system now given how many tests have been written since. I know for a fact it was worth the effort. So why haven’t I added end-to-end tests to my other project, Lazydocker? Because I CBF.

I raised an issue in somebody else’s open source repo and they asked me to present them with a minimal repro git repo. Why haven’t I done that yet? Because I CBF.

Why do I still have so much of my code living in a God Struct? If I could just finish that big refactor I started over a year ago, my codebase would be far easier to navigate and contribute to. The answer, dear reader, is that I CBF.

Is it burnout? Maybe. Is it a lack of Growth Mindset? Hard to say. Is it just the reality of my personality? Who knows.

As I continue my journey as a developer I learn more about myself, and one of the things I’ve learnt is that my motivation ebbs and flows. I’ll have a good run, inhabiting the persona of the developers I look up to, however imperfectly, until I once again find myself with the constraint that trumps all the extrinsic constraints of the project at hand: a deficiency of motivation.

I’ve also learnt that knowledge only gets you so far. I’m still just scratching the surface of all the developer-y things there are to be learnt, but even for the topics I consider myself knowledgeable, knowing what’s right and doing what’s right are two very different things. Knowing the long-term pain of tech debt is certainly a motivator for avoiding it, but it’s no guarantee.

And sometimes knowledge can be wielded impiously: ‘I’d add more tests but too many tests creates a maintenance burden’. ‘I could refactor this but I want to wait a little to see how other features affect things’. ‘Keep It Simple, Stupid’. ‘Premature optimisation’, ‘Cut scope aggressively’, etc. These maxims can be deployed for evil just as well as good. Have you ever hid behind one of these lines to hide the fact that in reality you just CBF?

Maybe you don’t have the energy to write perfect code, but honesty requires less creativity than lying. It’s a breath of fresh air when a contributor admits some element of their pull request is lacking because they’re lazy. At least then you have the opportunity to judge for yourself whether their laziness exceeds your own standards or whether their time is indeed better spent working on the next thing. That’s a much easier game to play than bandying software engineering maxims.

So, if you find that you CBF, don’t be dismayed; it happens to everyone (except those very special people we all aspire to). If in the moment you don’t have the strength to overcome it, at least be honest. And if you’ve been going 100% for too long, maybe it’s time to take that holiday.

I’d like to end this post with an exploration about how laziness evolved for a reason and that despite us all wishing we had more motivation, there are benefits to being selective with our energy, but… I CBF ;)

Other

If you liked this post you may also like my recent short story about an insecure superintelligent robot escaping from an AI lab

联系我们 contact @ memedata.com