Live data from Hacker News

Tools you’d miss if you left a company

rachelbythebay.com

21–30 of 112 posts

Re: Tools you’d miss if you left a company

#21
post #2

If you’re not building complicated new systems and just gluing things together, you’re not doing engineering? 1) definitely gate keeping 2) good engineering is about what not to build as much as it is what to build.

I agree - shouldn't you feel most proud of the products you've built that help actual people who pay you, rather than your coworkers for which those internal tools wouldn't need to exist if not for your customers. I'd rather have engineers working on products that customers would miss.

Everyone is motivated by different things. It makes sense that some people are motivated by the craft of software development, which overlaps with, but is not the same as, product development or running a successful business.

Re: Tools you’d miss if you left a company

#23

This article is dangerous in romanticizing the “not invented here” culture at many big tech companies and seems rooted more in the 90s than present day. The world of open source tooling and easily re-usable SAAS offerings means everyone has access to the best tools, whether you’re a small startup or a big company. Anyone who longs for internal, corporate tooling baffles me when they can use things that actually have…

The mistake you're making is thinking that the public tools are the best tools.

There are reasons that make them the best for many, if not most, companies: more investment, more mindshare, easier to hire employees with prior experience, and so on.

But there are also costs in having a wobbly stack of glued together stuff, especially if the parts aren't quite right for your goal.

Sometimes the best tool is more focused, more vertically integrated, in a different language or for a different operating system because those choices integrate better with the rest of your stuff.

The constraints of the company are also part of the problem domain. Using the wrong tools can be quite expensive, and the public tools may all be just a bit wrong in a way that compounds.

Re: Tools you’d miss if you left a company

#24

For 99% of engineering organizations, internal engineering tooling is not your source of competitive advantage. Your advantage in the market comes from understanding the needs of your target user better than anyone else, and building a product that meets those needs. For every piece of infrastructure or developer tooling you need, you have to make a buy vs. build decision based on cost/benefit analysis. Your cost to…

What if it's a tool which halves your operating costs and eliminates a new technology stack you'd need to teach your whole dev team?

What if the only tech that solves the problem is Oracle, and your business model can't cope with the costs that would incur?

(I have a specific example in mind but it's private. Poor evidence for an argument; but I'll stand by the fact that some business problems require too much glue with too many moving parts, and can admit simpler, more vertically integrated solutions whose maintenance is still within reach of your average dev.)

Re: Tools you’d miss if you left a company

#25

This really resonates with me. I have seen the “buy before you build” attitude turn into “buy because we can’t build”. I know correlation is not causation and there are always plenty of other things going on... but it sure seems like the pride in our work dropped off and we were on the wrong side of every tipping point.

I've seen this at a few places now. Learned helplessness is definitely a thing and a lot of it comes down to an inability or unwillingness to hire broadly. When you're hiring Bolt Turner #3, they might know a little bit about turning bolts (but might not, either) but expect everything that isn't a turnable bolt to be handed to them. But the screw turners and the pipe welders you've also hired don't think a working ecosystem of tooling is their responsibility either and they're not really equipped to build it either, so the only option becomes to buy. And at that point you lack the breadth and the depth of knowledge to effectively choose the right thing to buy, and the outcome is as if by dart board.

There's a reason to hire specialists in this industry, but we conflate one-track ponies with specialists and it's to our detriment.

Re: Tools you’d miss if you left a company

#26
post #7

I'd miss the engineering machine shop. Those facilities only get developed by accident, for instance if a company gets rid of its professional machinist but keeps the equipment, or something like that. The machines and collections of tooling take a long time to curate. Any modern manager would refuse to allow that much stuff to be purchased if they were asked, and believe in the magic of outsourcing everything.

At Apple Inc in the Sculley days (long ago) there was a lab in .. Monroe? .. the guys there were super orderly.. sports dads with good jobs.. that sort of thing.. I asked one day, what do you do here? They had so much precision equipment in one place.. the guy said that the did compliance testing for standards? and, some performance/spec testing? He looked slightly proud, and said "they had won Industry Awards" .. a year later they were gone. All the equipment, and I suspect most of the guys. The VP name was Moon? seemed like outsourcing and unwise to me..

Re: Tools you’d miss if you left a company

#27
post #24

For 99% of engineering organizations, internal engineering tooling is not your source of competitive advantage. Your advantage in the market comes from understanding the needs of your target user better than anyone else, and building a product that meets those needs. For every piece of infrastructure or developer tooling you need, you have to make a buy vs. build decision based on cost/benefit analysis. Your cost to…

What if it's a tool which halves your operating costs and eliminates a new technology stack you'd need to teach your whole dev team? What if the only tech that solves the problem is Oracle, and your business model can't cope with the costs that would incur? (I have a specific example in mind but it's private. Poor evidence for an argument; but I'll stand by the fact that some business problems require too much glue w…

Do the math - maybe it works in your case. I'd say a key question to ask is "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper.

When doing the math: A common mistake is to calculate the cost of "build" as SUM(compensation of developer team on the project) over the time it would take to build the thing. You should actually use SUM(business value created by developers working on the next-highest impact items on your roadmap). In a well-run business the latter should be much higher than the former.

Re: Tools you’d miss if you left a company

#28

For 99% of engineering organizations, internal engineering tooling is not your source of competitive advantage. Your advantage in the market comes from understanding the needs of your target user better than anyone else, and building a product that meets those needs. For every piece of infrastructure or developer tooling you need, you have to make a buy vs. build decision based on cost/benefit analysis. Your cost to…

I do not think it’s that simple. I understand the arguments for buying vs build. However, if you’re a technical heavy organization, relying on buying things also has its costs. You’re constrained on your product offerings because of the thing you bought. The decision is not that simple and requires a lot of work and foresight.

As such, my guiding principle has been to consider the layer at which the thing you’re trying to build/buy fits. For most companies it doesn’t make much sense to build data centers and any cloud vendor will do just fine. Infrastructure is therefore somewhat easier... almost always buy. But if your product requires some kind of integration that is critical for customers, I would think hard about it before buying.

The costs of integrating a bought tool are also overlooked in most of these conversations. External tools are marketed well but don’t always deliver on their promises of being easy to use or setup.

Fundamentally I genuinely believe that if your product is tech heavy you absolutely need a CTO or a founding engineer who has a solid experience in building things. There is no replacement or magic pill to replace that just yet. And still, many fall into this trap.

Re: Tools you’d miss if you left a company

#29

This article is dangerous in romanticizing the “not invented here” culture at many big tech companies and seems rooted more in the 90s than present day. The world of open source tooling and easily re-usable SAAS offerings means everyone has access to the best tools, whether you’re a small startup or a big company. Anyone who longs for internal, corporate tooling baffles me when they can use things that actually have…

The internal build tools I had access to at Amazon are unrivaled in the public domain. I DO miss them, at every job.

Re: Tools you’d miss if you left a company

#30
post #24

Earlier quoted context omitted.

What if it's a tool which halves your operating costs and eliminates a new technology stack you'd need to teach your whole dev team? What if the only tech that solves the problem is Oracle, and your business model can't cope with the costs that would incur? (I have a specific example in mind but it's private. Poor evidence for an argument; but I'll stand by the fact that some business problems require too much glue w…

Do the math - maybe it works in your case. I'd say a key question to ask is "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper. When doing the math: A common mistake is to calculate the cost of "build" as SU…

> If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper.

How does one do that? Do other businesses just tell you how they integrated? I remain highly skeptical of this. Bigger corporations especially are quick to tout their successes but hide their failures (publicly) which makes it hard to know how happy/sad these businesses are with the decisions they made.

Post reply on HN