Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Coding skills

Reply
Thread Tools

Coding skills

 
 
Flash Gordon
Guest
Posts: n/a
 
      02-17-2008
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
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      02-17-2008

"Flash Gordon" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-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

 
Reply With Quote
 
 
 
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      02-17-2008
[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.

 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      02-17-2008
On Sun, 17 Feb 2008 14:04:43 +0100, Serve Laurijssen wrote:

> "Richard Heathfield" <(E-Mail Removed)> schreef in bericht
> news:(E-Mail Removed)...
>> 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.

 
Reply With Quote
 
Serve Laurijssen
Guest
Posts: n/a
 
      02-17-2008

"Richard Heathfield" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
>> news:(E-Mail Removed)...
>>> 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)

 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      02-17-2008
On 17 Feb 2008 at 13:54, Richard Heathfield wrote:
> Serve Laurijssen said:
>
>>
>> "Richard Heathfield" <(E-Mail Removed)> schreef in bericht
>> news:(E-Mail Removed)...
>>
>>> 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.

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      02-17-2008
Malcolm McLean wrote, On 17/02/08 18:08:
>
> "Flash Gordon" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)-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
 
Reply With Quote
 
Ark Khasin
Guest
Posts: n/a
 
      02-17-2008
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
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      02-17-2008
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....
 
Reply With Quote
 
Ivar Rosquist
Guest
Posts: n/a
 
      02-17-2008
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
general coding issues - coding style... calmar Python 11 02-21-2006 10:36 AM
please help me in improving my designing and coding skills phani rajiv Java 5 09-20-2005 05:49 PM
Basic skills needed for wireless network set-up? =?Utf-8?B?TWFyaw==?= Wireless Networking 3 01-09-2005 01:02 AM
SKILLS BEING MEASURED exam 70-306 Christiaan MCSD 5 02-10-2004 07:23 PM
Staff Skills Assessment Tests Emma Microsoft Certification 1 10-02-2003 11:31 PM



Advertisments