One of the many popular comments for the Ferengi Programmer's article is as follows:
From what I can see, the problem of "programming too attached to rules" is almost unimportant by the problem. "Many programmers don't really have a clue in software development." most. ”Most programmers don't interact too much with design patterns, SOLID, or agile, or waterfall … They often use instant noodles solutions like cowboys in a completely wild environment, using Simple drag-and-drop, data driven, VB programming style techniques.
But this is a paradox: the type of programmers will benefit the most from guidelines, rules, rules … who must at least be able to read and follow them. Throwing a book containing the rules into a corny programmer will only create a corn pulp programmer with a bruise on their forehead, where the book hit. This is a problem I discussed earlier in Mort, Elvis, Einstein and You article:
So if you read this article, then you're probably already in the 20% group. The other 80% group did not actively think about software development. They will never find this article, let alone read it. They simply don't read programming blogs – they just search for results on Google to find quick answers to a specific problem they are having. And they didn't read any books in my list of proposals either . The characteristic to define most of the so-called "evil deviant programmers" is that they are inaccessible . No matter what you, me or anyone wrote here – they will never see.
In the absence of consulting and apprenticeship , the dissemination of good programming practices is often packaged for convenience into processes and methodologies. How many methods listed below are you aware of? How many of these methods have you used?
1969 Structured programming
1975 Jackson Structured Programming
1980 Structured Systems Analysis and Design Methodology
1980 Structured Analysis and Design Technique
1981 Information Engineering
1990 Object-oriented programming
1991 Rapid Application Development
1990 Virtual finite state machine
1995 Dynamic Systems Development Method
1999 Extreme Programming
2002 Enterprise Unified Process
2003 Rational Unified Process
2004 Constructionist Design Methodology
2005 Agile Unified Process
And how do we expect middle-level programmers to learn about these? Only encapsulated in one word, marketing . It is no coincidence that there are many methods of counseling and teaching about them. Because most developers are inaccessible:
I'm sitting in my office talking to a colleague named Jeremy Sheeley. Jeremy leads the development team for Vault and Fortress. During our discussion, I suddenly realized that none of our marketing efforts could reach Jeremy. He never went to a technology trade fair or conference. I don't read magazines. I don't read programming blogs. He also did not attend the meetup sessions. Ironically, Jeremy is the one making the decision about which version of the group he will use the version control tool on, and without what we are doing will make him know about our product. How many of these Jeremies are out there?
There are millions! As Seth Godin noted, this inaccessible situation is truly irreverent – at least not through marketing.
So, if we know the programmers will benefit the most from the rules, guidelines and re-instructions:
- Do not like to read them voluntarily
- It is almost impossible to reach them through traditional marketing methods
This makes me think – who do we write to these principles, rules, guidelines and methodology? If we only reach developers who are thoughtful enough to care about their work, will our mission really be completed? I agree with Jeff R., who left a comment like this:
There is nothing wrong with the SOLID rules at all; they mean something to me. But I've programmed since the days when people used reader and teletypes cards. They will not make sense to those with little experience. They do not know when and how to apply these principles appropriately. They will be bogged down in their efforts.
Therefore, trying to follow them changes the focus from the results to the process. And that is a fatal mistake.
It is the job of the lead programmer or manager to see good principles to follow, perhaps by guiding others invisibly, without explicit instructions. or even mention these principles.
In my effort to make programming skills worse every year, I read hundreds of programming books. I have studied all modern programming methods. I even got a Certified Scrum Master certificate. All of this, for me, seems to reinforce the four core fundamentals in programming. But what is that "4 core fundamentals" ?. I will speak shortly:
Atwood's best programming methods system
What do all these extremely detailed rules, guidelines, methods, and principles mean? You will not need it. If it cannot be explained clearly on a single piece of paper, it is a waste of your time. Read and write some code! And if you can't lay down the basic principles for the first three or four years of your programming career, yes – a little change in this quote by R. Lee Ermey may be helpful to you.