5 ms·
Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the
by mdavid626 4mo ago
Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.
- jihadjihad 4mo ago> as if duplication would be the root of all evil And instead it gets replaced with the actual root of all evil, complexity.
- mdavid626 4mo agoExactly!
- kimtan21 4mo ago[dead]
- Akronymus 4mo agoTo be more specific, incidental complexity. Many problems have tons of inherent complexity already.
- ttoinou 4mo agoWe still need a way to track that there’s some common pattern in the code. So that when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that
- Akronymus 4mo agoMy metric for that is "does that code MEAN the same thing" or "does it just look the same". Has worked quite well for me so far. I frequently find myself making a copy of some code rather than adding a parameter (most commonly done with code that would get some flag added)
- ttoinou 4mo agoMe too ! I don't follow DRY that much, I'm aware that copy pasting is good enough for a few weeks / months to see how things evolve in the future, and do refactor when it's really needed. That said, how do you know if they mean different things ? For GUI code for example, they do mean the same thing, but there's a good chance the code will evolve in the future so premature refactor are wasted time
- Akronymus 4mo agoMostly by looking at the calling site where the code is already used and the calling site where I want to reuse it. If both of those mean the same (calculate the tax on x products, for the purpose of applying to the shopping cart, vs for applying to generating reports) then I'll reuse it, if it can be achieved without adding stuff like flags, in most cases. In other cases, it just looks the same (sum some field + calculate a percentage of that, for example, for discounts vs taxes on products) where it's obvious that they don't mean the same. (Though, I do heavily rely on a good type system to deal with future evolutions of that copied code) TL;DR: Vibes
- ttoinou 4mo agoIts always about how far ahead in the future you plan ahead. And sometimes this future thinking is wasted time
- pocksuppet 4mo agoGUI code changes as fast as your GUI does. If you have two buttons, call makeButton twice. If they have totally different sizes, don't calculate the size inside makeButton. If tomorrow you want a button and a checkbox, don't call makeButton twice with isCheckbox=true the second time. Fun fact: Win32 checkboxes are buttons with a bitflag that says they are actually checkboxes.
- Brian_K_White 4mo agoThis right here. Here we're loading the customer record and updating their discount % Here we're loading the broker record and updating their commision % They will have 99% identical code. It's possible but exceedingly unlikely we have found 2 things that should be a load_record_and_update_percent(file,id,field,val) Tomorrow the business logic behind one of those will no longer be a simple % and now you have a real mess.
- t-3 4mo ago> when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that It can, that's all about how aggressively you factor and structure your code, eg. combinators make it easy to reuse code in different application patterns without rewriting.
- the_af 4mo agoThis is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This all before the AI deluge, mind you. Very similar with patterns. I've often read people protesting that juniors overuse design patterns, yet I've seldom seen a junior (mis)use anything more complex than a singleton, and when they use any pattern, it's usually forced upon them by an opinionated Java framework.
- dasil003 4mo agoThis smells more like the fluidity of what people mean by “junior” more than anything else. Journeymen engineers in their over-engineering phase, or even very “senior” expert programmers can suffer over fitting the product to their own mental model. The most senior judgment is to understand when an abstraction makes sense at a customer level, because that defines the durability of a business-logic abstraction.
- the_af 4mo agoI do agree this happens with the senior overengineering phase, but the comment I replied to mentioned "especially juniors" and I've heard this trope specifically about juniors, with the implication they want to apply what they learned in college, but this hasn't been my experience at all.
- robotresearcher 4mo agoIn the early 2000s I often saw juniors and students make staggeringly deep class hierarchies. The equivalent of: Shape::Polygon::ConvexPolygon::FourSidedConvexPolygon::Square::BlueSquare... "Intro to OOP" lectures/articles made a deep impression on some people in not quite the right way :)
- the_af 4mo ago
- wellpast 4mo agoDefinitely the hallmark of junior. Obsession with code deduplication as the highest pri when it’s quite low among others.
- ozim 4mo agoWell I have seen a lot of „expert beginners” who have years of experience on paper but fight tiny duplications like their life depends on it. „How Software Groups Rot: Legacy of the Expert Beginner”. https://daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner/ https://daedtech.com/how-software-groups-rot-legacy-of-the-e...
- annzabelle 4mo agoThank you for this link. I have recently fallen into a job at a small company that really seems to have this culture. Thankfully, I'm only going to be here for a year and a half or so (fixed term job for working holiday visa), but I'm trying to be really aware of how its impacting my career development. There is no automated testing, no meetings, seemingly no code review process, no standardization of schemas for files that are passed between different applications, all jobs are run on on prem desktop workstations.
- throwaway2037 4mo agoThe hardest part is two algorithms or business logic routines that are nearly identical. What to do? Frequently, all solutions look equally bad!