I did not even read the article but only the title and it amazes me how developers pride themselves on their ability to rush through something and get it out within a day. This defeats a lot of software engineering principles where accounting for edge cases is more important than the happy case because there are more ways that a piece of software can go wrong than right. Also, there is practices such as defensive programming which is very important for more mature developers.
To me, developers who pride themselves on how quickly they can get something out is a bad metric for successful software delivery.
That is true, I mean this politely but what does your response have to do with what I stated initially? Any company with a solid defensive programming strategy would not allow a developer to develop something and push it to production without quality gates in place. A software engineer's job is to be resistant to introducing code into a system.
I did not even read the article but only the title and it amazes me how developers pride themselves on their ability to rush through something and get it out within a day. This defeats a lot of software engineering principles where accounting for edge cases is more important than the happy case because there are more ways that a piece of software can go wrong than right. Also, there is practices such as defensive programming which is very important for more mature developers.
To me, developers who pride themselves on how quickly they can get something out is a bad metric for successful software delivery.
Rome wasn't built in a day :)
That is true, I mean this politely but what does your response have to do with what I stated initially? Any company with a solid defensive programming strategy would not allow a developer to develop something and push it to production without quality gates in place. A software engineer's job is to be resistant to introducing code into a system.
I meant that things take time to get up and running, and work efficiently
Agreed!