> At that point, the telecom carrier's representative intervened and bluntly told the set-top box representative to just shut up.
This got a laugh out of me. The whole scenario was both hilarious and surreal from start to finish. It's a wonder what people get hung up on sometimes, even if getting hung up on it makes them look bad.
Like many people in the working world, he likely knew his company's policy but did not consider it important to know the reason, only to stand by the policy.
> The installer, written in Python, often failed because of incorrect assumptions about the target environment and almost always required some manual intervention to complete successfully.
Nothing ever changes. I spent half a day just getting some SDR development stuff to work just now, long live Python code with baked in hard dependencies on particular versions of obscure libraries... In the end it worked, but what a mess.
Python is an absolute disaster when it comes to packaging runnable artifacts. I love the language for server-side stuff where I control the environment (the final deliverable is a container image) but there’s no way I’d use it for anything else.
I've worked at a place or three where development environment setup took the better part of two days. Sometimes it was due to shitty proprietary software that nobody had bothered to automate the installation and configuration of. Other times it was due to an accumulation of crufty half-abandoned OSS projects with shell script glue liberally applied to hold it all together. In virtually all cases these environments would break randomly every few months and lead to unnecessary dev downtime.
One place I worked decided that it'd be easier to build an AMI and provision quasi-ephemeral EC2 instances to developers instead of putting the time in to pare down the landfill of dev dependencies they had. This whole process was, of course, orchestrated by a custom CLI that would itself randomly break in odd ways.
> I've worked at a place or three where development environment setup took the better part of two days.
I feel like this is a real barrier to getting effective contributions from outside of existing team members. Some colleagues seem to see this as an advantage.
Well, I probably was born stupid then. This was a Gnuradio setup (super impressive piece of software by the way) for a not-very-well supported SDR running an even less well supported GRC file. I'd been putting it off because I know those tell tale little clouds on the horizon well enough by now. Anyway, it's working now. But what a nightmare.
Roughly this happened to me once. Got a horrible review after doing what I felt was a heros effort. I'll skip the details but the cherry on top was "you did all this work but it didnt build on the cloud server so we're not going to count it for anything" - the "cloud server" (of the live project) was the ctos laptop and it could only build his local stuff (you could even see the local paths in the web output). As if that wasn't enough, literally all he had to do was git pull and it would have all the new work on it.
Cto was eventually fired for trying to steal the company IP and he went on to fail upward making a security camera company infra famously insecure and got a ton of very valuable stock for it.
> With a single jump to the processor's reset entry point, I had somehow inspired someone to step back from academic competition in order to have more fun with learning.
Seems like it wasn't just the processor that reset.
These were great. It’s certainly a blessing and curse to no longer dazzle people when solving a tech puzzle as a middle-aged person. I’m hoping I’ll become impressive again if I can still do it when I’m elderly. :)
for devops I highly recommend Davide Bianchi's "tales from the machine room".
https://www.soft-land.org/cgi-bin/doc.pl?mode=setpreferredla...
> At that point, the telecom carrier's representative intervened and bluntly told the set-top box representative to just shut up.
This got a laugh out of me. The whole scenario was both hilarious and surreal from start to finish. It's a wonder what people get hung up on sometimes, even if getting hung up on it makes them look bad.
All the STB guy had to say was that there was no way to get it smooth enough on real hardware.
Instead he made himself look like an idiot.
Great article.
Like many people in the working world, he likely knew his company's policy but did not consider it important to know the reason, only to stand by the policy.
> The installer, written in Python, often failed because of incorrect assumptions about the target environment and almost always required some manual intervention to complete successfully.
Nothing ever changes. I spent half a day just getting some SDR development stuff to work just now, long live Python code with baked in hard dependencies on particular versions of obscure libraries... In the end it worked, but what a mess.
Python is an absolute disaster when it comes to packaging runnable artifacts. I love the language for server-side stuff where I control the environment (the final deliverable is a container image) but there’s no way I’d use it for anything else.
I've worked at a place or three where development environment setup took the better part of two days. Sometimes it was due to shitty proprietary software that nobody had bothered to automate the installation and configuration of. Other times it was due to an accumulation of crufty half-abandoned OSS projects with shell script glue liberally applied to hold it all together. In virtually all cases these environments would break randomly every few months and lead to unnecessary dev downtime.
One place I worked decided that it'd be easier to build an AMI and provision quasi-ephemeral EC2 instances to developers instead of putting the time in to pare down the landfill of dev dependencies they had. This whole process was, of course, orchestrated by a custom CLI that would itself randomly break in odd ways.
Fun times.
> I've worked at a place or three where development environment setup took the better part of two days.
I feel like this is a real barrier to getting effective contributions from outside of existing team members. Some colleagues seem to see this as an advantage.
I got let go once because they didn’t have setup instructions and hardcoded their own paths into scripts and things that “worked on their machine”.
The reason they gave was “Unable to perform basic environment setup”.
Some people are just born stupid.
Well, I probably was born stupid then. This was a Gnuradio setup (super impressive piece of software by the way) for a not-very-well supported SDR running an even less well supported GRC file. I'd been putting it off because I know those tell tale little clouds on the horizon well enough by now. Anyway, it's working now. But what a nightmare.
Roughly this happened to me once. Got a horrible review after doing what I felt was a heros effort. I'll skip the details but the cherry on top was "you did all this work but it didnt build on the cloud server so we're not going to count it for anything" - the "cloud server" (of the live project) was the ctos laptop and it could only build his local stuff (you could even see the local paths in the web output). As if that wasn't enough, literally all he had to do was git pull and it would have all the new work on it.
Cto was eventually fired for trying to steal the company IP and he went on to fail upward making a security camera company infra famously insecure and got a ton of very valuable stock for it.
Life is weird!
> With a single jump to the processor's reset entry point, I had somehow inspired someone to step back from academic competition in order to have more fun with learning.
Seems like it wasn't just the processor that reset.
These were great. It’s certainly a blessing and curse to no longer dazzle people when solving a tech puzzle as a middle-aged person. I’m hoping I’ll become impressive again if I can still do it when I’m elderly. :)
working in software before LLMs, you had to be there.