Coding skills

Discussion in 'C Programming' started by sophia.agnes@gmail.com, Feb 17, 2008.

  1. Guest

    Dear all,

    I have heard many arguments from s/w engineers(doing appln
    programming) having 2-4 years of experience that

    1) There is not much deal in coding, anyone can do it, as lots of
    source code are available in the net

    2) coding only amounts to 30% of the project

    3) it is all about designing the project done by project lead /
    project manager

    4) some even say that computer programming doesn't have much
    scientific basis although mathematically it may have some basis

    Is there any truth in above statements ?

    OR

    why coding skills are not given much importance ?
     
    , Feb 17, 2008
    #1
    1. Advertising

  2. said:

    > Dear all,
    >
    > I have heard many arguments from s/w engineers(doing appln
    > programming) having 2-4 years of experience that
    >
    > 1) There is not much deal in coding, anyone can do it, as lots of
    > source code are available in the net


    This is true. And of course anyone can paint a picture. All you need is a
    subject, a brush, some paint, a canvas, an easel, and a place to stand.

    So - if programming doesn't work out for you, just dash off a few quick
    6'x8's and sell them to the Louvre for a million each.


    > 2) coding only amounts to 30% of the project


    Latest figures show that it's actually 29.04%. Adjust your spreadsheet
    accordingly.

    > why coding skills are not given much importance ?


    Most managers don't attribute a great deal of importance to coding skills
    for two reasons:

    1) they don't really know what good coding is all about;
    2) they don't really get a chance to find out. (Many, if not most,
    programmers aren't actually all that good at programming.)

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Feb 17, 2008
    #2
    1. Advertising

  3. <> wrote in message news:
    > I have heard many arguments from s/w engineers(doing appln
    > programming) having 2-4 years of experience that
    >
    > 1) There is not much deal in coding, anyone can do it, as lots of
    > source code are available in the net
    >
    > 2) coding only amounts to 30% of the project
    >
    > 3) it is all about designing the project done by project lead /
    > project manager
    >
    > 4) some even say that computer programming doesn't have much
    > scientific basis although mathematically it may have some basis
    >
    > Is there any truth in above statements ?
    >
    > OR
    >
    > why coding skills are not given much importance ?
    >

    If you've got a full and accurate specification for the typical business
    application which does nothing more challenging than access and
    already-written database engine, put some windows up on screen, and do a few
    trivial calculations, then converting the spec to code is indeed a
    brain-dead job.

    In practise it is easier to write the specification in code and cut out the
    programmer entirely. When you come to reduce a specification to code, you'll
    usually find that it doesn't work. So actually you need some very skilled
    people on the programming team.

    However managers who are not programmers themselves will constantly look for
    ways to reduce the status and salaries of programmers, just as for any other
    group of people they employ. This is human nature. Programmers are
    especially vulnerable because there is no professional body.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Feb 17, 2008
    #3
  4. Malcolm McLean said:

    <snip>

    > If you've got a full and accurate specification


    Ha! :)

    > for the typical business
    > application which does nothing more challenging than access and
    > already-written database engine, put some windows up on screen, and do a
    > few trivial calculations, then converting the spec to code is indeed a
    > brain-dead job.


    Converting it correctly and robustly is rather less easy.

    > In practise it is easier to write the specification in code and cut out
    > the programmer entirely.


    At which point, the manager /is/ the programmer. At this point, he should
    either fire himself (because programmers are not required), or hire a
    programmer (because he has just discovered that they *are* required, and
    he ought to have other things to do with his time).

    > When you come to reduce a specification to code,
    > you'll usually find that it doesn't work. So actually you need some very
    > skilled people on the programming team.


    But you just fired them all, because you thought you could do it yourself.
    So now you have to re-hire them.

    Hiring the right people is costly enough at the best of times. (Of course,
    hiring the wrong people is dead easy and dirt cheap, so most managers will
    settle for this.)

    >
    > However managers who are not programmers themselves will constantly look
    > for ways to reduce the status and salaries of programmers, just as for
    > any other group of people they employ. This is human nature. Programmers
    > are especially vulnerable because there is no professional body.


    Actually, I think the vulnerability of (good) programmers comes from
    several areas:

    1) because software is easy to edit, it is easy to take credit for
    something you didn't do;
    2) consequently, it is easy to lose credit for something you did do [*];
    3) there is little visual difference at runtime between a mediocre program
    and a well-crafted program, and few shops track bugs accurately;
    4) good programmers do have an appalling habit of being truthful (which,
    among other things, makes it harder to get interviewed in the first
    place);
    5) managers tend to confuse "exposure to a tool" with "skilled user of a
    tool"; they also confuse "has used many tools" with "is a red-hot
    programmer". So anyone with 10 years of .Net is obviously a really good
    ..Net programmer (no matter how many bugs he has coded but never spotted),
    and never mind that it only went live about five years ago.


    [*] This (credit-stealing) has happened to me once or twice, and on one
    occasion nearly cost me a contract. Had it actually done so, I would
    almost certainly have ended up suing a major software consultancy company
    - and winning several hundred thousand pounds off them.

    (For the record, I have never sued anyone, and I didn't *want* to sue these
    folks either - and in the end, I didn't have to, so all's well that ends
    well.)

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Feb 17, 2008
    #4
  5. "Richard Heathfield" <> schreef in bericht
    news:...

    > Actually, I think the vulnerability of (good) programmers comes from
    > several areas:
    >
    > 4) good programmers do have an appalling habit of being truthful (which,
    > among other things, makes it harder to get interviewed in the first
    > place);


    What do you mean by this?
     
    Serve Laurijssen, Feb 17, 2008
    #5
  6. "Richard Heathfield" <> schreef in bericht
    news:...
    > 5) managers tend to confuse "exposure to a tool" with "skilled user of a
    > tool"; they also confuse "has used many tools" with "is a red-hot
    > programmer". So anyone with 10 years of .Net is obviously a really good
    > .Net programmer (no matter how many bugs he has coded but never spotted),
    > and never mind that it only went live about five years ago.


    I dont know if you can spot a good or bad programmer by the number of bugs
    they create or dont create.
    I mean, somebody who creates lots of code introduces more bugs than somebody
    who doesnt
     
    Serve Laurijssen, Feb 17, 2008
    #6
  7. Morris Dovey Guest

    Serve Laurijssen wrote:

    > I mean, somebody who creates lots of code introduces more bugs than somebody
    > who doesnt


    For some somebodies, but not for others. :-D

    --
    Morris Dovey
    DeSoto Solar
    DeSoto, Iowa USA
    http://www.iedu.com/DeSoto
     
    Morris Dovey, Feb 17, 2008
    #7
  8. Serve Laurijssen said:

    >
    > "Richard Heathfield" <> schreef in bericht
    > news:...
    >
    >> Actually, I think the vulnerability of (good) programmers comes from
    >> several areas:
    >>
    >> 4) good programmers do have an appalling habit of being truthful (which,
    >> among other things, makes it harder to get interviewed in the first
    >> place);

    >
    > What do you mean by this?


    They don't tell lies on their CVs. If anything, they tend to understate
    their skill level, because they don't want to create unrealistic
    expectations. And they tend not even to mention technologies with which
    they have a nodding acquaintance - despite the likelihood that they are
    more able to use those technologies effectively than the people already
    being employed by the interviewer's organisation.

    I've seen this a few times in Real Life. Searching such people out at
    interview can be difficult, but is invariably rewarding if done
    successfully.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Feb 17, 2008
    #8
  9. Serve Laurijssen said:

    >
    > "Richard Heathfield" <> schreef in bericht
    > news:...
    >> 5) managers tend to confuse "exposure to a tool" with "skilled user of a
    >> tool"; they also confuse "has used many tools" with "is a red-hot
    >> programmer". So anyone with 10 years of .Net is obviously a really good
    >> .Net programmer (no matter how many bugs he has coded but never
    >> spotted), and never mind that it only went live about five years ago.

    >
    > I dont know if you can spot a good or bad programmer by the number of
    > bugs they create or dont create.


    Yes, I was truncating a large idea into but a few words, and I know that I
    oversimplified.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Feb 17, 2008
    #9
  10. "Richard Heathfield" <> schreef in bericht
    news:...
    > They don't tell lies on their CVs. If anything, they tend to understate
    > their skill level, because they don't want to create unrealistic
    > expectations. And they tend not even to mention technologies with which
    > they have a nodding acquaintance - despite the likelihood that they are
    > more able to use those technologies effectively than the people already
    > being employed by the interviewer's organisation.
    >
    > I've seen this a few times in Real Life. Searching such people out at
    > interview can be difficult, but is invariably rewarding if done
    > successfully.


    Sounds familiar yes. I remember telling in an interview how I created
    applications in ASP, which meant using VBScript to call C++ COM components
    which were wrapper classes around a C library. The ASP scripts retrieved XML
    from those components and were transformed into HTML with embedded
    javascript with XSL. I had to maintain the C++ and C code too when bugs were
    found. But at the time I told him this I noticed he didnt believe I could
    keep apart all those techniques (its really not so hard to do as fellow
    programmers will know although it does require lots of study time) so I
    immediately decided to put something in later that I wasnt that good. Stupid
    now I think about it! I wasnt hired, their loss :)
     
    Serve Laurijssen, Feb 17, 2008
    #10
  11. Flash Gordon Guest

    Malcolm McLean wrote, On 17/02/08 10:32:

    <snip>

    > any other group of people they employ. This is human nature. Programmers
    > are especially vulnerable because there is no professional body.


    Apart from the BCS in the country in which you live if you want a
    professional body dedicated to IT or the IET if you want a larger body
    which does not specialise in IT but does accept it as a discipline. Of
    course, if you don't count bodies that can grant Chartered Engineer
    status...

    I will admit that the BCS is fairly new, after all it was only
    established in 1957...
    --
    Flash Gordon
     
    Flash Gordon, Feb 17, 2008
    #11
  12. "Flash Gordon" <> wrote in message
    news:-gordon.me.uk...
    > Malcolm McLean wrote, On 17/02/08 10:32:
    >
    > <snip>
    >
    >> any other group of people they employ. This is human nature. Programmers
    >> are especially vulnerable because there is no professional body.

    >
    > Apart from the BCS in the country in which you live if you want a
    > professional body dedicated to IT or the IET if you want a larger body
    > which does not specialise in IT but does accept it as a discipline. Of
    > course, if you don't count bodies that can grant Chartered Engineer
    > status...
    >
    > I will admit that the BCS is fairly new, after all it was only established
    > in 1957...
    >

    I'm not a member of the British Computer Society, and this is typical.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
     
    Malcolm McLean, Feb 17, 2008
    #12
  13. [snips]

    On Sat, 16 Feb 2008 23:49:16 -0800, sophia.agnes wrote:

    > OR
    >
    > why coding skills are not given much importance ?


    Mostly, IMO, because few are competent to judge it. In an example from
    work, just this past week:

    We've got a monitoring system which involves two chunks of code running
    on two different machines and four databases. The data needs to be
    recorded to one DB, mirrored to another, then massaged and delivered, in
    processed form, to two more.

    The design requirements are pretty simple, and the code was designed to
    handle outages - cases where the DB didn't respond, that sort of thing.
    In essence, every problem the code would run into in the real world, from
    power outages to accidental database wipes, was dealt with.

    So what happens? They want a test, which we do by "injecting" two years'
    worth of "virtual" records. So far so good, but then they do it again,
    using slightly different data, and everything breaks - the databases get
    completely hosed, the reports are junk, we're seeing reports of days with
    48 hours in 'em, that sort of thing.

    Their conclusion? Something's broken. Proper conclusion: if you
    invalidate the contract against which the code was designed, things are
    going to break.

    This is the same sort of thing as designing an above-ground parking
    garage, where each level is basically just flat concrete with painted
    stalls on it, then, after it's built, adding on planters and sidewalks
    and those cement "stall bumpers". When you add all that extra weight,
    when you violate the design contract, what do you expect to happen? You
    expect the garage to collapse from all the additional weight.

    Yet when it comes to code, for some reason the world works by magic. We
    did some testing, things broke, obviously the system is fragile, poorly
    designed. No, it's not, it's very well designed, it's just not designed
    to handle poking fingers, any more than it's designed to keep working if
    you uninstall the underlying OS.

    The really sad part is, I'm seeing this sort of thinking from technically
    skilled people who, even if they don't understand the code, should at
    least understand the underlying principles, yet here they are, whining
    that it's too fragile.

    Yet these are the people who, at least here, would be the ones to decide
    whether the code quality was sufficiently high. They can't; they don't
    even grasp the concepts, let alone the details, and we're in a situation
    where the people involved *should* be able to do this, which is not the
    norm.

    Coding skills? Who cares, as long as things work? It takes a really
    unusual environment to even be able to recognize coding skills, let alone
    determine the relative level of skills involved.
     
    Kelsey Bjarnason, Feb 17, 2008
    #13
  14. On Sun, 17 Feb 2008 14:04:43 +0100, Serve Laurijssen wrote:

    > "Richard Heathfield" <> schreef in bericht
    > news:...
    >> 5) managers tend to confuse "exposure to a tool" with "skilled user of
    >> a tool"; they also confuse "has used many tools" with "is a red-hot
    >> programmer". So anyone with 10 years of .Net is obviously a really good
    >> .Net programmer (no matter how many bugs he has coded but never
    >> spotted), and never mind that it only went live about five years ago.

    >
    > I dont know if you can spot a good or bad programmer by the number of
    > bugs they create or dont create.
    > I mean, somebody who creates lots of code introduces more bugs than
    > somebody who doesnt


    Not necessarily; one can design code fairly robustly to guard against
    such things, or at least, to reveal them early on - though this does
    depend a lot on other things, such as the particular case being solved.

    That said, in a lot of cases, it's not the programmer who is ultimately
    at fault in either case.

    Consider two programmers, one of moderate skill, one rather more
    advanced, each tasked with doing a similar job. The difference in the
    job being that the moderately skilled coder works in an environment where
    there are no unrealistic expectations on shipping dates and the like.

    That programmer has the opportunity to sit down, spend the time up front
    and really engineer the application, to avoid many bugs. The other
    fellow, despite being a technically better programmer, simply hasn't got
    the time to do this; he needs to get the code working now, deal with the
    bugs as they arise. Which is liable to produce the less buggy app, and
    what does that tell you about the relative skills of the programmers?

    This is, IMO, a big problem over at Microsoft, or at least, has been for
    years. It's not that they lack skilled coders; they don't. They have
    some of the best and brightest. However it appears, at least to an
    outsider, that those skills are largely crippled by the application of
    too-short release dates and the like: the coders, while themselves often
    excellent, simply lack the time to tackle the job in a manner that would
    produce fewest bugs, fewest problems. Instead, it's "get the code out
    now, we'll fix it in a service pack".

    I don't *know* that this is the case with MS; as I say, I'm an outsider.
    However, I do know several programmers there who are exceptionally bright
    folk, who have complained about just this sort of thing, and I see the
    results, in terms of applications which, while fundamentally functional,
    are somewhat more bug-ridden than they should be.

    If you based your judgement of competency on "number of bugs", such
    coders may well score rather poorly, despite actually being excellent
    programmers.
     
    Kelsey Bjarnason, Feb 17, 2008
    #14
  15. "Richard Heathfield" <> schreef in bericht
    news:...
    >> news:...
    >>> 5) managers tend to confuse "exposure to a tool" with "skilled user of a
    >>> tool"; they also confuse "has used many tools" with "is a red-hot
    >>> programmer". So anyone with 10 years of .Net is obviously a really good
    >>> .Net programmer (no matter how many bugs he has coded but never
    >>> spotted), and never mind that it only went live about five years ago.

    >>
    >> I dont know if you can spot a good or bad programmer by the number of
    >> bugs they create or dont create.

    >
    > Yes, I was truncating a large idea into but a few words, and I know that I
    > oversimplified.


    Now that I think about it, I have seen it happen where a good (imo)
    programmer was deemed not good enough because of his bug count and didnt
    survive his test period. (sorry, dont know how to say that in english)
     
    Serve Laurijssen, Feb 17, 2008
    #15
  16. On 17 Feb 2008 at 13:54, Richard Heathfield wrote:
    > Serve Laurijssen said:
    >
    >>
    >> "Richard Heathfield" <> schreef in bericht
    >> news:...
    >>
    >>> Actually, I think the vulnerability of (good) programmers comes from
    >>> several areas:
    >>>
    >>> 4) good programmers do have an appalling habit of being truthful (which,
    >>> among other things, makes it harder to get interviewed in the first
    >>> place);

    >>
    >> What do you mean by this?

    >
    > They don't tell lies on their CVs. If anything, they tend to understate
    > their skill level, because they don't want to create unrealistic
    > expectations. And they tend not even to mention technologies with which
    > they have a nodding acquaintance - despite the likelihood that they are
    > more able to use those technologies effectively than the people already
    > being employed by the interviewer's organisation.


    If sheer arrogance was the main criterion for a job, then you'd get it
    hands down.

    Just take a step back, read what you've written, and ask yourself just
    how smug and self-satisfied it sounds.
     
    Antoninus Twink, Feb 17, 2008
    #16
  17. Flash Gordon Guest

    Malcolm McLean wrote, On 17/02/08 18:08:
    >
    > "Flash Gordon" <> wrote in message
    > news:-gordon.me.uk...
    >> Malcolm McLean wrote, On 17/02/08 10:32:
    >>
    >> <snip>
    >>
    >>> any other group of people they employ. This is human nature.
    >>> Programmers are especially vulnerable because there is no
    >>> professional body.

    >>
    >> Apart from the BCS in the country in which you live if you want a
    >> professional body dedicated to IT or the IET if you want a larger body
    >> which does not specialise in IT but does accept it as a discipline. Of
    >> course, if you don't count bodies that can grant Chartered Engineer
    >> status...
    >>
    >> I will admit that the BCS is fairly new, after all it was only
    >> established in 1957...
    >>

    > I'm not a member of the British Computer Society, and this is typical.


    You said there was no professional body, you were wrong. There are two
    in the UK alone, one dedicate to just IT professionals. Just because you
    and lots of others are not members does not stop them from existing
    especially as lots of people *are* members or one or both of them.
    --
    Flash Gordon
     
    Flash Gordon, Feb 17, 2008
    #17
  18. Ark Khasin Guest

    Kelsey Bjarnason wrote:
    > [snips]
    >
    > On Sat, 16 Feb 2008 23:49:16 -0800, sophia.agnes wrote:
    >
    >> OR
    >>
    >> why coding skills are not given much importance ?

    >
    > Mostly, IMO, because few are competent to judge it. In an example from
    > work, just this past week:
    >
    > We've got a monitoring system which involves two chunks of code running
    > on two different machines and four databases. The data needs to be
    > recorded to one DB, mirrored to another, then massaged and delivered, in
    > processed form, to two more.
    >
    > The design requirements are pretty simple, and the code was designed to
    > handle outages - cases where the DB didn't respond, that sort of thing.
    > In essence, every problem the code would run into in the real world, from
    > power outages to accidental database wipes, was dealt with.
    >
    > So what happens? They want a test, which we do by "injecting" two years'
    > worth of "virtual" records. So far so good, but then they do it again,
    > using slightly different data, and everything breaks - the databases get
    > completely hosed, the reports are junk, we're seeing reports of days with
    > 48 hours in 'em, that sort of thing.
    >
    > Their conclusion? Something's broken. Proper conclusion: if you
    > invalidate the contract against which the code was designed, things are
    > going to break.


    I've been around for some time, and I am yet to see a single case where
    a customer (external or internal) knows upfront what requirements she
    actually has.
    It is a sign of maturity of the programmer to anticipate (and suggest!)
    changes in specifications, - and write code with guards against
    attempted violations. E.g., "don't use native types", "guard buffers
    against overflow", "assert sanity of results", "beware of arithmetic
    overflow" etc. etc.
    And yes, robust software design, and of API in particular, is not for
    the faint of heart, and this is sorely under-appreciated.
    >
    > This is the same sort of thing as designing an above-ground parking
    > garage, where each level is basically just flat concrete with painted
    > stalls on it, then, after it's built, adding on planters and sidewalks
    > and those cement "stall bumpers". When you add all that extra weight,
    > when you violate the design contract, what do you expect to happen? You
    > expect the garage to collapse from all the additional weight.

    There are good engineering practices out there, e.g. put 12-15-fold
    safety margin on the architectural construction. The garage should not
    collapse if every car parked there has dumbbells in their trunks.
    >
    > Yet when it comes to code, for some reason the world works by magic. We
    > did some testing, things broke, obviously the system is fragile, poorly
    > designed. No, it's not, it's very well designed, it's just not designed
    > to handle poking fingers, any more than it's designed to keep working if
    > you uninstall the underlying OS.

    Design not withstanding poking fingers is IMHO too fragile to be what's
    called "industrial strength" or, in programmer's parlance, "production
    code". A garage might not withstand a major earthquake (by design) =
    uninstalling the underlying OS, but should stay solid in the face of a
    sunrise.
    >
    > The really sad part is, I'm seeing this sort of thinking from technically
    > skilled people who, even if they don't understand the code, should at
    > least understand the underlying principles, yet here they are, whining
    > that it's too fragile.

    It was said that the difference between high-tech and low-tech is (by
    definition) that low-tech just works. Shame?
    >
    > Yet these are the people who, at least here, would be the ones to decide
    > whether the code quality was sufficiently high. They can't; they don't
    > even grasp the concepts, let alone the details, and we're in a situation
    > where the people involved *should* be able to do this, which is not the
    > norm.
    >
    > Coding skills? Who cares, as long as things work? It takes a really
    > unusual environment to even be able to recognize coding skills, let alone
    > determine the relative level of skills involved.
    >

    If things /really/ work, the skills have been adequate (by definition).
    Not every parking garage has to be an architectural marvel. None should
    collapse under its weight.
    Coding skills stand out immediately in e.g. code reviews. They are often
    obvious to the maintainer when the inevitable requirements change comes
    around.

    --
    Ark
     
    Ark Khasin, Feb 17, 2008
    #18
  19. Flash Gordon wrote:
    >
    > I will admit that the BCS is fairly new, after all it was only
    > established in 1957...


    Interestingly I don't think I've ever meet a single person I was aware
    of who was in the BCS, in 13 years of working in IT in the financial
    services sector. I did once meet a guy who was on the UK's C++
    committee....
     
    Mark McIntyre, Feb 17, 2008
    #19
  20. On Sun, 17 Feb 2008 10:32:27 +0000, Malcolm McLean wrote:

    > In practise it is easier to write the specification in code and cut out
    > the programmer entirely.


    This brought to you by the author of the buggiest, most useless
    text on C around. Sure, we'll take your word for it.
     
    Ivar Rosquist, Feb 17, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Girish
    Replies:
    10
    Views:
    851
    Steven Cheng[MSFT]
    Mar 6, 2004
  2. =?Utf-8?B?UmFlZCBTYXdhbGhh?=

    Imporving programming skills

    =?Utf-8?B?UmFlZCBTYXdhbGhh?=, Jun 29, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    522
  3. PFN
    Replies:
    2
    Views:
    376
    Mickey Segal
    Apr 8, 2004
  4. phani rajiv
    Replies:
    5
    Views:
    1,335
    Darren
    Sep 20, 2005
  5. calmar
    Replies:
    11
    Views:
    917
    calmar
    Feb 21, 2006
Loading...

Share This Page