![]() We know that psychotherapy works well for the majority of people who make use of it however, despite decades of research costing millions of dollars, and hundreds of articles and books claiming the greater importance of “common factors” or model-specific techniques, we still can’t really say with great confidence why therapy is helpful. Remember, if you're writing software at any decent scale, another developer will eventually read and have to work with every line of code (and comment) you write so pay it forward by avoiding the House of Cards.4. More importantly, the experience has chiseled a cornerstone of my personal development ideology and helped me become a better programmer. ![]() The silver lining of the story is that the comment got removed, the tangled mess of business logic got ironed out, and I got to closed out a ticket. If this comment got checked in, not reviewed, and released into production somewhere there is a software manager that needs to do more code reads. Why? Just Why? Whomever wrote this comment & code obviously wasn't confident about it's durability to say the least - so why not.peer review, get help online, bump it up to your lead, re-tool the solution, re-visit requirements & stakeholder needs? There are a hundred better ways to resolve a programatic challenge than laying down a land mine to inevitably mangle a dev in the future. If you end up feeling like you're on the tail end of a 10 hour game of Twister, there IS a simpler way. If I'm in here, fixing a bug - and my stack trace as led to your little gem of logic, whatever you were trying to do with your rickshaw recursion pattern is obviously not working. With the vast amount of automated documentation tools available you never know when & where they'll pop-up - and it's never more than a repo blame away to see what asshole wrote the Homer Simpson comment which appeared in a stack trace on the projector during a Board demo. Being a developer is a rad job from the gate, leave the "Here we go again Batman" comments for around the water cooler - not in code. If the code is so tricky or dangerous to touch, actually explain why - add some ticket references or backlog ids, an equation, a hyperlink to the federal compliance mandate, anything but this cop-out tomfoolery. The chances are IF you're still with the organization by the time someone else does have to touch it - you won't remember what was so bad about it anyway. People are the worst at remembering things, they just are - so why write some ominous comment that doesn't actually tell me a damn thing about what's so intricate, tricky, or counter-intuitive about the code snippet. Reason This Comment (& Any Code It Could Be Used to Describe) Suck More so I now consider when I'm building my own solutions how to NOT write house of cards (HOC) code/comments. The source control blame showed a developer years since departed from the organization, but as I painstakingly labored over the issue resolution there were certainly more than a few times his commented words mocked my efforts. ![]() I often recollect the chuckles my fellow developers and I had reviewing the code and as well as my frustration first dealing with cascading yields in. Still to this day, my favorite inline comment has been: //do not touch this, it is a house of cards and there is a strong wind a 'blowin!!
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |