If you’re at a tech conference and see a vendor presenting a solution built on top of their product, use caution.

If you hear someone say, “There are many ways to test software,” it's true enough, but there's an excellent chance that most engineers and managers will disagree with whatever is coming next.

When deciding whether to go cloud-native and if so, what platforms to build on, ask yourself what you want to achieve.

Obtaining a Ph.D. requires the kind of persistence you probably want on your team. In an interview, follow a couple of simple tips to make sure you give these folks the best shot at showing you what they can do.

Given a code coverage percentage, how do you say whether it's “adequate” or not?

The new generation of knowledge workers went through school using GSuite, Asana, Trello, and yes even Office 365 online instead of on the desktop. They aren’t going to settle for collaboration via emailing .DOC files.

How many platform engineers think they can build a better logging library, see it adopted by the entire company, and achieve glory (and “impact” for promotion)?

In the face of an economic downturn, focus on profitability, and rising layoffs, it’s reasonable to expect that tech company executives and managers will start to question how many engineering resources are being dedicated to open source work.

Fifteen years or so into public cloud computing, perhaps the strangest lingering objection to cloud migration and lift-and-shift has to be the notion that “sensitive” data needs to stay on premise. Let's take a minute to break that down.