> 4. The best code is no code, or code you don’t have to maintain
Relativised in the last sentence:
> This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.
Rubs me the wrong way. I get what he is saying here. But damn this feels outdated to me coming from web development.
I work in a small web dev team, but we're constantly working hard to reduce dependencies and rather code things up ourselves. We have designed it, we know how it works, what it can do and what it can't. We have tested it, we maintain it. It is smaller and more purposeful and fits our needs well.
Just keep in mind that this is a learning process.
You will likely suck at writing your own libraries and tools until you made some mistakes. But the end result is code that does exactly what it needs to instead of something that is cobbled together, hard to debug, hard to change.
When your code breaks you can debug the code in your head, while you are walking your dog or after you woke up from a nap. You can see it all there, you can _feel_ it.
With external tools, services and libraries it's not like that. It's always a black box. And it might suddenly change its contents if you look at it funny.
To add onto this, I'm growing more and more skeptical of auto-generation. I understand how it theoretically helps, but the issue is I now have to learn yet another proprietary language to configure the auto-generator (which I then forget because it doesn't get touched often), and when something goes wrong we can't just fix the type and move on, we have to reregenerate the whole module, often with flaky eclipse plugins that require their own arduous "get it working" procedure.
Yes typing mundane things manually is a bore and subject to human error, but that's what code reviews and testing are supposed to be for. It's possible my company's just doing it wrong, but I've definitely had the experience where by the time I got the auto-generator doing what I wanted I could have just written the service/classes myself without piling on extra arcane technical knowledge that I use maybe three times a year.
Very good general point. But I would add the caveat that generating code in a data driven way from a standardized format is fine. You change the data and re-generate the code, fix the calling code if need be.
Also I think it depends a bit on the language and what exactly you generate. If you generate concrete types (or classes) then that might lead to more fixing and refactoring down the line. If you generate data it's different, because you are going to have a general interpreter for said data that doesn't care about its concrete shape.
I said it before: coders import libraries, engineers import dependencies.
Not having to maintain code you depends on means someone else is maintaining it (or not!). That makes this person a stakeholder in your project. It also means that the functionalities your project is relying on might get deprecated tomorrow morning. Then what? Fork and maintain yourself?
> 4. The best code is no code, or code you don’t have to maintain
Relativised in the last sentence:
> This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.
Rubs me the wrong way. I get what he is saying here. But damn this feels outdated to me coming from web development.
I work in a small web dev team, but we're constantly working hard to reduce dependencies and rather code things up ourselves. We have designed it, we know how it works, what it can do and what it can't. We have tested it, we maintain it. It is smaller and more purposeful and fits our needs well.
Just keep in mind that this is a learning process.
You will likely suck at writing your own libraries and tools until you made some mistakes. But the end result is code that does exactly what it needs to instead of something that is cobbled together, hard to debug, hard to change.
When your code breaks you can debug the code in your head, while you are walking your dog or after you woke up from a nap. You can see it all there, you can _feel_ it.
With external tools, services and libraries it's not like that. It's always a black box. And it might suddenly change its contents if you look at it funny.