I have almost nothing to say that I could summarize in the time I have for this. I am stunned anyone could actually (seemingly) seriously express these thoughts.
"Why test my own code, when there's an entire department of other people to test it?" - Are you that selfish that you don't care about what garbage you produce to other people, and you're happy to just make it "their problem" as soon as possible? Are you that ashamed of your work that you literally don't care? I just cannot comprehend this. I take pride in the fact that when I finish a task I can say with a reasonable level of confidence "it works as intended", without having to shove the responsibility of figuring out if it does to someone else.
"Takes lot of time to name things" - Do you really not comprehend WHY this is done? Because when you use int d = 10; that might make sense to you right there and then, but it won't make sense, even to YOU, in a year or two after you've not seen that code for a while. Then nobody knows what that code does, or why it does what it does, and most importantly what it's intended to do. Seriously now? Of course you don't have to go to ridiculous lengths as you do with your particularly poor example numberOfDaysInTrailPeriod [sic], just use trialDays or similar and it's MUCH clearer than d.
int d = 10;
"Needs unnecessary separation between modules" - What magic book of rules has told you to unnecessarily separate modules? Move code into modules when it makes sense, i.e. when you need the same code somewhere else and want both of those uses to update at the same time. If there is no reason to avoid duplication, don't just deduplicate for the sake of deduplication.
"Not allowing to add comments" - Another mind-blowing statement from a magic book of rules you must have stashed in your shelf. Yes, add comments to places worth comments. However, if your code needs comments, you should probably think about why it's so unclear that it needs comments. There are valid answers that lead to the decision "yes, adding a comment is the right choice".
"The main purpose of unit testing is to see if our code is working as expected or not" - AND much more importantly than to check if what you wrote now works, it is to ensure it also works in the future, and to notice when it breaks due to an unexpected interaction with another change somewhere else possibly by someone else.
"Unit testing unnecessarily forces us to split our big good fat functions to smaller chunks." - Where exactly does it say that in the name "unit testing"? Write your big functions if you want to, just write tests for them as well. I really can't think of a single unit testing framework that enforces a maximum number of lines or your code will fail, but many organizations do enforce that kind of rules for various reasons, mainly readability.
"I don't understand what makes them think to hide implementations behind these interfaces?" - Clearly you don't. One obvious BIG reason is so the implementation can be changed without all the uses being changed. Have a search function? Great, make a clear search interface so when you upgrade from your current search solution to a better system only the code inside the search implementation has to be changed and nothing outside it, assuming you did a good job.
"Force to make intentional errors first and then solve them." - What on earth are you talking about? TDD has nothing to do with INTRODUCING an error first and then solving it, but instead e.g. when you try to solve a bug, you first write a test that reproduces that bug and then you fix it, so you can confirm that you actually fixed the bug. Some people might go to extremes with it by first writing a full set of tests for their code that they haven't written at all, but not even that is as ignorant at what you're proposing, that TDD is "a nightmare". The point of it is to have good unit test coverage so you notice when something breaks and you have good ways to check if you have actually fixed the issue later on.
"So just chill and write a code that just works!" - What an incredibly ignorant statement to make after you've proposed you write code without any tests, and is an unreadable and unmaintainable mess. Good luck with your "just works" when you shove the garbage you produced to your QA department.
In short this post seems like a disastrous tantrum -post by an ignorant non-professional. Take pride in your work, strive to make great code that is maintainable and understandable to other people as well and long after you leave the company. Take everything this post says as something to avoid. The person who wrote this should not be working as a programmer.
Calm down. It's pretty clearly satire.
As an avid satirist, I have to disagree. None of the classic signals of satire are present, and I suspect that you and I have both met people who could write something like this in complete seriousness.
Admittedly, the response is pretty harsh. The article indicates a lack of experience rather than total lack of aptitude for software development.
Nah, assuming lack of satire I don't think it was harsh at all.
It sounds like the person HAS some experience, and that experience has taught him about TDD, Unit Testing, naming, etc. and they decided against all those things as simply slowing them down from doing their thing.
A person following these guidelines would generate more work for others than they would solve with their own work, i.e. they would generate negative effort towards solving problems. Simply having them not be around would make any company do better.
This would highlight a problem with personality rather than lack of experience.
I tried my best to put it in sarcastic manner, but may be I fall short to reach clear sarcasm
Glad I read this comment... This article is upsetting
You really should place a "This is supposed to be sarcasm people" disclaimer in the article, because it's blowing up all over and it's going to damage your reputation as a developer at this rate.
Fair enough. I thought from the title that it must be satire, but the way it is written makes it sound like you are 100% serious.
Thanks for the clarification.
Keep your day job.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.