Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
How do you deal with massively poorly-performing and unknowledgeable teams?
For background, I've been in my current position for ~7 months now.
A new manager joined recently and he's just floored at the reality of the team.
I mean, a large portion of my interview (and his) was the existing manager explicitly warning about how much of a dumpster fire everything is.
But still, nothing prepares you for it.
We're talking things like:
- Sequential integer user ids that are passable as query string args to anonymous endpoints, thus enabling you to view the data read by that view *for any* user.
- God-like lookup tables that all manner of pieces of data are shoved into as a catch-all
- A continued focus on unnecessary stored procedures despite us being a Linq shop
- Complete lack of awareness of SOLID principles
- Actual FUD around the simplest of things like interfaces, inversion of control, dependency injection (and the list goes on).
I've been elevated into this sort of quasi-senior position (in all but title - and salary), and I find myself having to navigate a daily struggle of trying to not have an absolute shit fit every time I have to dive into the depths of some of the code.
Compounded onto that is the knowledge that most of the team are on comparable salaries (within a couple thousand) of mine, purely owing to length of service.
We're talking salaries for mid-senior level devs, for people that at market rates would command no more (if even close) than a junior rate.
The problem is that I'm aware of how bad things are, but then somehow I'm constantly surprised and confronted with ever more insane levels of shitfuckery, and... I'm getting tired.
It's been 7 months, I love the job, I'm working in the charity sector and I love the fact that the things I'm working on are directly improving people's lives, rather than lining some fintech fatcat's pockets.
I guess this was more a rant than a question, and also long time no see...
So my question is this:
- How do you deal with this?
- How do you go on without just dying inside every single day?8 -
Built my own IoC container for C#. This taught me way too much about SOLID principles and dependency injection that i could give lessons now 😂
I'm still using my own IoC in my projects... It's great 🤘11 -
http requests
literally the bread and butter of any software engineer building applications, you would ASSUME they know what they are doing...
and you're gonna write a seperate http get and post function for every type you have?
apparently stuff like this that is written by "senior" developers? you don't even have a basic understanding of software...
i'm won't do it that way, becuase i'm an adult, not a child
what i'm going to do is write a HTTP request util function that can be used for any type and HTTP verb. DRY, single responsibility, etc.
imagine making the http request itself a responsibility coupled to the type 😂😂😂😂
get a clue and come back later
i can't tell anymore if my thoughts are so outlandish compared to everyone else that no one understands them, or if i've been doing this so long that i just immediately understand what needs to be done and don't know how to explain it to anyone else anymore (or take the mental effort to)
peace out
oh P.S.: imagine thinking the SOLID principles are only applicable to OOP
stay safe out there folks, its getting more painful every day
8 -
SOLID and KISS principles are necessary when building enterprise apps. Some people don’t think about design and make things complicated when it should be simple. 😒1
-
I've played around a bit with illustrating the SOLID principles (Single Responsibility, Open/Closed, etc., you know).
You may check it out here: https://okso.app/showcase/solid
Let's see if it will be helpful or more confusing :D
14 -
Today I was told that full stack is another name for a shit developer who wont be able to develop anything good because they aren't focused on one skill.
But it was by a person who claims to like OOP but doesn't know the 4 principles, SOLID, GoF, or DDD. So I take it with salt. But he claims his entire company follows this philosophy.
I think that some developers just decide that they're hot shit and refuse to talk about any other skills they don't know about since they must not be needed if they don't know them. Code is code.9 -
I've been creating my Typescript/C# projects using SOLID principles. Whenever someone randomly joins me in my projects at work, i feel they need a lot of help. Specially since they know programming, but are not familiar with SOLID.
Like ohhh ok you created a base class for that, or ohhh that method already exists in the base class sorry i've implemented it again, or ohhhh ok you already implemented this method in that class.
The more classes i create the more complicated it becomes, sometimes for me too!
I feel I have to write a documentation for the code I write just to keep up with the different, but code changes/augments so writing a doc is really time consuming.
However if i didnt create base classes or interfaces it would be less complicated to browse through method definitions.
I am happy with the code like that though, but in some specific times it's a pain in the ass.
Comments?2 -
Why do technical interviewers expect and force you to know a made-up word such as SOLID and treat it as if it's a gospel?
Is this "SOLID" a technical standard now that should be taught in schools?
I'm not against learning and using the principles in SOLID. I just find it funny (and weird) that if I didn't watch the talk by the guy who came up with SOILD, I wouldn't be able to answer the interviewer.17 -
Good code is a lie imho.
When you see a project as code, there are 3 variables in most cases:
- time
- people / human resources
- rules
Every variable plays a certain role in how the code (project) evolves.
Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.
Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.
Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.
People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?
Too many people working on one thing is only bad when there are no rules ;)
Rules. There are two different kind of rules.
Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.
Coding itself. This is a very critical thing.
Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.
Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.
Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.
Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.
If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.
Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.
There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.
Good code is a lie - because it can only exist at a certain point of time.
A codebase should be a living thing - when certain parts rot, other parts will be affected too.
The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state -
Any other people here that find Python to be actually a harder language than Java? With Java it's much easier to keep track of your code and to track what variables refer to certain object types.
It feels like Python has much more quirks and feels therefore much more inconsistent as a language. Object oriented programming is more verbose with static methods and decorators being vague for example. This makes it harder to grasp concepts like design patterns and SOLID principles in Python imo.7 -
A lot of this might be an assumption based on not enough research on both NestJS and TypeScript, so if something here is not well put or incorrect then please feel free to provide the necessary info to correct me since I care far more about getting dat booty than I do being right on the internet :D
Sooo, a year or so ago I got a hold on the Nest JS framework. A TypeScript based stack used to build microservices for node. Sounded good enough in terms of structure, it is based on the same format that Angular uses, so if you use Angular then the module system that the application has will make sense.
I attempted (last night) to play with the framework (which I normally don't since I am not that much of a big fan of frameworks and prefer a library based approach) and found a couple of things that weird me out about their selling points, mainly, how it deals with inversion of control.
My issue: This is dependency injection for people that don't really understand the concept of dependency injection. SOLID principles seem to be thrown out of the window completely due to how coupled with one another items are. Literally, you cannot change one dependency coming from one portion to the other(i.e a service into a controller) without changing all references to it, so if you were using a service specification for a particular database, and change the database, you would have to manually edit that very same service, or define another one....AND change the hardwire of the code from the providers section all the way into the controllers that use it....this was a short example, but you get the gist. This is more of a service locator type of deal than well....actual dependency injection. Oh, and the documentation uses classes rather than interfaces WHICH is where I started noticing that the whole intention of dependency injection was weird. Then I came to realize that TypeScript interfaces are meeheed out during transpilation.
Digging into the documentation I found about custom providers that could somehowemaybekinda work through. But in the end it requires far too much and items that well, they just don't feel as natural as if I was writing this in C# or Java, or PHP (actually where I use it the most)
I still think it is a framework worth learning, but I believe that this might be a bias of mine of deriving from the norm to which I was and have been used to doing the most.3 -
Has anyone actually ever seen evidence of SOLID principles being 100% adhered to, as opposed to people just saying they're using them correctly then you look at their code and they're clearly not.
I can count more than one responsibility here...1 -
when i look at the code structure of the project i work on with my friends, i always think about how to implement the SOLID principles of bob martin for clean code
... and then i think about the clusterfuck of almost unmaintainable code that has been created over time and all the unit testing that doesn't exist at all and how much time and effort it would need to correct that code and how i realize that i don't even understand the principles and how to implement them
... and then i give up and go on coding even more mess
... and then i repeat😅😖😩3 -
So, I have a pretty decent understanding of big complete languages like Java, I build android applications following several design patterns, solid principles, building big stuff with databases and servers and libraries interconnected with gradle, tracking everything with git, using tdd and functional programming capabilities blablabla ... And I still have trouble making sense of a FREAKING STUPID SHELL SCRIPT I MEAN WHO CAME UP WITH THAT SINTAX I HATE IT SO MUCH OMG I CAN'T EVEN
But for real everytime I need to read a '.sh' I literally wanna throw my computer away and die. Am I alone? -
Be humble. Nobody knows everything.
Keep learning: read books, take Pluralsight courses, go to meetups.
Write unit tests for your code. No really! Write unit tests for your code!
Learn what the SOLID principles are.
Your job does not define who you are, you define who you are.1 -
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. -
A philosophical question about maintenance/updating.
There is no need to repeat the reasons we need to update our dependencies and our code. We know them/ especially regarding the security issues.
The real question is , "is that indicates a failure of automation"?
When i started thinking about code, and when also was a kid and saw all these sci fi universes with robots etc, the obvious thing was that you build an automation to do the job without having to work with it anymore. There is no meaning on automate something that need constant work above it.
When you have a car, you usually do not upgrade it all the time, you do some things of maintance (oil, tires) but it keeps your work on it in a logical amount.
A better example is the abacus, a calculating device which you know it works as it works.
A promise of functional programming is that because you are based on algebraic principles you do not have to worry so much about your code, you know it will doing the logical thing it supposed to do.
Unix philosophy made software that has been "updated" so little compared to all these modern apps.
Coding, because of its changeable nature is the first victim of the humans nature unsatisfying.
Modern software industry has so much of techniques and principles (solid, liquid, patterns, testing that that the air is air) and still needs so many developers to work on a project.
I know that you will blame the market needs (you cannot understand the need from the start, you have to do it agile) but i think that this is also a part of a problem .
Old devices evolved at much more slow pace. Radio was radio, and still a radio do its basic functionality the same war (the upgrades were only some memory functionalities like save your beloved frequencies and screen messages).
Although all answers are valid, i still feel, that we have failed. We have failed so much. The dream of being a programmer is to build something, bring you money or satisfaction, and you are bored so you build something completely new.13 -
Today I made a class to do one simple thing. Duplicate a database entry along with a few of its relationships. At first it didn't make sense to create one class for that but I decided to follow my SOLID gut. It ended up being almost 100 lines long with just one entry function working as a route controller. Thank God for SOLID principles...
-
Question directed to devs who know a bit about setting up middle sized architecture.
Prestory: Joined into development of a middle sized online game. Figured they created a monolith over the last 6 years up to a point where nothing works properly and nothing can be changed without wrecking the whole system. Figured a monolithic approach isn't such a great idea.
Current Situation: In a different, same scale online game development team, game itself working but team is struggling with architecture.
My job is to come up with an approach on how to set up masterserver/matchmaking/database etc. Reading through various articles about common principles (SOLID etc.), i figured that a microservice+event-/servicebus architecture may work for that kind of project.
The idea would be to have a global interface in which microservices can be hooked. So a client registers to a client handler on startup, then starts to queue for a game, the client handler throws an event on the bus to register the user to matchmaking. The matchmaker happens to listen to those events (Observer Pattern) and adds him to matchmaking, when a match is found it throws an event on the bus to connect the user to the server, etc. One can easily imagine a banhandler throwing in a veto to cancel such an action, metrics and logging is fairly simple to add (just another service listening to all events), additionally Continuous Delivery, FRP and such are also beneficial advantages and it is said to scale well.
The question is, would you do the same, is there maybe something i might be overlooking? Do you have better ideas?
Keep in mind that we are not too experienced and are bound to different languages (python, C++ and java mostly) and are a small (4 Devs) Team with different strengths.
Thank you for your feedback and criticism!1 -
Anyone that recommends a book that is not boring to read, has figures/code examples and easy to understand for design principles such as SOLID?1
Top Tags
Weekly Rant
View