Ranter
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
Comments
-
hexc11266yNo. Literally never read any programming books, learned off other various places. Not saying books are bad, just saying they aren't necessary for everyone. I've done full stack dev, real time 3d rendering, etc, and everything I've learned has been from YouTube, School, and forms / code review sites.
-
donuts238486y@hexc I'm self taught too but the code I see at work takes me days/weeks to figure out what the fuck it's doing because it is so bad that it looks like a script kiddy/ADD monkey wrote it.
We also have a lot of productions issues.... Caused by bad code logic that needs to be hot fixed (with duct tape code). -
donuts238486y@hexc and you seem self taught which is a bit different. You learned things the hard way and had to clean up your shit so you don't do it again... Not by just reading Teach Yourself ... in 24 Hours.
I have to clean up monkey shit bc they don't know how to but it's already in Prod. -
hexc11266y@billgates I get where you're coming from in that regard, I've had to do plenty of cleanup/patch/redo other peoples broken code. Not fun, and in many cases would have been just as fast if not faster to do it yourself..🤔
-
sceiler726yOh I have read the Phoenix project. Nice book, would recommend. And thanks for the other book recommendations.
I still respectfully disagree. -
donuts238486y@AlpineLinnix @zacg @PrivateGER @sceiler I guess I can now see why I will never be able to get coworkers to read these books... And we'll keep hiring monkeys since I'm not the boss...
So how do I get them to stop writing shit code that I have to cleanup after it blows up? -
@billgates By introducing code reviews in the development process, and rejecting bad code. Some kinds of coding standards should also be there. Maybe there is tooling for your production language? For C, that could be CppCheck, PC-Lint, SourceMonitor.
-
donuts238486y@Fast-Nop but I'm not the boss and I can't call the shots. You see the problem?
And yes code reviews is one of the things mentioned but the thing I see is they need to level up from script kiddies. If I did a code review, it's going be like "this is shit, do it over again... This is how you should do it" and I basically write it all over again and do their work... Which is basically what I do when it blows up in prod....
And the whole point of the interview is to make sure you don't hire script kiddies as senior devs... -
donuts238486y@PrivateGER we do... The monkeys find other monkeys to approve or my boss approved because "all the tests passed and we need to meet deadlines"
QA == Prod Support who just gives it back to us because they have no idea what to do when something blows up in prod... -
@billgates I see, so you would need to convince the bosses that there is business benefit. Production is supposed to make money, and if it doesn't, it bleeds money.
Also, you could ask for a raise because you are doing their work - and if you can fix someone else's shitty code under time pressure, then you are a dev that other companies would also like to employ.
For Interviews, you might consider using SourceMonitor on a bad code base and having the candidate comment on the extracted stats. If they have nothing to say on functions with 4000 lines and 10 indentation levels, it's a red flag. -
donuts238486y@Fast-Nop well they have read the Phoenix Project when I recommended it and that book pretty much makes the business and managerial case for this stuff.
Perhaps things are changing but change is slow... and I get stuck with the cleaning.
I'm technically the highest paid person on the team. And my personal health reasons make it hard to interview. I also don't care much for technical interview questions...
So I'm sorta stuck here.
So I had a discussion now with my mom about my work and it turned into a rant. But I came to this conclusion:
My most effective way to screen candidates for a backend/fullstack tech job would be to ask them what are the most influential programming books they have read and why.
If they don't mention any books (or points covered in these books) in this list, they immediately fail:
-the effective engineer
-clean coder
-code complete
-team geek
-the Phoenix project
rant