Posts tagged: SOFTWARE ENGINEERING

I was recently asked: “What if you start a new job and their codebase is a mess?”

We’ve all been there. Here are some of the tactics I’ve used.

I enjoy writing tests because I love what they give me.

• I love knowing that I’m adding defense against breakage from future changes.
• I love thinking through how a feature is really supposed to work, and having the test capture that understanding.
• I love thinking about edge cases that the code should handle, and writing tests for them — especially if it turns out that the code under test didn’t yet handle them correctly, because that means I’ve just saved us from a bug.

I can remember projects with zero test coverage (early in my career, I didn’t even know that was a problem) where implementing and shipping large changes was anxiety-provoking — both during the work, and after deployment. That awful feeling of holding your breath waiting for bugs to manifest.

I can be kind of a stickler about leveraging the ticket/issue tracker in software projects (which always seems to be Jira these days, but nevermind that). I write tickets carefully; I link to related issues; I add comments to note the status of work in progress, or to record info that’s important to the work to be done.

I’ve been a full-time remote worker since 2010.

The COVID-19 pandemic has brought big changes to things involving face-to-face contact – like going to an office for work. Since this sea change has gotten more engineers (and employers) to think about remote work, I thought I’d share some tips on how to find and keep remote gigs.

This was written with junior-level engineers in mind, and is more about full-time employment than freelancing. Hopefully it has useful bits for others as well.

TLDR: Use python-future.

A couple weeks ago I accidentally replaced our live, production database with a 17-hour old snapshot.

I had intended to target a test server, not production. I didn’t realize what I had done for an hour or so, and by that time I had already left work. (I was actually out walking my dog. Not a good setting for managing a production crisis.)

Here’s how my team and I handled it.

You could say Z-80 assembly language is what really turned me into a software developer.

My first programming language was BASIC, which was built into my first computer (a TRS-80 Model III). I wrote a lot of BASIC code, including arcade-style games (compiled BASIC — you can still play them on this TRS-80 Model III Emulator).

I always wanted to keep learning. There was no World Wide Web for research and nobody I knew could guide me, so we went to Radio Shack and asked them how else I could program the computer. They sold us the Editor/Assember package.