> 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.
> 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.
> 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.
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. :)
> I could never register susam.com for myself though. That domain was always used by some business selling Turkish cuisines.
Looks like the .com is for sale, in case you didn’t notice. https://sedo.com/search/?keyword=Susam.com
You could probably acquire it (for less than asking price IMO) if you have a sentimental attachment. Nothing wrong with your .net, of course.
Thanks for sharing the stories.
> 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.
1 reply →
> 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.
for devops I highly recommend Davide Bianchi's "tales from the machine room".
https://www.soft-land.org/cgi-bin/doc.pl?mode=setpreferredla...
> 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.
2 replies →
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.