At risk of sounding elitist and “gate-keeping” - this is what happens when you open the gates to millions of people with no technical talent whatsoever, and promise them riches if they just complete a simple 6-week bootcamp course on React and slap a “Software Engineer I” sticker on their LinkedIn. Of course React is used everywhere, it’s all a lot of people know.
And once these people are in, they tend to moan about the state of things, about how everyone is “gatekeeping knowledge” and intentionally making software difficult to work on. No, you just lack the skills to work in this field. It would be like a pre-med trainee walking into a hospital and insisting everything is too complicated. That it all needs to match their limited understanding of how medicine works.
I’m speaking as someone without a computer science degree, but with a master’s in a different field of engineering. Software is VERY difficult, among the most difficult fields to work in, cognitively speaking. I have spent YEARS of my free time learning everything that a B.S. in computer science would provide, and still feel like I have a superficial understanding of a lot of CS topics.
If someone lacks the chops to make it, then we should either train them up or encourage them to pursue something else. Not offer them “get-rich-quick” schemes and destroy the technical rigor of the field in the process.
From Michael C. Kohn's Practical Numerical Methods: Algorithms and Programs (1987):
---
Fortran and Pascal programs for selected methods are included for the reader's convenience. Although computer scientists have attacked Fortran because it does not force the programmer to write clear, structured code, no other language provides so many easily used tools for mathematical programming. Many of the newer languages suffer from an impoverished mathematical library and primitive input/output functions. Structured program control can be easily achieved in Fortran; all that is required is discipline.
If this is supposed to be insightful, then I missed the point you’re trying to make. Is the advent of “autocoding” e.g. FORTRAN supposed to be comparable to the scenario I described?
Mm, just sympathetic to your comment. The author tried to rebut objections to Fortran with "programmers need to be more disciplined." It sounded similar to your experience with poorly-written Javascript.
I'm not sure which other language Mr. Kohn referred to, though. Supposing it's COBOL, for example, that language has explicit sections for file data, variables, and such. Since Fortran lacked a "compilable organization scheme," he may have thought readers would object to a language where "one opened Notepad and vomited up funcs" (in a manner of speaking).
We sort of see the same in Javascript (or really many other languages): without tooling, or external guardrails--or even experience--there is not much in the way between the programmer and the program.
And we would agree that missing friction is sort of par for the course for dynamic languages. There is a tradeoff between (compiled) static typing versus typoing one's variable names. And--in the context of hacking, in terms of prototyping curiosity--advantages abound in having languages that fill this niche.
Okay, so now we circle back to the engineering bit. Employers appear to see value delivered in these bootcamp graduates. They may not see the travails of code review, the gnashing of teeth, and the general discontent on the part of folks who see programming as methodical, a sort of craftspersonship, to output something of rigor, performant, well-documented, and easy to extend & maintain.
Those principles may not be easily burdened in six weeks. Much of it is intangible, maybe self-actualized, with little mentorship to speak of. They are busy learning loops, lists, and--in the name of commercial expedience--assured that most issues are only a package or plugin away.
But surely not everyone is complaining of gatekeeping? For some, software has opened an immense portal to a lifetime of hitting walls and surmounting them. They can take their grit and perseverance, cast questions into the ether, and cobble working pieces.
Then that just leaves the complaints for complexity. Better tooling helps. Automated checks help. Business-enforced policies for code quality, security, and CI/CD help.
Even with all that, shenanigans abound. That part is more of a social issue, and something no amount of engineering is going to solve.
4 comments
[ 5.3 ms ] story [ 21.9 ms ] threadAnd once these people are in, they tend to moan about the state of things, about how everyone is “gatekeeping knowledge” and intentionally making software difficult to work on. No, you just lack the skills to work in this field. It would be like a pre-med trainee walking into a hospital and insisting everything is too complicated. That it all needs to match their limited understanding of how medicine works.
I’m speaking as someone without a computer science degree, but with a master’s in a different field of engineering. Software is VERY difficult, among the most difficult fields to work in, cognitively speaking. I have spent YEARS of my free time learning everything that a B.S. in computer science would provide, and still feel like I have a superficial understanding of a lot of CS topics.
If someone lacks the chops to make it, then we should either train them up or encourage them to pursue something else. Not offer them “get-rich-quick” schemes and destroy the technical rigor of the field in the process.
/rant
---
Fortran and Pascal programs for selected methods are included for the reader's convenience. Although computer scientists have attacked Fortran because it does not force the programmer to write clear, structured code, no other language provides so many easily used tools for mathematical programming. Many of the newer languages suffer from an impoverished mathematical library and primitive input/output functions. Structured program control can be easily achieved in Fortran; all that is required is discipline.
I'm not sure which other language Mr. Kohn referred to, though. Supposing it's COBOL, for example, that language has explicit sections for file data, variables, and such. Since Fortran lacked a "compilable organization scheme," he may have thought readers would object to a language where "one opened Notepad and vomited up funcs" (in a manner of speaking).
We sort of see the same in Javascript (or really many other languages): without tooling, or external guardrails--or even experience--there is not much in the way between the programmer and the program.
And we would agree that missing friction is sort of par for the course for dynamic languages. There is a tradeoff between (compiled) static typing versus typoing one's variable names. And--in the context of hacking, in terms of prototyping curiosity--advantages abound in having languages that fill this niche.
Okay, so now we circle back to the engineering bit. Employers appear to see value delivered in these bootcamp graduates. They may not see the travails of code review, the gnashing of teeth, and the general discontent on the part of folks who see programming as methodical, a sort of craftspersonship, to output something of rigor, performant, well-documented, and easy to extend & maintain.
Those principles may not be easily burdened in six weeks. Much of it is intangible, maybe self-actualized, with little mentorship to speak of. They are busy learning loops, lists, and--in the name of commercial expedience--assured that most issues are only a package or plugin away.
But surely not everyone is complaining of gatekeeping? For some, software has opened an immense portal to a lifetime of hitting walls and surmounting them. They can take their grit and perseverance, cast questions into the ether, and cobble working pieces.
Then that just leaves the complaints for complexity. Better tooling helps. Automated checks help. Business-enforced policies for code quality, security, and CI/CD help.
Even with all that, shenanigans abound. That part is more of a social issue, and something no amount of engineering is going to solve.