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
-
So let me get this straight: you have no mandatory code review, no linter, and devs are left alone on projects with no supervision?
Your working environnement have deep issues if a bad dev is allowed to harm you so much.
You should work on getting proper process in place if you are in charge, or push hard to get them if you are not. Or just leave. -
@DevotedSniper There are multiple reasons to do code reviews, preventing a bad hire to do harm is actually not remotely one of the top reasons.
It allows to keep up with other devs work, to have a cohesive code, raise architecture issues early, catch formatting/naming issues, find bugs before testing (or that can't be found by testing, sometimes).
Working in a small company, one of my top reasons to recruit our first developer (I'm the technical founder) was to be able to review each other code (BOTH ways, I want my code to be reviewed by a peer too).
If someone doesn't like code reviews, he isn't concerned by high code standards, and therefore is not someone I'd want to work with. -
Unfortunately, things like code review go straight out of the window when you start getting crazy deadlines.
A team starts getting unrealistic workload and they somehow pull that off (obviously without peer review, with poor documentation and with poor unit tests). Client gets the product.
Management is happy for the moment.
Code is utter shit. -
Sort of a similar case here. We are a very small team and don't have the bandwidth to watch every line of code.
That being said, I did perform code reviews after it was clear some of the problems had started. How ever 2 of the projects were "done" by this stage and I never had the time to go back and review them, as they were no longer a prime focus. That's where the problem is now.
Yes the formatting can be fixed easily, and we actually do have a linter, it wasn't setup for this project, again I was unaware. We have an Angular 2 typescript linter, but as I said he wrote an Angular 1 app.
Anyway, long story short, he sucks, left me with a mess, ranting about him being a dick
So we had a dev on our team who was on a performance improvement plan, wasn't going to pass it, but decided to quit before it was over saving us 2 weeks.
I was ecstatic when he left (caused us hell). I knew updating his code wouldn't be great, but he was only here 6 months
"how bad could it be" - practiseSafeHex - moron, idiot, suicidal.
A little run down would be:
- Despite the fact that we use Angular 2+, one of his apps is Angular 1 ... Nobody on the team has ever used Angular 1.
- According to his package.json he seems to require both mongoDb and Cloudant (couchDb).
- Opened up a config file (in plaintext) to find all the API keys and tokens.
- Had to rename all the projects (micro services) because they are all following a different style of camelcase and it was upsetting my soul.
- All the projects have a "src" folder for ... you know ... the source code, except sometimes we've decided to not use it for you know, reasons.
- Indentation is a mess.
- He has ... its like ... ok I don't even know wtf that is suppose to be.
- Curly braces follow a different pattern depending on the file you open. Sometimes even what function you look at.
- The only comments, are ones that are not needed. For example 30+ lines of business logic and model manipulation ... no comment. But thank god we have a comment over `Fs.readFile(...)` saying /* Read the config file */. Praise Jesus for that one, would have taken me all week to figure that out.
Managers have been asking me how long the "clean up" will take. They've been pushing me towards doing as little as possible and just starting the new features on top of this ... this "code".
The answer will be ... no ... its getting deleted, any machine its ever been on is getting burned, and any mention of it will be grounds for death.
undefined
re-work
bad dev
busy few days