4 ms·
Yeah the very concept is a blind and kind of dumb argument by analogy that ignores the obvious - especially in software engineering - that code isn't people. No
by Nasrudith 7y ago
Yeah the very concept is a blind and kind of dumb argument by analogy that ignores the obvious - especially in software engineering - that code isn't people. Not to mention oaths especially arbitrary ones have come and gone. The whole article is like this - clearly arguing by analogy about things he doesn't understand. The fact he views IDEs as a risk /from lack of knowledge/ just shows the sheer depths of his ignorance given its role is to make it more accessible.
At this point I have grown weary of every article proposing some sort of professionalization. At this point I want to shout to everyone writing them "Stop trying to professionalize code to your gatekeeping standards already!".
From the number of failed outsourcing attempts I suspect unsatisfactory performance is true though for reasons not on them - organizational, communication and cultural barriers rather than lesser merit. The threats there aren't even on the software engineers but the management making the decisions! The only thing they could do to "stop" that is to work for free which was unreasonable to expect from even priests and would remain utterly stupid blame shifting.
- azangru 7y ago> At this point I want to shout to everyone writing them "Stop trying to professionalize code to your gatekeeping standards already!". Are you saying that there are no agreed upon characteristics of code (apart from being able to run) that together comprise the notion of code quality?
- Nasrudith 7y agoNo, more the kind of people who think there should be a "coding license", guilds, or similar. There may be a place for certifications individually but universality is folly. I meant professionalization in the sense of trying to erect barricades. As for code quality it is depends upon the domain, scale, and situation. Some things are objectively bad but even bad may be complex. Hard tested COBOL legacy code that was old when the current veterans started may be hard to comprehend, close to immutable but utterly reliable for instance.
- a1369209993 7y agoThat's not it. There are such characteristics (I suppose you could debate the "agreed upon" part) and professionalization is actively counterproductive to them.
- JoeAltmaier 7y agoFacility at a reasonable development process, is a useful thing to measure. E.g. if I could sort resumes by who has experience with GitFlow and who doesn't, that'd be a help, not a hindrance.
- theK 7y agoCome on, GitFlow is a really bad example here. A rookie will take that up in a couple of days work if your operation works correctly :-D
- JoeAltmaier 7y agoNot so sure. There are lots of source disciplines. Learning one makes the next one not so obvious. And you can tell me with a straight face, you know right now how to revert a change from a deleted development branch that was merged through a feature branch to master, from both master and the feature branch, after two other features were merged as well with conflicts?