If he had that insight in 2011 then he was pretty late to the party. By then the 1K to 2K line limit for 'beginner programmers' was very well established.<p>To go beyond that you need a few tricks of the trade, mostly structured programming and avoiding global scope will get you to 10K and up.<p>After 50K or so you will need even more tricks: version control will become a must, naming conventions matter and you're probably well into modularization territory. Some actual high level documentation would also not be a bad idea.<p>By the time you hit 100's of thousands of lines you are probably looking at a life-time's worth of achievement by a single programmer, or more likely you are looking at teamwork. And so you'll need yet more infrastructure around your project to keep it afloat.<p>You can see quite a bit of this at work when you browse through open source repositories at github, those are roughly the points at which plenty of projects and up being abandoned, as often as not through lack of insight in how to organize a larger project as through the demotivation that comes from lack of adoption.
This can be true for a beginner, for a developer who never hit that wall before or for a developer without enough talent to learn how to do it right after all. But once you start using the right methodologies, making things highly modular and as much as possible independent from each other, you can go quite a distance before new "walls" arise.<p>Sometimes I take more time to think of a proper and scalable name for variables and methods than the time it actually took to write the implementation. While refactoring I might do another round of thinking about naming and make sure there are no or an absolute minimum of possible side effects for the implementation, etc..<p>I'm coding almost 30 years now. I'm still learning and make my mistakes of course, but most of the time they occur because I rush for some reason. Writing good code takes time, especially to rethink what you're doing, refactoring, making the right adjustments so it completes the codebase. Before I complete the beta release of a codebase I've made thousands and thousands of decisions, where only 1 wrong decision can cause a terrible amount of trouble later on.<p>For me it's a creative process. It goes in waves. I cannot always be a top performer, I've accepted that. When I recognise I was in a low during some implementation I might do a total rewrite of it or apply some serious refactoring(and force myself to take the time for that).<p>I still experience coding to be much harder to get right than I ever expected it to be. For me a codebase is a highly complex system of maybe hundreds of files with API's working together, not just a bunch of algorithms.
I feel that there is some naiveté in this perspective, although the OP does touch on it somewhat. A novice most likely would write their code in a very monolithic fashion. That same approach fails significantly with larger code bases.<p>As a seasoned developer I have come to realize that one of the most important things to be a good developer is organizational skills. Unfortunately it seems that ways to organize code bases, including things like naming, mutable state, modularization, cohesion/coupling, etc., are not as well developed or understood in general in our industry as they should be.<p>While understanding and knowing the right algorithms is important. I sometimes wonder if our emphasis on the knowing algorithms off the top of your head interviewing process contributes to putting the emphasis on the wrong things in software development.
"Absolutely refuse to add any feature or line of code unless you need it right now, and need it badly."<p>As I've gotten older I've seen the value of this rule. Though it sounds merely negative, it can produce effects that seem little short of genius.
I'm a novice just building my first 2k+ program and the thing that seems crazy to me is that based on what you learn in intro courses, thinks like namespaces and organization and modularization not only aren't emphasized, but seem like unimportant distractions from the core task of programming<p>Based on all the blogs and HN comments and comments here, that couldn't be further from the truth. Are these just things you learn from experience / mentors?
Does this depend on language? 20k lines of Perl is a different beast from 20k lines of Python, or 20k lines of verbose Java, I would expect. If not, does it suggest we should be aiming to use more expressive languages, that can get more done in less lines?
I hadn't come across this before, and sure enough, looking at the current personal project I'm working on, it's composed of 3 main files of C++, a Windows program, a parser [1] and a custom OpenGL control [2], each is 500 - 600 lines.<p>For me, I use Stepwise Refinement [3] to get to this point, but to get further, I have to start breaking out a more abstract approach. I found this definition of Structured Programming that puts it very nicely [4].<p>There's also a perhaps self-imposed wall, where you might trial a solution and implement a prototype, then use that to realize that it no point in pressing on without some serious redesign of a key component. For my example above, the rendering part is old-style OpenGL, which works pretty nicely at 60 fps, but I'm holding off doing more until I can slot in and benchmark a better approach using vertex buffers and shaders, with the goals of enabling me to shape and scale the renderings in an abstracted coordinate system, and scale to rendering hundreds of files instead of just one.<p>[1] <a href="https://twitter.com/watmough/status/962470455037841409" rel="nofollow">https://twitter.com/watmough/status/962470455037841409</a><p>[2] <a href="https://twitter.com/watmough/status/965007110391128064" rel="nofollow">https://twitter.com/watmough/status/965007110391128064</a><p>[3] <a href="http://www.informatik.uni-bremen.de/gdpa/def/def_s/STEPWISE_REFINEMENT.htm" rel="nofollow">http://www.informatik.uni-bremen.de/gdpa/def/def_s/STEPWISE_...</a><p>[4] <a href="https://www.encyclopedia.com/computing/dictionaries-thesauruses-pictures-and-press-releases/structured-programming" rel="nofollow">https://www.encyclopedia.com/computing/dictionaries-thesauru...</a>
Discussed at the time: <a href="https://news.ycombinator.com/item?id=8072730" rel="nofollow">https://news.ycombinator.com/item?id=8072730</a><p>and in 2015: <a href="https://news.ycombinator.com/item?id=10191540" rel="nofollow">https://news.ycombinator.com/item?id=10191540</a>
Interesting. My main project is getting near the 20k range. I haven't hit a wall, but it is getting noticeably harder to stay fluent in every part of the program. When I switch from one major system to another, there is a few days ramp-up. Still happy with readability and complexity.
A bit over dramatic. I remember Unreal 3 was close to 2 mil and that's the normal region for games (and has been for a decade) and trust me, gamedev studios are <i>not</i> staffed by seasoned programmers.