FUCK!!! FUCK IT ALL. FUCK YOU AND YOUR CRAPPY BULLSHT UNDOCUMENTED AND OUTDATED API.

YOUR DATABASE SERVER BACK-END HAS TO BE THE ONE MANAGING THE DISPLAY DATA FOR ITS WEB AND MOBILE CLIENTS. NOT THE OTHER WAY AROUND, DAMN IT.

I'M NOT GONNA SIT HERE ALL DAY HARD-CODING ALL YOUR SERVER'S INADEQUACY.

MAKES ME WONDER DO YOU EVER USE DESIGN PATTERNS OR APPLY DESIGN PRINCIPLES? DRY AT LEAST? DON'T FUCKING REPEAT YOURSELF, DAMN IT.

I CAN'T WAIT TO LEAVE THIS PLACE FOR GOOD.

I absolutely hate the way we are taught programming in Indian colleges.

FML #1: I'm pursuing a UG CS course, and this semester, I only had one subject of Computers, that too only 1 credit. The rest with all electronics.

FML #2: In that 1 credit course, we had to make a C++ project which had "data handling". No one cares if you build something cool or not, just that a project should have "extensive use" of data handling.

FML #3: Source code had to be >= 1000 lines. This is the only place where ADDING MORE LINES OF CODES THAN REDUCING IT is appreciated. Had to stuff my code with all kinds of comments and violating the basic principle of DRY.

So, yeah, we're fucked big time. 😥

My boss just asked me for a cheat sheet I have that lists all our app server's paths.

The paths are attached as annotations throughout some Java files.

Anyway I send him the one I have but he asks if he could have an updated one.

Now imagine if I were like most monkeys and had made this cheat sheet by hand....

2 mins easy vs an(other) hour of grunt work

Why is it that I'm the only person on the team that writes utilities to automate boring grunt work while everyone else just does it manually whenever it needed....

Isn't DRY a core principle of being a developer?

I'm the only person that builds utility apps that automate frequent tasks that people keep asking us to do....

I was assigned to maintain the website as full stack dev but the code from backend is horrible previous devs didn't use SOLID principle, DRY, KISS, or Design patterns. I had to adjust from OOP mindset to Procedural its hard to debug in this state.

When programmers try too hard to reuse everything that already exists on their code.

Why is everyone saying we should be doing DRY but we really end up defining the same shit everywhere?

Does separation of concern breach DRY principle?

I have dtos, entities, viewmodels all throughout different layers I have to define. I swear I've changed 8 files just to introduce a new field!!!

My colleague feels guilty about repeating code and defeating DRY principle

I just read Robert Martin's chapter on the Single responsibility principle in Clean Architecture.

In it he explains that stakeholders, or actors, that require their own functionality that may be similar to others should have separated code. This is because 2 actors == 2 potential reasons for change.

But this seems to run counter to DRY. Am I mistaken?

Compromise.

I think that sums up development pretty much.

Take for example coding patterns: Most of them *could* be applied on a global scale (all products)… But that doesn't mean you *should* apply them. :-)

Find a matching **compromise** that makes specific sense for the product you develop.

Small example: SOLID / DRY are good practices. But breaking these principles by for example introducing redundant code could be a very wise design decision - an example would be if you know full ahead that the redundancy is needed for further changes ahead. Going full DRY only to add the redundancy later is time spent better elsewhere.

The principle of compromise applies to other things, too.

Take for example architecture design.

Instead of trying to enforce your whole vision of a product, focus on key areas that you really think must be done.

Don't waste your breath on small stuff - cause then you probably lack the strength for focusing on the important things.

Compromise - choose what is *truly* important and make sure that gets integrated vs trying to "get your will done".

Small example: It doesn't really matter if a function is called myDingDong or myDingDongWithBells - one is longer, other shorter. Refactoring tools make renaming a function an easy task. What matters is what this function does and that it does this efficiently and precise. Instead of discussing the *name* of the function, focus on what the function *does*.

If you've read so far and think this example is dumb: Nope... I've seen PR reports where people struggled for hours with lil shit while the elephant in the room like an N+1 problem / database query or other fundamental things completely drowned in the small shit discussion noise.

We had code design, we had architecture... Same goes for people, debugging, and everything else.

Just because you don't like what weird person A does, doesn't mean it's shit.

Compromise. You don't have to like them. Just tolerate them. Listen. Then try to process their feedback unbiased. Simple as that. Don't make discussions personal - and don't isolate yourself by just working with specific persons. Cause living in such a bubble means you miss out a lot of knowledge and insight… or in short: You suck because of your own choices. :-)

Debugging... Again compromise: instead of wasting hours on debugging a problem, ASK for help. A simple: Has anyone done debugging this before or has some input for how to debug this problem efficiently?... Can sometimes work wonders. Don't start debugging without looking into alternative solutions like telemetry, metrics, known problems etc.
It could be a viable, better long term solution to add metrics to a product than to debug for hours ... Compromise. Find a fitting approach to analyze a problem instead of just starting a brute force approach.

....

Et cetera et cetera.