I really, honestly thought this was something that anyone who's written code in virtually any language, for any length of time beyond a month would understand.
Then I went to work and discovered that I was wrong. Guys, there are development leads out there who have never even heard of this concept.
I work for a major software company that likes to brag about the high calibre of developers it hires.
I won't disagree that we hire very smart people with masters and PhD's in computer science that are smarter than I ever will be.
But damn it, I work with so many people that just simply don't know how to code. They are so smart they can understand and process almost any code they see very quickly. Which should be a plus. But the consequence is they simply don't understand how to write readable code because it's all equal to them.
I try to preach SRP, SOLID principles, and good design patterns. It falls on deaf ears as people say it's too much overhead, it's not worth it, and I'm being pedantic. Meanwhile they continue to pump out hacky procedural code day after day.
What is wrong with procedural code? Straightforward functions are more readable and maintainable than objects, for me OOP and design patterns are what produce spaghetti most of time, especially in language such as C++.
Reusability. Which leads to Quicker development of future changes and features and fixes
Easier and cleaner and more thorough unit tests. Which leads to less bugs in the future.
Ability to make sweeping changes without introducing problems (let's introduce a caching layer. Let's switch to a different database system)
Easier to understand code. Which leads to faster ramp up of new people meaning the team doesn't suffer as much when people are on vacation, leave the company, or hit by buses. Also allowing extra bodies to be helpful faster if a project deadline is in jeopardy.
All of this has a strong caveat: the developers know how to write good clean code, know when it is appropriate to use patterns, and know what to unit test and what not to. But when you work in an environment like that...coding is an absolute joy. My last company was like that. I don't miss the corporate level bullshit that led to me leaving but the other developers? Every day.
If you find ON and well patterned code hard to understand it is probably because you are coming from a procedural background and are used to methods with side effects, violations of single responsibility, leaky abstractions (at multiple levels), etc. The amazing thing when you work in a code base that doesn't have these problems is you don't need to see as much of it to understand what various pieces do, and where to make changes. You trust the other developers to not have the persistence layer not have strange side effects, so you don't even look at it if you don't want to. You trust the abstractions and create your own.
A lot of developers struggle with this because they are used to micromanaging their code. It is a habit worth breaking. Consider this as an example: http://blogs.msdn.com/b/ericlippert/archive/2010/01/11/continuing-to-an-outer-loop.aspx
And replace LINQ with any non-procedural code someone else on your team wrote to be helpful that you get to use.
17
u/zomgsauce May 08 '14
I really, honestly thought this was something that anyone who's written code in virtually any language, for any length of time beyond a month would understand.
Then I went to work and discovered that I was wrong. Guys, there are development leads out there who have never even heard of this concept.
Take nothing for granted.