Tools you’d miss if you left a company

At the 50-person company I worked at 6-8 years ago, my team's product was custom Ubuntu-based OS images that booted appliance-style on customer hardware and ran our product full-screen. We had some very nice tooling based on the live CD creation stuff that would a) build our cross-platform code into Debian packages b) patch and rebuild a couple of Ubuntu packages, or fail the build c) generate a nice OSS compliance bundle and d) output a .iso as well as a directory of .debs for internal interactive testing (so you could upgrade a machine you'd already installed without reinstalling it). We wrote some small custom tooling to snapshot the Ubuntu repo metadata periodically (https://github.com/mokafive/apt-mirror) and build using the snapshot as of the time the SVN branch was created. Keeping this system running, once it was built, took very little time - that project was briefly down to one engineer and I could keep writing code and trust the build system to work fine. If I needed to implement that today using the best commodity tools I could, I'd probably be in some sort of Dockerfile hell, and in fact I'd probably be strongly inclined to design the customer system on top of Docker somehow, even though it would be absolutely the wrong fit, simply because that's what everyone else's OS-image-building problems look like these days.

I guess the flip side is that there are probably few startups building products like that, and many more startups where you're building a CRUD app in Rails^WNode.js and your value to the customer is that you're just doing a really good job of writing a CRUD app. That's fine and valuable, and there's an interpretation where it's my personal failing that I'm not really excited by that, even if it's delivering business value / helping the world / etc.. But it is how I feel (and my guess is the author feels the same way), and I once did leave a company because I felt, for lack of a better term, bored - I was having to invent my own opportunities to grow as an engineer, and it was made clear to me that I would get better performance reviews if I worked on less ambitious projects. And when I've been interviewing people at my current place, I've heard enough stories of people being equally bored at their current jobs at large companies.

So - this isn't a BigCorp vs. startup argument, I think. It's an argument that different companies have different levels of appetite for build-and-encourage-internal-tooling vs. buy-and-conform-to-the-outside-world in their culture, and if you're an engineer who's going to be frustrated by the latter, look for a company (of any size) that believes in the former.

I've found there to be a pretty huge difference in those offices, particularly the European offices. The staff is far more diverse (e.g. I'm on a 40 person team and the largest number of people from one country is 4) and the culture and attitude to work is completely different. Much less koolaid-drinking and much better work/life balance. People actually use their (much more generous) vacation time!

The only reason the OP can boast about the experience with these proprietary tools is because they're used by FAANG. No other reason — it's just an indirect and inconspicuous boasting about having worked at FAANG.

If it was yet another proprietary non-OSS language used by one of the investment companies that has no direct analogues at any of their competitors — good luck boasting on your resume that you have skills in programming languages that noone cares about.

Proprietary software sucks. Just because it's written and used internally by FAANG doesn't make it suck any less. When you're evaluating whether or not to join a company, presence of such tools should be more of a red flag, if anything. Same goes with software-as-a-service. Tools should be OSS, and easily portable between the workplaces.

Another case in point — it kind of works both ways — many companies start around with Erlang and ejabberd, because it's a really great tool, but then, after having issues finding developers who can understand it properly, they eventually, one way or another, convert their stack back to the more common languages; I recall this has happened with Facebook Messenger and Heroku, and also at a random startup I was interviewing with during the course of my interview (they just hired a manager who knew Java — and, what do you know, he decides to set a direction to eventually replace all Erlang with Java).

What takes months is feeling like you understand the most important tools and aspects of the environment to be as effective in them as those around you, or to match how you felt in an environment where the scope is smaller. It’s not like you’re sitting in classes for months - you’re doing your job (maybe even more effectively than normal due to the availability of these tools), but every once in a while you’re encountering something where you need to ask someone else or explore or watch a video about how to do something, and that might break your momentum.

Isn't the point that they often don't need those tools? I've lost track of the number of "I replaced Hadoop with Excel!" blog posts I've read.

That is, I expect the 5+ months is more how long it takes to find a good project and ramp up on it and deliver something of value while figuring out the social processes, not how long it takes to learn how to use the tools. I would not expect that developers just aren't writing code for their first four months.

For instance - I am generally under the impression that Google interns get something done (not necessarily a lot, but they do complete a project) in a 2-4 month internship, and they use the same tools as everyone else.

It is expected that a new employee takes that much to actually be part of company culture.

Dont under estimate the profitability of a dev. I-make my employer three times as much as he pays to keep me, the industry really misses that.

Let them train the juniors, and solve their issues. Its worth it.

I think the main issue is fad-tooling. It is annoying and often not needed. Its also a complex issue really... what about saving educational costs ?

Say my devs want k8s. Dows my scale allow me to send them to confs, or do we go and shred our monilith? Maybe start a new project? Stuff like that. Its not an easy problem to solve.

Those were nice tools which worked quite well most of the time. They worked in any browser on any OS, unlike some of the ActiveX-only stuff they tried to replace it with.

This is not the Rackspace you probably know. This is the teeny little one that nobody had heard of outside of a few advertisements in Linux Journal (and the occasional rant about spammers and malware hosting). This is them back before the whole cloud thing - over fifteen years ago.

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

These days, I very rarely enjoy using tools that aren't open source, or at least generic and very widely available. I simply don't want to spend my limited brain cells learning a piece of software that I won't be able to use in the future.

And in any case, large, internally developed tools are usually awful. Unless I wrote them. ;-)

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.)

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.

> If you're at a mega-corp with a huge engineering staff:

Netflix is an odd choice for number two on a list of two. I’d guess it has an order of magnitude fewer engineers than Facebook.

So what’s the rough cutoff here? 1000 software engineers?

As for Prometheus, I like the rules engine VERY much (unsurprising, since they basically reimplemented borgmon, there). I'd take Viceroy any day over Grafana, though.

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.

A previous employer had an all-proprietary stack: language, IDE, version control, deployment system, database, job scheduler. It was, frankly, amazing. The most productive environment I’ve ever worked in. Time-to-market was this company’s competitive advantage and this stack let them leave their competitors in the dust, scrabbling for a distant second place.

everyone has access to the best tools,

It’s 5 years since I left there and the FOSS tooling we use at my present company doesn’t come close, and it never will, because choices are driven from the basic assumption that FOSS is always best, and it just isn’t true. We are at least 5 years behind where the previous company was when I left it and they won’t have stood still in that time.

I'd rather have engineers working on products that customers would miss.

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.