One day, when I get an office job and stay with a company for more than a month, I might have the chance to have complete trust with my team. But I’m not the kind of person to look up to people or trust them (unlike my newbie self years ago).
Of course development methodologies are irrelevant to you; it doesn’t matter if your code is maintainable if you’re not going to be around next month.
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.
I’m surprised by this, they were certainly a core part of my curriculum. They’ve also done me well over the years when looking at the new hotness of the week/month and realizing very little of it is actually new.
He’s right. Personally, my degree program has only one course that addresses ethics. You take it your senior year, and it’s mostly a soapbox for the professor to air out his religious and political opinions. The only software engineering class is also taught by the worst professor in the department (he actually just incorrectly read and explained Wikipedia articles multiple days). I’m the Vice President of our student ACM chapter, and one of our main goals as an organization is to fill in the gaps left by the curriculum, particularly regarding the development of real-world software experience. It’s frustrating that the department does so little in this regard, but talking to students at other schools my experiences aren’t uncommon.
I think the developer is going through a phase every programmer should go through. At first when you don’t have much experience, you don’t have the knowledge to judge different methodologies, frameworks or whatever. All you can do is follow the crowd and use what is popular. Once you’ve gained enough expertise, you start to become sceptical about what you read, in fact, you might be completely reluctant to hear anyone else’s praise of the next big thing that will solve your problems. So for some time you stick with what you know and stop trying new things. I think the developer is at this stage. Afterwards, one starts to understand that trying new tools is important, but not all tools are good, there are no one-size-fits-all solutions, everything must be used in the proper manner, time and place. And the ability to use the right framework or methodology when it is objectively the best choice, is a large part of what makes a good programmer.
This is a thoughtful post. Thanks for sharing it.
One concept that’s always helped me in engineering, if not elsewhere too, is the heuristic. Heuristics can’t tell you what to do in every case, but they often give you really useful rules of thumb. These rules by definition don’t always agree, but they do give you a starting point from which to start figuring things out for yourself. (Need to build a distillation tower? There’s a good chance that your first design should start off with a particular number of plates. Need to build a military aircraft? You’re probably going to use a factor of safety between 9 and 15 for stresses on the airframe.)
Thus, I’m not so keen on orthodox methodologies, but I invariably depend on heuristics, whether existing, improved, or invented with my peers.
If this idea interests you, a great person to read is Billy Koen, a mechanical engineering professor at UT Austin. He has a good summary at http://www.me.utexas.edu/~koen/OUP/HeuristicHistory.html , but at least one of his books, notably Definition of the Engineering Method, (http://files.eric.ed.gov/fulltext/ED276572.pdf, but also on Amazon and in libraries) is also worth looking at.
A good rant, I mostly agree. Methodologies are not pointless, they (the same as “Best Practices”) are often evolved under certain circumstances and are appropriate at the time. To ignore them is ignorance, but to embrace them fully as the-one-true way is ignorance combined with drone-ism.
Usually the things that have been accepted as methodologies and the like are there for a good reason, but that doesn’t mean they’re applicable universally. Accept them, learn from them, but always try to fit things to your environment, improve, and make things better.