Skip to main content

Getting Back to React

Written by michael

After a year or so away from my first big React lesson, I decided I wanted to try diving back in again. I took pretty good notes the first time around, and figured I could get back up to speed pretty quick. I was mostly wrong.

It wasn’t React’s fault, though. It was purely a function of a year passing and technology moving forward.

The web hosting where I kept some of my notes got moved to a new server, and something broke the images beyond the common permissions fix. WordPress doesn’t output any helpful debugging info about why it can’t show its images (Devs, you should always output something when you hit internal errors…), so it took me a while to get everything back up and running (URLs and WP subdirs are a bit tricky to sort out, so I cloned the site with Softaculous to a subdir, deleted the original site, cloned the clone back to the original URL, and then deleted the first clone – worked a trick!)

Meanwhile, the new server also meant I had to learn the new DirectAdmin client that replaced the venerable cPanel client. A couple of tickets were needed with my hosting provider to add back settings that had fallen through the cracks during the migration.

Then I had to figure out dumb things – things that the curse of knowledge had made me overlook in my earlier note taking. For example, where I had put the source code. How I started up Visual Studio Code.

The worst though, was getting npm updated and running again. As you can imagine, there were a lot of pretty out of date modules, some so much so that there were very significant problems running the updates. The dependency calculations bogged down into spinning with no progress, and I started getting errors about lock files. I finally had to resort to obliterating my node_modules directory and reinstalling from scratch.

Fortunately, that also took care of the complaints GitHub’s Dependabot, another of the year’s tech introductions, was making about a few of the module versions in my package.json file.

Finally, I’m starting in on a new React course – not because the old one was bad, but because it’s already somewhat out of date with the state of React, for example that some of the lifecycle methods became unsafe, and caused me some problems in my sample app.

It just goes to show in neon lights how very fast software development keeps moving and how you can’t let your attention wander for a minute.

dailygrind, philosophy

Taking Notes

Written by michael

It’s not just scientists that need to take good notes in their lab notebooks. Every day as a software engineer you are figuring out code, determining processes, making decisions, and learning detailed concepts. How many of you are documenting all this, though, writing things down as you go so that others, and even your future self, can benefit from all this hard work?

I challenge you to approach things much more like a scientist or (real) engineer does and start keeping a lab notebook and also publishing your results. It can all be virtual, of course, and probably should be to be searchable and to maximize its visibility to others and across your devices.

Taking a course? Write down your notes. Figure out how to make something work? Write down your notes. Listening in on a meeting? Write down your notes. Working on a project? Write down your notes.

This might be one of the most important skills you can learn.

craft, philosophy

Your Product is More Than Your Service

Written by michael

As a software developer, it’s easy to forget you have customers. I mean, of course you know you have customers. But, without the personal interactions you get as, for example, a retail salesperson or a restaurant waiter, you may need to remind yourself that your seemingly abstract actions and choices have very real effects on people. Pay attention to times when you’re annoyed or disadvantaged by the choices of the software you rely upon, and resolve to avoid committing the same offenses against those that depend on you.

I was reminded of this advice this morning as I went to pull up the O’Reilly Media Learning site to continue my React class and all I saw was this…

https://learning.oreilly.com/home/

On the one hand, fair enough. Live services occasionally need downtime and early on a Saturday morning is probably a reasonable time for it. But, notice there is no indication of when the service would likely be restored. They provide a hint that the downtime will be quick, but 2 hours later, with no updates provided, “…in a flash” seems simply disingenuous. This is clearly more than a simple platform restart. Speaking of updates, there are no warnings of upcoming maintenance, or even status messages of any kind, on O’Reilly’s social media feeds. I took their advice and tried pinging the support email, but you just get an impersonal robo-response and I doubt I’ll see anything further until the outage is over when I’ll get an equally impersonal “Thanks for your patience while we work hard to improve your experience. All services have now been restored.” response.

This is just crappy, lazy work from O’Reilly. It turns me from being mildly frustrated at, yet understanding of, the disruption of my plans to being actively irritated and thinking of ways to broadly share my negative experience.

Let’s take it to heart as a lesson in what not to do, and focus on how to be better developers. Make sure you build your muscles for communicating with your customers, using all the available mechanisms. Give them fair warning, multiple times and far enough in advance that they can act on it. Be transparent about what is going on, even if an outage is unscheduled or you don’t have a resolution ETA. Don’t suggest support channels if you’re not prepared to respond appropriately. Mostly, remember that your product is not simply the normal functioning of your service, but the small quality of life touches that go along with it and make the customer experience worth coming back to.

craft, philosophy

Welcome

Written by michael

I’ve been a software engineer for a pretty long time. I remember when there were no email addresses. I remember the first time I ever saw a “GUI” on a new Macintosh toaster. I remember (barely…) when you typed on a console and it printed out on a never ending accordion of green and white paper.

Things have changed a lot over the years, and I thought I was doing a decent job of changing along with them. For the last seven years, for example, I worked on moving a feature animation studio from a LAN oriented infrastructure based on an RPC client/server architecture, to a Web oriented cloud infrastructure based on HTTP and services.

One thing I didn’t pick up on , though, is the use of the Web to “brand” oneself and show a portfolio of work and thinking. I only saw that when I left the safety of a secure and comfortable job to find something more interesting and challenging.

So, here I am, on my own domain, typing my first tech blog entry. It’s fun and I’m excited, because many of my past coworkers know how much I like to think and talk about software. While I’ll likely never have the time to become a serious blogger, I do hope that I can use this avenue to put down my thoughts about my industry, its practices, and some answers it might provide.

philosophy