[Update: Don’t] Share your Manager README

NOTE: I no longer recommend writing a Manager README. Click through to read why.

As a manager, on-boarding is both tough and really important whether you’re joining a team or they’re joining yours. My very short list for on-boarding in either direction is:

  1. Share expectations
  2. Build trust
Continue reading “[Update: Don’t] Share your Manager README”

Gender Diversity in Tech Reading List

This collection of lists is predominantly skewed towards gender diversity in tech. I don’t mean to imply that racial diversity is less important, but this collection sprung out of discussions related to James Damore’s memo.

This article by Rachel Thomas touches on many of these issues (with citations), and I recommend it.
We have a problem with institutionalized sexism in (at least) the tech industry which reduces gender diversity. This has multiple aspects:

Gender diversity in tech is important. Here are some reasons why:

Are there any links I should add? Please let me know!

2016 in Review

Let me just start with: Wow.

It’s been a huge year for all of us, full of changes and growth.



At the beginning of the year, I was looking for a new job in software engineering management. My wife was 5 months pregnant, and I was trying to figure out how rapidly I needed to get a paycheck. I was very lucky to be able to sell some stock options from my last company to tide me over for six months and allow me to find the job I wanted rather than settling for the job I needed. That has not been my experience in the past, and I don’t count on it being the case in the future.

Finding a management job can be tough.

Continue reading “2016 in Review”

Testing Databases

I work with Oracle and MySQL on a daily basis, and one of the questions I’ve often met is: How do I test my database controllers? This post explores that question using Java, but the principles apply to any language.

Most of the time, you can mock your controllers away. For example, if you have code that retrieves a data set, performs some manipulation of that data, and then visualizes it, there are several tests to perform:

  1. Did the data retrieve correctly? (i.e. was your query correct?)
  2. Did the manipulation algorithm work correctly?
  3. Did the visualization work correctly?

(2) is the one that most people test through unit tests. Hopefully you can test your manipulation methods by passing in a testing data set and evaluating the resulting dataset. If necessary, you can replace your controller with a mock/stub so that you’re not actually hitting the database.

(3) is the one that usually gets picked up by UI integration tests with frameworks like Selenium, Jasmine/Jest, etc. These tests can be fragile as UI changes and are usually very slow, as they require full-stack latency (POST your request, wait for the server to respond, inspect the DOM, rinse and repeat).

(1) is one for which I’ve seen the least number of tests (outside of integration tests), but they have some undesirable expenses: you have to have access to a database, and the left-over data might screw you (or your co-worker) up later. Continue reading “Testing Databases”

Expectations Should Not be Kept to Yourself

I’ve been watching Sex and the City with my wife. I’d gotten her to watch a lot of other shows of my choosing: Breaking Bad, The Wire, Justified, and I thought I’d try something from her corner of the television universe. We blasted through all six seasons, alternating between HBO Go and the (very large) pink album of the complete series sitting on our shelf when our internet crapped out. We watched the first movie last night. There are a lot of lessons to be learned from that show, and most of them are of the “What not to do” sort.

[Spoiler alert!]

Last night, Carrie and Big were arguing about the size and impact of their nuptials.

Big angrily shouted “200 people! Page 6! Do you know how that makes me look?”

I shouted back at the TV (I do that): “No, because you don’t communicate your feelings with Carrie!”

In fairness, Carrie isn’t good at that either, but that brings me to my point: communication is key. Continue reading “Expectations Should Not be Kept to Yourself”

Not So SoftWare: Because Software Development Can Be Hard

Hi everyone,

My name is Matt Newkirk. I’m a software engineer and I build tools, mostly in Java, Perl, or Bash. Those are reasonably easy to create, maintain, and deploy.

I also help other engineers with their technical designs, testability, and code reviews. Installing a Perl tool is easy: yum or rpm can help you with that. Instilling better design is harder, though arguably more important.

This blog will be about both: software development (and management) practices, and parachute tools to get you home safely when those practices fail.

I hope you enjoy these forthcoming posts and that you’ll share your software development path with me as well!