Ah, the naïveté of youth.<p>Here's the thing about methodologies: anyone can use them. Any methodology that is popular enough for you to have heard about it was developed by one or more smart people and solved some real problem. Between now and then though, countless cargo-culters have jumped on the bandwagon and misapplied the methodology to the wrong problem in innumerable ways. Maybe they implemented it wrong, maybe they didn't have applicable problems, maybe they are as dumb as a box of rocks but have carved out a comfortable niche in a fat corporation somewhere. The point is, a methodology is <i>meaningless</i> out of context.<p>Hell, all ideas are meaningless out of context. In every day human life we tend to share a lot of context with those around us, in terms of software development—ie. the stuff of pure thought where the only limit is logic itself—we share considerably less so. When you're writing a web app you are living in a wholly different world from someone writing a Mars lander ROM, yet we call both of those things "software engineering". If you want to have good ideas and be competent you have to apply whatever ideas to the context you are in. Being smart is not about having the best ideas, but about evaluating how ideas apply to and interact with systems. The hardest thing about entrepreneurship isn't figuring out how to write software to do X, it's how to choose X such that a cascading chain of seemingly random events translate into market traction.<p>The horrifying thing about software development is the limited intelligence of the human brain to begin with. From a certain perspective we are hopelessly stupid and incapable of truly elegant software design, but on the other hand we are the only entities we know of with the capacity to write software at all! All this is to say you need to embrace ignorance and subjectivity, and simply pledge yourself to continual improvement. You do this not by latching onto ideas and filing them into good or bad buckets, but rather by processing a lot of them, applying them in practice, and seeing how those with more experience than you do the same.<p>If your curiosity outweighs your frustration over a period of decades, eventually I guarantee you will be at least a competent software developer, and maybe by then ageism in a tech will be something the kids laugh at like televisions with twisty knobs.
Once he gets older and a bit more mellow, he'll see that there are always people who are better - and you can recognize them. Also that it just makes sense to stick to some methodologies to find common ground, to keep your code readable by everyone in the team.<p>Having a desk job helps in understanding it is more important that you can understand your code 3 years down the road than squeeze the last 5% of productivity out right now.
>On the note of software methodologies for teams, I think they are pointless, at least for me. [...] The problem I have with them is their meaning and significance vary between everyone.<p>This looks to be the crux of your argument and it's a weak one. Just because there are wide ranging opinions on definitions does not mean the ideas have no merit. The idea of "education" means something very different to many people. That doesn't mean that public school, college, or Cisco certification training is "pointless". There are thousands of ideas/words that don't meet 100% agreement. Just the other day, there was a thread on HN about what "mathematical proof" meant. Does that mean someone can legitimately dismiss math proofs as pointless because mathematicians disagree?<p>Alan Kay's idea of "object-oriented" is different from Bjarne Stroustrup's. Martin Odersky's idea of "functional language" is different from John McCarthy's. Regardless of <i>the differences</i>, there are still good ideas in both OOP and functional paradigms that can improve designs of software architectures.<p>>I don’t know if I should “love to hear your argument against this” but since this is a blog post from some obscure programmer on the internet, then I’m sure you’ll write it anyways.<p>I don't understand the conceit you wrote here. If this is how you truly felt, why did you post your blog to HN? I thought the idea was to invite commentary.
> I've found that beginners don’t learn about this until it is far too late, and the teachers rarely emphasize it. Many of those who are learning programming through a school aren’t taught about the ethics of programming. They aren’t taught how to design library API’s, how to separate concerns, or how to write small cohesive modules.<p>I like to call this the 'fallacy of assumed competence'. We assume teachers are good at teaching, and teachers assume students are good at learning and understanding. As i've grown older i've come to believe that most teachers suck really hard at teaching, and that most students suck really hard at knowing how to ask the teacher what they need to know.<p>In terms of programmer methodologies: nobody in the real world cares all that much. Nobody quits their job because their bosses wouldn't enforce using their preferred methodology. If you're all tasked with developing some giant framework or application and you all have to work together, at some point you learn it's a lot less painful to put your ego aside and just get work done.