Skip to main content

Programmers Don't Need to Know SOLID

A recent comment on a fairly old post was very adamant:

As a PROGRAMMER YOU MUST KNOW SOLID 

This is completely and utterly wrong, in my opinion.  I was simply going to reply, but I spent a lot of time trying to locate a blog post and the reply started to grow, so I decided to put it here.

SOLID is just a set of principles


The SOLID principles were created based on things good programmers were already doing.  The principles in SOLID are a result of people trying to write good code; they are not a precursor to it.  In other words, clean code comes naturally.  SOLID is a good concept to understand, certainly, but there's a lot more out there than one acronym to know about, and whether or not you can memorize the principles that each of the letters represents has little effect on the quality of your code.

Don't get me wrong, learning about them may help you to understand some concepts that make your code better, but memorizing anything in the programming world is....almost always a complete waste of time.

SHOULD, not MUST


As a programmer, you SHOULD write code that is maintainable and extendable (i.e. Readable).   Note that I said SHOULD, not MUST.  It is important to understand that all it takes to be a programmer is that you write programs.  You can do that with little more than an understanding of how to copy and paste.  That said, if you want to be a good programmer, as defined by your peers and managers, you will want to write good software, that does something useful, doesn't breakdown constantly, and is easy to change and improve upon.

SOLID isn't everything


Let me show you a list of principles and techniques on my resnume:

SOLID, DRY, YAGNI, KISS, Agile, Scrum, Extreme Programming, TDD, BDD, POCO, Code First, Lean, Normalization, Dependency Injection, Loose Coupling, Continuous Integration/Delivery/Deployment

SOLID is listed, of course, but it's just one of the many.  More than that, notice how KISS is considered a programming principle.  I'd consider it a general life principle, but that's what the world seems to care about these days.  The reality is, it's not about any one specific thing, but about a general desire to write better code.

From that desire you'll grow as a programmer, seek out knowledge of principles and techniques that will make you better, and your software better.  The word for this is passion, and it's the most important trait I look for in my employees.  In my opinion, passion is the one thing that separates a career that you love, from a job that you just get money for doing.  Which brings me to the most important bit of this discussion.

Not everyone agrees with SOLID


Passion drives good programmers to improve constantly.  We analyze what we've been doing and try different things to improve upon it.  For example, this guy argues that if you're not careful in how you implement the principles of SOLID, it can become an anti-pattern and make your code less maintainable, not more maintainable.

In his drive to improve his code, this guy is discussing how the world of programming isn't what it was when SOLID was designed, and would like to remove the O entirely.  That means you may end up with an interviewer asking you what the SLID principle is soon.

And then there's this expert, who has been a SOLID advocate for years and has completely changed his mind, saying that it's not even good to teach it!  He's started developing his own set of principles in his follow-up post.

The software world is constantly changing


I have said it before, but this sort of mentality makes me think it bears repeating: Technology is always changing.  10 years ago, the concept of server-side javascript was alien to most developers.  6 years ago, AngularJS was only used by Google.  6 months ago, Disney didn't have the dashboard I just built them (with the MEAN stack) that they now want to improve upon, which means the next dev they hire to look at that software will be working on my code, and have to understand how I did things.

The developers who step into existing companies (startups don't have to worry about this) benefit from FLEXIBILITY, not rigidity.  Mandating that no one can step through your door until they can recite some arbitrary line without looking at their notes (especially when that information is easily available on the net) is restricting yourself from hiring real talent.  It makes your interview process into a game of luck.  Like roulette, you're going to lose most of the time.

This is about work after all


You need the passion, drive, and flexibility to be useful AFTER the company hires you.  The company only cares about what you have done before to the extent that it means you can do something useful for them.  That means that what you know walking in the door, is less important that what you learn after you enter.

Don't memorize an arbitrary set of principles.  Get a deep understanding of how to write clean, flexible, maintainable code.  That's what really matters.

Comments

Popular posts from this blog

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …

When Is Software Done?

I have some very exciting news.  A piece of software I've been working on for over 2 years is released to the general public!  This is a little exciting if it were software I'd been working on for some big company.  It's very exciting because it's software I have been working on for my company.  That's right!  My company is ready to start selling software and start making money!

I'm not gonna use this blog post to talk about my company and what it does.  You can read about that in our press release.  Instead, I'm going to talk about the software industry and the concept of done.  Because, as with everything, it's more complicated than it seems.

Software is never really done
Actually that's a misnomer.  Software can really be done.  But done is sort of a quantum state--there and not there at the same time.  First and foremost, anyone can understand that software that works is complete.  If the software's purpose is to process a credit card, if th…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…