Enthought Home
About Enthought

What Kind of Developer Fits at Enthought?

The typical developer at Enthought chose to pursue a science or math degree in school, but was strongly tempted by the CS route. In the end, having programmed in their spare time during high-school, they figured they could pick up the CS on the side more easily than the physics, math, and engineering. This is not the only route to becoming a fluent scientific software developer, but it is a common one.

A scientist will thrive at Enthought if their passion for software is as deep and ingrained as their scientific interests.

Many people talk about building scientific applications (seismic processing, financial modeling, fluid dynamics simulators, astronomy tools,... ) by having a computer scientist sit with an engineer to work out the correct design. We fundamentally don't think it possible to obtain a quality product by handing off a description to a "developer" who has little domain understanding. The developer must have the chops to grok the purpose of the end application and function as an end user well enough to make the appropriate trade-offs throughout the development process.

If you've only read a book on algorithms (Newton-Raphson, FFT, etc.), but never picked one up on data structures or software design principles, that is a concern. If you haven't enjoyed writing multiple user interfaces or thought deeply about the visual interactions that best fit a data set, then we're probably not "hand meets glove" for you. Enthought developers use their scientific backgrounds to understand what needs to be built and their software architectural skills to ensure it is built in a scalable, extensible, and maintainable way.

A computer scientist with a strong love and understanding of science is likely a good fit as well. In fact, because we have fewer of these people, a background in development can be a very important skill set. We even have a sneaking suspicion that developers who have spent a lot of time in the game industry could be a good fit.

The day-to-day at Enthought revolves around making high quality architectural decisions about how we structure client projects so that they are extensible and maintainable — UI frameworks that simplify building "pluggable" applications, display libraries for highly interactive visualizations, and domain-specific scientific tools that are comfortable for specialists to live in and flexible enough for them to mold around their ever-changing jobs. It rarely, if ever, centers on squeezing 10% more out of some signal processing algorithm.

Enthought may be the place for you:

  • If your science fair project looked like something out of Myth Busters. If you made a styrofoam model of our solar system, not so much...
  • If you spent four hours programming the voltage generators and oscilloscopes for physics or engineering labs to automate data aquisition that could be taken by hand in one hour. ("But look! I can run the entire experiment in three minutes now!" Your teacher may not have been impressed, but we are.)
  • If you couldn't wait to finish your homework to work on your own OpenGL graphing library, score one. If you coded Bresenham's algorithm in assembly, score another. If you've written a Fibonacci number generator in Postscript, bully for you.
  • If you find DeMorgan's Law surprisingly cool, remember that a 7400 logic chip is a NAND gate, bread-boarded a digital clock driven by a 555 timer, and joyously wrote microcode for your chip design that you coded in C++ or Python. If you wrote a UI that plots out the timing diagrams for your chip simulator, it's an extremely good sign. If you want to re-write the thing because the code was too messy and you thought of a better software architecture, please be sure to send your resume.
  • If you wish you were a better welder. It is also promising if you have Digi-Circuits, Mini-Circuits, and Grainger catalogs on your nightstand.
  • If you know what NoSQL is, installed several different ones just to experiment with them, and are wondering how to fit one into your next project just to see how it wears in a real project, bueno. If the same goes for LLVM, muy bueno.
  • If you've spent more than four hours adamantly arguing that Git (or Mecurial, or Bazaar, or... whatever) is vastly superior to SVN, you would certainly fit in...
  • If you have a watch that reads out in binary (seriously...), then, well, we're not so sure about this one.

Thriving at Enthought really depends on whether you have a life-long curiosity about how all things work — cells, transitors, gears, black holes, and brains,... This curiosity is coupled with an inescapable urge to write computer simulations of these things and visualize how they function.

If you've played with Erlang to see what all the fuss is about, good. If you've ever answered that your favorite language is Lisp or Haskell, pat yourself on your back. Now, please come use Python.