Good Developers Write Good Code, Instinctively

So my last post ruffled some feathers, but Steve hit the nail right on the head in his commments, and it was sort of the subtext of what I was saying:

All this kerfuffle about "software craftsmen" and "code quality" and "best practice" misses the ultimate fundamental truth :

Good Developers Write Good Code, Instinctively

Let start with a funny statistic ... it certainly applies to drivers, I'm sure it applies to developers too (and almost any group of people) ...

80% of developers think they are above average!

Our logical brains can't help but admit that at least 30% of developers are therefore deluded. Our mathematical brains can't help but admit that 50% of developers must be totally average or below average. And yet, most of us think we are above average developers. I would boldly go further, and put myself in the top 20% of developers - I like to think I at least have a damn good idea who the 20% above me are and why they are better.

If you are a "good developer" you will write "good" code. It will probably use a dozen standard patterns, maybe without you even knowing what they are called, it will have low coupling, high cohesion, be easy to test, easy to extend, hard to modify, avoid duplication and abstract code behind well thought out interfaces. And yet despite all that - you may well have never heard of software patterns, OCP, ISP, DIP, unit Testing, DRY, YAGNI, etc etc etc

Before The Renaissance

There was a time, which sadly I am old enough to remember, when we didn't have all these fancy names, and yet we pretty much did what all the enlightend are doing today.

We may not have had "unit testing", but we had "test harnesses", and we may not have had automated tests running after every build, but we had QA people using our test harnesses to verify our code.

We may not have had software patterns, but we all used factories, observers and singletons.

We may not have has SOLID, but we wrote good decoupled code, well abstracted, easy to test and easy to maintain.

None of These Things Are New

While many like to go on almost holy crusades about these wonderful new inventions, some of us know that these are just evolutions of things good developers have been doing since programming began. Sure they are now formalised, they have great names, they have been refined to be more automated and more efficient - but at the end of the day - good developers already did this stuff.

What concerns me more is how "new" these things seem to some of the holy crusaders. I remember code I wrote in 6502 assembler that had these principles applied (you try writing games in 3.5kb of RAM if you don't apply DRY), I remember code I wrote in COBOL on a PDP/11 that had "factories".

I remember working on a RAD team in an investment bank, long before RAD had meaning. We delivered software fast, direct to the customers, with rapid feedback and weekly releases. We sat with the traders, we were "Agile" and "Lean" long before anyone thought of proper words.

These great software practices were not invented, they were formalisations of things we were already doing.

All Of These Things Are Good

Before anyone decides to rip my head off and banish me to the pits of hell, let me state - all of these practices are good. More over, these practices are (probably) the pinnacle of our current understanding of development practices garnered over the last 30 or 40 years - and we should strive to write code with these things in mind. In 5 years I have no doubt all these things will have evolved, and there will be new best practices. Half of these things only apply to Java and C# anyway - in the world of F#, Erlang, Ruby and Python there are new principles and best practices.

Formalisation of all these practices, principles and methodologies is good - it helps promote understanding and gives us a way of communicating.

The thing is, the real "above average" developers were probably already doing this - and all that code they wrote for the past 30 years is probably still running your bank accounts, processing your taxes and helping keep your aircraft in the sky, precisely because they already did.

Below Average Developers Will Always Write Below Average Code

No way to avoid this I'm afraid - we can talk about the need to raise the bar, to raise the average, to help those below average developers write better code - but fundamentally, below average developers will always write below average code. The above average developers need to recognise this, and understand that they will always feel they are being held back by the lower 50%, and they are always fixing the code of the lower 50%, and they are always doing more than their share.

And one last question... are you sure YOU are above average? I'm not sure myself, in fact my most common comment in interviews is that I am not the best C# developer in the world by a long way, I am rarely the best C# developer in my team for that matter. Am I in the top 20%? Probably by my own standards and measures - that doesn't mean I am by everyone else's measures.

 


Posted 10-06-2009 9:09 AM by Jak Charlton

[Advertisement]

Comments

Jeremy Likness wrote re: Good Developers Write Good Code, Instinctively
on 10-06-2009 6:58 AM

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.

Awkward Coder wrote re: Good Developers Write Good Code, Instinctively
on 10-06-2009 8:28 AM

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

Jak Charlton wrote re: Good Developers Write Good Code, Instinctively
on 10-06-2009 8:54 AM

@Jeremy

I knew you would come around in the end :)

@Awkward Coder

Everyone has a marketing niche they want to fill - a new language gives them a distinct product.

Corey Coogan wrote re: Good Developers Write Good Code, Instinctively
on 10-06-2009 11:19 AM

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

Steve wrote re: Good Developers Write Good Code, Instinctively
on 10-06-2009 4:24 PM

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! :)

Mike Murray wrote re: Good Developers Write Good Code, Instinctively
on 10-06-2009 4:46 PM

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.

Zaki Shaheen wrote re: Good Developers Write Good Code, Instinctively
on 10-07-2009 2:08 AM

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.

Zaki Shaheen wrote re: Good Developers Write Good Code, Instinctively
on 10-07-2009 2:10 AM

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.

Corey Coogan wrote re: Good Developers Write Good Code, Instinctively
on 10-07-2009 11:22 AM

@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.

PandaWood wrote re: Good Developers Write Good Code, Instinctively
on 10-07-2009 11:04 PM

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".

Steve Bohlen wrote re: Good Developers Write Good Code, Instinctively
on 12-13-2009 12:18 PM

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 :)

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)