Computer programmers' habits in electronics

[Joel Kolstad]

I can one-up this one. I was on a temp job, doing "document coding", which
is pretty much data entry by a whole roomful of grunts. But, they found
out that I had computer skills, so they let me take a look at this
database software. It was called "Paradox", and the way it worked was
that all of the coders (the grunts at the PCs which are acting like
dumb terminals) were editing one huge database file by way of one
invocation of the program on "The Server".

Sounds famliar... I set up the occasional computer or piece of software at a
place that brokers fruits, and the custom software written for them was done
in Delphi, back in the days when a "fast" PC was something like a 100MHz
Pentium with 16MB of memory. The guy who wrote the software designed so that
every time you performed a query on the database, the contents of the entire
database were sucked over to the local PCs (10baseT Ethernet back then) where
the search was actually performed. :-(

I never re-wrote the thing (I don't have the skills nor am I particularly
interested in learning them), and happily PC performance has scaled much
faster than their database size, so these days performing searches only takes
some 5-10 seconds. Unfortunately, they now want to work from home with their
DSL or even dial-up connections, so it's the exact same problem all over
again. The currently proposed solution is using remote desktop software...
sheesh...

All of this because some guy didn't have the foresight to spend about 3
seconds thinking about scalability a decade back to reach a conclusion I think
most of the techno-nerds around here would have already come up with in high
school ...!

---Joel

 

[Rich Grise]

.

Software pretty much never works the first time it's fired up. ...

Mine does.

Cheers!
Rich

 

[Dirk Bruere at Neopax]

Mine does.

I think he meant something more complex than "hello world"

--
Dirk

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

 

[Rich Grise]

And I did consider everything you wrote. Which is why I asked how it
was implemented since as a function, where() would have had to have
been exactly that, a function. Your choice of the word "construct"
keyed me into that. Strictly speaking, "while" is a keyword, not a
construct or a function call.

Now, what's the difference between

where(x == active)
{
do_something;
}

and

while(x == active)
{
do_something;
}

and why did it require creating a new keyword?

Because it's not C, it's VHDL or Verilog.

Cheers!
Rich

 

[Rich Grise]

Do spend time documenting = longer time before you have blinky lights
and motors going "zing", ultimately shorter time to having a product
fully ready to foist on an unsuspecting public.

I once rewrote a Z-80 stepper motor drive loop so that instead of going,
"CLACKETY-CLACKETY-CLACK", it went, "Hmmmmmmmmmmm."

Seeing veeps and CEOs and PHDs and stuff going "Ooh, Aah" is extremely
gratifying.

Cheers!
Rich

 

[Rich Grise]

Would you agree if I replaced "lack of documentation" with "not
understandable software"? I agree that stuff that is written in a
manner that is hard to understand, needs at least documentation,
although I feel that it is better to rewrite it.

In many, if not most, instances, there is a way to write code that is
basically very self explanatory or needs just a fewe comments on top
and some sprinkled in.

Admit it, Iggy. You're just looking for excuses to get out of doing the
grunt work. ;-)

Cheers!
Rich

 

[Pig Bladder]

In what languages are you coding?

Apparently, Ignoramian!

 

[Rich Grise, but drunk]

I am sorry, what is overflow work.

When you have so many customers that you can't fill the need, so you take
on outside help temporarily to take care of the overflow. You know, like
"My cup runneth over", but of work?

I'm kinda looking for some stuff where I could telecommute; I know just
enough C and perl to get myself in trouble, and can do hobbyist-level
electronics - I used to be able to slap together uC circuits, but I
don't really have a proper lab these days.

I'm wondering if I should look around for proofreader work, or does
anybody bother to have anything proofread these days?

Thanks,
Rich

 

[Ignoramus32515]

When you have so many customers that you can't fill the need, so you take
on outside help temporarily to take care of the overflow. You know, like
"My cup runneth over", but of work?

I'm kinda looking for some stuff where I could telecommute; I know just
enough C and perl to get myself in trouble, and can do hobbyist-level
electronics - I used to be able to slap together uC circuits, but I
don't really have a proper lab these days.

I'm wondering if I should look around for proofreader work, or does
anybody bother to have anything proofread these days?

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.

i

 

[Tim Wescott]

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.

i

Someone who likes to ask that question told me of an interviewee who got
as far as saying "I think it involves recursion...".

So I wrote a version that did it using recursive function calls and sent
it to her. I don't know if I would have gotten the job -- they had
already made the mistake of hiring me.

Good thing the PC has a lot of stack space.

For interviewing embedded SW engineers we finally settled on a fairly
basic scaling problem. We started with a little story problem that
required the interviewee to find the ratio of a couple of numbers and
multiply it to a third, then we said "oh, by the way, our floating point
library is too slow -- do it with integers". The question usually took
about 40 minutes to explore fully, with some folks never getting it and
some just glancing at the board and writing down the correct answer.

It's amazing how you can separate the desktop programmers from the
embedded engineers with that one.

 

[Spehro Pefhany]

Someone who likes to ask that question told me of an interviewee who got
as far as saying "I think it involves recursion...".

So I wrote a version that did it using recursive function calls and sent
it to her. I don't know if I would have gotten the job -- they had
already made the mistake of hiring me.

Good thing the PC has a lot of stack space.

For interviewing embedded SW engineers we finally settled on a fairly
basic scaling problem. We started with a little story problem that
required the interviewee to find the ratio of a couple of numbers and
multiply it to a third, then we said "oh, by the way, our floating point
library is too slow -- do it with integers". The question usually took
about 40 minutes to explore fully, with some folks never getting it and
some just glancing at the board and writing down the correct answer.

It's amazing how you can separate the desktop programmers from the
embedded engineers with that one.

The string reversal problem also may test whether the programmer
thinks about limit-checking and error handling, unless they choose to
reverse it in place (which could be influenced by specifics of the
question).

Reminds me of the time I gave a little programming job to a fellow.
Other than the GUI (which he did an okay job on), the 'guts' of the
task involved coming up with a handful of vectors and doing a few
dozen flops. Speed was of no concern. He precalculated every possible
value and created a multi-megabyte Access-compatible database.
Absolutely grotesque.


Best regards,
Spehro Pefhany

 

[Ignoramus32515]

Someone who likes to ask that question told me of an interviewee who got
as far as saying "I think it involves recursion...".

So I wrote a version that did it using recursive function calls and sent
it to her. I don't know if I would have gotten the job -- they had
already made the mistake of hiring me.

That's interesting, although as you can well see, not the most
efficient.

Good thing the PC has a lot of stack space.
yep

For interviewing embedded SW engineers we finally settled on a fairly
basic scaling problem. We started with a little story problem that
required the interviewee to find the ratio of a couple of numbers and
multiply it to a third, then we said "oh, by the way, our floating point
library is too slow -- do it with integers". The question usually took
about 40 minutes to explore fully, with some folks never getting it and
some just glancing at the board and writing down the correct answer.

That's interesting. How is your actual problem phrased? Just curious.

It's amazing how you can separate the desktop programmers from the
embedded engineers with that one.

That's true... Much better that just chatting with people.

i

 

[Ignoramus32515]

The string reversal problem also may test whether the programmer
thinks about limit-checking and error handling, unless they choose to
reverse it in place (which could be influenced by specifics of the
question).

that's what we want, reverse in place.

Reminds me of the time I gave a little programming job to a fellow.
Other than the GUI (which he did an okay job on), the 'guts' of the
task involved coming up with a handful of vectors and doing a few
dozen flops. Speed was of no concern. He precalculated every possible
value and created a multi-megabyte Access-compatible database.
Absolutely grotesque.

scary stuff...

i

 

[John Larkin]

Someone who likes to ask that question told me of an interviewee who got
as far as saying "I think it involves recursion...".

So I wrote a version that did it using recursive function calls and sent
it to her. I don't know if I would have gotten the job -- they had
already made the mistake of hiring me.

Good thing the PC has a lot of stack space.

For interviewing embedded SW engineers we finally settled on a fairly
basic scaling problem. We started with a little story problem that
required the interviewee to find the ratio of a couple of numbers and
multiply it to a third, then we said "oh, by the way, our floating point
library is too slow -- do it with integers". The question usually took
about 40 minutes to explore fully, with some folks never getting it and
some just glancing at the board and writing down the correct answer.

It's amazing how you can separate the desktop programmers from the
embedded engineers with that one.

Sure. I never use floating point in embedded stuff.

Who was it that said "If you have to use floating point, you don't
understand the problem"?

John

 

[Tim Wescott]

That's interesting, although as you can well see, not the most
efficient.




That's interesting. How is your actual problem phrased? Just curious.




That's true... Much better that just chatting with people.

i

It was a display problem, where we had a display of a certain known
size, and we wanted to plot a line on it that reflected an even-numbered
(10, 20, 50, 100, etc.) length. We told them that we wanted a procedure
that took the screen size in real-world coordinates, the desired size in
real-world coordinates, and the number of pixels in real-world
coordinates, and that coughed up the line size in pixels. It actually
came from a real product (sometimes we had system pictures in the
conference rooms & we could point to the box & say "it's in that there
box, as a matter of fact").

If they didn't start that way themselves we'd encourage them to "just do
the math" first, and look for how well they did their 8th grade algebra
problems.

Once the math was done, and sorted out into something that worked well,
we'd say "Oh, that's good, now write the procedure that calculates it".
Sometimes the interviewee would have to be encouraged to just do it in
floating point with no error handling -- if it looked like they were
concerned with side issues because of good programming habits we'd give
them extra credit.

Once the function was written then we'd drop the bombshell: "This
particular code base doesn't have a functioning floating point library
-- if you try to do any floating point operations the processor will
lock up. Please do this with integer arithmetic". Then we'd spend the
rest of the time allotted for the question working through issues of
truncation, overflow and (for extra credit) rounding.

We probably only saw 10% of the candidates make it through the question
100% unscathed, so we didn't grade on results. Instead we looked for
how quickly folks picked up on the concepts being thrown at them and
figured out solutions.

Interestingly enough the folks that did the worst at this were the
telecom guys. In spite of doing "embedded" software they never had to
do math and they _always_ worked with 32-bit machines -- to the point
where some of them required convincing that 'int' in C could refer to a
16-bit number, and many had no concept of the notion that a 'long int'
is, well, _longer_ than an 'int'.

Probably the most amusing anecdote that came out of this was a guy we
hired after he did quite well on The Question. His first task on the
job was to embellish a control loop, which he did using floating point.
I was called in to figure out why it didn't work, and was able to
point out that the code was just too damn slow. When I pointed out that
he did so well at The Question he replied that he thought it was just a
question -- he didn't realize it was a warning, too.

 

[Spehro Pefhany]

Someone who likes to ask that question told me of an interviewee who got
as far as saying "I think it involves recursion...".

So I wrote a version that did it using recursive function calls and sent
it to her. I don't know if I would have gotten the job -- they had
already made the mistake of hiring me.

Something like this? (ugh)

#include <string.h>

rev2(char * istring, int start, int fin)
{
char t;
t = istring[start];
istring[start] = istring[fin];
istring[fin] = t;
start++; fin--;
if (fin > start) rev2(istring, start, fin);
}


....

/* reverse the string in place */
rev2(mystring, 0, strlen(mystring)-1);

....

Good thing the PC has a lot of stack space.

For interviewing embedded SW engineers we finally settled on a fairly
basic scaling problem. We started with a little story problem that
required the interviewee to find the ratio of a couple of numbers and
multiply it to a third, then we said "oh, by the way, our floating point
library is too slow -- do it with integers". The question usually took
about 40 minutes to explore fully, with some folks never getting it and
some just glancing at the board and writing down the correct answer.

It's amazing how you can separate the desktop programmers from the
embedded engineers with that one.

Here's one I did to approximate e^(-x) over the range 0 .. 0.75
(the end product would be written in assembler**, the C is just to
explain).



---

where xf, yf are 32-bit integers.

xf = x * 128;
yf = 32768 - xf + (xf* xf)/65536 - (((xf * xf)/32768
)*xf)/(6*32768) + (((xf*xf)/32768)* ((xf*xf)/32768))/(32768 * 24)
- (((((xf*xf)/32768)* ((xf*xf)/32768))/32768) * xf)/(32768 * 120)
;

The result is ~= exp(-x/256) * 32768 over the range
x = 1 to 192.

yf/32768 agrees with exp(-x/256) within 0.001 over that range.


You can easily extend this to additional terms, although it gets a bit
tedious.

It's based on the textbook Taylor/Maclaurin series

infinity

 

[Rich Grise]

I think he meant something more complex than "hello world"

Like an in-line assembler/disassembler to interface with a ROM simulator?

;-)

Cheers!
Rich

 

[Mike Young]

and BGA chips? So at some point, you may as well stop fiddling and
start designing, and get the real product right the first time without
wasting your time on prototypes.

And why not design software that way, too?

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. It has to be, otherwise the design tool will have taken over as
the programming tool, and that hasn't happened yet. Thresholds vary with the
person, tools involved, and task at hand. There is no direct analogy in
circuit design, leading directly to that inescapable conclusion: software
and circuit design are very different tasks once you leave the broad
brush-stroke level of talking.

Anyway, our young friend Iggie was asking about the world beyond "20 wires
or so". No BGA involved there. Complexity at that level is next to nil, but
the details are already too large to keep internally alone. That's quite a
bit different from mashing code into a keyboard; the first line of code is
likely still on the same screen as the last. At even 10 or 100 times that
size, referencing decisions already made is just a keystroke or two away.

 

[Rich Grise]

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

YGBSM.

OK, since it's a job app, lessee what I can come up with.

Um, do you want me to reverse it in place, or to create a reversed
copy on the heap?

Thanks,
Rich

 

[Rich Grise]

Someone who likes to ask that question told me of an interviewee who got
as far as saying "I think it involves recursion...".

So I wrote a version that did it using recursive function calls and sent
it to her. I don't know if I would have gotten the job -- they had
already made the mistake of hiring me.

Something like this? (ugh)

#include <string.h>

rev2(char * istring, int start, int fin)
{
char t;
t = istring[start];
istring[start] = istring[fin];
istring[fin] = t;
start++; fin--;
if (fin > start) rev2(istring, start, fin);
}


...

/* reverse the string in place */
rev2(mystring, 0, strlen(mystring)-1);

...

Good thing the PC has a lot of stack space.

For interviewing embedded SW engineers we finally settled on a fairly
basic scaling problem. We started with a little story problem that
required the interviewee to find the ratio of a couple of numbers and
multiply it to a third, then we said "oh, by the way, our floating point
library is too slow -- do it with integers". The question usually took
about 40 minutes to explore fully, with some folks never getting it and
some just glancing at the board and writing down the correct answer.

It's amazing how you can separate the desktop programmers from the
embedded engineers with that one.

Here's one I did to approximate e^(-x) over the range 0 .. 0.75
(the end product would be written in assembler**, the C is just to
explain).



---

where xf, yf are 32-bit integers.

xf = x * 128;
yf = 32768 - xf + (xf* xf)/65536 - (((xf * xf)/32768
)*xf)/(6*32768) + (((xf*xf)/32768)* ((xf*xf)/32768))/(32768 * 24)
- (((((xf*xf)/32768)* ((xf*xf)/32768))/32768) * xf)/(32768 * 120)
;

The result is ~= exp(-x/256) * 32768 over the range
x = 1 to 192.

yf/32768 agrees with exp(-x/256) within 0.001 over that range.


You can easily extend this to additional terms, although it gets a bit
tedious.

It's based on the textbook Taylor/Maclaurin series

infinity
---
\
exp(x) = > (x^n)/n!
/
---
n= 0


** actually assembler macros, but that's another story

---

Yabbut, none of youse guys will work as cheap as me.

Thanks,
Rich