Repeat yourself, do more than one thing, and... — programming is terrible


72 bookmarks. First posted by nicferrier 10 weeks ago.


Repeat yourself, do more than one thing, and rewrite everything If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs...
programming 
2 days ago by geetarista
If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever! [...] The advice isn’t inherently bad—although there is good intent, following it to the letter can create more problems than it promises to solve.
programming 
11 days ago by epochblue
2018-08-05 If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one…
from instapaper
5 weeks ago by iany
programming is terrible
Programmieren  Blog  Text 
5 weeks ago by derjan
If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever!.
devops 
5 weeks ago by muhh
"Usually, a rewrite is only a practical option when it’s the only option left. Technical debt, or code the seniors wrote that we can’t be rude about, accrues until all change becomes hazardous. It is only when the system is at breaking point that a rewrite is even considered an option. Sometimes the reasons can be less dramatic: an API is being switched off, a startup has taken a beautiful journey, or there’s a new fashion in town and orders from the top to chase it. Rewrites can happen to appease a programmer too—rewarding good teamwork with a solo project."
a:Thomas-Edward-Figg  p:Programming-Is-Terrible  d:2018.08.05  w:2500  instructional  programming  software-design  software-development  from instapaper
6 weeks ago by bankbryan
best practices, advice, dogma
dev 
7 weeks ago by username
The problem with always using an abstraction is that you’re preemptively guessing which parts of the codebase need to change together. “Don’t Repeat Yourself” will lead to a rigid, tightly coupled mess of code. Repeating yourself is the best way to discover which abstractions, if any, you actually need.

As Sandi Metz put it, “duplication is far cheaper than the wrong abstraction”.
programming  abstraction  bestpractices  software_engineering  software_architecture  development  inspiration  advice  from instapaper
7 weeks ago by andrewsardone
As Sandi Metz put it, “duplication is far cheaper than the wrong abstraction”.

You can’t really write a re-usable abstraction up front. Most successful libraries or frameworks are extracted from a larger working system, rather than being created from scratch. If you haven’t built something useful with your library yet, it is unlikely anyone else will. Code reuse isn’t a good excuse to avoid duplicating code, and writing reusable code inside your project is often a form of preemptive optimization.

When it comes to repeating yourself inside your own project, the point isn’t to be able to reuse code, but rather to make coordinated changes. Use abstractions when you’re sure about coupling things together, rather than for opportunistic or accidental code reuse—it’s ok to repeat yourself to find out when.
software-development  cultural-norms  refactoring  advice  to-write-about 
8 weeks ago by Vaguery
2018-08-05 Repeat yourself, do more than one thing, and rewrite everything If you ask a programmer for advice—a terrible idea—they might tell you something like…
from instapaper
8 weeks ago by wjbr
Repeat yourself, do more than one thing, and rewrite everything
If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever!.

Following “Don’t Repeat Yourself” might lead you to a function with four boolean flags, and a matrix of behaviours to carefully navigate when changing the code. Splitting things up into simple units can lead to awkward composition and struggling to coordinate cross cutting changes. Avoiding rewrites means they’re often left so late that they have no chance of succeeding.

The advice isn’t inherently bad—although there is good intent, following it to the letter can create more problems than it promises to solve.

Sometimes the best way to follow an adage is to do the exact opposite: embrace feature switches and constantly rewrite your code, pull things together to make coordination between them easier to manage, and repeat yourself to avoid implementing everything in one function..

This advice is much harder to follow, unfortunately.
advice  prog  blog 
8 weeks ago by kmt
You can’t really write a re-usable abstraction up front. Most successful libraries or frameworks are extracted from a larger working system, rather than being created from scratch. If you haven’t built something useful with your library yet, it is unlikely anyone else will. Code reuse isn’t a good excuse to avoid duplicating code, and writing reusable code inside your project is often a form of preemptive optimization.
9 weeks ago by nexuapex
'As Sandi Metz put it, “duplication is far cheaper than the wrong abstraction”.' <-- this is the best programming advice ever
programming 
9 weeks ago by aparrish
Invoking the ‘single responsibility principle’, programmers have been known to brutally decompose software into a terrifyingly large number of small interlocking pieces—a craft rarely seen outside of obscenely expensive watches, or bash.
programming  advice 
9 weeks ago by wholewheattoast
repeat yourself, do more than one thing, and rewrite everything!
9 weeks ago by kurver
In the end, we call our good decisions ‘clean code’ and our bad decisions ‘technical debt’, despite following the same rules and practices to get there.
code  advice  programming 
9 weeks ago by tedw
The problem with always using an abstraction is that you’re preemptively guessing which parts of the codebase need to change together. “Don’t Repeat Yourself” will lead to a rigid, tightly coupled mess of code. Repeating yourself is the best way to discover which abstractions, if any, you actually need.
[…]
although one class might do two things in a rather nasty way, disentangling it isn’t of much benefit when you end up with two nasty classes with a far more complex mess of wiring between them.
[…]
Technical debt, or code the seniors wrote that we can’t be rude about, accrues until all change becomes hazardous. It is only when the system is at breaking point that a rewrite is even considered an option.
[…]
In the end, we call our good decisions ‘clean code’ and our bad decisions ‘technical debt’, despite following the same rules and practices to get there.
nützlich  Meinungen  Projektmanagement  Entwicklung  Programmierung  tested  Konzeption 
9 weeks ago by Stolzenhain
2018-08-05 If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one…
from instapaper
9 weeks ago by badboy
2018-08-05 Repeat yourself, do more than one thing, and rewrite everything If you ask a programmer for advice—a terrible idea—they might tell you something like…
instapaper 
9 weeks ago by ckolderup
2018-08-05 If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one…
from instapaper
10 weeks ago by aviflax
RT : repeat yourself, do more than one thing, and rewrite everything!
from twitter_favs
10 weeks ago by briantrice
RT : There’s some truth to this , but the problem it attributes to DRY isn’t inherent.

If you ha…
from twitter
10 weeks ago by orta
RT : repeat yourself, do more than one thing, and rewrite everything!
from twitter
10 weeks ago by mjr5749
If you ask a programmer for advice—a terrible idea—they might tell you something like the following...
p:programming-is-terrible  a:tef  2018-08-06  abstractions  advice  arch  architecture  code-design  code  craft  development  dry  microservices  modularity  programming  refactor  refactoring  reliability  software-design  structure  style  sweng  thought-provoking  tips  wham 
10 weeks ago by andrewjbates
- Don't Repeat Yourself
-- Can lead to rigid, tightly coupled mess of code.
-- duplication is far cheaper than the wrong abstraction
-- Create abstractions for things that change together
- Modularity
-- Are booleans a sign of code that maybe we have reduced too much?
-- Modules are often changed because they are the easiest to change, not because they are the best place to make the change.
- Rewrite Everything
-- We rarely understand the previous system, and many of its properties are accidental.
-- If a replacement isn't doing anything useful after three months, odds are it will never do anything useful.

"In the end, we call our good decisions ‘clean code’ and our bad decisions ‘technical debt’, despite following the same rules and practices to get there."
10 weeks ago by aesterline
repeat yourself, do more than one thing, and rewrite everything!
from twitter_favs
10 weeks ago by nicferrier
repeat yourself, do more than one thing, and rewrite everything!
from twitter_favs
10 weeks ago by indirect
repeat yourself, do more than one thing, and rewrite everything!
from twitter_favs
10 weeks ago by feltnerm
repeat yourself, do more than one thing, and rewrite everything!
from twitter_favs
10 weeks ago by moderation
repeat yourself, do more than one thing, and rewrite everything!
from twitter_favs
10 weeks ago by mike_moran