Will you have an office or other quiet working area? To me this keeps bubbling up to the top of my list. I would rather work on absolute shit as long as I am in a peaceful environment.
Maybe it's just me, but I was under the impression that working on internal tools was one of the best places to be, at least at primarily software-based companies. You're insulated from whatever invariably boring domain your company happens to serve, you have far more range to innovate and try new technologies, you don't have to deal with customers who aren't also developers...
A disproportionate amount of interesting projects I've read about and seen were internal tools of various sorts: compilers, static analysis, testing, verification, building. If I was going to work at a big company like Google or Facebook, I would definitely prefer to be on a tools team.
Also, I think working at a financial company like Jane Street would be great, and that is also an internal sort of job. Really, the company doesn't have any external customers at all. Yet I'd go there over virtually any other standard software engineering sort of job.
Well, I think it also depends on what your company does, too. There's at least a few companies where the internal tools probably aren't nearly as cool as the external product.
For Google or Facebook, I imagine you're right in that the ops teams and the internal tools teams are the most exciting, but the products those companies sell aren't exactly super exciting to me, or at least the features they say they are currently working on don't seem very interesting. Perhaps, that's partially because they are both selling a product that is fairly mature. Ad words, search, gmail, and maps have been around or a long time. Perhaps Google drive or google apps still have a few things up their sleeves, but they are also fairly mature products. Similraly, the main facebook features (not ui) have been relatively stable (exceptions that i can think of: likes, timeline, graph).
OTOH, Apple has products at almost the other end of the spectrum (exceptions: the mac pro and ipod classic). On the hardware side, it seems like they are constantly iterating and updating macbook, imac, iphone, and ipad designs. And while I don't like what they've been doing by merging OSX and IOS over the last few iterations, I can hardly say that what they've been doing hasn't at least been innovative. I'd be very surprised if apple had any sort of internal tool that was as interesting to work on as some of the things I just mentioned.
For technology startups like nicera or meraki or arista, I bet most of the interesting work isn't related to internal tools as well, just because I doubt a startup has resources to build very interesting internal tools when they could just deal with what already exists and spend the resources they would have spent rolling their own version on improving the product.
Ultimately, I think the type of product the company sells and how mature their product is (the number of major features left to implement seems like it might be a good rough heuristic) matters quite a bit in determining in whether the internal tools are better than the product in terms of being interesting.
Apple - LLVM, Clang, and that whole ecosystem is pretty sweet to be involved in now. Wouldn't say it's 2nd rate.
Nicera - From working in Open vSwitch code for a while now, it's very clear that there were talented software engineers with a purpose to build something very real that solved a very real problem... I guess that is the basis of a 'product'.
Product wasn't the perfect word to use. I just meant something intended for outside use, as opposed to tools not designed to ever be released, like many internal tools are. I'd even say that the tools you mentioned are more of an external product than an internal tool; eg the whole clang/llvm ecosystem is more of a "product" than an internal tool since apple began using it as part of their iOS sdk.
It's not just you, I thought the same thing while reading the article.
It may be a different thing if you're working on a profit center vs on a cost center I guess. If your clients are outsourcing their software needs to you (so, basically, you are in a cost center), the focus is on reducing the costs of production: you want to deliver as cheaply as possible, no need to innovate. Usually what happens in this situation is that the average joes end up taking the job of building the (boring) product while the best guys build tools to automate the job of the joes, reducing costs in order to increase the profit margin. The innovative work end up in the hand of the tool builders.
However, if you work on a profit center, innovation is the core of the job; the meat is on the external product, and the tool builders just need to automate the boring parts (doing the job the other guys don't want to do.)
That blog is a gem. At least for me as a student. One item that I found particular fascinating is this:
in [1] he quotes: Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run (Fact 37)
How to implement this in a loosely organized group of 3 to 4 developers that each have other projects on their schedule but work on some common projects? I'm eager to write a long email to them explaining that we should do a "talk about your code hour" but I can also see the problems with such a approach. Shame, Ego, "no time for this shit", poorly spewed out presentations... are there patterns? or are pattern yet another problem layer?
God is just. The world is just. Are you calling Him lazy?
If you talk your way into being over your head, you're gonna have a bad time.
Marriage between equals is best. In other words, if your salary is too high, they will never let you forget it. If it's too low, you will own them.
God is just -- more money, more stress, usually. Your work will suck -- doing it.
Pride before a fall and humility before honors applies on a big time scale. If you take a shitty job for a year, God will reward you with an exaulted job for a year.
God says...
C:\Text\2CITIES.TXT
sea; but, still the deep ditch, and the
single drawbridge, and the massive stone walls, and the eight great
towers, and still Defarge of the wine-shop at his gun, grown doubly
hot by the service of Four fierce hours.
A white flag from within the fortress, and a parley--this dimly
perceptible through the raging storm, nothing audible in it--suddenly
the sea rose immeasurably wider and higher, and swept Defarge of the
wine-shop over the lowered drawbridge, past the massive stone outer
walls, in am
9 comments
[ 3.1 ms ] story [ 30.1 ms ] threadA disproportionate amount of interesting projects I've read about and seen were internal tools of various sorts: compilers, static analysis, testing, verification, building. If I was going to work at a big company like Google or Facebook, I would definitely prefer to be on a tools team.
Also, I think working at a financial company like Jane Street would be great, and that is also an internal sort of job. Really, the company doesn't have any external customers at all. Yet I'd go there over virtually any other standard software engineering sort of job.
For Google or Facebook, I imagine you're right in that the ops teams and the internal tools teams are the most exciting, but the products those companies sell aren't exactly super exciting to me, or at least the features they say they are currently working on don't seem very interesting. Perhaps, that's partially because they are both selling a product that is fairly mature. Ad words, search, gmail, and maps have been around or a long time. Perhaps Google drive or google apps still have a few things up their sleeves, but they are also fairly mature products. Similraly, the main facebook features (not ui) have been relatively stable (exceptions that i can think of: likes, timeline, graph).
OTOH, Apple has products at almost the other end of the spectrum (exceptions: the mac pro and ipod classic). On the hardware side, it seems like they are constantly iterating and updating macbook, imac, iphone, and ipad designs. And while I don't like what they've been doing by merging OSX and IOS over the last few iterations, I can hardly say that what they've been doing hasn't at least been innovative. I'd be very surprised if apple had any sort of internal tool that was as interesting to work on as some of the things I just mentioned.
For technology startups like nicera or meraki or arista, I bet most of the interesting work isn't related to internal tools as well, just because I doubt a startup has resources to build very interesting internal tools when they could just deal with what already exists and spend the resources they would have spent rolling their own version on improving the product.
Ultimately, I think the type of product the company sells and how mature their product is (the number of major features left to implement seems like it might be a good rough heuristic) matters quite a bit in determining in whether the internal tools are better than the product in terms of being interesting.
Nicera - From working in Open vSwitch code for a while now, it's very clear that there were talented software engineers with a purpose to build something very real that solved a very real problem... I guess that is the basis of a 'product'.
Arista - FPGA in your switch? Sweet!
It may be a different thing if you're working on a profit center vs on a cost center I guess. If your clients are outsourcing their software needs to you (so, basically, you are in a cost center), the focus is on reducing the costs of production: you want to deliver as cheaply as possible, no need to innovate. Usually what happens in this situation is that the average joes end up taking the job of building the (boring) product while the best guys build tools to automate the job of the joes, reducing costs in order to increase the profit margin. The innovative work end up in the hand of the tool builders.
However, if you work on a profit center, innovation is the core of the job; the meat is on the external product, and the tool builders just need to automate the boring parts (doing the job the other guys don't want to do.)
in [1] he quotes: Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run (Fact 37)
How to implement this in a loosely organized group of 3 to 4 developers that each have other projects on their schedule but work on some common projects? I'm eager to write a long email to them explaining that we should do a "talk about your code hour" but I can also see the problems with such a approach. Shame, Ego, "no time for this shit", poorly spewed out presentations... are there patterns? or are pattern yet another problem layer?
(sorry for hijacking this thread)
1: http://blog.davidtate.org/2011/12/5-minute-book-review-facts...
Internal/external/customers/shmustomers - it is all secondary.
Nervous, always-over-the-budget, unrealistically deadlined environment kills all traces of creativity and joy.
Well-funded, peaceful, intelligent and happy environment makes for the best lifetime experiences to learn, create and deliver.
If you talk your way into being over your head, you're gonna have a bad time.
Marriage between equals is best. In other words, if your salary is too high, they will never let you forget it. If it's too low, you will own them.
God is just -- more money, more stress, usually. Your work will suck -- doing it.
Pride before a fall and humility before honors applies on a big time scale. If you take a shitty job for a year, God will reward you with an exaulted job for a year.
God says... C:\Text\2CITIES.TXT
sea; but, still the deep ditch, and the single drawbridge, and the massive stone walls, and the eight great towers, and still Defarge of the wine-shop at his gun, grown doubly hot by the service of Four fierce hours.
A white flag from within the fortress, and a parley--this dimly perceptible through the raging storm, nothing audible in it--suddenly the sea rose immeasurably wider and higher, and swept Defarge of the wine-shop over the lowered drawbridge, past the massive stone outer walls, in am