inner strength

The past month has been extremely difficult. I've been weathering personal and societal storms on a large scale. And this weekend saw a massive tragedy in a community I'd been part of for years. The artist of the track above was one of the victims.

It's hard to bother with sleep when you already know you'll wake up to a crushing sense of hopelessness. And yet, we're still here. In a couple of hours, the sunrise will shed light on the fact that we still exist. Maybe we'll have another day to make the most of what some people no longer have. Maybe we'll have the opportunity to help others do the same.

what i do most days

Developers who debug inherited codebases do a lot of what I've been doing lately, which is tracing. It's time-consuming, but like most brute-force methods, it's simple and works eventually. You:

  • look at what errors you're getting
  • try to figure out which function they're happening in
  • go to that function
  • insert a bunch of log printing functions around where you think the error is happening
  • run the code again and see which logs actually get printed to the console

Unless you have asynchronous stuff happening, the last thing that gets printed to the console is directly before where the error happens. If the next line is another function, go to that function and repeat the process.

(Pro tip: if you are debugging something this way, log the name of the function you're in. You will probably forget to remove at least one of the logs when you're done, and knowing which function is printing a bajillion messages to your production console will be useful when you need to find and remove it.)

Tracing works for most debugging scenarios, but web developers also need to be aware of how the server gets information from its database (the backend) and passes it to a user's web browser (the frontend). Otherwise, you won't even know where to look-- are your errors and logs printing to your browser's dev tools console, or your server terminal?

In my company's case, the codebase's layout makes it clear which files:

  • On the browser side:
    • Send HTTP requests for data to the server
    • Parse the data from the server
    • Create views for the user using the parsed data
  • On the server side:
    • Receive HTTP requests for data from the browser and route them to the right data retrieving functions
    • Retrieve data from the database
    • Structure the data and send it back to the browser

A couple of well-established and stable Node.js libraries handle our MySQL database calls (mysql), HTTP requests (request), and server routing (express). We also use larger, newer libraries to create our user views (React) and to structure and parse our data (Redux).

These popular libraries also throw useful errors that help with debugging. For example, their error messages might indicate which files and lines an error is happening in, and I can follow those errors up from a library's files to our actual codebase's files.

This might look obvious to experienced fullstack developers, but I started as a primarily frontend dev and had to figure out a lot of this stuff on the fly, so I wanted to write it down for people who are still learning.

under pressure

This month I've been busy working on a new feature for my company's book club websites, most of which are managed by one server. I spent my first few months creating internal tools, scripts, and emails, so I wasn't as familiar with the user-facing codebase as the other web developers. But we needed to mitigate our bus factor, so I decided to bite the bullet. I wanted to better understand how the different pieces of our web stack worked together anyway, and this was a small feature that touches a lot of parts of our web architecture behind the scenes. (I'll write more about the actual code later.)

One of the most important things I realized during this whole ordeal has already been written about:

Nothing gets done when you interrupt an engineer.

We have an open office plan and just moved to a smaller building. The view is nice, but there aren't that many corners where developers can run away and be alone for a while-- places where we can get guaranteed uninterrupted focus time.

I usually like chilling with my coworkers, and a lot of them are naturally social as part of their jobs (marketing, customer service, etc). So I didn't really notice this aspect of our office until this week. Specifically I didn't notice until it was crunch time on Friday afternoon, I was concentrating on debugging a big issue that came up at the last minute, I was interrupted for the fifteenth time about whether we were going to have something ready for release that night, and everything I was trying to keep track of flew out of my head. Again.

My office spirit animal: a bunny falling over at work Me yesterday, my concentration broken again

My project manager is super understanding and tried to run interference for me, but there's only so much you can do on Friday at 5pm when everyone wants to hang out and unwind while you need to get something out the door. (We have a "No Releases on Friday Night" rule, but our other option was releasing on Sunday night and putting out fires during our Halloween festivities the next day-- I put my foot down on that one.)

I managed to debug the issue and do the release eventually... after the office emptied out a little bit.

about robots taking people's jobs

I'm not opposed to the idea of robots taking over dangerous manual jobs. I'm not even opposed to the idea of robots taking over creative or technical jobs. I'm just opposed to people blindly trying to make that happen as soon as possible, before any societal provisions are put in place for the people whose jobs will be taken.

I don't believe in meritocracy. I'm not in favor of economic or intellectual Darwinism. It assumes that only the smartest or most resourceful should survive, and it also assumes an even playing field for all involved. "If someone's manufacturing job will be taken by a robot, they should just learn the skills needed to get a better one," say people from well-off families who have never tried to master a skill while hungry, or while working a low-wage job 16 hours a day.

I'm all for robots taking our jobs, but before that, we need our society to function without jobs at all. We need to set it up so that no one needs to spend their entire life working at a place they don't really care about just to feed themselves and their families.

We need get our world to a place where no one has to work to stay alive. Once that happens, bring on the robots.

not a technocracy

Last weekend, while camping on an island full of ponies, I had a long conversation with a newfound friend who works in Washington D.C. as a lawyer and political fixer, and Joel, who's studying computer security but did his undergrad in economics and political science.

The new friend implored Joel and me to venture into roles outside of tech, not a hard sell since we're both from non-tech backgrounds. But she emphasized the fact that non-techies have no idea what's going on with technology, and that's a huge issue, especially in law and the government.

We already sort of knew this, but the bleakness with which she presented us with this information was startling. Joel and I are years away from being computer experts, but she said that decades of experience aren't a prerequisite to be a consult for some of the concepts that lawyers and lawmakers need help grasping. It just takes a few connections with the right people-- and a knack for translating technology into language that actual human beings understand.

As someone who went into tech partly to make it more accessible, it's encouraging to see that I really am filling a pressing need-- the need for techies to have actual human skills. However, it's also disconcerting to hear that our government is still largely tech-illiterate when technology now permeates everything. Entrenched systems have a lot of catching up to do.

rabbit holes

I spent several hours today working on an increasingly frustrating string of technical problems I should not have even been working on.

It all started with me trying to get a working version of my rudimentary NYPD stop and frisk data grapher online for public commentary (and hopefully statistics help-- I slept through my 8am stats class in college, so I never really learned how to normalize data).

While investigating, I fell down the following rabbit holes, which were all only moderately related to the problem at hand:

  • Amazon Web Services: I first considered putting the app on an Amazon EC2 instance, so I looked at my list of instances and found out that the one hosting this blog was about to be retired. I tried to stop it and migrate my blog to another instance, but it hung on the stopping part, so I had to file a support ticket and they presumably stopped it for me.
  • HTTPS: When I finally managed to migrate my blog over, I remembered that doesn't have HTTPS, so I looked into what it would take to get an SSL certificate. I visited LetsEncrypt and learned that they only really work when you have shell access, so I looked through my old notes and realized I had SSH access to the server. (This blog's server is completely different, and I redirect with an .htaccess file.)
  • Plesk: My web host uses Plesk to help me manage permissions and stuff for the site. I found an SSH terminal feature built directly into it. I tried using it and was told to download Java. I downloaded Java and was told to download another package. I downloaded that and the terminal application opened, then crashed, citing a faulty security certificate.
  • SSH: So I tried SSHing into with my FTP credentials like I was once able to. That didn't work, but I managed to do several other things with my FTP credentials, like telnet and log in with ProFTPD commands, neither of which I'd ever used before (except for watching ASCII Star Wars). I finally filed another support ticket and was told that SSH access is now restricted to a specific port, and that I can't just use my FTP password to authenticate anymore. Luckily they were able to put some new keys into the server so I could log in (and promptly change them, because they sent me the private key via email). I logged in, remembered that the server uses nothing but vi, and promptly logged out.
  • Bitnami: After migrating my blog, I tried to update a CSS file on my instance of Ghost, whose Amazon EC2 image was provided by Bitnami. After changing the file and pulling it into the server, I found that the CSS file name was garbled in the browser. I discovered that Bitnami uses Pagespeed, hence the garbled file names, and set about turning that off in their Apache configuration. Then I realized I had to restart the whole Bitnami setup to get Apache to reload and to recompile the one CSS file I had changed.

While I was waiting for the support people to grant me SSH access to my site, I discovered that Heroku now has a MySQL add-on with a free tier, so I actually got the data graphing app built and on Heroku from my Github repo in about thirty seconds. I still have to configure the database and add the datasets to it, but that'll take me less time tomorrow than all of these other shenanigans put together.

All things considered, the five seven hours I spent on this was only maybe a fifth as frustrating as listening to yesterday's US presidential debate for five minutes. I might have even learned something new.

bunny running away suddenly