The flight was uneventful, until its final minutes. It started to go wrong when a pitot tube - an instrument for measuring airspeed - froze over, c...
For further actions, you may consider blocking this person and/or reporting abuse
I've got to put a plug in here for a computer game called TIS-100. It is described as "the assembly language programming game nobody asked for." After completing puzzles like (parallel) sorting/filtering lists with (hardware) stacks in an assembly language with maybe a dozen instructions, I have to tell you I am extremely grateful for
List.filterand the like.I think the subtext here is that you want people to care enough or be curious enough to go deep in their craft. Unfortunately, not everyone is going to do that or even be in a place to understand why they should. I think that's okay -- that person can still be a benefit to the team and experience personal growth in the right position. In the wrong position, well, the opposite. As a side note: if you find a place with good management (who can recognize and respond to this situation), plant yourself there. Managers who care about their craft are hard to find too. :)
I have a couple questions:
Do you think a front-end web or mobile developer needs learn some of this more fundamental stuff?
What if that front end developer first learns how to put together a UI with some interaction, then later in their career develops an interest in figuring out how virtual memory and more advanced topics work?
I understand your argument, but I want to unwrap the possible different order of things.
Now that's an interesting point. And no, it's not as if I think people should start with logic circuits, move through flip-flops up to counters and then finally consider assembler. It's more that as people can't completely neglect the lower level stuff.
If you're a Javascript programmer, for instance, you might want to look at Phil Robert's talk on the event loop:
Loupe
It's thankfully very easy to ignore a lot of low-level stuff, these days - but it's still useful, and occasionally vital, to learn about.
I'm a newbie in the field, and I've never been taught about what I usually think of as "low level stuff", during formal education. I've watched several video and read blog posts on things like virtual memory, interrupts, how I/O is handled, etc.but because I've never had to actually apply this stuff, the details never really stick. If you have experience with online tutorials that teach the fundamentals, which includes practical exercises, I might give that a try.
Also, I enjoyed the airplane crash stories (weird to say that about a crash, I know), but I think it'd be good to include an actual dev story where knowing the fundamentals came in handy. This way, the need to know the fundamentals becomes more clear
Lastly, I think you have a typo at "Not only was nobody was injured ..."
Air crashes are more interesting than computer crashes. Most serious computer system failures are similar in nature - not one single fault, but a set of cascading faults which might well start with a minor issue but result in a disaster. (An example would be a broken RAM module in an Amazon datacentre which resulted in a hefty chunk of AWS dropping a few years ago).
As far as trying to learn these things - write a webserver. I used to write webservers in all sorts of languages, to learn things. I wrote one in TCL (not recommended), I wrote one in C using threading, then another when I realised I'd got threading all wrong. They're simple enough things to write at a basic level - you might want to restrict yourself to HTTP/0.9 - but just complicated enough to experiment with all sorts of architectures.
And well done for spotting my deliberate typo.