jrtipton

Lathrop, CA; Full time, remote okay; some travel

(Posting for someone else -- please see the contact info at the end. Thank you!)

Power Automation Systems (PAS) builds large scale customized material handling systems, which is a fancy way of saying highly automatic warehouses. Think "reinventing the way things are done in an industry where everything was 'solved' already" and you're on the right track. PAS is looking for a skilled automation engineer.

The automation engineer (AE) will design, develop, configure, and implement complex control strategies and applications & integrate them with existing systems at our customer’s facilities. The AE reports to the Director of Automation, which is to say the person would have a high degree of responsibility.

We're especially looking for someone who knows how to communicate and build a team. If you're experienced at coaching and mentoring, that's a huge plus too. Since we help customers all over the world, there will be some travel involved.

If you are interested in making things move -- and are familiar with databases like SQL Server; experienced with PLC; field IO devices; and ERP or WMS -- please get in touch with us.

This is an extremely interesting industry in which the right software leader could really a lasting change for the better.

Contact mike.terrill@pas-us.com for more. We're looking forward to it.

I work in Windows file systems for a living. We very much live with two models: exception handling and canonical return codes. I cannot tell you how many times I would have killed for Lisp-like conditions. If I were to tell you that, however, I would also have to tell you that most of the killing would have been in vain.

The trouble with the never-ending "try-catch versus conditions versus return codes versus fail-fast" argument is that there is no easy way to have the conversation about big swaths of code. The log parser is a great example, yes, but it is exceedingly simple. The fact is that 'low' in the linked example is exposing its guts to 'high' whether it likes it or not, and that in any reasonably large body of code this too can become unmanageable.

Wherever you see a religious war, your Spidey sense should be tingling, telling you: people are arguing over which tool is better for all jobs when in fact you might want to learn all of the tools and choose the best whenever possible. And that you will at times show up to a job site where they're using the wrong tool and you'll have to learn to change them or live with it -- whichever makes more sense/is more possible.

That said, sometimes consistency just wins out. A module that throws to a module that returns is always baffling, but if it's hiding this fact from the rest of the module -- or many more modules -- then it's worth it.

(edited to note that these are Windows file systems, hoping to avoid 'is that really so')