In school I worked as an intern for a U.S. defense contractor (which I feel rather bad about now, but that's neither here nor there). Every now and then some important general or captain type would show up for a meeting and walk around and look at what all the various labs were doing. When they came to the room where all the interns sat we would all pull up hacker typer and just furiously type away while they were looking in the door.
The important person would always be very impressed and say what a good job we were doing, and our boss who was showing them around (and knew exactly what we were doing) would have to nod and sweat bullets and then would get furious with us afterwards (but it was worth it and we did it every time we knew someone was coming to do an inspection).
Only tangentially related, but on my MacBook Pro simply running
cat /dev/random
causes my terminal to hang and my speakers start emitting a loud buzzing sound until the terminal is force-quit or system is restarted.
I can understand the terminal not being able to handle the amount of data from /dev/random but for the speakers to start emitting sounds as a result of this is certainly very strange. Almost like /dev/random was being piped into /dev/audio or something. Anyone have an explanation?
This ASCII 7 (C escape "\a"), which when printed emits a bell sound. The exact sound is terminal dependent, and modern terminals won't use the PC speaker but rather play a sound using the audio hardware (which is required on Macs because they don't have a PC speaker). The bell isn't expected to be emitted often and quickly in series, so depending on the capabilities of the terminal program and the audio hardware, it may go haywire trying to play a more complex/longer sound repeatedly or overlapping (like seeming to lock up or slow down as the audio is queued). Your terminal may be configured to "flash" instead of emitting a sound when ASCII 7 is printed -- this may be implemented as rendering the entire window in reverse video for a short duration. A series of discrete bells played quickly may sound like a tone with a rising pitch. Other terminal oddities could occur if ANSI escape sequences. There are many ANSI escape sequences, for changing colors of text, moving the cursor, changing the typeface, or for querying terminal capabilities or customizing the terminal window title bar, that when printed randomly may make the terminal go haywire.
My initial thought is you're getting escape sequences or other signals to trigger the bell/chime. I've never had it crash a terminal but I've never really used a macbook. A common one I'll see in gnome terminal is the terminal printing out some info about itself (I guess there's a way to get some info back from the other side of a link) or changing the title bar.
An easy test would be to have something dump that bell character to the terminal as fast as possible and see if that does it, and also try /dev/zero to check that doesn't.
When I was in college, the local news was interviewing a comp sec professor of mine in the computer lab. The cameraman was taking B-roll footage (blinking lights from racks, cables going everywhere, that sort of thing). He asked if he could film a few of our screens to show what we were diligently working on, which is how we got hacker typer onto the nightly news.
If you press it enough times, eventually three alt keys will get through to the page and it will pop up. I think it could could prevent the menu appearing by using preventDefault() on the keydown event.
Weirder, every time I see a code snippet on some video, it's the same "struct group_info ...". It is so common that I recognise it every time. I wonder where it is coming from, that makes this snippet so popular?
One of the first computer fair I went when I was about 12 I saw a guy demonstrating a software called Sued (Deus (God) backwards). The guy would ask the computer questions about the person he was showing the software to; questions like: what is the color of the hair on the girl next to me? And the computer would answer. Amazing! Later on I figured that while you type the answer the computer would show the beginning of a generic question, character by character. Even more amazing!
Oh, for an instant, I felt I'm a real hacker like the ones you see in movies! Just randomly press any key on the keyboard, and it will generate chunks of meaningful text quickly. Long-press any key, and it starts behaving like ChatGPT when generating an answer.
Disable "Search for text when you start typing" in the settings.
This 'feature' is so infuriating, as many websites have shortcuts that become unusable from this. There is nothing wrong with CTRL + F total idiotic feature to have on by default.
Coming from the other side, an annoying number of websites use '/' to focus their own search box, while I am used to using it to activate quick-search, which it's bound to by default. It's like the ctrl-f search, but disappears when it loses focus.
This is so nostalgic. Many of the engineers at a company I worked for over a decade ago used this one day when our little startup was visited by some Important People. We were so 1337. Haha! Good times. Good Friday post. Thanks.
Reminds me of certain (music) keyboards where you can select some built-in songs and then just press random keys and it will play the song correctly, but in the tempo of your keypresses. Who needs piano lessons?
Pure genius. Finally, an opportunity to parley my effusive laziness into a promising career as a “coder!”
BTW I hate that term with a passion.
As someone who has crafted software for the last 45 years, it’s like implying that learning the alphabet makes you a Tom Robbins.
Writing software is about understanding the problem and the information involved in such a way that you can craft algorithms and data structures to efficiently and reliably solve those problems. Putting that into code is the smallest, least important part of that skill.
That’s why software engineering is mostly language agnostic. Sure, there are paradigms that fundamentally change the way that the problem space is handled, but at least within a paradigm, languages are pretty much interchangeable. Some just have less hidden footguns.
Interface design is another thing altogether,
And is either fruitless drudgery or fine art, depending on your predisposition.
There is definitely room for a subclass of brilliant interface designers that do not need deep data manipulation intuition …. But they do need to have a deep understanding of human nature, aesthetic principles, color theory, some understanding of eye mechanics and functional / perception limitations, accessibility/disability engineering, and a good dose of intuition and imagination.
In short, nothing about producing quality software is something that you gain by writing code snippets to solve simple problems. But you do have to learn the alphabet to write, and “coding” it is still a prerequisite to learning to write software. It just shouldn’t be sold to people as if it was some kind of degree lol.
Give me some kid who’s been building things with Arduino in her basement for a few years over a coding bootcamp graduate any day. I can teach her how to write good code. I’ll just pull out more of my non-existent hair trying to reach the “coder” to actually solve problems, unless I get lucky.
The fact that someone entered software engineering through either building things with Arduino or through a coding boot-camp does not indicate what is their potential when it comes to software engineering.
I've seen people who are really great at combining "recipes" off the web for anything (including hobby electronics and programming), but never really get to the bottom of things or develop clear understanding of how things work and tie together.
I imagine you'd only get more out of that kid toying with Arduino because of persistence ("few years"), and not because of the type of things they did, but I ultimately believe you'll have similar chances of developing a great software engineer out of any of them in general.
You’re right on about the time part, that was definitely a big part of what I meant.
You can start anywhere, and coding boot camps are useful, just as following YouTube tutorials. But until you learn to identify, quantify, and characterise the problem and data space you aren’t really doing the job of software engineering.
My experience is that many people are deceived into thinking that language fluency is the core skill of software engineering, and coding bootcamps tend to foster that misrepresentation.
That doesn’t make them bad. It just means that often, thrashing around with no real knowledge of the tools and solving a problem with the tiny set of syntax you can get to work is much, much more educational towards the goal of becoming a software engineer than getting a good grasp of the language as it pertains to solving toy problems that require little effort to characterise.
Anyone that is willing to hack around a problem long enough that the solution emerges is doing the real job.
It doesn’t matter where they start, or how much they “know” about “coding”. The real task is to fully characterise the problem and data structures, and sometimes that emerges from the horrific beast that rises from the tangled mess of a hacking session, a malformed but complete caricature of the actual solution.
Then, all you have left to do is to code the actual solution, the structure of the algorithm and data has been laid bare for you to see by your efforts.
That, I believe, is the essence of software engineering.
No disagreement there, but one other thing I'd throw in for learning coding is that it increases confidence for someone embarking on this journey, and sometimes that's all the motivation they need to dive deep and persist.
I've obviously seen people who misjudge this (they can code, hire them), but ultimately, developing someone requires an amenable minds of both a mentor and a mentee on top of talent and persistence.
The important person would always be very impressed and say what a good job we were doing, and our boss who was showing them around (and knew exactly what we were doing) would have to nod and sweat bullets and then would get furious with us afterwards (but it was worth it and we did it every time we knew someone was coming to do an inspection).
reply