The 2 types of modern software engineers

I have been a software engineer for over 15 years now, and have been writing software since getting my first computer: an Apple 2+ in 1984.

It's amazing how computer languages and hardware have evolved in the last 30 years. Even more interesting is how software engineers, like myself, have evolved over the years.

I recently have come to the conclusion that there are really only 2 types of software engineers in this world nowadays: those who think high-level software design is more important than the actual implementation, and those who don't.

In my opinion, software implementation without high level design, encapsulation of functionality, decoupled or loosely coupled frameworks is a disaster waiting to happen.

What this implies is that we need to "think" about modeling real-world tangible things or concepts in code that accurately represents them. And that this is even actually more important that coding the software itself.

My opinion is based on the fact that I have lived through so many projects at this point in my career which failed to have the complete lack of what I just stated.

Oh, and this isn't an object oriented vs. embedded programming argument. This is a "should I think a little about it first?" vs. "I will just get started and hack" argument.

Most of us in the "Design is more important" camp rely heavily on the use of Software Design Patterns, and prefer to implement the design using higher-level object-oriented languages such Java. We don't feel the need to be too close to the processor.

Don't get me wrong, I like c and c++. I do write code in c/c++ at my current job and am a fairly decent programmer in these languages. I just don't see any reason to use them if the task can be done with Java assuming performance and memory benchmarks can be met and lack of byte-level processing is necessary.

And I am not implying that code written without design is bad, or that the software engineers who do this sort of thing are not as talented as us design people; on the contrary, they are often more knowledgeable in almost any language than design people. But, they have to be. They are better "programmers", but that doesn't make them better software engineers.

When you are developing an application that models a customer account or a shopping cart or real-time multi-threaded UI or server, do you really want to deal with unsigned integers, process byte arrays, dereference pointers, parse a char array, or perform pointer arithmetic or access a register on the processor? Of course not. Knowledge of those things doesn't help you build an application faster.

The funny thing is, is that each camp is fiercely loyal to their opinion. And having a conversation about software and implementation between 2 people that are in different camps is not possible. Their priorities are entirely different, and their understanding of the problem domain and the implementation solution are entirely different.

What do you think?