locked
What do we –really– mean by 'code' (verb)? RRS feed

  • Question

  • Suppose a young member of the developer role in your next project team approaches to you (member of the architect role in the same project) and said: —I will be coding as part of my role in our project and I am looking for further understanding of how my work will be related to actual business value. Could you –as seasoned software professional– please share your insights with me?

    What would be your answer?

    1. Young subordinate: your main task —as a necessary evil— will be mechanical and repetitive because all intellectual and engaging artwork will be exclusively done by me and my peers; please be prepared to eagerly follow our direct commands and to strictly follow our plans, doing whatever required extra effort in order to hit established milestones on time. Your association with business value is that and the same of the cheap labor force in well established economies of scale, that is, the execution of industrialized tasks by expendable and interchangeable human resources. You know, it is the real world and nothing can be done about it. No problem at all, it’s my pleasure to clarify.

    2. Young peer: first of all let me thank you for the opportunity to share my perspective on such an important question of yours; second, let me please clarify that coding is –actually– another name for a design activity which is part of a continuous flux of learning experiences shared by all members of the team. You, along with the rest of project team members, will be doing software design which is a cooperative endeavor to tackle the complexity coming from a number of dimensions like people, process, product and technology; we need all your intellectual power, critical thinking and energy to keep a balanced mix of problem-solving, creativity and tactical execution as the project unfolds. Join us, we are about to review current business priorities with the customer...

    3. Please excuse me but I’m really not the right person to answer your question because I’m not in a position that has exposure to such level of fine-grained details so I don’t know what you are going to be doing and how that is related with business value.

    4. Next possible answer...

    Wednesday, May 7, 2008 5:26 AM

Answers

  • Hi Marco,

       it seems to me that the 2nd option is the most adequate. In overall terms, an architect is a technologist able to align technology with business needs. For that reason, option 3 is naturally discarded (even if the architect is unable to explain what each line of code written by the developer does, in major terms the architect must understand the module where such code is entitled)

       Option 1 is also likely to be avoided is it may have tough consequences in terms of team motivation: I dare to say that, even enjoying the act of coding, most of developers would like to be -some day- promoted. Therefore they need and must know where what they do fits in a broader scale

     

    My 0.02

    Wednesday, May 7, 2008 7:31 AM
  • Hi Marco, my take:

     

    I too with no doubt second your option no 2 (very well put, by the way!). I'd just also give him some reference to some good book on Information/Software Engineering, so that the guy can get the overall picture is some more rigorous terms -- with respect to the "engineering discipline".

     

    -LV

    Wednesday, May 7, 2008 11:07 AM
  •  

     

    I see Number 2 as the best of the answers, or most constructive.

     

    I would answer that the coder, or developer produces the embodiment of the architects vision, which is consisely defined view of a system perceived to provide value to the business.

     

    As a software developer, or coder, you will be making real the thing that in conjuction with the architects you helped conceptualise, and turning it into something that actually makes money.  The fact thatyou are asking this question as a coder means that I should be giving you more involvement in talking with the architects to define that value, and guide the project to a better end product or making more money ultimately.

     

    Cheers,

     

    Martin Platt.

    Thursday, May 8, 2008 6:34 AM

All replies

  • Hi Marco,

       it seems to me that the 2nd option is the most adequate. In overall terms, an architect is a technologist able to align technology with business needs. For that reason, option 3 is naturally discarded (even if the architect is unable to explain what each line of code written by the developer does, in major terms the architect must understand the module where such code is entitled)

       Option 1 is also likely to be avoided is it may have tough consequences in terms of team motivation: I dare to say that, even enjoying the act of coding, most of developers would like to be -some day- promoted. Therefore they need and must know where what they do fits in a broader scale

     

    My 0.02

    Wednesday, May 7, 2008 7:31 AM
  • Hi Marco, my take:

     

    I too with no doubt second your option no 2 (very well put, by the way!). I'd just also give him some reference to some good book on Information/Software Engineering, so that the guy can get the overall picture is some more rigorous terms -- with respect to the "engineering discipline".

     

    -LV

    Wednesday, May 7, 2008 11:07 AM
  •  

     

    I see Number 2 as the best of the answers, or most constructive.

     

    I would answer that the coder, or developer produces the embodiment of the architects vision, which is consisely defined view of a system perceived to provide value to the business.

     

    As a software developer, or coder, you will be making real the thing that in conjuction with the architects you helped conceptualise, and turning it into something that actually makes money.  The fact thatyou are asking this question as a coder means that I should be giving you more involvement in talking with the architects to define that value, and guide the project to a better end product or making more money ultimately.

     

    Cheers,

     

    Martin Platt.

    Thursday, May 8, 2008 6:34 AM
  • Ok, thank you all for the replies so far.

    Now, please assume that you are fully aware the approaching developer is also a senior researcher whose secondary purpose in your project is to report back to general scientific community a current, actual, reliable and justified characterization of the ‘coding’ activity.

    Please re-read the proposed answers and re-think your own answer so far but now with this new perspective in mind.

    Would you change your answer? Which would it be now? Why?

    Thursday, May 8, 2008 11:36 AM
  •  Marco Dorantes wrote:

    Ok, thank you all for the replies so far.

    Now, please assume that you are fully aware the approaching developer is also a senior researcher whose secondary purpose in your project is to report back to general scientific community a current, actual, reliable and justified characterization of the ‘coding’ activity.

    Please re-read the proposed answers and re-think your own answer so far but now with this new perspective in mind.

    Would you change your answer? Which would it be now? Why?

     

    I'm far from sure I get your point there, anyway I'll venture that, in *that* case, not only I would confirm the answer I have already given, but even more convincedly so... That's because I do trust overall engineering principles, practicies and discipline as foundational to software development, and I suppose a "senior researcher" is after the same kind of rigour.

     

    Again, I might be missing your point there.

     

    -LV

    Thursday, May 8, 2008 7:02 PM
  • I also stand by my original answers, the only difference being the one that I created was implying knowledge of what a developer or coder actually does.

     

    Presumably the researcher would also need to spell that out.  The task, then how it is viewed in the context of a project, and business value.

     

    Martin Platt.

     

    Thursday, May 8, 2008 9:37 PM
  • I would pick option 1, only if I want to get fired or revolted out of the project.  Option 3, when I am not knowledgeable to perform the job...

     

    Option 2, is what I believe and practice even if it is a tester approaching me about the scope and the objective of the project.  It is my belief that every resource in the project are adding value to the project (not just mechanical work, in that case I would use some kind of automation tool to perform the mechanical work)...

    Friday, May 9, 2008 2:06 PM
  •  

    Option 1 is really a bad answer, I believe that even "young Members" of the project can give valuable suggestion to more experienced members.

     

    Young subordinate: your main task —as a necessary evil— will be mechanical and repetitive because all intellectual and engaging artwork will be exclusively done by me and my peers;

     

    It is impossible for me to agree with this, if this statement would be true, there is no need for human person in the project, it is better to buy some sort of 4GL tool that will generate the code from artifacts.

     

    This lead to answer number 2, that is surely the best one, even in the second scenario where we deal with the senior researches. Coding is a design activity, and it is fundamental that it is shared among all members of the team.

     

    alk.

    Friday, May 9, 2008 2:55 PM
  • I would simply show this up and coming developer the vision of the architecture in a visual form.  Then point out where in this diagram their code fits in.  I would also explain that there are many moving parts to create the solution and it is up to us to make sure each part is done to the best of their ability.  The architecture is only as stable as the worst-coded component.

     

    This would help the researchers undestand as well.

     

    This would also have been my original answer.

     

    Architecture is not something that can have multiple perspectives - its our job to paint a consistent, integral picture that everyone else understands so they can follow in unison.  If people dont understand the value of what they do in the bigger picture, they tend not to a good job and dont take pride in it.

     

    Monday, May 12, 2008 6:59 PM
  • As others in the forum has expressed their views about different options. IMO the option 2 sounds good and very close to the most appropriate answer. However there is no single approach to it. Personally the way I would like to take this is:

    1. Understand the background of the new team member. His strengths, weaknesses, area of interest etc.
    2. Learn about his expectations from the project.
    3. Align his expectations with the project requirements with the new member.
    4. Make him feel the sense of ownership in the project and also make him realize how his contribution matters in this project. What he can take away from the project and what he can contribute to.
    5. Coding is not just plain typing but it is more than that. It also involves using the right algorithm, proper testing (unit testing), optimizing etc. So the new member must be aware of these expectations as well.

    Cheers

    Samir Kumar Mishra

    Tuesday, May 13, 2008 1:24 AM
  • Still 2 for me, IMO it's the only one that satisfies the mantra of, 'whatever you do must add value to the biz', without the understanding implied in 2 I don't see how you could effectively meet that. As far as the changing role they're still doing the first role so the requirement hasn't changed.


    Tuesday, May 13, 2008 6:20 AM