Thanks for your post! It's interesting because it seems to go against the grain in a lot of ways.
All your points got a response out of me, so I thought I'd share.
1. I ask, "How Does This Not Exist?!" A Lot.
I've done the same thing a few times now. Sometimes the only things on the market satisfy 80% of what you need.
Sometimes there are too many options to assess with no clear winner. I find that it's often a tough question to find an answer to.
I have reinvented the wheel before though and it was quicker than learning new technology - in terms of installation, development, and maintenance -
it was also fit for purpose. Many tools you find online solve a generic problem and it's a lot of overhead to fine-tune it to your needs.
2. I Don't Think Building Things Yourself Builds Character
I disagree.
I would love to write my own compiler or database, just to get a better idea of the underlying principles.
Just not on business time. You have to find a balance between putting the business needs first vs. your own curiosity.
I do think that it says more about your character as a developer if you work on a side project in your free time rather than just staring at a Netflix show.
3. Don't Speculatively Abstract Anything
SOLID principles disagree with you here. Perhaps I'm still drinking the Kool-Aid at this point in my career but you need to follow a methodology when you're working with other people.
It's like road rules: Imagine people started driving on the wrong side of the road, disobeying traffic lights, etc. during rush hour.
If they did it at 3 am when no one else was around, they'd get away with it and no one would get hurt.
Because it's your codebase and the team is relatively small, you've gotten away with it.
4. Technical Debt Can Be Technical Leverage
It can be but often isn't. That being said, perhaps it depends on what we define as technical debt. True technical debt, sure. A mess? Never.
5. My Pride in My Work Product is Irrelevant
Ivory towers of code don't give you business value, true.
However, no one wants to work on a crappy codebase.
I think your team will be more productive if there's a certain standard maintained.
That being said, I know what you mean. From a business aspect, you need to deliver and you can't always make things exactly as you'd want.
I generally follow the advice of Kent Beck's quote: "Make it work, Make it right, Make it fast" - You start with the first but the rest are as important for the overall health of your codebase -> product -> business.
Regarding (2), I'm not sure that the only choices in your free time are a "character building" re-invention of the wheel or watching television. Instead of building the world's 90,000th compiler, but probably not as good, why not build a plugin or SaaS that someone might actually use in your spare time?
Regarding (3), I'm curious as to which SOLID principle calls for speculative abstraction. I've never seen an argument that SOLID and YAGNI are at odds. Usually, in my consulting travels, the sorts of clean-code-minded craftsman types that advised companies would tout both of these concepts together.
BTW, looks like you put a lot of thought into the responses here -- if I were you, I'd flesh them out into a post here :)
2) Hahaha, yes I would think that it would be more useful. I'm not saying that you should go and martyr all your free time by redoing what has already been done, only that it's fine to do so if it's an exercise for you to learn something.
3) Maybe I should have clarified that what I was referring to specifically was this: "And interfaces. Interfaces everywhere.
Sure, today you might want it to sort MP3 files on disk, but maybe tomorrow you'll want it to be links in a relational database or blobs in a document store. If you interface all of your layers, you can swap out your entire persistence model without ever touching anything else!"
You seem to be speaking against the Interface segregation rule in SOLID here. I agree that arbitrarily abstracting away things for the sake of it or just to follow some "best practice" doesn't make any sense. But I think that having code that is flexible enough to swap out portions is pretty nifty. Not necessarily in order to change the implementation, but at least to be able to mock up concerns and do unit testing.
I think your team will be more productive if there's a certain standard maintained.
Very true! I know exactly the kind of code you mean: Copy-pasting is everywhere (down to the typo in the comments); subroutines are named "oldMethod", "newMethod" and "reallyNewMethod", the most recent of which is 14 years old. Someone has, effectively, handed in their first-draft. Working in that kind of codebase is like wading through treacle. Nothing happens quickly.
That said, I have questions about the Make it right part of Kent Beck's quote. It needs a proviso: (until wrong). I tend to reach a point during refactoring where I think "Does this code actually need to be any Righter?" That's usually my sign to stop -- I'm no longer adding value. I've crept into ego-project territory, exactly as Erik describes in his post. Sure I can keep tidying, but doing so would be wrong.
Ultimately, I guess the people who have this kind of debate don't tend to be the problem. At the very least, their crappy code will be considered crappy code. They will be able to justify their decisions with something more than a shrug and a yawn. And hopefully, someday, they'll go back and make it right (until wrong).
You would have to define what "Right" means to you.
Overly academic and difficult to follow is not what I would strive towards.
Code, like all communication, needs to be simple in order to be effective.
Learning to simplify is probably the most valuable skill I've picked up over the years. The question "How can this be made simpler?" has served me extremely well. Particularly, as you say, when communicating -- be it in code or even just an email. I often think of the Blaise Pascal quote: I'm sorry I wrote you such a long letter; I didn't have time to write a short one.
Kudos for digging this far into the comments, Erik! It's a fantastic quote ... even if I'm never sure who it's attributed to. (I'm sure at least one source will say it came from Albert Einstein.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Eric,
Thanks for your post! It's interesting because it seems to go against the grain in a lot of ways.
All your points got a response out of me, so I thought I'd share.
1. I ask, "How Does This Not Exist?!" A Lot.
I've done the same thing a few times now. Sometimes the only things on the market satisfy 80% of what you need.
Sometimes there are too many options to assess with no clear winner. I find that it's often a tough question to find an answer to.
I have reinvented the wheel before though and it was quicker than learning new technology - in terms of installation, development, and maintenance -
it was also fit for purpose. Many tools you find online solve a generic problem and it's a lot of overhead to fine-tune it to your needs.
2. I Don't Think Building Things Yourself Builds Character
I disagree.
I would love to write my own compiler or database, just to get a better idea of the underlying principles.
Just not on business time. You have to find a balance between putting the business needs first vs. your own curiosity.
I do think that it says more about your character as a developer if you work on a side project in your free time rather than just staring at a Netflix show.
3. Don't Speculatively Abstract Anything
SOLID principles disagree with you here. Perhaps I'm still drinking the Kool-Aid at this point in my career but you need to follow a methodology when you're working with other people.
It's like road rules: Imagine people started driving on the wrong side of the road, disobeying traffic lights, etc. during rush hour.
If they did it at 3 am when no one else was around, they'd get away with it and no one would get hurt.
Because it's your codebase and the team is relatively small, you've gotten away with it.
4. Technical Debt Can Be Technical Leverage
It can be but often isn't. That being said, perhaps it depends on what we define as technical debt. True technical debt, sure. A mess? Never.
5. My Pride in My Work Product is Irrelevant
Ivory towers of code don't give you business value, true.
However, no one wants to work on a crappy codebase.
I think your team will be more productive if there's a certain standard maintained.
That being said, I know what you mean. From a business aspect, you need to deliver and you can't always make things exactly as you'd want.
I generally follow the advice of Kent Beck's quote: "Make it work, Make it right, Make it fast" - You start with the first but the rest are as important for the overall health of your codebase -> product -> business.
Regarding (2), I'm not sure that the only choices in your free time are a "character building" re-invention of the wheel or watching television. Instead of building the world's 90,000th compiler, but probably not as good, why not build a plugin or SaaS that someone might actually use in your spare time?
Regarding (3), I'm curious as to which SOLID principle calls for speculative abstraction. I've never seen an argument that SOLID and YAGNI are at odds. Usually, in my consulting travels, the sorts of clean-code-minded craftsman types that advised companies would tout both of these concepts together.
BTW, looks like you put a lot of thought into the responses here -- if I were you, I'd flesh them out into a post here :)
2) Hahaha, yes I would think that it would be more useful. I'm not saying that you should go and martyr all your free time by redoing what has already been done, only that it's fine to do so if it's an exercise for you to learn something.
3) Maybe I should have clarified that what I was referring to specifically was this: "And interfaces. Interfaces everywhere.
Sure, today you might want it to sort MP3 files on disk, but maybe tomorrow you'll want it to be links in a relational database or blobs in a document store. If you interface all of your layers, you can swap out your entire persistence model without ever touching anything else!"
You seem to be speaking against the Interface segregation rule in SOLID here. I agree that arbitrarily abstracting away things for the sake of it or just to follow some "best practice" doesn't make any sense. But I think that having code that is flexible enough to swap out portions is pretty nifty. Not necessarily in order to change the implementation, but at least to be able to mock up concerns and do unit testing.
Thanks, maybe I will :)
Very true! I know exactly the kind of code you mean: Copy-pasting is everywhere (down to the typo in the comments); subroutines are named "oldMethod", "newMethod" and "reallyNewMethod", the most recent of which is 14 years old. Someone has, effectively, handed in their first-draft. Working in that kind of codebase is like wading through treacle. Nothing happens quickly.
That said, I have questions about the Make it right part of Kent Beck's quote. It needs a proviso: (until wrong). I tend to reach a point during refactoring where I think "Does this code actually need to be any Righter?" That's usually my sign to stop -- I'm no longer adding value. I've crept into ego-project territory, exactly as Erik describes in his post. Sure I can keep tidying, but doing so would be wrong.
Ultimately, I guess the people who have this kind of debate don't tend to be the problem. At the very least, their crappy code will be considered crappy code. They will be able to justify their decisions with something more than a shrug and a yawn. And hopefully, someday, they'll go back and make it right (until wrong).
You would have to define what "Right" means to you.
Overly academic and difficult to follow is not what I would strive towards.
Code, like all communication, needs to be simple in order to be effective.
Totally agree.
Learning to simplify is probably the most valuable skill I've picked up over the years. The question "How can this be made simpler?" has served me extremely well. Particularly, as you say, when communicating -- be it in code or even just an email. I often think of the Blaise Pascal quote: I'm sorry I wrote you such a long letter; I didn't have time to write a short one.
"I'm sorry I wrote you such a long letter; I didn't have time to write a short one." - Classic XD
I love Mark Twain wisdom, regardless how how deep it's threaded in any comments section ❤️ (It's also the story of my life)
Kudos for digging this far into the comments, Erik! It's a fantastic quote ... even if I'm never sure who it's attributed to. (I'm sure at least one source will say it came from Albert Einstein.)