This takes it full circle from yesterday, and I agree with most of these points.

And I do stand corrected ... it is probably true most software isn't written with certain standards/concepts/paradigms in mind. However, I do believe that many of the examples you gave yesterday: airline software, bill pay, etc ... are absolutely developed in shops that follow some sort of methodology or standard, right or wrong.

I agree that good developers are, well, good, and tend to write good code, but I also believe that learning and understanding methodologies can help and improve them. It's like learning new words ... as your vocabulary increases, so does your ability to express yourself.

Learning about TDD or BDD or inversion of control doesn't automatically make you a better developer or mean you have to rush out and add a reference to NUnit and Unity to every project, but it does expand your vocabulary for programming and improve your ability to determine what needs to go where.

There are obviously caveats. Unlike the days when we were hacking together 6502 code and watching $d012 for the right raster line to flip a bit in $d011 to make a smooth scrolling effect, our code was likely to sit on some BBS with a few die-hard enthusiasts willing to wait 2 hours to download something at 300BPS.

On the flipside, with the advent of the various "mobile stores" and online commerce, I've noticed two trends: first, anyone can develop a mobile app and push it out there and if it is popular and gets downloads, then does it really matter what principles or designs are behind that cool game people like to play? Second, it only takes a small investment to build an e-Commerce website today so more and more "web developers" are "experts" because they've built a website and sold an item through PayPal.

In all of these cases it turns out that whether or not principles and methodologies were followed, whether the software is good or bad or buggy or uses tests or doesn't, in the end, what is really important is someone somewhere in that pipeline with vision and good sales and marketing skills.

I've seen the worse software become a best seller and the best software languish from lack of being able to get it out into the market.

To make a short story boring, I guess my point is that just because you know a big word doesn't mean you have to use it everyday, but sometimes it's the key that wins the game.

I think you've just described the developer tautology...

Nice couple of articles Jack.  A couple observations...

I realize that much of what is "hot" these days may be old hat to many out there.  But for younger developers, this stuff is a key factor in taking skills to the next level.  I think this is especially true in the .NET arena where MS and the blogosphere has polluted much of the developer pool with bad examples and tools that lead to lazy practices.  Many of the developers I encounter have never heard of SOLID and would be hard pressed to name 1 or 2 well known design patterns, and their code reflects it.

I certainly agree that bad developers will probably continue to write bad code.  I think in the end it all comes down to having the passion for this stuff, which pushes you to learn more and try to become better.  Those who have been writing bad code year after year are probably in this strictly for the paycheck - not because they love it.  Sadly, big corporate America makes it too easy for people to live a life as a mediocre software developer which just perpetuates the cycle.

I wrote a blog post about Passion and it's something that I feel is a real issue, but could be corrected to some degree.

blog.coreycoogan.com/.../passion-in-software-development

Well written Jak, and my feelings exactly.

What would fix much of this is if interviewers actually asked better questions in job interviews.  How many times do the same string manipulation or syntax questions need to be asked before we realize that just because the person answers it correctly it doesn't mean the person can actually code.  

About a year ago I was part of a panel interviewing a candidate and when the bog standard "how do you connect to a database in C#" she answered how, but said that they don't bother where they currently are because they now use NHibernate.  Not one person in the interview room besides me even knew what NHibernate was.  After the interview I explained what an ORM was to the rest of the people I work with, and they decided against the candidate because she was "lazy".  

Instead, they picked someone who knew all sorts of syntax...a few months later that person was let go because their quality of work was so poor.   But hey, they know the difference between a DataSet and a DataReader! :)

It is true that developers tend to think highly of their skill set.  A large majority of us think that we are better than average.  And by strict definition, this just can't be; only half of us can truly be better than average.  However, I do think we need to be careful not to label average so negatively.  It all depends on what average for the industry is.

Let's take a look at the field of medicine.  Surgeries are becoming more advanced and more successful than ever.  Look how far best practices and communication of knowledge have come in that industry.  The "average" surgeon is a highly-skilled and successful practitioner in whom you can entrust your very life.  Average individuals in that particular skill set are amazingly talented.

My point is to say that the field of software development is improving greatly.  It is one of the most fast-paced, in-demand, and successful industries out there.  Software is now the language of business.  However, I don't think we can yet say we trust an average developer as much as we trust an average surgeon.  But I really do think we will get there.  "Average" will not remain a burden on those at the top for very long.

It has been immensely helpful to detail and give names to these patterns and best practices for communication purposes.  Because of this formalization revolution, I will learn and implement these best practices much quicker than I would have learning them the hard way on my own through trial and error.

Nicely written Jak. Though I'm a total newbie and do not match the experience of yours or other commenters/readers here but here's my two cent on this.

I've been in the industry for about 2 years now working with a company that makes 'big' softwares (3d AEC etc.). Here the learning is good, the enviornment is good. I get to know more about patterns that no one told me about back in the univ. days. I started my job overlapping my bachelor's degree. Initially I was quick, but somehow that learning curve has dropped and that worries me. Flashback to 2/3 years when I was doing freelance application development I wrote good code. Even if I go back then and see that code, amazingly enough like you said, it had good design, low coupling, high cohesion, design patterns, planning for extension and much more. It was complete end-to-end deliverable to the client. I was on my own writing good code.

So the point is, yes its good to give a name to design patterns. Its really good to give a name to Unit tests and all that. You people were good because you arrived at those good designs not by the book but by actually writing code and facing problems. I think its totally rubbish to think you'll present 23 design patterns to students in software engineering class and expect them to make use of it. NEVER. Or make them write unit tests the first time around. NEVER. These jargons and things, though good, are enough to 'formulize' things and write them in books for more than average developer.

So my point is, to be above average developer, u need to develop! Do i consider myself above average? from my peers are the univ. definitely. If not the top i'd be in top 5%. Am I at the top 5% at my office, I doubt. I know that I read a lot more, and I probably am more tech savvy than others, but no that does not make me a good developer. The strength of a developer comes from experience not jargons.

Just my 2 cents :) I hope I didnt digress much.

Nicely written Jak. Though I'm a total newbie and do not match the experience of yours or other commenters/readers here but here's my two cent on this.

I've been in the industry for about 2 years now working with a company that makes 'big' softwares (3d AEC etc.). Here the learning is good, the enviornment is good. I get to know more about patterns that no one told me about back in the univ. days. I started my job overlapping my bachelor's degree. Initially I was quick, but somehow that learning curve has dropped and that worries me. Flashback to 2/3 years when I was doing freelance application development I wrote good code. Even if I go back then and see that code, amazingly enough like you said, it had good design, low coupling, high cohesion, design patterns, planning for extension and much more. It was complete end-to-end deliverable to the client. I was on my own writing good code.

So the point is, yes its good to give a name to design patterns. Its really good to give a name to Unit tests and all that. You people were good because you arrived at those good designs not by the book but by actually writing code and facing problems. I think its totally rubbish to think you'll present 23 design patterns to students in software engineering class and expect them to make use of it. NEVER. Or make them write unit tests the first time around. NEVER. These jargons and things, though good, are enough to 'formulize' things and write them in books for more than average developer.

So my point is, to be above average developer, u need to develop! Do i consider myself above average? from my peers are the univ. definitely. If not the top i'd be in top 5%. Am I at the top 5% at my office, I doubt. I know that I read a lot more, and I probably am more tech savvy than others, but no that does not make me a good developer. The strength of a developer comes from experience not jargons.

@Steve

Great comment on interview practices.  I have a pretty rigorous phone screen before I spend an ounce of the team's time in a face-to-face.  It's amazing how many fail this screen despite their resume saying they are a "seasoned architect".  The typical response is "I don't know all the textbook terminology" to basic OO questions like why I would use an interface.

I found that the vast majority of companies out there don't bother to ask deep technical questions, opting instead for the "tell me about a time when..." type questions that do nothing more than show one's ability to bullsh*t.  In one insurance company where I've worked, HR actually forbids the interviewers from sending people to the whiteboard.

Raising the bar in interviews could possibly indirectly force the developer community to up their game if only to get a face-to-face interview.

Yep, we're all chickens and no eggs.

Your assumption in this blog is that good programmers already know stuff like SOLID without having to think about it. And that if you don't know about SOLID, it will never help you because you must already be "below average" if you hadn't figured it out already. I've heard this before.

But "Good Developers Write Good Code" only because they got better than they were before. No skill suddenly jumps into existence without slow, gradual steps.

I wrote bad code before, I write better code now, and I will write even better code in the future. I can achieve this only by reading and learning about what makes code "good" and refining those skills. It will not just "happen" because I'm good already.

SOLID and code quality have educational value - I know it because I was a much worse coder before I was introduced to them. I know that for certain, and it doesn't really matter whether I'm above average or not. I am better only because of  code quality "kerfuffle".

Its probably worth pointing out that (IME) one of the important hallmarks of the developers who actually *ARE* in the top 20% is that they routinely consider themselves to *not* be in the upper 20%.

Constant introspection, self-critical review, and ability to question one's own experience and expertise are essential qualities of a 'good developer' and as a result most that actually are 'good' consider themselves to still have an awful lot to learn and so tend to routinely *undervalue* their skill level...I know I sure do :)