That's how the server room at my school worked. They said to get out of there if the alarm went off because the room would fill with some inert gas and you'd suffocate.
I have Claude code and some gemini capacity from a Google One subcription.
For my home projects, I generally use Claude Opus. If I'm coding I run claude CLI. If I am chatting I just use the web or the phone app.
I don't know how much it matters but I use fable for big picture planning discussion. This costs some added money, but I switch back to Opus to use quota for coding.
No swarm tools... I sometimes add a skill or an MD file to the repo to keep context through compaction.
Haven't tried OpenClaw, not really sure what the value add there. The bottleneck is me understanding what code is going in and I don't think I want a ton of code I don't understand being added while I'm afk.
I worked at MS when they were putting out win 8, so I'm maybe biased. I enjoyed the touch interface laptops but I'll fully acknowledge that in my case they were making up for a bad touchpad experience.
Yeah, at least in the pre-AI times I was writing way less code than in my startup days. but like 10 to 1000x people actually interacted with them.
OP might have been stuck in a dept that is winding down to prep for a layoff or something. I probably would have stuck around unless I found a different role. Who knows, you might just get some severance.
I had a professor who asked us to print source code for our projects for him to read. Looks like he's still at it. I'm sure he's being driven insane in these AI times.
Source code has a structure, and some parts are more important to the reader than others. Good syntax highlighting makes the important parts easier to see; bad highlighting gives all parts the same emphasis. Notionally you could use font weight to convey this in a black and white medium, but color makes this easier.
After working as a programmer for about a decade, I went back to college to try to complete my education. This was when I first encountered code printed in a textbook. And it was just black monospace font on white paper. No color, not even bold / italic etc. It was Java.
Initially, it was much harder to read, both because of the habit I've developed and because, I think, the author also didn't use a "fancy" editor to write their code, so it wasn't formatted properly, didn't observe naming conventions. Well, your typical college professor writing. My first reaction was to type the code into the editor so I can explore it easier. This, of course, also provided syntax highlighting.
Of course, it took extra time. So, eventually, for shorter snippets, I'd just suffer, skipping all the typing part. I later discovered it to be somewhat helpful exercise when using Git diff or other Git commands that displayed code snippets in terminal w/o highlighting. But then the industry caught up to it, and now I don't have to read unadulterated Git output like that.
So, my conclusion so far: highlighting helps to discern the structure, to process larger blocks of code and to navigate it more efficiently. You can get better at reading code that's not highlighted, but it's never going to be as good as reading the highlighted code. It just seems like the struggle to even get to the level where it's palatable not worth it as there are very few situations where it would come in handy.
we only had a black and white printer, I don't think they would spring for color. Also, iirc he had a script he had us run to print it, so it' not like we were printing straight from the editor.
For some harder C code (implementing `malloc` for example) my preferred debugging method was printing out the code and debugging it with a pen between classes.
I eventually realized being inside an editor gave me too much attraction to thrash with "just one more quick iteration & debug run..." and could actually end up more time consuming than being forced to reconcile my mental model with what I had already written by me double checking my assumptions.
Interestingly, some of my peers started picking up the habit for their own projects and we ended up having small "debugging" sessions by trading print-outs .
This is interesting. For a while I used to print out code and debug too - more due to resource constraints: didn't own a computer, and my high school's computers were available only for limited hours per day. I used to code my first iteration also on paper - so that in the limited computer use time, I could type in the code quickly and actually see it run. Wild times but I think it made me good at programming. My friend (who did have a computer at home, but lived far away) and I co-wrote a program called "graph generator" that could plot math functions, with me doing my share on paper and giving to him to type in :) This was in the Turbo C++ IDE and since GUI based programs were unusual (at least as a project in highschool - India, 1999) it temporarily made us popular. Well, wow, that was fun to reminisce!
Even in 2010 at Berkeley I was doing a fair amount of paper coding. Some of the professors gave paper-only tests, and we'd practice a bit since you didn't want a midterm to be the first time you had to do it.
Though I also remember sketching programs on paper as a teenager for my TI-83, since it was annoying to type everything out and then have to make a bunch of edits.
reply