[laserlight]

> I know how to write good code.

> Usually it means spending more time now to make the code better for some future state of the world.

No. That is called premature optimization/abstraction/development and should be avoided. Shitty code is shitty today. Poorly chosen names, copy-pasted pieces, implementation doesn't reveal intent, mismatch in code and comments, etc. Doing these right should be habitual and shouldn't be a function of cycle time. Otherwise, they tend to creep easily.

[kretaceous]

> Shitty code is shitty today.

This is really helpful.

I think I write reasonably good code. When people who are junior to me ask me, how to differentiate between premature abstraction and writing good code, I don't generally have an answer. This comment made me realise what I actually think while writing code.

[laci37]

Naming things is hard, copy-pasting is fast compared to extracting shared logic if you need small changes. Implementation will not reveal your intent, if you are not sure what you intend to do.

I'm working in ML research so I kind of write shitty code for a living. All these problems are small things, that are okay if you just try something new. If it sticks, you'll build on your previous code so the junk just piles up. The challenge is spotting the time when the shit just starts o bog you down.

[rob74]

I guess it will bog you down from the minute you (or someone else) has to go back to a piece of sh... er, code you wrote a few months ago in order to implement a new feature or fix a bug. So I'd say following some minimal standards of non-shittiness would be real nice: names don't have to be perfect, but e.g. shouldn't be completely misleading or contain typos (ok, pet peeve of mine), you shouldn't use strings where a boolean is obviously better (like in the screenshot above the article) etc. etc. So, not stuff that will require hours of thinking and planning, but stuff that should be second nature to any programmer worth their salt. Of course, if you're a beginner or someone dabbling with a new programming language, by all means, go ahead and write all the shitty code you want, until you get better at it...

[jeremyjh]

If you can't come up with a good name for a function or variable, you will find it difficult to make progress because you do not have a high-level understanding of what you are trying to accomplish. Laboring on without achieving that may be possible but it will never be as efficient as building up a good mental model of the problem space before spewing more lines of code.

[laserlight]

If one makes it a habit to think about how to name things, it will become easier. Copy-pasting is not fast if you factor in the time spent on problems because of it, even in the same coding session. One may not be sure of their intent, but they should have some intent. So at least reflect that one in the code.

I don't mean to be perfectionistic. There are certainly cases where “good programming habits” could be compromised. But people tend to excuse bad habits quite easily, without thinking of better ways.

[xandkar]

That is all fine if you're the only one that needs to understand that code. Otherwise you're wasting other people's time and sanity. Unless, of course, it all works for everyone, in which case carry on. At least until a new-enough team member arrives and starts pulling their hair out :)

[jean_valje4n]

Data Science is all about writing shitty code. Most of the time you're just digging for data in a notebook, and then you can write things out proper once you've got something that could work.

[laserlight]

I guess we can distinguish between programming and prototyping. Prototyping is more forgiving because it has narrower scope and spans shorter time. Even then, bad habits tend to carry on to the programming part. So better be deliberate about it.