Comment by mwcampbell | Hacker News Reader

Comment by mwcampbell | Hacker News Reader

This is tangential, but:

> Some engineers tell me they are “just engineers”. They don’t care too much about who uses their software or why. They are just implementing, say, JIRA tasks – building services with some bytes on the input and some bytes on the output.

I think this might be one reason why I didn't stay in my previous job as an engineer at a big tech company. I do care about who's using my software and why, especially since I work in an area (accessibility) that's all about the human factors.

But now that I'm a cofounder and one of only two developers at a tiny company, where I have the power that I wanted to shape the whole user experience, I find that I too often get side-tracked trying to make the technically best decision on some tactical thing, e.g. choosing the best distro for a container, as if I were specializing in that area, when I should just quickly choose something popular and good enough so I can stay focused on the big picture. As is so often the case, I guess I'm trying to have it both ways.

This might be a “no true Scotsman”, but I'd argue that if someone is just performing tasks from a JIRA queue and not doing any systems thinking or concerning themselves with the broader picture, they aren't just engineers, they're just programmers.

You’ll feel better about making “worse” decisions if you shift your thinking towards now/next/later.

_Now_, we choose off-the-shelf X because it will get us started and we have 99 other things to bootstrap.

_Next_, we throw the original away and plug in better tech Y.

_Later_, when resources are not an issue, we’ll use Kubern... tech Z. :)

If I've learned anything from launching a product thats getting some real traction, there is no _Later_, and _Next_ keeps slipping further into the future. It's okay to move a little bit slower and make sure you get decisions right since you'll likely never come back to what you're working on now, and if you do it'll be years later. This doesn't mean that you should sit there and built everything out today as if you're Googlescale, but don't be afraid to move a little bit slower and consider some more options including rolling your own if it makes sense.

> there is no _Later_, and _Next_ keeps slipping further into the future

"Later" can turn out to be functionally equivalent to "No" and still be as valuable as "No" can be.

Moving carefully can be valuable too, of course.

Maybe the product you launched wouldn't have gained traction if you delivered a bit slower or lacked a few of the features? The strategy you used worked, why do people so often say "I got successful doing this, but don't do what I did do this other thing instead!"?

That's an interesting point. In our case, I'd say that slower would have been fine because we already moved slowly trying to figure out the features that would really get people to start buying, at which point things took off. Given that we're not really pushing new technology and primarly competing on price and simplicity, it doesn't seem like speed to market was a determining factor for us, while having spent some time earlier thinking longer about some fundamental issues could have avoided some serious pain I am experiencing now.

If you’re on the business/product side, I hear you; it’s often “never” and forgotten about as soon as the meeting ends. If you’re technically-minded like the OP, then it can help structure and focus your analysis paralysis.

These aren't engineers, they are programmers.

Engineering isn't about coding, coding is simply a tool to achieve results. If your organization managed to silo it's engineers into ticket-coder orgs, there's something wrong with your company.

Reply on news.ycombinator.com