4 ms·
More hardcoded credentials than ever, and sloppy coding is to blame
- commandlinefan 3y ago> sloppy coding ridiculous deadlines, unreasonable understaffing and lack of any sort of time for training whatsoever are always blamed on "sloppy coding". Don't get me wrong - there are bad programmers out there, but there are orders of magnitude more bad managers and the most probably culprit is worth looking at.
- Ancalagon 3y agoAgreed. And the more experience I get the more I realize the root of this problem is non-technical leadership surrounding themselves with yes-men. I have had so many non-technical leaders fail to understand the true technical complexities of whatever new feature they’re asking for. To many it’s just a few figma slides, how hard could that be to code up? Just absolute failure to comprehend what they’re asking.
- naikrovek 3y agoagreed. the problem is the desire to fill seats as quickly as possible above literally all other considerations. I regularly support "Lead Developers" at work who have never used the command line.
- carlmr 3y agoThis is exactly why human error is not a valid answer in the 5-why process. A good company will try to identify what makes this more likely and remove the root cause. A bad company will find someone to blame. Reading up on Deming's work and the Toyota Production System, is eye-opening if you haven't read it. The methods to improve are publicized, you only have to implement them.
- maverwa 3y agoI think it’s also worth noting what makes a „bad programmer“. It’s not just people just being stupid or deciding to be that way. It’s, as you said, bad training, lack of motivation and stuff like this. People usually do not want to do a bad job.
- michael1999 3y agoRails and others mis-trained a generation of web devs to put credentials into a big environment file. This was always a bad idea, and even worse now that things like AWS credentials can be turned into cash so quickly.
- p10_user 3y agoWhat is a more proper way to do it? And I'm assuming you aren't talking about an environment file that is part of the codebase - unless your point is that it is very easy to accidentally add the env file to the codebase - then I get your point.
- michael1999 3y agoThat's exactly what lots of early web frameworks did. One big yaml/ini file with every credential for every environment, and a single "environment" selection when launching the app. A truly huge footgun. In their defence, it wasn't as bad back then. They were created by/for small teams/sole practitioners with no separation of responsibility. Source control would be on-prem (or just local directory backups). The Java EE model with explicit separation between development and deployment as separate activities was a disliked, or not understood.