The Business of Software

I've heard the argument before, and I have to agree that working in an industrial/manufacturing company could sound like an "ordinary" life for a developer. IMO this should not carry the impression of an experience-less time (for the lack of better words). As a matter of fact, one of the key drivers to my love for S/W development is that I experience how the it could shape up the manufacturing one. I also, on a daily basis, HAVE TO deal with the good, bad, failed, unrecognized implementations.

With this in mind, It's impossible to deny the gains:
* Immersed in user experiences
* Valuing the agility
* Domain knowledge
* People skills (level of expertise, cultures).
* Continuous S/W Improvements.

Unfortunately, I only came across few (in fact one) who shared similar experiences during their careers ( http://dev.mysql.com/tech-resources/interviews/mike-zinner.html ). So, If you've worked/been working in an industrial/manufacturing environment, I'd really appreciate hearing from you.

[Originally posted on my blog with modifications]

I have worked for a manufacturing company for the last 8 years.  It's where most of my software skills have come from.

"Manufacturing" encompasses a wide spectrum. I don't think it would be meaningful to characterize it without being more specific about the type of operation. And then, you would be to be specific about the role within such an organization.

For example, there's obviously a huge difference between working for a 10-man plating company and working for Intel. Moreover, within a comapny like Intel, the roles are as diverse as you you see across the entire spectrum of software jobs in the market.

But, with all that said, I still think the domain knowledge is very valuable. Techies may be surprised, I have see some remarkably successful companies that are woefully behind on the tech front.

I ran into a friend yesterday who now heads the engineering division for one of the top high-end throttle manufacturers in the world. They are a completely hardcopy shop - no electronic document control, no PDM for their CAD.

Companies like this are more common than you might think. Consequently, I think there are still plenty of opportunities there.

I think the concern would be: Are they a software manufacturing company (software is a profit center), or is software incidental to their main business of manufacturing something else (iow: software is a cost center).

I cut my teeth as a developer working for a small manufacturing company. It was the perfect size -- big enough to have cash flow and small enough to still be personal.

I loved the fact that I was part of the American industrial complex. We made parts for General Dynamics Land Systems and other defense contractors. I always felt that the software I wrote powered one small cog in the American machine. I liked that feeling.

On the other hand, I worked in a factory. There was constant noise. There were no other "knowledge workers." I reported to the 'office manager' whi knew my job had something to do with computers. I was called whenever something broke with blinking lights on it. What the f**k do I know about an LCD Sign?

All in all, i rate the job in the lower 50% of my past employers. But at the time, it was the best job I'd ever had and it gave me the skills I needed later on.

I managed the IT department at a plastics manufacturer for five years, and was lead developer with three devs beneath me and one sysadmin.

Much like the OP said:  the distance between you and your customers is negligible; instant feedback on quality and user experience; incremental improvements; seeing the effect of your software up close and personal.

To that I'd add: none of the ego problems a software shop has.  No marketing or salesperson telling me what they can sell.  No prima donnas writing a holy book of code.  No 'visionaries' waving their hands about.  Just straightforward coding, and no one there to tell me otherwise, so I could set high dev standards and practices as long as my contribution to the company was worth it in a business sense.

Like another poster said, though:  noise, interruptions, meetings with non-technical people to do with the business.  Just not as insulated as a dev in a software shop.

Worth the trade-off, IMHO.

I would also add that the experience was extremely valuable in terms of being aware of how a non-tech business actually ran.  "Should we allow NULLs in that field?"  "Good question: Go ask Sue in Accounts Payable if the invoice always has that populated."  A lot of design questions could be resolved by looking immediately at the actual practice.

There's also something to be said for being able to code to a set of specific cases, rather than a general case that you *think* applies.

I started out of college working as a developer/supervisor for developing software to run test equipment at a wafer fab.  We made logic chips and other types. 

Being in the systems group, we had to work over the holidays and whenever the plant was shutdown to impact production as little as possible.

It definately was a different type of attitude there.  One hour of down time was $1 million of lost productivity.  Routines needed to be optimized down the the msec to make sure they could test more and more chips a year.  That one plant producted over 2 billions chips per year when I had left. 

I was on 24/7 call and had to be able to get in to the plant to fix things ASAP if needed.  When I had started there the technician that worked for me was coming in off hours 1-2 times a week.  When I left 7 years later I had to come in or even get called about once every 2 months.  And most of the time things could wait until morning.

I find it very hard to find others that have had that kind of experience too.  It makes sitting here doing web pages at work and my uISV at home seem tame and downright boring at times.

I learned a lot, but the environment was crappy. I never knew when I would be screamed at by some borderline psychopath production manager because of having the bad fortune to be meeting with him on a bad production day. And the feast or famine cycle of capital improvements budgets (which funded the projects I was working on) wasn't much fun either. Oh, and the hearing loss.

I'd agree with Mediocre Coder.

At one point in my career, I worked for the Jet Propulsion Laboratory.  There, I very quickly learned how to tell the difference between things that have to be very precisely specified, and things that you could sort of just narrow down as you went along until it was "good enough".

Being able to do so gives you a very healthy perspective on what work really is crucial, and what can (or should) wait til the next morning.  The reason I'm mentioning this is because most people in manufactoring/craft have the same viewpoint, whereas most "pure managers" tend to equate the importance of the problem with the importance of the customer - problems get exaggerated or minimized based on how loud people are yelling.