3 ms·
Honestly, I agree with you. I don't mean to discourage anyone trying to learn software engineering but: IMO its something that takes years to learn the fundamen
by Uptrenda 7y ago
Honestly, I agree with you. I don't mean to discourage anyone trying to learn software engineering but: IMO its something that takes years to learn the fundamentals. There are so many small details that aren't what you expect them to be that I see no way bootcamps could prepare you.
Things like how file systems work, what system calls do -- how write() works -- does it write data or not? How do blocking / non-blocking calls differ? What concurrency models are there in programming? How does parallel execution really work? How do you (properly) handle I/O, networking, and other events? How do you evaluate and compare the efficiency of algorithms? What kinds of security threats lie in different types of code? Practically, how do you prevent them? How do databases work? How do you design applications to avoid corruption? What are the different isolation levels in a database? What parts of the database are 'locked' for a given query, what 'order' are transactions executed in? How does the OS allows multiple programs to run?
Cryptography. Sessions, encryption, hashing, salting, peppers, verifiable delay functions, public keys, symmetric vs asymmetric crypto. Signatures. Mutual authentication. Message integrity. I guarantee you most developers have screwed up their handling of I/O, security, db use, or concurrent code at at least once in their career. These are deep concepts that can be "learned" in 10 minutes from a tutorial, but have tons of weird, undefined behavior that only shows up if you don't completely understand what you're doing.
IMO, what seems to have changed recently is there's now more ways to shoot yourself in the foot. I.e- more open source libraries that are usable right off the bat as black-box-plugabble, square-peg-in-circular-hole type deals. Kind of like how people trick themselves into feeling like experts from reading wikipedia -- a little knowledge can be just as dangerous as no knowledge at all.
- ip26 7y agoConsider however that not all software jobs require all that knowledge. As software spreads, not all new software jobs are rockstar positions. A lab full of scientists, for example, might benefit a lot just from a couple people who know how to operate a database and do some basic data crunching. Or, consider the vast number of people who get their job done in Excel today, who don't need to call write() but could do their job better & faster if they switched to Python. If the future is software, then there will be places for PhDs & bachelors, but also for associates and even bootcamps/certs. Even people who are not deeply passionate about software can make a useful contribution. Putting men on the moon took a lot more than just rocket scientists.
- johnwyles 7y agoYou should note that a bulk of your list is the knowledge that a senior engineer should require of his peers. To be productive writing a small feature in a React app it could be had under a week out from bootcamp with modest support sharing whatever tribal knowledge and documentation for onboarding.
- learc83 7y ago>To be productive writing a small feature in a React app it could be had under a week out from bootcamp with modest support sharing whatever tribal knowledge and documentation for onboarding. That's not my experience at all. I've on-boarded many bootcamp graduates and I've never seen one that was doing anything that I would call "productive" a week out of bootcamp. I could see that maybe if they had a good bit of experience before bootcamp.