If I submit this "first draft code" instead of a spec, will the programmer like it or hate it?

I am a factory employee who's done just a little programming. I want to suggest that our computer shift reports do a couple calculations for us so I don't have to punch them into a calculator several times a day. Rather than just saying "I would like the computer to take the net net weight and tare weight I entered elsewhere and tell me the gross weight", I would like to submit some code or pseudocode with my suggestion:

function calculategross () {
    int gross = fldshf_skidnet + fldshf_tare;  
    //use fldshf_skidnet, not fldshf_net in case of multiple rolls per skid.
    }

Since I know exactly which calculations I need done and which variables are available in the database table, pseudocode could save the application programmer a lot of thought. It should make my suggestion look more viable as well, and writing new code is just fun. But a real programmer might rather have a detailed spec or something without my opinion on the technical features. If a manager asked you to code something and submitted some non-compiling "code", would you say "hey, good roadmap" or "geez, get a clue"?

Background: The shift report is a tabbed form view of a database table, made in Alpha V5. So you have a front end that looks somewhat like the first result here, and if you hit F8 you are looking at the underlying table in the database. (This is how I know all the variable na开发者_如何学Cmes.) My calculator page would be on its own tab. Some of the data it uses will be user-entered in other tabs, some on the page itself.

Here's some of the "first draft code" I'm considering. The interface stuff that I'm shakier on is near the top, some of the calculator functions are at the bottom.

Button GetDataButton = new Button();
GetDataButton.onclick() = UpdateAllUneditedVariables() {
    //Populate all fields on this tab with data entered elsewhere 
    //Don't update fields the user changed on this page.
    //I didn't actually write this function, I'm just describing it.
    }

Button CalculateAll = new Button();
CalculateAll.onclick() {
    FillEmptyFieldsWithDefaultValues();
    CallAllCalculatorFunctions();
    DisplayAllCalculationResults();
    }

sub CallAllCalculatorFunctions() {
    CalculateGross();
    CalculateAverage();
    CalculateNetPoundsPerHour();
    //I feel like this is a non-programmer way to structure this...
    }


//Here's a couple of the mathier functions -- not that hard, but complicated 
//enough that I'd rather not have the programmer have to think through them.

function SkidsPerJob () {
    //How many skids must we divide this job into based on weight limits?
    int max_by_weight = ceil (fldshf_total_lbs / max_lbs_skid);

    //How many based on height limits?
    float total_height = fldshf_gauge * fldshf_total_sheets;
    int max_by_height = ceil(total_height / max_height / stacks_per_skid);

    int total_skids = max (max_by_weight, max_by_height);
    }

function CalculateNetPoundsPerHour () {
    int netpph = sheet_weight / sheet_length * feet_per_minute * 12 * 60;
    if (number_of_webs > 1) {netpph *= number_of_webs;
    }

If you don't think this is good, would you recommend just refreshing my coding ability by brushing up on Microsoft Access forms? (I have made them before, with dropdowns and everything, just not recently.) Get an editor from Scriptlance to fix naming conventions and coding errors? Or should I just concentrate on the look of the page and describing the functions I need and not try to design it myself?

When writing a specification, you have to express what you want in a language that both you and the developer understands. I think it is a good idea to make use of your programming experience and express the business logic in a programming-like language. I wouldn't bother with coding errors or naming conventions: It is more important that you get the naming right (from a domain perspective) than syntactical correctness.

Don't spend too much time on this, though. Focus on the things that are unique to your domain.

In the agile world you would tend to avoid trying to spec everything up front, accepting that this is nigh on impossible, and instead allow the design to evolve through continual prototyping and interaction with the developer (see Scrum or DSDM for example).

My advice is to focus on the business requirements and allow the developer to decide exactly how best to implement them, that's his job and he will know how to do it better than you. Doubtless he will also have things like coding standards and existing libraries of code he may want to re-use. You should be primarily concerned with working closely with him to ensure that he understands your requirements (I would advise you to break them up into small, discrete 'chunks') so that what he produces addresses your needs and there are no surprises come delivery day.

As others have already said (Anders Lindahl & Simon), you should be focusing on making sure the programmer understands your business requirements.

As a progammer, I'd rather see the spec as a screeen diagram, with descriptions of what each button (or other active control) does, than screen-creation pseudocode. However, I see nothing wrong with specifying the calculations in pseudocode, particularly if they're tricky. If the order of operations is critical (either from a user perspecitve or a "this value depends on that calculation" one), I'd also welcome high-level English-like pseudocode to specify the crucial bits.