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
-
That's pretty much the same for me, but I never managed to leave; Everytime I try to explain them how my work there is pointless both for me and them, they come up with this promise that they have plans to change, standardize the work, learn my odd methods (talking about version control here lol), and convince me to stay. But since most of them see this job as only a career to make money, they probably see a little profit in what I offer to them and nothing really changes. They even might look at me as just an arrogant graduate that is haggling over his wage. And this happens somehow every couple of months.
-
Don't worry, there are companies out there which are better!
e.g. my team needs more people ;)
(we are based next to munich)
All our code goes through pull requests and parts of our code even have test-coverage from 100%
If you want to see some code from us, have a look here: https://github.com/plusnew/plusnew -
@JoshBent nah, they know i'm joking because they know my humor. But at the same time they won't be sure because i was given root access to the servers and i know my way around linux.
There is no backdoor, and if they find one i'd be surprised because network security was part of my job. -
@2erXre5 also i'm pretty sure they'll never read this. All of them use eclipse and it only shows the first line of the commit message.
-
I too am facing the exact same issue at my current job. Everything is great but Code quality is not.
Instead of nagging I went ahead and wrote few docs for git participation, coding style ...etc. but all to no avail, nothing was applied, I find lots of duplicates in the code, copy/paste, and bad naming. Of course unit testing is not something to discuss because "it takes time and a waste of time"
this is really depressing because most of the time is wasted on understanding how the code is written then spending huge time editing one thing in a million places ... -
@plusgut thanks for the offer, but i have to pass. Munich is too far away from where i live.
I still took a look at your code and i have 3 questions:
What you're doing seems to be very similar to react/redux, why do you develop your own thing when there is a supposedly better alternative?
Is typescript worth it? I can imagine it'll be worth it in the long run, but adding type-information to every object feels like overkill if the file is subject of future changes.
And
What editor do you do js-development with? I ended up with atom, but what's missing for me is eclipses ctrl-click-feature that lets you jump to the definition of a function and the mouseover that displays the functions docs. -
@YouAreAPIRate you are welcome, if ypur change your mind in the future,just tell me.
Yes you are right, it's very much like react with redux,it's heavily inspired by that. I took all the good partsand changed whatI think is bad.
At react you have the concept of higher-order-components,which are extremely shitty in my opinion.
If you have a router,i18n and redux to wrap your components,you will have a real mess. Especially if they have to be in the correct order to propagate your props down.
At my framework ypu just declare what dependencies you have, and that's it.
Reduxis awesome,but you have just one store and every action is going each reducer, which makes typesecurity impossible.
One more thing: my framework is fully synchronous,which makes debugging a dream, in general i took great care of dx (developer experience)
Typescript is definetly worth it, especially when it comes to refactoring it is amazingly helpful.
You change something deep in the core? You'll will know everywhere where you have to change your stuff.
I use VSCode as the IDE the typescript Integration is great. It has the ctrl-click for everything ;) -
@gitpush i fell you, <s>man</s> person of male gender. When i think about git/coding style in my company i find that nothing has changed much. We all developed on one branch and the code was a mess.
But I found that you could always suggest new frameworks on the beginning of a new project. Say things like "we always lost time <there>, but with <this> we can automate things/save time/etc." And maybe they'll listen to you. It didn't always work though. But i found old projects were doomed, nothing will change there.
When it comes to coding style there is not much you can do. On the newest project i introduced a pre-commit-hook that prettifies changed files. I thought about writing a hook that denies the commit if files get larger than 300 lines or the project has too many warnings. But that would be too restricting and i didn't do it.
There are many ways to tackle this, and i hope you find one. If not, you might consider quitting like i did. -
@YouAreAPIRate The good thing manager listens to me the bad thing no one applies what they are asked for, they seem to follow the "it is easier that way" approach, and you know what ends up using that approach.
I hope I don't reach the point where I have to consider switching jobs because of the only reason that shouldn't be there, code quality! -
@gitpush you'll find a way, there a so many possibilities of what you can do. One of them is splitting the project into core and other and refactor the core yourself so the savages can ruin their part of the project themselves.
I truly hope you don't have to quit your job over this, because in addition to code quality i quit to find work on a bigger project with a newer stack. If i were to quit based on code quality alone it would have to be so bad i don't even want to imagine it. ^^" -
@YouAreAPIRate looool exactly, I'll try splitting that project in hope I will be able to make.my self clear the next I argue with anyone 😅
Today was my last day of work, tomorrow i have officially left that place. It's a weird feeling because i'm not certain about the future.
The job was certainly not bad, and after all i read on devrant i'm beginning to believe it was one of the better ones. A nice boss, always something to eat/drink nearby, a relaxed atmosphere, a tolerance for my occasionally odd behaviour and the chance to suggest frameworks. Why i would leave that place, you ask? Because of the thing not on the list, the code, that is the thing i work with all the time.
Most of the time i only had to make things work, testing/refactoring/etc. was cut because we had other things to do. You could argue that we had more time if we did refactor, and i suggested that, but the decision to do so was delayed because we didn't have enough time.
The first project i had to work on had around 100 files with nearly the same code, everything copy-pasted and changed slightly. Half of the files used format a and the other half used the newer format b. B used a function that concatenated strings to produce html. I made some suggestions on how to change this, but they got denied because they would take up too much time. Aat that point i started to understand the position my boss was in and how i had to word things in order to get my point across. This project never got changed and holds hundreds of sql- and xss-injection-vulnerabilities and misses access control up to today. But at least the new project is better, it's tomcat and hibernate on the backend and react in the frontend, communicating via rest. It took a few years to get there, but we made it.
To get back to code quality, it's not there. Some projects had 1000 LOC files that were only touched to add features, we wrote horrible hacks to work with the reactabular-module and duplicate code everywhere. I already ranted about my boss' use of ctrl-c&v and i think it is the biggest threat to code quality. That and the juniors who worked on a real project for the first time. And the fact that i was the only one who really knew git. At some point i had enough of working on those projects and quit.
I don't have much experience, but i'm certain my next job has a better workflow and i hope i don't have to fix that much bugs anymore.
In the end my experience was mostly positive though. I had nice coworkers, was often free to do things my way, got really into linux, all in all a good workplace if there wasn't work.
Now they dont have their js-expert anymore, with that i'm excited to see how the new project evolves. It's still a weird thing to know you won't go back to a place you've been for several years. But i still have my backdoor, but maybe not. :P
rant