Re: On accounting and engineering.(Slightly offtopic)

[Mark Johnson <mark_h_johnson@raytheon.com>]

Caffeine Junky wrote:
> 
> [snip - background info]
> Hence we came up with a possible solution to the language wall(at least
> as far as software development is concerned.) As part of orientation for
> a company(in the tech field, but possibly other fields as well) have the
> engineers take a couple short introductory courses on accounting, so as
> to give the engineers a tool for effectively communicating with the bean
> counters, and likewise give the bean counters a couple short introductory
> courses on programming and software engineering, to reciprocate the tool.
I used to work with a group that generally did the following...
 - the first few years, a developer is given daily direction by a lead
person, gradually doing more and more complex systems. Would help to
status schedules, explain accomplishments, problems, etc.
 - at about three to five years, starts to get the responsibility of
making those plans, generating estimates, and so on. Still working
closely with a lead person, but begins to learn the lingo as part of
their regular work.
So that when they become a "lead person", they have the basic planning
and financial background that they need to lead a project (or part of a
project). It doesn't have to be a formal training session as long as you
have the right framework in place to train people as they move up in the
organization. However, I did attend a good "Management Course" which was
50/50 management techniques and "how the facility worked". The second
half did a lot to improve my insight into how the other departments
worked.

> I've recently picked up several books on accounting, and it's giving a
> much better picture of how to pitch myself to the bean counters. Likewise
> my pal in accounting has begun reading some introductory books on
> programming and software engineering, and has a much better idea of why
> the engineers make pitches that before sounded completely irrational to
> him.(Stuff like purchasing rackmount servers rather than beige case
> systems, and when to/when not to do in house development.)
> 
That is of general benefit anyway. A good software developer has insight
into more than just "Software Engineering" but on how their products are
used (e.g., software, plans, presentations). Walking a mile in the shoes
of another goes a long way to making that happen (and explains why
rotating staff through an organization to different positions makes for
stronger staff).

  --Mark