I'm looking for honest feedback on my content. Please comment or reach out to me on Twitter!
Building software is easy. Building well designed, go...
For further actions, you may consider blocking this person and/or reporting abuse
Great article! The only thing I have to say is that I'm one of those people who says that repeating something twice isn't enough to justify abstracting it out just for the sake of being DRY. In only the most simple programs will something that you use a third time be exactly the same as the first two times you did it. Waiting until you've repeated yourself three times helps you know what it is that you're actually repeating.
Context is crucial too...you can have the same code show up in different places with completely different contexts which looks repetitive, but it makes no sense to de-duplicate something that crosses system boundaries.
Absolutely right. Sometimes you can have the exact code verbatim and working off two different input/outputs. One of those implementations may change without the other so by de-duping and putting into a method you can be creating a regression.
This is why software engineering is so fun! (not saying it sarcastically)
duplication is better than the wrong abstraction :D
most of the time, yes
I can live with that. I usually stop and abstract when I find myself repeating something the 2nd time because I don't want it to spiral out of control. I've been criticized in code reviews for abstracting too much into methods, some of them only having one or two lines. I abstract things early which may be repeated... that arguably can be another form of YAGNI lol.
But I do like the "do one thing and do it well" philosophy. 3 times is reasonable.
Yeah I was recently being told to go back and learn my basics in SoCs and stoics because I challenge the notion of blindly following patterns and abstractions.
Abstraction create layers and can lead to obfuscation if the wrong thing is being abstracted. This "right" thing can be extra hard to identify, so this is where YAGNI creates conflict with Dry or SoC.
Welcome to level <n+1> :)
As you have neatly expressed, it's always a compromise between YAGNI and DRY/SOC. I like to aim for a sweet spot where it just passes the tests, and someone else (always yourself in 3 years time!) can maintain it without swearing at you!
Just to give even more advice to some beginners: don't focus too much on making sure you're hitting these things. Your first job is to write the software. Spending too much trying to make sure you're hitting all these can keep you from your main goal: finish the project.
Most of the time these things will just happen with experience. I mistakenly spent entirely too much time trying to meet one of these 5 principles before and it kept me from actually finishing projects. As you grow as a developer these things will develop naturally in your code most of the time.
Hi Jeremy!
Thanks for your post.
I think that YAGNI and KISS are principles that you acquire with the experience because when you're novice you want to create complex software although your target was simple.
Adding to that, when you're starting you believe that complexity somehow decreases your chances for bugs, improves your code quality and things like that.
I believe that many times that's not necessary. And I believe that many senior developers don't grow out of that phase, and keep trying to apply ALL concepts and ALL abstractions ALL THE TIME!
It becomes a giant feedback loop with some people. You create a bunch of complexity in the beginning, learn more and lean it down, then learn more and make it complex again trying to fit some neat pattern you read about. I've been guilty of it myself.
Sometimes you have to step back and ask yourself "Am I shipping anything? Why not?"
There is no difference between "software engineer" and "software developer" other than that some organizations like one term over the other. AFAIK in some parts of the world the term "engineer" is also protected and thus "developer" is preferred.
While I agree many organizations abuse the terms, there is a clear difference.
It's similar to a bricklayer and the architect drawing up plans. While they're both essential to creating the building, each has their own craft to it. This is exactly why some people enjoy being developers and staying developers rather than move to the engineering side of things.
This is like arguing "hacker" is different from "cracker", might have been the case 30 years ago, definitely not so in the world we live in now. The security industry decided to find a new way to differentiate with the white/gray/black -hats.
I've worked in the industry quite a long time and never think a "Software Engineer" is in any way different from "Developer" when I see them in CVs/business cards/whatever. With the way people abuse the terms I barely see any difference between a "Junior Developer", "Developer", or "Senior Developer" .. hell some "Lead Developers" are basically people who learned to code 2 years ago on some online site and someone incompetent then hired them in their startup.
At least the difference between Developer, Architect, DevOps/SRE, etc. still mostly remains clear.
Very specific and out-standing, thank you. I'm on my way learning more about abstraction and OOP principles, if you have advance and good source code that shows these principles clearly, I'd be glad if you share it with me.
I will be sharing a lot more examples of this an more in the coming few months on here. I imagine others will be joining in as well. Be sure to follow the Pluralsight page.
I know why we need to learn Software Design principles. They let you build scalable, maintainable, and reusable piece of code. There by generating more value to organisation by reducing computing or human resources required to do a Unit of Task which would convert as a value for you.
Guilty. But lots of abstractions means faster running unit tests, right?
Cool not sure on the extra code part ; I guess it's a case by case kind of thing.
Oh, but I do care. lol
I get the point you're making though.