Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tools you’d miss if you left a company

rachelbythebay.com

Post reply on HN
Print view View original

11–20 of 112 posts

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

#11

Post by stereolambda »

I don't agree without reservations but like how against the grain this currently is. Outsourcing everything does seem like a sign of immediate hyperoptimization and missing building a more lasting engineering value. Do as little as possible to extract some margin. There is business wisdom in this but indeed such companies would seem more brittle. Sometimes it's like there's an ecosystem of plumbing companies selling to other plumbing companies without much visible external cash intake.

That being said, I think most of the things she mentions are not customer facing but still pretty differentiating to the businesses.

Another perspective is that the first crop of truly successful Internet companies were in the position to solve the big backend problems with running big Internet companies in-house. Nowadays getting to the scale while building some fundamental in-house stuff makes less economic sense (you'd lose to someone who doesn't). It's probably better to have some unique technology but more closely related to the specific business.

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

#12

Post by Insanity »

At one of the places I worked, a relatively large university-hospital, there was an entire Java-UI framework build based on C#s XAML. But it could also experimentally be compiled to html/css/js.

Writing any type of UI in Swing is just painful - but this system made it so much nicer. It also had a WYSIWYG editor that you could interop with actually writing the code. Plus you could write either the 'markup language' or the "Java" flavour directly.

Making complex responsive UIs was a breeze. It's a shame it did not get open sourced - but it was tied into a great amount of internal tooling. (The entire codebase was 28+ million lines of code when I left).

It's one of the few non-open source libraries I've worked with that really impressed me.

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

#13

Post by i386 »

vector_spaces wrote: post #9
i386 wrote: 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.

Yes, exactly. The view that such work just constitutes writing "glue" is super reductive. So much time is also spent empathizing with others: talking to stakeholders, understanding existing processes, determining requirements, and simplifying. So if we can reduce the solution to glue instead of needing to write a complicated system, that's hands down a win.

Any engineer who comes up with a solution that requires less new code being written is a more valuable engineer IMO. Less code is less time spent on building then maintaining code for all eternity.

If you go through the build/buy/partner decision, and decide to buy or partner with development comprising of glue code - then that's probably the optimal solution for your org. And you made the right engineering choice.

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

#14

Post by patrec »

vector_spaces wrote: post #9
i386 wrote: 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.

Yes, exactly. The view that such work just constitutes writing "glue" is super reductive. So much time is also spent empathizing with others: talking to stakeholders, understanding existing processes, determining requirements, and simplifying. So if we can reduce the solution to glue instead of needing to write a complicated system, that's hands down a win.

Just because you're not doing much (any?) interesting engineering doesn't mean you're not creating a lot of value. But it probably does mean that if you really deeply care about engineering in itself you should reconsider your employment options. But learning when you can just glue and how is a super-valuable skill, even if some of your work involves pushing the envelope.

The worst engineers are not those who just glue stuff together, it's the people who cv-drivenly develop 100x too slow, resource intensive and broken buzzword bingo clusterfucks that could be solved, correctly and cheaply, with a page of shell script.

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

#17

Post by wpeterson »

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 polish, user experience and likely better implementations under the hood.

Companies should spend their time/energy building things unique to their problem domain, not weak also-ran corporate tooling.

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

#18

Post by patrec »

i386 wrote: post #13
vector_spaces wrote: post #9

Earlier quoted context omitted.

Yes, exactly. The view that such work just constitutes writing "glue" is super reductive. So much time is also spent empathizing with others: talking to stakeholders, understanding existing processes, determining requirements, and simplifying. So if we can reduce the solution to glue instead of needing to write a complicated system, that's hands down a win.

Any engineer who comes up with a solution that requires less new code being written is a more valuable engineer IMO. Less code is less time spent on building then maintaining code for all eternity. If you go through the build/buy/partner decision, and decide to buy or partner with development comprising of glue code - then that's probably the optimal solution for your org. And you made the right engineering choice.

> Any engineer who comes up with a solution that requires less new code being written is a more valuable engineer IMO

Of course less code is good, all things being equal.

But taking that idea literally, basically no tooling code gets ever written and people develop some sort of learned helplessness around dysfunctional workflows that are just about feasible but fantastically wasteful of engineering time. This tends to happen a lot, also because tooling is often perceived by management as an unnecessary luxury.

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

#19

Post by stochastastic »

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.

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

#20

Post by alexhutcheson »

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 "buy" needs to include the upfront cost of developer time to configure the software for your needs, and the ongoing support cost to make sure it continues to work. When you include this, even open source software isn't "free", although it may be cheap. Your cost to "build" includes the upfront engineering time to design & code, ongoing support time to keep it working, and opportunity costs incurred because until the system is actually ready, no one can use it, and they have to either meet their needs in some other way or simply block until the tool is complete.

Very large engineering organizations like Facebook, Netflix, etc. can amortize the cost of tool and infrastructure development over thousands of developers and an enormous infrastructure budget. If a tool would make most of Facebook's developer's 3% more efficient, than it's worth staffing a team to build that tool. If better caching infrastructure could reduce Netflix's network usage by 3%, then it's worth staffing a team to build that infrastructure.

If you're a small- or medium-sized business, then that math doesn't pencil out. A 3% (or even 10%) developer efficiency improvement doesn't even pay for the opportunity cost of one developer. A 10% decrease in a single dimension of your AWS bill probably doesn't pay for the developer time either.

If you're at a mega-corp with a huge engineering staff: Yes, absolutely invest in tools that make your engineers more productive, especially if you've identified truly unique needs that can't be met by off-the-shelf software.

If you're at a smaller business: Focus your developer energy on your user-facing problems, and almost always prefer to "buy" instead of "build" (where "buy" includes using open source software).

Post reply on HN