Sorry, but #10 is silly.
"Clean code at any cost"? I assume you wanted to sound cheaply bombastic at any cost, but on the off chance you're not, here's an alternative view.
Uncle Bob wrote his book over the course of three years starting in 2005, just as the heyday of programming was starting to end.
In those days you could still take your sweet time for development and delivering something sooner than a couple of years was fast.
Nowadays that doesn’t apply. Being first is damn important and with all the tools we have nowadays the software lifecycle isn’t measured in years anymore.
I worked in an incubator that had a 3+3 strategy. 3 months to MVP and copyright meaningful IP and 3 months to stabilize/refactor if the MVP stood the market test.
Everybody in my team knew clean code but if you could stick by it 50% of the time, you were doing an awesome job.
We’re not here to output technical greatness and some ideal of clean code. We’re here to deliver a product to market, that’s above clean code.
I don't think it's silly and saying it is even more silly. This might not apply all the time but does apply most of the time. There needs to be a balance between going fast and making sure you don't break things, this balance will go either way depending on the type of product and the stage of the company.
There are tradeoffs for not writing "clean code" just like there are tradeoffs for not getting to market fast enough.
It is up to the team to decide on a balance based on their needs.
Yes, balance, of course. It’s a developers job to negotiate said balance and argue for maintainable code and where possible put a price on trade offs. But it’s a huge and far cry from “at any cost” which makes it sound like a good developer should commit seppuku like a disgraced samurai if they can’t follow uncle bob’s principles of clean code to the letter
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sorry, but #10 is silly.
"Clean code at any cost"? I assume you wanted to sound cheaply bombastic at any cost, but on the off chance you're not, here's an alternative view.
Uncle Bob wrote his book over the course of three years starting in 2005, just as the heyday of programming was starting to end.
In those days you could still take your sweet time for development and delivering something sooner than a couple of years was fast.
Nowadays that doesn’t apply. Being first is damn important and with all the tools we have nowadays the software lifecycle isn’t measured in years anymore.
I worked in an incubator that had a 3+3 strategy. 3 months to MVP and copyright meaningful IP and 3 months to stabilize/refactor if the MVP stood the market test.
Everybody in my team knew clean code but if you could stick by it 50% of the time, you were doing an awesome job.
We’re not here to output technical greatness and some ideal of clean code. We’re here to deliver a product to market, that’s above clean code.
I don't think it's silly and saying it is even more silly. This might not apply all the time but does apply most of the time. There needs to be a balance between going fast and making sure you don't break things, this balance will go either way depending on the type of product and the stage of the company.
There are tradeoffs for not writing "clean code" just like there are tradeoffs for not getting to market fast enough.
It is up to the team to decide on a balance based on their needs.
Yes, balance, of course. It’s a developers job to negotiate said balance and argue for maintainable code and where possible put a price on trade offs. But it’s a huge and far cry from “at any cost” which makes it sound like a good developer should commit seppuku like a disgraced samurai if they can’t follow uncle bob’s principles of clean code to the letter