4 ms·

>80 percent of software developers are amateurs and 20 percent professionals. Why do I say this? >Amateur software developers dislike - Standards - Unit test

>80 percent of software developers are amateurs and 20 percent professionals. Why do I say this? >Amateur software developers dislike - Standards - Unit testing - Design patterns/SOLID principles - Learning and setting DevOps and ALM (They like using it) - Fixing the build - Code reviews - Code Analysis/Solution checking What a troll statement, no way do 80% of software developers dislike those things.. maybe.. 20%?

foobarian 6y ago
Let's not even get into definitions of amateur and professional. Working with this guy? Hard pass.
alexjplant 6y ago
I've had the misfortune of working at a few places were many/most of these things were pretty universally frowned upon. > - Standards Resistance to using formatters and linters because they prevent you from merging code more quickly; "it's annoying". Two of the two-dozen devs on the product decide that they want to use NetBeans instead of Eclipse even though the formatter is built for the the latter and everybody else uses it so they can't format their code properly. > - Unit testing I recently went four years without writing a single unit test professionally. When I _did_ write unit tests I worked on one team where the only important metric was coverage percentage, not corner/edge cases or intentionally trying to break the software. People would write tests for auto-generated getters and setters in C#. That's right - they would _test the compiler_ just to satisfy a business metric. > - Design patterns/SOLID principles My tech lead at a previous job refactored a pretty substantial service I wrote with no team input to remove any semblance of organization or convention. The repositories, factories, and facades I built got merged into a giant single "helper" object just to follow some weird anti-pattern that they'd established. It wasn't testable, there was no separation of concerns, and it ended up being nigh-unreadable. > - Learning and setting DevOps and ALM (They like using it) > - Fixing the build I've been the "CI guy" at almost every software job I've had because some people are afraid of the command line and lack an understanding of the build tooling outside of the three SCM operations they know through Tortoise and the play button in their IDE. I could go on but you get my point. Software development is a vast industry and there are some pretty dark corners. For every high-performing team that has tech-savvy devs there are body shops full of people that are trained by rote to "build software". It's not pretty.

foobarian 6y ago

Let's not even get into definitions of amateur and professional. Working with this guy? Hard pass.

alexjplant 6y ago

I've had the misfortune of working at a few places were many/most of these things were pretty universally frowned upon. > - Standards Resistance to using formatters and linters because they prevent you from merging code more quickly; "it's annoying". Two of the two-dozen devs on the product decide that they want to use NetBeans instead of Eclipse even though the formatter is built for the the latter and everybody else uses it so they can't format their code properly. > - Unit testing I recently went four years without writing a single unit test professionally. When I _did_ write unit tests I worked on one team where the only important metric was coverage percentage, not corner/edge cases or intentionally trying to break the software. People would write tests for auto-generated getters and setters in C#. That's right - they would _test the compiler_ just to satisfy a business metric. > - Design patterns/SOLID principles My tech lead at a previous job refactored a pretty substantial service I wrote with no team input to remove any semblance of organization or convention. The repositories, factories, and facades I built got merged into a giant single "helper" object just to follow some weird anti-pattern that they'd established. It wasn't testable, there was no separation of concerns, and it ended up being nigh-unreadable. > - Learning and setting DevOps and ALM (They like using it) > - Fixing the build I've been the "CI guy" at almost every software job I've had because some people are afraid of the command line and lack an understanding of the build tooling outside of the three SCM operations they know through Tortoise and the play button in their IDE. I could go on but you get my point. Software development is a vast industry and there are some pretty dark corners. For every high-performing team that has tech-savvy devs there are body shops full of people that are trained by rote to "build software". It's not pretty.