Programmers Don't Need to Know SOLID
A recent comment on a fairly old post was very adamant:
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.
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.
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.
Let me show you a list of principles and techniques on my resnume:
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.
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.
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.
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.
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
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
Post a Comment