First, thank you for both the well written response as well as the lively discussion. The topics and ideas presented here are not new, but reflect a number of internal discussions and self-evalutions that I have considered not only for my own beliefs but as topics to expound upon while writing. I am curious as to what assumptions might be made regarding my perceptions and status. The article that initiated this discussion was written from the perspective of a manager. I have held that title for a number of years now.
Yet behind that, I have a degree in Computer Engineering from a well known Engineering school and a nearly 15 year background as a developer/software engineer prior to stepping into a management role. While I cannot lay claim to a well known and well used product from the likes of Microsoft, my experience is across the board and across the true full stack of development, from C code in firmware, to serial communications in C++, to frontend in vb, Oracle PL/SQL and data warehousing, with some web development on top of all of that with a sprinkling of mainframe COBOL thrown in for good measure. Please note that I am not attempting to compare resumes here — my goal is to provide some background context and nothing more.
Now that the background bona fides are out of the way, please bear with me as I attempt to address what I am humbly presuming to be assumptions regarding my place in the spectrum of software managers.
First, having also left a workplace due to the overbearing nature of a more “modern” project manager, I feel your pain at the current state of development. There are fads and topics and languages flying around with new ones hitting the scene every day. While in college in the late 90's, I remember feeling knowledgeable about most of the state of software development, machine languages, and hardware. To even attempt to ascribe to that level of understanding in today’s constantly evolving space is a ludicrous endeavor that gives me a headache just thinking about it.
However, writing has provided me with a platform to provide my views on topics like these and I have attempted to re-define the term Engineer in the method that fits my outlook and opinion. In my writing I use a capitalized term if for no other reason than to refer to my own personal definition. Yes, the state of the industry has changed. No, a college degree (or a garage self-education) is no longer a requirement for entry yet we have people taking 6 week bootcamp courses that are flooding into open roles due to a lack of qualified people to fill them. My whole point here is one of agreement — an Engineer definitely should have an ability to examine and evaluate an idea on merit alone, yet the amount of people with this ability it frighteningly small.
As I have gotten older, my willingness to put myself out there for peer review has grown. It has also given me greater perspective. So many of the comments that I am responding to carry a negative connotation regarding the current state of general software engineering. I cannot do more than state agreement with many of the arguments presented — yet I can attempt to describe the state of my world view as being much smaller in scope than the general state of the industry overall. I don’t work at a huge company like Microsoft. I often wonder if I would even be able to function in an environment such as that.
In my career I have primarily been associated with 3 organizations. In each of the moves I have made the organization has been small and the amount of profit at each successive role has been over an order of magnitude less than the previous company. Yet in each move, both my responsibilities and my ability to influence the direction of the company have increased. Currently I oversee a team of 15, with just over half that group working on software. If I am going to bring a new person into this group then as implied in the original article, they must be able to stand on their own. I don’t have time to fill a blank slate and I certainly need “individualistic” people on the team. I deal with conflicts between methodologies on a daily basis. And these are good and healthy things for the team.
There is an incredibly interesting change occurring in software engineering right now. The term Software Engineering is attributed to Margaret Hamilton during her time working at NASA on the Apollo program in the 1960s. At best, the field is only 50–60 years old. We are at the tail end of the first generation or two of people in this field and it is exploding faster than the structure, discipline, and science can keep up with it. In the group that I work with there is a range of 40+ years between the youngest and the oldest team members. This massive dichotomy in methods and opinions makes this job incredibly difficult at times.
I don’t have answers here in regards to generational outlooks and how they apply to writing code. That is a very interesting topic. I will readily admit that I have worked on broadening my views in my time as a manager to attempt to better understand people with different expectations than those that I hold. Whether this has helped or degraded my capabilities as a manager is something I am not ready to cast a verdict on as yet.
The intent of the human nature comments were not intended as a reflection of a group of Engineers. It was intended to reflect that a group of humans, no matter the area or topic, tend to form bonds through shared experiences. It is these that can potentially make assimilation of new members a difficult task for a new member of that group. This is not always the case. This is also certainly nowhere near an argument for development by committee. I am shuddering at the thought in just writing that statement.
Again, I will state that I very much appreciate the discourse here, it has given me not only a number of new topics to consider writing about, but a number of new ideas to review against my own ideas and beliefs.