7 ms·
This whole premise falls completely flat if you've only ever worked at small and/or young companies: > but which didn't exist on the outside world. > You're n
by wink 7y ago
This whole premise falls completely flat if you've only ever worked at small and/or young companies:
> but which didn't exist on the outside world.
> You're not allowed to include things you or your friends built
If you work for a service provider, you probably have zero to not much internal tooling, because you're usually solving the customer's problems, not your company's. When I did, we open sourced everything cool we built - sometimes tried and true defaults, or sensible Vagrantboxes or something like that. (Today that would be Dockerfiles, I guess) - and I consider myself lucky to have worked at a smaller company that was close to the FOSS scene, and not something like Accenture. Companies like ThoughtWorks might be an outlier here.
You're unlikely to build something so immensely cool in your first 1-2 years in a startup that it will change your live (as a developer) completely. (This is not about your company's product, but internal developer tooling, so if your startup does developer tools as a product, you're the 1% where this would apply).
And finally, if your startup grows.. you might probably still not be the next Google or Facebook where the internal team providing nice things to your fleet of developers is bigger than some companies. Internal tooling will often be seen more of a cost factor than a tool for productivity enhancement. And often it's actually the case. In my current company we just have so many software development teams creating parts of our products.. so many languages (with good reason) - the only internal things I could think about that would even make sense for all of them would be some code review tool, or anything targeting source control or maybe CI. Anything else would have to be really workflow-centric and language-agnostic. Anything regarding the mentioned borg/k8s/BigTable would be completely useless, for example.
That said, at my last company, I think we created some pretty cool things that made a lot of things a lot easier for the team. But we were two small teams, so point to "we built it ourselves, for ourselves" applies. Also it probably wasn't so revolutionary in the greater sense, but everything made sense for that company and I'm often still sad if I have to solve some similar problem these days and don't have my old setup (more than a specific tool).
- rachelbythebay 7y agoCounterpoint: Rackspace. The line internally was "service, not servers". They developed CORE which was their customer tracking and computer provisioning system. When RightNowWeb stopped working for them, they built the CATS ticketing system on top of that. 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.
- wink 7y agoPoint taken. Rackspace at least seems to be technical enough to be able to put engineers first. :) I've not had so many jobs at product companies, but I've never seen this even when I was doing consulting-type work and came around a bit, and many companies (at least here in Germany) being decades old are simply not digital-first. Maybe the mechanical engineers building the (non-computer) hardware have enough clout, but software is really often not more than a cost factor. I guess the bigger and older the company the more likely that everyone hates internal tooling, and you were focusing on the exceptions, whereas my life was the opposite. Waiting for an internal server just to deploy your shiny new thing could take months.