I noticed I’ve written a lot about the building an application part of what I do for a living. Wanted to fill in the gaps.

Early:

Unit tests are nice to have. You’ll notice when you have none, but you’ll also notice when you have too many. If your coverage makes a desi parent happy, it’s probably a smell.

When set up correctly, Acceptance tests with a proper Gherkin statement double as integration tests and demos. Significantly easier for Product to read than junit.

Physically accessing a machine on a customer site to copy logs, followed by emailing them works. But ideally this data exists in the cloud.

Middle:

TDD followed to a T has mixed results. Yes mocking isn’t great practice for tests. But show me how developing every unit of code in a black box with dependency injection all over the place, unnecessary interfaces, indirection, and artificially short methods meaningfully helps. In my experience, the raw dogma leaves application performance on the table.

Do not underestimate a good Dashboard. We need to know how the code is running. It building and deploying successfully is about as impressive as an ABCD finishing undergrad.

Writing code is great, but it’s important to learn how the company actually makes money. An application outside a business context is a toy.

Current:

These are more niche, but places with more rules typically ask for them. Smoke tests to make sure all the critical components work. Performance tests to make sure you can handle spikes and failures.

Make sure your Alerts are properly calibrated. Getting paged at 2 in the morning for a false positive sucks.

Strong Querying fundamentals are underrated. I’ve lost count of the number of bugs I can identify off the logs. Nothing hits quite like figuring out the problem off your teammate’s description alone.