JIT Learning. Just in time Learning. You Don't need read a book from cover to cover. YAGNI. Many technical books talk about topics that you might never need in your career. Focus on what you need to know after making a plan for what you want to achieve.

YAGNI applies to coding as well. Don't create a class or a method just because you Might need it later. Create them only when necessary. This keeps your code cleaner and there is less to test.

No one fucking knows how to handle/raise errors.

I feel like this is the least talked topic in all fucking programming industry. This shit needs to be tought even more than the fucking SOLID, DRY, KISS, YAGNI and other kinds of buzzwords that fancy devs love tossing left and right.

Basically everyone just does "whatever you dumb error just dont bother me". They will just log/return null/ignore the errors and be in their oblivion with bugs propagating upstream the call stack.

"Throwing errors you say? Ew, why do you want to produce more errors?". Yeah, right, just stick another log/return null/or ignore the fact that the monke calling your function with bullshit arguments.

"But bro it's so difficult and time consuming and it would never happen!" Yes, you fucker! Yes! Programming IS fucking difficult if you want reliable systems! Did you not know that!? Well now you do! Go and fucking learn it!

FUCK!11!1!!

Learn enough docker to convince my coworker that it is not the solution to EVERY problem, especially not to our problem

Always respect de YAGNI principle (You Aren't Gonna Need It). Maybe the hardest thing to follow, as beginner and after.

There's little irritations that happen when working with clients over time that let you know that they're stuck in the past and definitely not the kind of client you want to have long term.

My personal favorite example:

"Can we put an icon that shows the weather on the banner of the website?"

Note: I don't make "websites," information portals, content pieces, etc.

It doesn't to matter what type of application it is; time tracking, HR, mortgage application, industrial control system, etc. I don't know why, but every single client I've ever had where I've been saddled with one or more people who have no business being anywhere near the term "stakeholder" asked for this stupid, banal, 1995 web portal fuckery. Their shitty little mushroom stamp contribution wasting everyone's time.

What's worse, they want it be prominent in the screen real estate. It can't just be a responsibly sized waste of space like the screenshot's top example (from a company whose entire business is weather, nonetheless). No, it has to be the busiest fucking thing in the control space, as in the example inferior.

Or maybe I'm just wrong and people desperately want to know if the sky is going to piss on them if they leave the cave.

Anyone else have a pet peeve in regards to recurrent, pointless functionality?

Damn this week topic is hard.

I am gonna go with managing a team. I have to use the DRY SOLID YAGNI KISS on daily basis at non-dev tasks too.

Overengineering

I really wish that I adopted TDD earlier

Trying to talk about development principles in a place with shitty code and suddenly realise half the group is laughing. When asked why they replied those abbreviations are so funny (DRY, YAGNI, KiSS). And one of them is supposedly a senior Dev. fml

Well fuck. I am experiencing over-engineering first hand.

I am the single dev responsible for developing a small feature but which is an identity to our whole product(feel free to guess it here). This is quite simple I thought, I can just modify the constants which are being used in the source code and I can finish it off in a week tops. I asked all the relevant teams over which this feature would have dependencies and they gave me a green signal. Setup Jenkins configuration and everything for this new feature. With a wide grin on my face, I sent out a pull request. Now the architect of our product declined the pr saying to change everything from the bottom up giving the reason that it would be configurable sometime later in the future. Now mind you, I get it if this feature could change over time and needs customability. But it has been the same since last seven years and would probably not change again for a couple of years ahead [you have to take my word for it.]. Its not that the guy is a douche or anything, he is one of the best dev I have ever personally came across and I highly respect and admire him. But there has to be a trade off between the effort you are putting in versus the benefit you get. Now I have to touch almost every file, super carefully look in the whole product if a bug creeps out from anywhere and change the existing code to a point where it doesn't even make sense to me anymore, and write tests ofcourse.

wubba lubba dub dub!

I go to add a method call in a business logic class that's used exclusively in a particular service, and get blocked in the PR by some other guy-

Other Guy: refactor this into the shared framework referenced by all our microservices

Me: it is only and would only be used in this service

OG: what about the other business logic class in this service?

Me: it's not used there, and if it does end up used there then we can refactor it into a class that they both reference then

OG: I need to know when the abstraction of this function will be done. is it going to be delivered next sprint?

Me: YAGNI - better to avoid doing extra work when we don't know if we'll even need it

OG: tbh you can still abstract it with some generics and lambda magic, but im not gonna enforce that

Me: premature abstraction is the root of all evil (tongueout)

OG: not really, its the root of not having a million miles of tech debt in 2 years

I just can't win for losing with the anti-YAGNI yogi.

I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?

KISS YAGNI

I think here the CS degree/experience just gives you training basically to pass this technical interviews which has been a constant problem because 99% of the work you actually do, you ain't gonna need it. (I don't work at big tech companies but pretty sure it's the same, have to be very Senior and leading a project before you really need to think about this stuff?)

I don't have a CS degree unfortunately, completely self taught, but that experience while "impressive" to interviewers doesn't seem to matter much when do how do you implement a red black tree or quick-sort.

I may know the difference in general but I don't fucking care to remember the details as YAGNI... If rather remember the things I need every day