In many cases, getting something out quickly is more valuable than having it be clean.
Part of being a senior is knowing when fast is more important than perfect. Not saying your senior did everything right, just that a single example of someone’s code isn’t enough to judge the value of a person to an organization.
Fair enough, though I contend that for a common-case application like a database-backed REST API where the architecture is basically standardized there is no meaningful time difference between writing crappy code in a clean architecture and writing a crappy pile of spaghetti.
Not always. It can be perfectly reasonable to implement something in a quick and dirty way to get it out there with a view to either kill it off (eg if it doesn’t get adopted by users) or re-write before it needs to be extended. The key is having the awareness when putting yourself in that position.
Forewarning : ops here, I’m one of the few the bosses come to when the “quick code” in production goes sideways and the associated service goes down.
soapbox mode on
Pardon my french but that’s a connerie.
Poorly written code, however fast it has been delivered, will translate ultimately into a range of problems going from customer insatisfaction to complete service outage, a spectrum of issues far more damageable than a late arrival on the market.
I’d add that “quick and dirty code” is never “quick and dirty code with relevant, automated, test coverage”, increasing the likelihood off aforementioned failures, the breadth of their impact and the difficulty to fix them.
Coincidentally , any news about yet another code-pissing LLM bothers me a tad, given that code-monkeys using such atrocities wouldn’t know poorly written code from a shopping list to begin with, thus will never be able to maintain the produced gibberish.
In many cases, getting something out quickly is more valuable than having it be clean.
Part of being a senior is knowing when fast is more important than perfect. Not saying your senior did everything right, just that a single example of someone’s code isn’t enough to judge the value of a person to an organization.
Fair enough, though I contend that for a common-case application like a database-backed REST API where the architecture is basically standardized there is no meaningful time difference between writing crappy code in a clean architecture and writing a crappy pile of spaghetti.
Ensuring all developers can continue putting out things quickly is equally (if not more) important.
Not always. It can be perfectly reasonable to implement something in a quick and dirty way to get it out there with a view to either kill it off (eg if it doesn’t get adopted by users) or re-write before it needs to be extended. The key is having the awareness when putting yourself in that position.
Forewarning : ops here, I’m one of the few the bosses come to when the “quick code” in production goes sideways and the associated service goes down.
soapbox mode on
Pardon my french but that’s a connerie.
Poorly written code, however fast it has been delivered, will translate ultimately into a range of problems going from customer insatisfaction to complete service outage, a spectrum of issues far more damageable than a late arrival on the market. I’d add that “quick and dirty code” is never “quick and dirty code with relevant, automated, test coverage”, increasing the likelihood off aforementioned failures, the breadth of their impact and the difficulty to fix them.
Coincidentally , any news about yet another code-pissing LLM bothers me a tad, given that code-monkeys using such atrocities wouldn’t know poorly written code from a shopping list to begin with, thus will never be able to maintain the produced gibberish.