I am strongly convinced that the developments of the last hundred years in philosophy and linguistics could give a big boost to the software engineering at all levels. It is absurd that the software engineers by definition deal full-time with the artificial and natural languages and yet they wield practically no linguistic appartus in their daily endeavour.
Many if not most programmers know nothing about the simple and powerful concepts available: they are not taught them, there are no books on such knowledge, and the things that already have found their way into the programmer's psyche - like pattern languages, object orientation, agile methodologies, etc - are often misconstrued, since mechanics behind them are not exposed to the practicioners.
On the other hand, being soft - and therefore vulnerable - knowledge, the humanities tend to protect themselves, wrapping their core concepts into endless layers of the intricate fabric of defensive reasoning, cross-referencing, arguments from authority, etc, which makes them difficult, if not impenetrable and useless, for the layman. The humanities lose their original drive and purpose, which is the application in the human daily life, technology being a major part of it.
Since the purpose of software engineering on the small and large scale is to produce useful innovative high-quality systems in timely way, the proven practical application beats the academic rigour.
I will try to present some concepts that help solve actual problems and dispell some entrenched misconceptions in sofware engineering.
When applied, concepts turn into tools and practices: how to reason, while designing a class, collecting user requirements, judging how useful a meeting is, etc. Or rather - and it is one of my main points - if a concept cannot be expressed as a practice, it is not a true concept. Concepts and practices are the same thing.
Many of those concepts already exist as a part of the common wisdom in software engineering. I just will try to articulate and trace them back to their simple and lucid roots.
They will not solve all problems of software engineering or teach one how to be code. They essentially are not axioms or rules, but best practices and critical attitude that may improve and sort out what one already knows and does.
Even if you find that concepts I suggest contradict your ways, they will give you a mirror or yardstick to reflect upon your own methods.
It is too familiar a situation, when a couple of bright people incredibly rapidly implement the first cut of a great idea that starts off a major project or attracts further funding. After a while the progress slows, which looks natural since more tedium kicks in and more engineers need to collaborate. But then it slows beyond what would look natural, often to a griding halt or, worse, the constant fire-fighting makes things going backwards.
What slows the project down? A bad design? But then why things went so well in the beginning? Does not it mean that the original design was good? Then where was the wrong turn? Something was good, hence the original success and quick advance; but something else went bad too, often not lack of smarts, but lack of a certain type of discipline.
"Discipline" sounds like "obedience" or "subordination", but the software development is fueled by unrepressed minds, thus the real meaning of good software discipline is "restraint". Good code has good manageable structure. Structure as opposed to mess is about limitations and constraints. One can go as far as saying that limitations and constraints are the only forces that create and shape structure.
Therefore, the starting point of coding is understanding constraints, not structure; discipline and not architecture or design.
A bright skillful person may not consciously perceive constraints, while she or he creates and designs, because constraints most of the time are not equal to obstacles. They are forces - as in Pattern Languages - and the creative design always is about skillfully using and directing those forces.
Development discipline is about constantly being conscious about those forces and continuously reflect whether one's code is violating those constraints and rectify it at the first signs of the things starting looking not as they are supposed to. There often is nothing wrong about being oblivious of constraints or acting against them; it just is expensive.
In the following posts I mostly take such a critical approach and methods of analysis, rather than trying to come up with a constructive design mindset: in software engineering, there already are dozens of thousands of sharp minds full of creative ideas; and perhaps millions good engineers whose work puts bread on their families' tables. My notes are about making their work less stressful, more efficient, tractable, and hopefully more fun.