Hacker News Reader

My friend and colleague lost his job over this type of behavior... He'd simply go of the rails for days trying to figure out a problem. When he got his next job, I advised him to always think about how the company makes money from his labor. Sometimes it makes sense to "go deep", but often it's cheaper to let it go. If you're dead set on figuring it out, do it on your own time, not the company's.

View on HN

The real trick is finding a company and industry where it always makes sense to go deep.

I don't know. I think the key is just knowing how to prioritize. Sometimes it makes sense to go deep, especially if the problem is causing a lot of expense. Other times it's important to work on other problems.

Right now we're refactoring our codebase from one language/framework to another. Identifying which parts are still maintained and need the refactor vs. which parts would be a waste of time because a developer hasn't touched it in years is important.

This is especially important if you're one of few/sole engineers on a project.

"that's what she said."

Reply on news.ycombinator.com