It's okay to slow down, but don't stop moving.
4,272 karma · joined March 8, 2012
I despise Apple fanboys and Microsoft shills, but I'm getting better (mostly by laughing at the former and ignoring the latter).
I used to be what I considered a master of C++; nowadays I'm an unabashed Lisp elitist, but mainly I putter along working on personal projects. Not currently looking for work, but if your project is interesting enough . . .
Still of the opinion that Emacs is the last editor on the last OS (Debian GNU/Linux).
It's okay to slow down, but don't stop moving.
I'm not really a brave guy, I fear change, but you got to take your chances while you're still alive.
"Jack of all trades, master of some." That's been my goal for most of my life.
I could see a lot of people who are complaining here about TFA whinging 70 years ago when their secretary might push back on being sexually harassed.
Yeah, the document could have been written a bit better, but having open and honest communication about how to put people at ease and ensure they will be at optimal performance levels just seems like a good idea.
This was a problem I also bumped up against quite often as someone who has been doing "DevOps" things since before that term was coined, but the government very much wants to pigeonhole people and couldn't wrap it's head around someone with IT experience who was also a software engineer. Even with certs that I basically earned blindfolded, they wouldn't grant me a sysadmin letter, and I didn't want to re-code to IT/IM because I saw how burned out sysadmins got. The turnover in government IT was insane.
If I really wanted, I could go be a government contractor, but I've seen they still want even contractors on-site, and it's completely unnecessary. For now, I'm just "re-tooling" to tech stacks that have piqued my interest, exploring my options (eg, my brother the designer wants to build games with me).
Honestly, I'm not the first, and from people I've kept in touch with, I'm far from the last. Government agencies need a serious kick in the pants if they want to keep good talent. It's not so much about the money, that's always going to be below market rate due to the tradeoff in stability and benefits (and even benefits are dwindling), it's more about recognizing that WFH is a right, not a privilege, and being flexible in hours and horizontal job duty changes. I've watched many a better engineer than myself leave for greener pastures (Micron, Blue Origin, etc), and middle management is still in denial because they've been in the same role for 30+ years and think "nothing has changed", or if they do adopt business practices, it's always the worst ones (open floor plans, etc). FFS, I couldn't get the last project I worked on to enable CI on their GitLab instance.
This was a very large factor in why I quit - old job wouldn't let me cut back hours, even at reduced pay, even framing it as "leave without pay", so I had no choice but to quit to get my time back, and I had enough money.
As it is, I'm content staying in that "learning and broadening" mode, even though I'm 20-ish years in on my career.
I don't think I'll go back, unless I absolutely have to, or a project catches my interest, but even then, no amount of money is going to convince me to work so many hours or ever in an office again (another reason I quit was they wanted us back in the office, despite my being much more effective working from home).
I'm not. Not sure where you got that idea.
/me over here reverse proxying to Hunchentoot with CL framework of the week. Have yet to see a serverless setup that even has any idea what CL is . . .
You aren't. I'm one who actually moved from a more managed product to a VPS precisely because I couldn't get what I needed from the managed solution.
It's great we have options, but it's absolutely a false dichotomy that the author is presenting. You can have SaaS solutions for things that fit well, while having VPSs to research and develop things that don't fit into a neat little package (yet).
That might help, I should probably do that. I started with "Cyberiad", then got into Lem's other works just sort of at random. It doesn't really feel like the Tichy series is grouped together in the way say the Heechee saga or a lot of other "serial" or "extended universe" works are.
"The Futurological Congress" is good, but not great; "The Congress" with Robin Wright was loosely based on it and had more of an impact for me.
"His Master's Voice" I read while still in civil service, and it hit pretty close to home, albeit it also reminded me of the bad parts of academia. I need to read that one again sometime.
Honestly, the line "had me question everything, including my self-worth, my identity, and purpose" resonated with me so deeply, not just the first time I was laid off, but even now 20 years later and having left by choice.
On the flipside, to get CYA-managery, but any time someone in management says anything approaching "you should quit" that can be a bit worrisome. They might be doing you a favor, but the org is more than likely to be hurt by you leaving.
If that's not a glaring neon sign telling you to quit, and quit now, I don't know what is.
I'm thoroughly of the jaded opinion that when it's not a power play (no one's lizard brain wants to admit there's someone smarter than them), it can actually be a sort-of-rational decision: don't be beholden to someone hard to replace. Hence why you see tons of PHP jobs, but few in languages like the Lisps or Haskell.
I found a flat-bottomed induction compatible wok on Amazon when I got my induction cook top. I'm not a master stir fry cook, but it woks for me!
My first thought exactly, and one I've easily debunked for at least myself.
Anecdata point of one, YMMV, but I definitely have learned more by myself than I ever have from a teacher or mentor. I can go at my own pace, stop to look things up, try things out, and never have to feel pressure due to falling behind or waiting for others.
Even in the case of the paper's specific area of learning (visual and spatial), I can watch a video, slow that video down, skip around, etc, much more effectively. And for many things, there are usually plenty of them - that's actually how I learned to tie a bowtie, after failing to learn from a friend who tried to show me.
Which is precisely what every single "plan" from the article does.
Thank you, this is the term I was looking for, and indeed, pretty much all of the "plans" the author lays out are "just so stories", untestable and with the implication that they are the true reasons things are as they are.
I am fully convinced there are vast swaths of legal "adults" who are not fully emotionally developed. On my really bad days, I'm one of them. The one thing that saves me is I tend to snap out of it eventually and think of the long term. I think that many "adults" never do.
Events in recent years have only reinforced this point of view.
For one thing, there is a lot of begging the question going on in most of these "plans that shall not be named", with a side order of heavy cultural colorings the author does not even appear to realize they operate under.
Edit: After having read the link, yes, McIlroy has a point. For quick prototyping, a one off, above all else small project, the UNIX way fits, and fits well. It's a philosophy I agree with and use on a very regular basis as a sysadmin.
But as a developer on larger projects, where chunking them into pipeable tools would probably result in 1000 pipes, any one of which might break, and you want to hand it off to people who don't even know what a pipe is, well, I'm sorry, but I'm going to make something in the tools that they understand and use, and I'll make it more fault-tolerant to boot. And yes, I've run into exactly this sort of situation multiple times in my career.
I might prototype with pipes and commands, but Larry Wall invented Perl for a damn good reason.
Really, TL;DR is that Bentley picked an over simple problem (count words in a file), asked Knuth to write a program in the literate programming style, and McIlroy completely missed the point of the exercise. What a shame, he might have had something useful or insightful to say had he understood what Bentley and Knuth were trying to achieve.
I can't remember where I read it, but the wisdom I heard for writing is that until you've written a million words, your writing won't be worth reading. This feels to me like the 10,000 hour rule.
Code has the added problem that the reader must have additional fluency in it on top of human language, plus a whole bunch of idioms that may or may not be in vogue, or mayhap haven't been seen outside the organization they originated from (think silos; copyrights, secrecy and only getting binaries really don't help here). In some respects, we have code written by Chaucers, but is only from 50 years ago.
I do agree with you that Pareto principle definitely applies, but wherever possible I try to make my code as understandable as possible, with comments and ancillary documentation showing the "why". What I really wonder, is where are the world-class codebases we can point to as exemplars of what readable code looks like? Who can we cite as masters of the craft that make code others understand easily? Is Knuth one of them?
Ah, the Joey Hess DE: https://usesthis.com/interviews/joey.hess/
> (Of course you could optionally split it up differently to see multiple files.)
Now I want to go write some elisp . . .
But for the moment, I'll let you know that C-x 3 will keep splitting an emacs "frame" (window) in half vertically until you hit something like 10 columns. Just need to write the elisp for the rest of your feature request.
I very much agree with this - alt-tabbing between browser, terminal and fullscreened Emacs are what I've been doing for years. But very recently I decided to make two significant changes:
1. Adding a second monitor for documentation or visualizing output. When I'm going through longer written works (tutorials on languages, toolkits, etc), it's rotated to portrait mode and I find it more conducive to typing and testing things on the first monitor (with Emacs still fullscreen, but C-x 2 for splitting it in half). Recently I've been playing with OpenSCAD and I've liked having the second monitor in landscape mode; then I edit files in Emacs, and OpenSCAD updates the render as soon as I save the file. Transcribing music from scans displayed on a portrait monitor into MuseScore in fullscreen on a landscape monitor is a third "topic" I find two monitors handy for. Lastly is IT/sysadmin where I have a 160x60 terminal with a tab per server on the landscape monitor, and dashboards or documentation on the second monitor rotated to landscape mode. Control PgUp and PgDown between server consoles, each running screen, where screen zero is colorized log output.
2. The second change might have a a bigger impact than the first: multiple virtual desktops, one for each "topic." For example, my virtual desktops are currently entitled "Main", "IT", "3D Modelling", "Programming", and "Music". Of course I switch between them with a keyboard shortcut. This really seems to help my focus, by putting things "out of reach" so that I can't just Alt-tab to Reddit or HN when I'm bored or stuck.
The key with any tool is to figure out how to make it work for you, not against you. Sounds like you've already made progress on this front, but I thought I'd provide my two cents.