I read some weeks ago this blog post on John Carmack talking about inlined code (What I understood to be -english is not my first language, so please bear with me- the need, or lack of need of moving chunks of code to functions, even though those functions aren't going to be called more than once), and it has kept me wondering for a while, bot on how I write code and what I've seen around my (short) laboral experience.

Now, I've been working for a bit of time on your standard, boring J2EE corporate applications, and I've found a strange (for me) tendency to avoid separation of chunks of code into auxiliar functions in favor of "monolithic" chunks of code over 200 or 300 lines long.

I've seen this specially on "front/facade" classes, where the application "receives" input, either a REST service class or a class that handles the drawing of a web page. For instance, in Vaadin (A framework that allows you to make webpages using Java code), there could be a single function called "generateBody" with several hundred lines. I would separate that code into different chunks (what would end up being divs on the main function), and have the main function be, let's say, some dozens of lines of code wide, replacing the actual code for "element A" for a "generateA" function that returns the element.

I can understand that too much branching into different functions can lead to a code that is more complex to read through way too much function calls, but I can't wrap my head around why writing one function with 1000 lines of code is better than having some functions and subfunctions (arranged in what I hope is a logical manner), besides having to work on "auto mode" due deadlines and such.

I don't really know what could be the question here, as I'm wondering if something in my way of thinking is off, if almost everyone I've seen on companies writing code are doing it wrong (or at least "not really well") or what (if something) could learn from this question. So, any thoughts on the topic?