5 ms·
I don't see this as such a problem. For instance, calculus, linear algebra, differential equations, numerical analysis, and so forth, are only a small part of
by geebee 9y ago
I don't see this as such a problem.
For instance, calculus, linear algebra, differential equations, numerical analysis, and so forth, are only a small part of what makes a good actuary. But they have a formal exam that you need to pass in these areas in order to be an actuary. They don't quiz new candidates with 10+ years experience on integration by parts during a job interview.
Because we lack even a basic exam in software development, we have to do data structures and algorithms over and over in interviews. I'd be more than OK with setting up a basic exam for what we can cover. I'd much rather take these exams with some assurances that it will be graded consistently and fairly, cover the proper material, and will lead to a lasting credential respected in industry. I wouldn't mind this even if it involved substantial effort and studying on my part, because I'd know what I was studying for and why.
Hey, maybe it means my next software job interview won't have to involve weeks of studying followed by 5+ hours solving tree traversal problems at a whiteboard.
- abalashov 9y agoThat's a very fair argument. I still think there'd be far too much contention over just what is to be included in the corpus of essential knowledge. Everyone seems to agree that data structures, algorithms and systems fundamentals seem appealing, but just which ones depends greatly on whether you're doing embedded PLCs for fuel injectors or whether you're doing React. I've been programming since I was 9, for most of that time in C. Yet I'd be very hard-pressed to tell you how exactly CPU instructions work, and have never touched anything "closer to the metal" than C. Should this disqualify me from the profession?
- geebee 9y agoAlmost nobody I know would say it should disqualify you from the profession, but I can see why you're nervous about this. After all, law now generally requires a $150k+ degree and three years of your life. Plenty of people, including Obama, believe that it should be at least shortened. But once entrenched, it's very tempting for gatekeepers to install expensive and lengthy credentialing procedures. So overall, I think there's a good way to do this, and I do think that software development could be a better profession with some credentialing, provided it was done sparingly and properly (a huge "if", I must admit). I'd like to see this happen along the lines of the actuarial field, with exams rather than required degrees, largely because I think people should be free to acquire the knowledge at a pace that suits them. If you want to major in math, or physics, or something else, and "read for" the exams (to quote an old law practice), you should be allowed to. If we had something like this, it might benefit our field immensely. It would be a huge improvement over the capricious, opaque, and arbitrary informal exam taking we do over and over every time we interview. But... I can't possibly pretend I don't understand your concerns. I personally was a math major and I got a MS in Industrial Engineering. I never did major in CS, I certainly didn't study "Software Engineering." I am also willing to openly question the value of test-driven development. There are plenty of people who think one or the other or both should disqualify me from the profession, and the idea of empowering them with the force of law (ie., the power to fine or imprison me for developing without the background and methodology they've decided is acceptable) is pretty chilling. That would be much worse than what we have right now.
- deleted 9y ago[deleted]
- cr0sh 9y ago> Yet I'd be very hard-pressed to tell you how exactly CPU instructions work, and have never touched anything "closer to the metal" than C. Should this disqualify me from the profession? No - it shouldn't. I feel that you should want to know this level and more about the internals (and history) of computers. I'm biased in that has been a driver for me personally... ...but to give you a hint: A CPU (in the most basic sense) is nothing more than a very fast and very complex player piano, regulated by a clock. At each "tick" of that clock a row of "holes" (bits) representing a variety of information (address, data, instruction) is presented to the CPU. These bits are actually voltage levels. The CPU uses these voltage levels to change the state of logic gates in the system (which are wired for a variety of different tasks - but you only need one particular kind of gate to make any others - a NAND or NOR), which determine what happens, what to do next, etc. I won't go further - and let me be clear that what I wrote above is nowhere near complete, and only describes the most basic level of an "ideal" CPU (or ALU or whatever) - because in the real world, you have things like voltage transients, timing issues (signals not arriving at the same times - hence things like wait states and such), noise, plus things like triggering on rising or falling edges of clock signals, multiple clocks staggered in time (for multiple triggerings per "cycle"), and a whole host of other things. Yeah - it's pretty complex. But at the heart of it, it is pretty simple - a player piano, more or less, with a music reel spinning at mind-boggling speeds. If you need or want more information, there are (like everything else) plenty of resources on the internet about how all this stuff works. Check out some of the sites on people who have built computers from relays or logic gates; they typically have a lot of good information about the lower level stuff. Also look into some of the old books on building computers, and how they work (I'm talking the practical computing books from the 1950s and 1960s - difficult to find at times, check on used books online, in stores, plus on google books and archive.org; also, old back issues of Byte Magazine from the 70s and 80s are a good resource).