3 ms·
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
by jt2190 16y ago
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.
- Dilpil 16y agoThe real trick is finding a company and industry where it always makes sense to go deep.
- deleted 16y ago[deleted]
- okaramian 16y agoI 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.
- evo_9 16y ago"that's what she said."
- deleted 16y ago[deleted]