me giving advice to beginners: don't feel bad about your code. as long as it gets the job done, it's good

also me: don't look at my code. it's terrible!

I disagree with the first one though, I mean I agree on small personal projects, but not in a (semi) professional session

I'm currently working on a side project with 2 guys and we do code reviews etc. with strict requirements, all to allow eachother to learn best practices etc.

Always be critical of your code....the first advice is intolerably bad advice for a beginner.

Guys, the first one doesn't say "write bad and unreadable code, as long as it works". 🙄 It means, "don't let your mind discourage you from learning, you don't have to get everything perfect the first time, you'll learn better techniques with experience, just do it and then correct it".

Seriously, my first python script is bad - it's still readable but I do a lot of things kinda manually because I didn't know a useful lib for the task back then and some language tricks. (I had programming experience, just not with Python.)

Now I know my way around that lib, inherit from its classes for easier comparison between systems, do a lot of one-liners with dict/list comprehension...

@irene Yeah, but iterate is different from "drop everything, you can't make it good at first" or "try to perfect this one line over and over, while you haven't even started on anything else".

Treat it like premature optimisation - first do a general thing, then correct some stuff. Iterate, as you said yourself.

School and even school-level programming competitions teach us that we should perfect everything just as we create it or sometimes don't even start if we haven't perfected the idea. My country's national programming olympiad dropped that idea year after I graduated - before you had to optimise from the very start because you only got points for the whole group of tests and they liked to group nice tests with some one edge case or very huge data...

This left me a bad programmer.
And it was one of the reasons I eventually chose a polytechnic instead of normal university - I knew uni taught theory and that premature optimisation.

@haze how do you know what does he mean?

@aviophile Because that advice has been around for some time and I know the fallbacks for being a perfectionist (I.e. I am also guilty of the last line, "don't look at my code!").

The context is pretty clear if you look at that last line, not only the advice.

@haze the thing is, this sunshine and rainbows code sometimes make it into production...and those of us that actually took time to grind and learn how to be a proper softer developer have to go through a lot of shit to make said code work.

I would rather one:
1. Writes code
2. Sees and recognizes that it is shit
3. Fixes it through iteration and hard critique before letting it go into production.

"Well, it works !!!" <----never a flipping excuse

@AleCx04 Nobody says it should go into prod.

It's mostly for the learning process.
But also:

Have you ever had student colleagues/interns who either do something but take a lot of time or don't do anything?

The thing is, instead of doing something "bad" at first and going further, then going back and fixing the bad thing, they pause at one thing they can't figure out. There's no code at all to fix. Not even to test parts of it.

Because they got stuck 20% through the thing and instead of leaving it/doing a bad thing for the time being (and fixing it later)/askibg for help, and doing the other parts of the project.

It's the thing "10% of the project takes 90% of the time", but you don't even have the remaining of the project.
It's more like "10% of the project takes 10% of the time, next 10% takes 90% - you have only 20% at the end".
When it could've been 70-90% at the end with bad/no 10% chunk in the middle that someone has to fix.

I prefer the latter.

@haze if you keep adding "no one says it should..." taking our statements as if we were writing them in stone then you will never really understand where are we coming from.

By that, in my previous post I said "sometimes" which is a big keyword from my previous statement.

I don't know where you are getting your internships or what your experience was. In mine I would tell my interns to do as best as they can to come up with a solution and admit to me the parts they know are bad. Just telling them "its ok as long as it works" as the op said and which frankly seems that you took a different way is and will always be horrible advice.

I am all for teaching and being nice to learners if that is your concern. But saying "it werks yaaay" is a big no no for me. And being that i have a say in who gets hired or trained i would say that(at least in my experience) it matters for something.

I Agree.

There is a junior developper at my firm.

His code is not well structures, typos everywhere, not using some of things already in place.

BUT : His code ALWAYS work. In the past 1 year, he generated maybe 5 bugs.

He lacks "abstraction" and "patterns" part, but I'm accepting his pull requests almost without looking now. I know it will work.