Coding skills

[sophia.agnes]

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 ?

 

[Richard Heathfield]

(e-mail address removed) 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.)

 

[Malcolm McLean]

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.

 

[Richard Heathfield]

Malcolm McLean said:

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.)

 

[Serve Laurijssen]

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]

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

 

[Morris Dovey]

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

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

 

[Richard Heathfield]

Serve Laurijssen said:

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]

Serve Laurijssen said:

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.

 

[Serve Laurijssen]

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

 

[Flash Gordon]

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

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...

 

[Malcolm McLean]

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



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.

 

[Kelsey Bjarnason]

[snips]

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]

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.

 

[Serve Laurijssen]

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)

 

[Antoninus Twink]

Serve Laurijssen said:


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.

 

[Flash Gordon]

Malcolm McLean wrote, On 17/02/08 18:08:

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.

 

[Ark Khasin]

[snips]

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.

 

[Mark McIntyre]

>
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....

 

[Ivar Rosquist]

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.