This kind of straight forward/naive code actually tends to contain many bugs. I once worked with a guy who very quickly produced stuff. One thing he wrote was a

This kind of straight forward/naive code actually tends to contain many bugs. I once worked with a guy who very quickly produced stuff. One thing he wrote was a program to display a table on a small screen. He mentioned that he thought that something was off in the drawing api or the hardware because it would not show a border around the table. That sounded strange, but whatever. Then I inherited his code and was tasked with extending it. Because I found these very large functions of 'doing straightforward stuff' rather hard to extend reliably, I wrote some automated tests for it. During writing the tests I found the cause of his 'border issue'. There were two off-by-one errors in this. Firstly, when there were N rows/columns he would draw borders by iterating from 1 to N. However, between N rows/columns there are N+1 boundaries, so the iteration should be from 0 to N (inclusive) instead. Next, he was drawing the border with a coordinate that was one too large, making it fall of the screen by one pixel. I think this "write code like you just learned how to program" does not result into very maintainable stuff. And maintenance is generally is an important issue because people keep wanting us to produce features and extensions....