politics, sorry, but this is great...

[David Brown]

On 20/01/2022 19:29, John Larkin wrote:

On Wed, 19 Jan 2022 20:11:03 +0200, Dimiter_Popoff <dp@tgi-sci.com
wrote:

Nowadays you cannot be a good design engineer without being able to
write decent code and you cannot be a good programmer without being
able to do decent designs.

I disagree with both suggestions. One can do electronic design that
doesn\'t involve computers, or farm out the code to someone else. There
are lots of software tools, like Spice, that do the math without
having to code yourself. And there are lots of software things,
actually most software things, that require zero knowledge of
electronics.

But the most fun products mix analog and digital and FPGA and uP code,
with adjustable boundaries. I do need to know a little about, say, the
realtime limits of Linux on a Zynq, but I don\'t need to code to
measure that... just define an experiment for a programmer.

I agree with you on all that. (I would point out that projects don\'t
have to be \"fun\" to be good projects, good engineering, good designs.
But it is definitely nice when they are!)

The same thing applies in other directions. If I am making code for a
high-speed PWM signal, I need to understand the limits the hardware has
for switching times and dead times. I need to know about particular
frequency requirements. I need to understand that the hardware /has/
limits, and coordinate with the hardware designer(s) about them. But I
don\'t need to know or care about the details of how it is implemented in
the hardware. It doesn\'t matter if the frequency limits are because of
filter components, or EMI, or driver choices. I don\'t need to be able
to analyse harmonics, or know how to lay out components to minimise
stray inductance loops or what width tracks should be to keep
temperature rises in safe bounds. I don\'t need to be a hardware
designer to write code for the hardware. (It can be interesting to know
more of the details - but it is not necessary.)

Tool sets, like linux + some c compiler, or an FPGA with its massive
tool kit, can each become full-time chores. Teams are a good idea
these days.

Indeed.

Some projects are fine for one person to do everything, but often it
makes sense to have different people who are most experienced at
different parts. They need an overlap of knowledge with their
neighbours in the team, but they don\'t need to be experts.

(I\'m snipping the politics to keep the tone lighter.)

I think the internet has increased tribalism, partly by allowing
physically separated people to become tribes, without the subtleties
gained from physical proximity.

Certainly. Heated discussions can occur in real life too, but the more
extreme attitudes found online are rare in reality. Almost all the
arguments here would be a lot less polarised and a lot more friendly
around a pub table with a beer (but not too many!) at hand. I mean, can
you imagine Phil Allison talking in real life the way he posts here?
He\'d be locked up - either in a padded cell as a raving lunatic, or
behind bars as a public nuisance.

And as people get more information from random and unvetted sources on
the internet, they get more polarised from confirmation bias and
conspiracy theories abound.

I greatly prefer people in a conference room to Zoom things, which are
so one-dimensional.

Agreed. My favourite place in design meetings is standing at the white
board.

 

[Dimiter_Popoff]

On 1/20/2022 23:48, David Brown wrote:

On 20/01/2022 19:10, Dimiter_Popoff wrote:
On 1/20/2022 17:31, David Brown wrote:
On 19/01/2022 19:11, Dimiter_Popoff wrote:

Hah, what a party I have been missing here.

Nowadays you cannot be a good design engineer without being able to
write decent code and you cannot be a good programmer without being
able to do decent designs.

That might depend on what you mean by \"design engineer\", but if you mean
\"electronics design engineer\" then I disagree.  Most programmers haven\'t
a clue about electronics, and don\'t need a clue about it.

I know, and it shows.

 /Embedded/
programmers - especially those working on small systems or low levels -
need to understand some electronics basics and be able to read some
types of schematics.  They don\'t need to be able to design things
themselves, but they need to be able to work with the designers to
coordinate the interfaces between the programmable parts and the rest of
the electronics.  (This is also true during board bring-up and testing
and debugging new cards.)

At a higher level, programmers don\'t need to know what is going on
inside their systems to make them work (though a rough idea can help
them write more efficient code).

Programming without hardware design experience is much like writing
a novel having sufficient language skills and no life experience to
write based on. My observation, I know you disagree.


Again, are you talking specifically about programming embedded systems,
or programming in general?

Well I can only talk about my own experience, which includes just about
all kinds of programming - from lowest level system programming through
tools like assemblers, compiler, linkers to shell scripts and the like,
even some html if the latter counts for programming.
I know I could not have done it all - millions of lines of code
done without involving a single bit of outside written code - without
all the knowledge I have, it has been demanding enough as it is
really.
I understand your point and I know the world operates more like the
way you say it does - which does not invalidate my point, though.

When you are writing a program for a specific task, it is good to know a
bit about the use of the program. I\'m not a great believer in the idea
of one person writing a full detailed specification, and a programmer
implementing it blindly - that can work for small bits of code, but not
real programs. So if you are writing a program to control a piece of
farm machinery, for example, you need to talk to the people that make it
and the people that will use it - you need to have a feel for the
machines. But you don\'t need to be an expert farmer - any more than the
farmer needs to be an expert programmer in order to use the program.

If you are programming an embedded system, and you need to write the
driver for a I²C current sensor, you need to know how to read the
datasheet and understand the basics of the schematic. But you do /not/
need to be an electronics designer. You don\'t need hardware design
experience. Knowing how to pick the sensor, which lines to measure,
what filters to use, how to lay out the board - that gives absolutely
/nothing/ of benefit in writing code to use it.

Now, if you want to suggest that some of the best low-level programmers
have started out on hardware and moved into programming from that side,
and get better results than people who learned Java or C# and are now
trying to get to grips with an 8051, I can understand and relate to
that. But I would suggest that it is not because of hardware design
experience, but because they started with more limited things and worked
up, rather than starting learning with a cornucopia of resources and now
have to limit themselves.

(For other types of programming, people get better results if they start
from very different studies, such as mathematics.)

If you want to go into more detail of your reasoning and /why/ you find
hardware design experience helps programming, I\'d be interested to hear
it. And again, I\'d like to hear if it is particular types of programming.

All I can say is that hardware design experience has been an integral
part of my growing up as a programmer, I have been putting together
products and then programmed them - obviously I have been buying the
silicon and passive components for these but that was about it.

Without the full experience it is clearly practical to do work based
on less broad areas of experience but it does not take a huge product
complexity to reach a point where making certain decisions takes
as broad experience as one can get. Like which part to do in hardware,
invent algorithms to reach your goal - you don\'t have a lot of chances
to get it right with just superficial knowledge of half the product.

But don\'t take me too literally, I know my experiences do not apply to
many people. Thus obviously what I think is unlikely to be either
a universally applicable truth nor can it be very popular.

======================================================
Dimiter Popoff, TGI http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

 

[David Brown]

On 21/01/2022 15:34, Dimiter_Popoff wrote:

On 1/20/2022 23:48, David Brown wrote:

If you want to go into more detail of your reasoning and /why/ you find
hardware design experience helps programming, I\'d be interested to hear
it.  And again, I\'d like to hear if it is particular types of
programming.

All I can say is that hardware design experience has been an integral
part of my growing up as a programmer, I have been putting together
products and then programmed them - obviously I have been buying the
silicon and passive components for these but that was about it.

Without the full experience it is clearly practical to do work based
on less broad areas of experience but it does not take a huge product
complexity to reach a point where making certain decisions takes
as broad experience as one can get. Like which part to do in hardware,
invent algorithms to reach your goal - you don\'t have a lot of chances
to get it right with just superficial knowledge of half the product.

But don\'t take me too literally, I know my experiences do not apply to
many people. Thus obviously what I think is unlikely to be either
a universally applicable truth nor can it be very popular.

Thanks. We are all products of our own experience and history. My
programming history started with BASIC and then assembly on various
systems, and a smattering of a half dozen different languages. Then on
to university with maths, functional programming, algorithms, and more
languages - and an attitude that the actual language is a detail you
learn quickly once you understand the important things programming. In
my working career I\'ve written assembly on more systems than I care to
remember, vast amounts of C, C++, Python, Pascal, and various other
languages. I\'ve done electronics design, FPGA work, big server systems
and tiny microcontroller systems. All of that influences how I write my
code. I like to think I have taken the best parts of those experiences
and use it to write better embedded C and C++ code - but of course we
/all/ like to think like that!

Would I write C code in exactly the way I write it if I hadn\'t done any
electronics design? Probably not. Does that mean electronics design
experience is important for writing good C code? Absolutely not.

It\'s one thing to feel that your own personal experiences make you
better at writing the code you do. It\'s a different thing to suggest
that people /need/ similar knowledge and experience in order to be a
good programmer.