Anti-goals for coding:

- 1 liners that normally would be 10 liners
- covering every potential use case
- using a pattern because it sounds cool
- adding abstraction because you might need it
- feeling clever while writing it

That's definitely not a complete list. What would you add to it?

@raiderrobert oh no i feel so called out, and correctly so!

these are all things i habitually do and have to catch myself to avoid, good list!

@raiderrobert

Using a configuration file in yaml when you could use an env variable

@Aedius @raiderrobert you could reference that variable in a yaml file!
@raiderrobert
- needing several lines of comments to explain what the next few lines of code do

@kimvanwyk @raiderrobert Especially paired with the first one.

Writing anything in one line to "save code" just to explain it afterwards instead of just writing more lines of code that is easily understandable is such a common pattern these days.

@raiderrobert funny right now I’m having loads of “fun” with code where …

- writing 10 lines that could be one.
- Not covering cases that lead to sorrow and strife.
- Writing 30 classes that could be zero if you’d spoken with the people who’ll use the system.
- Testing the implementation and not the behavior. Preferably with a fancy mocking framework
- Not writing an obvious abstraction because you can’t be bothered to take 20 minutes to look at the existing code.

@raiderrobert I think goal or un-goals need context and the art of programming is to know or find the context?
@raiderrobert introducing a dependency to avoid writing less than one screenful of code

@raiderrobert for one bonus points if there’s not much of a reduction in number of characters.

I’d also add:

- Use all the marketing-ese, buzzwords and overly verbose academic jargon you can in comments and commit messages. Ensure that no one understands what it even does

- Roll your own crypto. As an exercise