Live data from Hacker News

Tools you’d miss if you left a company

rachelbythebay.com

101–110 of 112 posts

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

#101
post #51

Not everyone finds BigCorp problems to be the interesting problems. Not everyone wants to live in the Bay Area. There's a lot of jobs in the world that aren't at FAANG, and it's okay if the right job for someone is at a place whose entire dev shop is smaller than the team at Google that maintains Blaze. If you find yourself in a job like that, it is absolutely the right call to invest in the best commodity tools you…

There seems to be an elitism when it comes to working for faang. there are a ton of people that have zero interest in building advertising engines or living in the Bay area. Quite frankly my min salary for having to live there sacrifice working on something interesting with be mid to high 6 figures so I could save and move the hell away after a few years. I'd consider it a life sacrifice to endure the bay area and cu…

I feel similarly but I find it to be the Bay Area that's the problem rather than FAANG. All those startups and unicorns being in one place makes people see the Bay Area as some kind of software engineering Mecca and I think engineers based there subconsciously see themselves as superior for being a part of it, especially given the high pay.

If you go to another city or even better another country, even in the same company, things are very different.

Having done so, I would never return to the Bay Area except for the reason you mentioned: to pile up enough money to leave it again.

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

#102
Every time I make a neat tool I open source it using the unlicense so I can use it elsewhere with no attribution. I'm happy to work at a company where this is possible. This doesn't apply to business critical code a competitor might want, just libraries and tools for making generic 'stuff'. Typically, I make the tools at home first and decide I want to use them at work, but I eventually end up patching them at work for company purposes.

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

#103
post #80
post #51

Not everyone finds BigCorp problems to be the interesting problems. Not everyone wants to live in the Bay Area. There's a lot of jobs in the world that aren't at FAANG, and it's okay if the right job for someone is at a place whose entire dev shop is smaller than the team at Google that maintains Blaze. If you find yourself in a job like that, it is absolutely the right call to invest in the best commodity tools you…

I get the argument, but one of the reasons Google has a bigger-than-a-whole-startup team to maintain Blaze is their build tool needs to do a whole bunch of things. At a startup, your build tool just needs to build your product, not a thousand different products in fifty different tech stacks that all use them slightly differently. Sometimes, your product will look close enough to an existing internal Google product t…

BigCorp vs startup leaves out a whole lot of mature small- and midsize-businesses. People working for SMBs have a lot of reasons for doing so. Some people want to find 9 to 5 jobs where, when they're done for the day, they can shut off. Some people are kinda okay at writing at software and want to live in Ohio or whatever and they're not the sort of person someone is going to beat down the door for to make them an offer for a remote job.

Like, HN comes from YC, it's not surprising that there's a focus on startups and the sorts of BigCorps that grew from startups in living memory. But Java, C# and VB.NET are all in the Tiobe top-10, and I feel like HN has a real blindspot for the people who are writing line-of-business apps. It's like they're all dark-matter developers.

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

#104
post #18
post #13

Earlier quoted context omitted.

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 t…

Agree, In my own experience it’s only orgs with a min 50 to 100 developers who can afford to have a single developer (it was me!) out working on productivity tools.

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

#105
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.

Yup, it sure is nice to have a monopoly and be able to throw money at 100+ engineer teams to invent cool new tech from scratch. I'd like to see you try this at a startup.

Daddy AdWords always has a spare $100M

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

#106

Earlier quoted context omitted.

What's the closest OSS equivalent and how could they be improved?

Just responded to another comment - for the part I miss most, Pipelines, Spinnaker is probably closest (I'm aware of Concourse, etc as well). But Spinnaker is horrific to stand up yourself (especially at my company of 8 engineers), and it's actually too generic. The primary advantage I believe is that the tools were exactly built to work well at Amazon, with Amazon's infrastructure.

Armory (W17) can help with spinnaker. We offer a managed version for exactly this reason. Probably still way too heavy for an eight person engineering org but helpful for larger companies.

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

#107
post #79

I have to strongly disagree. When doing business you are solving a business problems. Facebook, Google, Microsoft as business has grown so much they have problems of scale no open tools are able to handle. On the other hand, any kind of smaller company doesn't have those business problems, but a cost of having and maintaining in-house solutions of that scale will just effectively topple and sink them. This is why I'm…

It's also a lot about the marketability of your skills.

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

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

#108
post #88

This topic is one of the primary reasons I enjoy working at MS these days. The tech stack is full of OSS or industry standard tools, not a bunch of internal NIH things. My current stack is: React, Node, Kubernetes, Linux (for dev and deploy), Git for sc, GitHub, vs code. I can’t even think of some internal tool that I depend on at the moment.

Github is open source?

Like it or, GitHub is ubiquitous enough that noone really cares. If you do care, there's plenty of OSS alternatives that aren't much different in their UI than GitHub itself.

You can easily put GitHub on your resume, and everyone would know what you're talking about. Of course, by itself, it's not much of an experience, but, surprisingly, it is often listed as a requirement and/or nice-to-have for certain SWE job posts.

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

#109

If the tool is valuable to you, make sure you know exactly how it works. Then you can recreate it, for yourself at least, whenever you go.

Also, if you wrote it (as often happens in my case), put some effort into getting it open-sourced if possible, so that you can just use it elsewhere later.

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

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

#110

Earlier quoted context omitted.

I'm asking this sincerely: What is/was so great about them?

It was probably some combination of how well-integrated and how opinionated they were. The build tool was multi-language. It allowed depending on arbitrary packages which had been imported to the Amazon package repository. It allowed package owners to annotate the packages with guidance - experimental, deprecated, forbidden (in the case of security issues), etc. You could also declare conflicts, which would notify co…

Awesome, thanks for the informative reply!
Post reply on HN