

Key points to look for in your next job if you are a developer - okuc
http://blog.davidtate.org/2010/08/key-points-to-look-for-in-your-next-job-if-you-are-a-developer/

======
tikhonj
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.

~~~
joshAg
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.

~~~
brooksbp
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'.

Arista - FPGA in your switch? Sweet!

~~~
joshAg
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.

------
gesman
Nothing beats well-funded, happy environment.

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.

------
nisa
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?

(sorry for hijacking this thread)

1: [http://blog.davidtate.org/2011/12/5-minute-book-review-
facts...](http://blog.davidtate.org/2011/12/5-minute-book-review-facts-and-
fallacies-of-software-engineering/)

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

