Computer programmers' habits in electronics

[Bob Stephens]

Stephens

Umm... I think you missed the implied smiley (;0~)


Bob

 

[Spehro Pefhany]

Man, you young'uns must think CPU cycles are free or something.

bool IsPowerOf2(unsigned val)
{
return !(val & (val-1));
}

-- jm

Ah, very good!

But I think to take care of all cases you might have to do:

return val?!(val&(val-1)):0;

Scrunched together, especially, it will also better confuse anyone who
comes along later and tries to modify "your" code.




Best regards,
Spehro Pefhany

 

[Richard H.]

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay

Ig,

Perhaps it really is poor practice, but programmers just get away with
it (because the cost is "softer")?

Consider...
* If it cost you many more hours to write (assemble) each hack
* And it cost you money for each compile (build with parts, PCB)
* And flaws subtly delete (burn up) parts of your project when tested
* And it took you serious time (and real money) to find and re-code
(re-solder) the missing parts from scratch

Would hacking code still seem like a smart approach?

When hacking was more costly (e.g., timeshare systems and punchcard
programming), a structured approach was valued. It's just less painful
now, so it's more common.

The same goes for resources. Today we have abundant processors /
networks / memory / disk - this doesn't improve the quality of lousy
code, it only hides it. Sadly, fast time-to-market is often rewarded
more than quality.

Richard

 

[Bob Monsen]

[quoted text muted]

Sorry, nothing that I can think of, of the sort.

Somewhat tangentially...

We are interviewing people for computer programmer positions. We are
looking for those who can actually "do stuff" without too much
babysitting.

Lots of people come in with impressive resumes. When I talk to them, I
know that some peope are very good at bullshitting, so I give them a
couple of actual tasks to do. Very small simple things. One is to
write a nice function that reverses a string in place. For example,
"Rich" would become "hciR".

Almost no one can actually do this without making mistakes, many
people give up completely.

Very frustrating. I consider it the most basic capability of a
programmer.

How many times have you had to write a routine like this in your coding
career? I'll answer: only when asked to by some clown on an interview.

I've had people ask me to reverse a fifo. Most coders try to avoid
reversing fifos...

Another guy asked me the fastest way to reverse bits in a word. He didn't
like the table lookup answer.

When I got out of college, an interviewer from Microsoft asked
me if I could figure out a way to create a doubly linked list using a
single pointer field per element. (hint: if A xor B = C, then A xor C =
B). No wonder their software is so horrible. They hire people who would
actually consider doing this.

I've always found it enjoyable to torture prospective employees, but it
never helps in determining if they are going to be productive. Often, the
smartest people get nothing done, and even become a drag on the
organization by bullying and posturing in meetings. It's the quiet, less
'clever' people with the good work ethic that end up doing most of the
work.

--
Regards,
Bob Monsen

The concept of fiction was nowhere in Mike's experience; there was
nothing on which it could rest, and Jubal's attempts to explain the
idea were so emotionally upsetting to Mike that Jill was afraid that
he was about to roll up into a ball and withdraw himself.

 

[[email protected]]

[quoted text muted]

Sorry, nothing that I can think of, of the sort.

Somewhat tangentially...

We are interviewing people for computer programmer positions. We are
looking for those who can actually "do stuff" without too much
babysitting.

Lots of people come in with impressive resumes. When I talk to them, I
know that some peope are very good at bullshitting, so I give them a
couple of actual tasks to do. Very small simple things. One is to
write a nice function that reverses a string in place. For example,
"Rich" would become "hciR".

Almost no one can actually do this without making mistakes, many
people give up completely.

Very frustrating. I consider it the most basic capability of a
programmer.

How many times have you had to write a routine like this in your coding
career? I'll answer: only when asked to by some clown on an interview.

Actually, doing things in-place like the reversing of string example is
quite common and useful in embedded code. Especially for small 8/16 bit
micros where memory is very scarce (Yes RAM is cheap but if you can use
the on-chip memory that saves the cost of one chip. And in some
applications $0.10 is considered expensive).

 

[Ignoramus16420]

[quoted text muted]

Sorry, nothing that I can think of, of the sort.

Somewhat tangentially...

We are interviewing people for computer programmer positions. We are
looking for those who can actually "do stuff" without too much
babysitting.

Lots of people come in with impressive resumes. When I talk to them, I
know that some peope are very good at bullshitting, so I give them a
couple of actual tasks to do. Very small simple things. One is to
write a nice function that reverses a string in place. For example,
"Rich" would become "hciR".

Almost no one can actually do this without making mistakes, many
people give up completely.

Very frustrating. I consider it the most basic capability of a
programmer.

How many times have you had to write a routine like this in your coding
career? I'll answer: only when asked to by some clown on an interview.

Doing things of similar nature, many times.

I've always found it enjoyable to torture prospective employees, but it
never helps in determining if they are going to be productive. Often, the
smartest people get nothing done, and even become a drag on the
organization by bullying and posturing in meetings. It's the quiet, less
'clever' people with the good work ethic that end up doing most of the
work.

I think that it would be stupid to hire people based only on being
able to write a little routine. We agree on that. But it would be
stupid to hire people who cannot program computers, to program
computers.

i

 

[Dirk Bruere at Neopax]

[quoted text muted]

Sorry, nothing that I can think of, of the sort.

Somewhat tangentially...

We are interviewing people for computer programmer positions. We are
looking for those who can actually "do stuff" without too much
babysitting.

Lots of people come in with impressive resumes. When I talk to them, I
know that some peope are very good at bullshitting, so I give them a
couple of actual tasks to do. Very small simple things. One is to
write a nice function that reverses a string in place. For example,
"Rich" would become "hciR".

Almost no one can actually do this without making mistakes, many
people give up completely.

Very frustrating. I consider it the most basic capability of a
programmer.

How many times have you had to write a routine like this in your coding
career? I'll answer: only when asked to by some clown on an interview.

Doing things of similar nature, many times.

I've always found it enjoyable to torture prospective employees, but it
never helps in determining if they are going to be productive. Often, the
smartest people get nothing done, and even become a drag on the
organization by bullying and posturing in meetings. It's the quiet, less
'clever' people with the good work ethic that end up doing most of the
work.

I think that it would be stupid to hire people based only on being
able to write a little routine. We agree on that. But it would be
stupid to hire people who cannot program computers, to program
computers.

Depends.
Some people learn fast.
I have often come across job requirements for knowledge of a particular 8 bit
micro. I used to say that it would take me about half a day to get up to speed
by reading the data book. Not good enough. Now I bullshit, and if I get the job
spend half a day getting up to speed...

Ditto programming languages. Originally it took me a couple of weeks to learn to
program reasonably well in C, then some years later another two weeks to add the
++. Then I didn't use it for about 4 yrs and so have had to relearn again for my
current job. Not a hope in hell of getting the job if the guy had set me some
poxy C++ test at the 'interview'.

Hiring a coding monkey over someone who can actually understand the entire
project, including h/w design, is IMO false economy. My job is solving
engineering problems.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[Joel Kolstad]

When I got out of college, an interviewer from Microsoft asked
me if I could figure out a way to create a doubly linked list using a
single pointer field per element. (hint: if A xor B = C, then A xor C =
B). No wonder their software is so horrible. They hire people who would
actually consider doing this.

The first version of BASIC for the (long defunct) Commodore Amiga computer was
provided by Microsoft. They used 32 bit words to keep track of addresses
(pointers) but, being 'clever,' used the uppermost byte for various flags
since (I believe this is the correct reason, someone correct me if I'm wrong)
the original Amiga 1000 used a Motorola 68000 that could only address 16MB (24
bits) anyway.

This came back to bite them when the Amiga 2000 was released with 68020, which
could address over 16MB.

Oops!

On the other hand, it can be a non-trivial choice as to how to optimize a
design -- PCs are so fast and have so much memory these days that no one
should think they're being clever by packing bits into the top-end of a DWORD
or building doubly-linked lists as you describe, yet people working on
embedded systems with little 8 bit CPUs can arguably make good use of such
techniques.

Hmm... thinking about it, I'd admit to not being able to implement a
doubly-linked list using a single pointer field. Say the addresses and
(pointer) contents of of element are:

0x0123: Magic number 1
0x0345: Magic number 2
0x0678: Magic number 3
0x09ab: Magic number 4
....etc...

I don't see how any single magic number (16 bits) that you place at 0x0345
that'll let you navigate to both 0x0123 and 0x0678?

---Joel

 

[Mike Young]

Hiring a coding monkey over someone who can actually understand the entire
project, including h/w design, is IMO false economy. My job is solving
engineering problems.

How well does that fly? Have you come across any disbelievers?

 

[Spehro Pefhany]

The first version of BASIC for the (long defunct) Commodore Amiga computer was
provided by Microsoft. They used 32 bit words to keep track of addresses
(pointers) but, being 'clever,' used the uppermost byte for various flags
since (I believe this is the correct reason, someone correct me if I'm wrong)
the original Amiga 1000 used a Motorola 68000 that could only address 16MB (24
bits) anyway.

This came back to bite them when the Amiga 2000 was released with 68020, which
could address over 16MB.

Oops!

On the other hand, it can be a non-trivial choice as to how to optimize a
design -- PCs are so fast and have so much memory these days that no one
should think they're being clever by packing bits into the top-end of a DWORD
or building doubly-linked lists as you describe, yet people working on
embedded systems with little 8 bit CPUs can arguably make good use of such
techniques.

Hmm... thinking about it, I'd admit to not being able to implement a
doubly-linked list using a single pointer field. Say the addresses and
(pointer) contents of of element are:

0x0123: Magic number 1
0x0345: Magic number 2
0x0678: Magic number 3
0x09ab: Magic number 4
...etc...

I don't see how any single magic number (16 bits) that you place at 0x0345
that'll let you navigate to both 0x0123 and 0x0678?

---Joel

No, but it's possible under less limiting conditions. Described here
(spoiler): http://en.wikipedia.org/wiki/Xor_linked_list



Best regards,
Spehro Pefhany

 

[Tim Wescott]

On Wed, 21 Dec 2005 19:45:51 +0000, Ignoramus32515 wrote:


On Wed, 21 Dec 2005 19:31:08 GMT, Rich Grise, but drunk

[quoted text muted]


Sorry, nothing that I can think of, of the sort.
Somewhat tangentially...

We are interviewing people for computer programmer positions. We are
looking for those who can actually "do stuff" without too much
babysitting.
Lots of people come in with impressive resumes. When I talk to them, I
know that some peope are very good at bullshitting, so I give them a
couple of actual tasks to do. Very small simple things. One is to
write a nice function that reverses a string in place. For example,
"Rich" would become "hciR".

Almost no one can actually do this without making mistakes, many
people give up completely.
Very frustrating. I consider it the most basic capability of a
programmer.


How many times have you had to write a routine like this in your coding
career? I'll answer: only when asked to by some clown on an interview.

Doing things of similar nature, many times.

I've always found it enjoyable to torture prospective employees, but it
never helps in determining if they are going to be productive. Often,
the
smartest people get nothing done, and even become a drag on the
organization by bullying and posturing in meetings. It's the quiet, less
'clever' people with the good work ethic that end up doing most of the
work.

I think that it would be stupid to hire people based only on being
able to write a little routine. We agree on that. But it would be
stupid to hire people who cannot program computers, to program
computers.

Depends.
Some people learn fast.
I have often come across job requirements for knowledge of a particular
8 bit micro. I used to say that it would take me about half a day to get
up to speed by reading the data book. Not good enough. Now I bullshit,
and if I get the job spend half a day getting up to speed...

Ditto programming languages. Originally it took me a couple of weeks to
learn to program reasonably well in C, then some years later another two
weeks to add the ++. Then I didn't use it for about 4 yrs and so have
had to relearn again for my current job. Not a hope in hell of getting
the job if the guy had set me some poxy C++ test at the 'interview'.

Hiring a coding monkey over someone who can actually understand the
entire project, including h/w design, is IMO false economy. My job is
solving engineering problems.

Asking that string reversal problem isn't, in my opinion, such a bad
thing. There's a difference between someone who just can't code and
someone who hasn't coded on a particular processor's assembly language.
If I care about what processors someone has worked on it is only to
get a feel for how flexible they are -- someone who's only done
8-bitters may be weak at handling really large and complex problems,
while someone who's done only C++ on 32 bit platforms is going to get
some rude surprises working on an AVR.

In addition to The Interview Question I related above, I also like to
ask an interviewee to give a quick chalk talk on some project that
they've worked on. This quickly gives you a good idea of their ability
to communicate, where they are going to want to fit into the hierarchy,
how much stuff _they_ actually did personally, and how good of a grasp
they had on the principals.

I should also mention that in the company where they used The Interview
Question and the chalk talk, we also made sure that every software
engineer talked to at least one EE, and we made sure that part of that
discussion was a test of their hardware skills -- the EE would stick a
schematic under their nose and ask them to find a signal coming out of
the microprocessor, and ask them to relate how they'd measure the
signal. Saying "I don't know but I do know how to ask an EE for help"
was acceptable; saying "I don't do hardware" was not.

 

[Dirk Bruere at Neopax]

How well does that fly? Have you come across any disbelievers?

Not amongst my customers.
Obviously I tend to work for smallish companies without all that formal HR crap.
They prefer Jack Of All Trades who can understand the whole project in all its
phases from idea to production. The fact I spend an extra couple of weeks
learning specifics is of far less importance than being able to pick up h/w,
s/w, standards, EMI and productionisation problems before it's too late.

I have worked for big companies, and the compartmentalised mindset is vastly
counterproductive. Sure the coding monkeys can write faster than me, but when it
doesn't work and the h/w and s/w guys are blaming each other that's not much of
an advantage.

The last small company I worked for had a team of 4 of us in R&D. We could get a
product from idea to mass production and in the customer's hand in 6 weeks.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[Dirk Bruere at Neopax]

Not amongst my customers.
Obviously I tend to work for smallish companies without all that formal
HR crap.
They prefer Jack Of All Trades who can understand the whole project in
all its phases from idea to production. The fact I spend an extra couple
of weeks learning specifics is of far less importance than being able to
pick up h/w, s/w, standards, EMI and productionisation problems before
it's too late.

I have worked for big companies, and the compartmentalised mindset is
vastly counterproductive. Sure the coding monkeys can write faster than
me, but when it doesn't work and the h/w and s/w guys are blaming each
other that's not much of an advantage.

The last small company I worked for had a team of 4 of us in R&D. We
could get a product from idea to mass production and in the customer's
hand in 6 weeks.

My CV
http://www.neopax.com/Artemis/cv/Curriculum Vitae.doc

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[Bob Monsen]

Hmm... thinking about it, I'd admit to not being able to implement a
doubly-linked list using a single pointer field. Say the addresses and
(pointer) contents of of element are:

0x0123: Magic number 1
0x0345: Magic number 2
0x0678: Magic number 3
0x09ab: Magic number 4
...etc...

I don't see how any single magic number (16 bits) that you place at 0x0345
that'll let you navigate to both 0x0123 and 0x0678?

Assume you have a circular list of A, B, C, D, A

Then A's link field has B^D, B's link field has A^C, etc. Now, given the
address of two consecutive pointers in the list, p and q, you can go
either way, since

next = p ^ q.link

and

prior = p.link ^ q

This does not give you what you usually want from a doubly-linked list,
though, which is the ability to remove an element from a list given only
a pointer to the element.

--
Regards,
Bob Monsen

Jill looked puzzled. "I don't know how to express it. Yes, I do! Ben,
have you ever seen an angel?" "You, cherub. Otherwise not." "Well,
neither have I but that is what he looked like. He had old, wise eyes
in a completely placid face, a face of unearthly innocence." She
shivered.

 

[Ignoramus14405]

On Wed, 21 Dec 2005 19:45:51 +0000, Ignoramus32515 wrote:



[quoted text muted]

Sorry, nothing that I can think of, of the sort.

Somewhat tangentially...

We are interviewing people for computer programmer positions. We are
looking for those who can actually "do stuff" without too much
babysitting.

Lots of people come in with impressive resumes. When I talk to them, I
know that some peope are very good at bullshitting, so I give them a
couple of actual tasks to do. Very small simple things. One is to
write a nice function that reverses a string in place. For example,
"Rich" would become "hciR".

Almost no one can actually do this without making mistakes, many
people give up completely.

Very frustrating. I consider it the most basic capability of a
programmer.

How many times have you had to write a routine like this in your coding
career? I'll answer: only when asked to by some clown on an interview.

Doing things of similar nature, many times.

I've always found it enjoyable to torture prospective employees, but it
never helps in determining if they are going to be productive. Often, the
smartest people get nothing done, and even become a drag on the
organization by bullying and posturing in meetings. It's the quiet, less
'clever' people with the good work ethic that end up doing most of the
work.

I think that it would be stupid to hire people based only on being
able to write a little routine. We agree on that. But it would be
stupid to hire people who cannot program computers, to program
computers.

Depends.
Some people learn fast.
I have often come across job requirements for knowledge of a particular 8 bit
micro. I used to say that it would take me about half a day to get up to speed
by reading the data book. Not good enough. Now I bullshit, and if I get the job
spend half a day getting up to speed...

Ditto programming languages. Originally it took me a couple of weeks to learn to
program reasonably well in C, then some years later another two weeks to add the
++. Then I didn't use it for about 4 yrs and so have had to relearn again for my
current job. Not a hope in hell of getting the job if the guy had set me some
poxy C++ test at the 'interview'.

Hiring a coding monkey over someone who can actually understand the entire
project, including h/w design, is IMO false economy. My job is solving
engineering problems.

I think that the test I am asking for does not require knowledge of C
beyond the very basics. It basically requires knowledge of computer
programming rather than knowing intricacies of the language.

i

 

[John Larkin]

There are many reasons why and why not, and even when not or how not. The
most direct answer is that below some level of detail, the program code is a
better, more effective, and more efficient descriptive tool than any design
language.

Most "modern" programming languages deserve the title "code"; they
must be painstakingly deceiphered to try to figure out what's going
on. The proper documentation of code is comments, which are rare these
days.

John

 

[Mike Young]

Most "modern" programming languages deserve the title "code"; they
must be painstakingly deceiphered to try to figure out what's going
on. The proper documentation of code is comments, which are rare these
days.

It's a learned skill, and perhaps even more fundamental than simply writing.
In fact, simply reading is not enough. You have to read critically for
correctness. How else would you know that the comments no longer describe
what the code is doing? One supposes this lack contributes more bugs than
even Microsoft's evil aura and intents.

 

[Keith Williams]

Most "modern" programming languages deserve the title "code"; they
must be painstakingly deceiphered to try to figure out what's going
on. The proper documentation of code is comments, which are rare these
days.

I guess that's why I prefer assmebler, PL/I, or VHDL. Assembler
forces comments to be able to figure out what you did next week.
The others are verbose enough to get by with fewer comments (a
high-level diagram would be nice). C/C++ are unreadable, IMO.

A former manager (a DOS/MVS developer in a former life) had the
term "xenocryptophobia" on a plague above his desk. I thought it
appropriate. It rubbed off.

 

[John Larkin]

I guess that's why I prefer assmebler, PL/I, or VHDL. Assembler
forces comments to be able to figure out what you did next week.
The others are verbose enough to get by with fewer comments (a
high-level diagram would be nice). C/C++ are unreadable, IMO.

I like assembly too. My comment/code ratio is about 3:1, and I include
the occasional soliloquy, math derivation, protocol description, and
ascii-art diagram. I saw some Windows source code a while back: a
simple API wound up being a score of source files, many doing nothing
but passing stuff off to others under assumed names. Each did have the
Microsoft-mandatory comment header. Under "Description of function:"
people had filled in useful things like "what it says."

John

 

[Keith Williams]

I like assembly too. My comment/code ratio is about 3:1, and I include
the occasional soliloquy, math derivation, protocol description, and
ascii-art diagram.

I do the same. The low-level drivers have ASCII art register
definitions in the headers and a long description of exactly what
the module is supposed to do, with all parameters and returns
specified. I also use running comments to describe the results of
each step and where it's all heading.

I saw some Windows source code a while back: a
simple API wound up being a score of source files, many doing nothing
but passing stuff off to others under assumed names. Each did have the
Microsoft-mandatory comment header. Under "Description of function:"
people had filled in useful things like "what it says."

Why am I not surprised. "If it was hard to write it _should_ be
hard to understand."