Subject: What is Software Engineer? (RE: [hackers-il] Re: packers and mapp ers)

From: Omer Musaev <[email-masked]>
Date: Thu, 28 Nov 2002 15:54:38 +0200

' -----Original Message-----
' From: Shlomi Fish [mailto:[email-masked]]
' Sent: Thursday, November 28, 2002 2:36 PM
' To: [email-masked]
' Subject: [hackers-il] Re: packers and mappers

Hi Shlomi,

' Some people will become better programmers in 1 year, than 
' many would in
' 10 years.

I have 3 questions that I am not sure I have answers to. I would like 
to hear the Hackers' opinion.

1. Let me start with a few almost rethorical questions: 
	What is meant by statement "become better programmers"? 
	What is better programmer? 
	How can we state that programmer A is better than programmer B? 
These questions seems to be flame baits, but they are not intended
to be so. The real question is:
	What are the criteria that can be used to judge quality of a
programmer?

2. What is a difference between a programmer and a software engineer? 
The trick's that while some engineering disciplines are fully developed,
e.g.
mechanical, civil or aerospace engineering, the "software engineering" still
sounds like a buzzword. You can find the term used at many occations; 
however there is no such thing as engineering duties upon software
engineering. 

There is no activity that must be approved and certified by a software 
engineer, contrary to civil engineering field where an engineer who signes
on the project bears criminal responsibility on the project's qualities.
There isn't "Israel's state software engineering bureau" neither.
However, the term is in wide use.  

I would like to know the list's opinion (prefferably backed by evidence,
common 
sence and citations) on the topic.

3. Let's take the first question, and s/programmer/software engineer/g it.
How 
the answers would vary?

Sincerily yours,
--
Omer Mussaev 
Mercury Interactive R&D
Topaz EMS team

---

From: guy keren <[email-masked]>
Date: Thu, 28 Nov 2002 17:10:20 +0200 (IST)

> 	What are the criteria that can be used to judge quality of a

wihtout trying to impose an objective answer - try taking a subjective 
"Definition" - you work with that person, and you just 'know' if they are 
good or bad ;)

i know that i often go and classify people as 'good programmers', 'bad 
programmers', without using a solid scale for measuring it. its not that 
there's no such scale at all - its just that i don't yet know how to 
formally define it.

when i consider a programmer as 'good' or 'bad', i most likely go by 
factors as:

- does it feel good to read their source?
- when i need to modify their source - is that hard for me, or easy?
- do they manage to do what they do in a time i consider to be reasonable?
  faster? slower?

i measure this both when the code is first written, and again several 
month, or a year or two afterwards. some qualities of good code only 
reveal themselves after a while.

> 2. What is a difference between a programmer and a software engineer? 

a programmer works in a usually non-predicteable and non-controllable 
manner. an angineer would define what they want to do, design it fully 
(at a high-level), supply a time table, keep track of how they go by that 
time table, design the code to be easy to test and document fro the 
beginning, rather then doing that an as after-thought. in short - an 
engineer can, given a fixed ammount of time and budget, tell you how well 
the software could be, and then do it as they stated. a programmer can 
write the software without this predictability - and without using the 
same methods over and over again.

naturally, most 'inventions' would come from non-engineers - cause the 
engineer is too busy doing things according to a pre-defined 'process'.

> however there is no such thing as engineering duties upon software

the engineering part perhaps is not fully developed, but yet it does not 
mean you can try to turn your own processes into semi-engineering.

device a method, find if its useful, and if it is - stick to it. this 
comes down to varioud mundane work - but engineering is not art. when we 
were children, we were always told that programming is an art, not a 
craft. but it does not have to stay like this. ofcourse, many people won't 
like this - but i guess the same process happened to other professions. 
look at how thomas edison developed electrical products. look how they do 
it now.

> However, the term is in wide use.  

there is no _external_ responsibility. but one can still have their 
personal integrity, and develope responsibility from there - rather then 
waiting for some external source to make them feel responsible.

> 3. Let's take the first question, and s/programmer/software engineer/g it.

they vary in the 'predictability' manner, i suppose. you'd expect more 
predictability form an engineer, then from a non-engineer. ofcourse, there 
are many examples of engineers not doing somehting in a predictable time 
(i.e. processes running late) in clasical engineering scenarios - but this 
is mostly when doing 'something new', which requires delving into 
something that people don't have enough knowledge about - and thus is 
quite inpredictable by its nature (can't predict how long it'll take to 
solve problems - if you don't know they exist).

so, if you want to be an engineer - i'd stay, statr by developing your 
ability to asses how long tasks will take. complete tasks - not just 'what 
we think the task is now'. take your next project, and start devising your 
own work plan for it. give osme time to each part of the work. then do it, 
fiind by how much you were wrong, and next time, use it to factor your 
times. i currently use a factor of about 1.5 for my time estimates, when i 
know _i_ need to do them, and a different factor if someone other then me 
needs to do the task. i used to use a factor of 2 when i was going to work 
on things similar to what i did in the past, and a factor of 3 when i was 
going to do things quite different from what i used to do in the past.
when you put the factor in, you'll say "hei, but this seems much more time 
then's needded to actually perform the task". but you'll find out, 
eventually, that it was not. the testing, playing with the exact 
interfaces to write, integrating with other parts of the code, and doing 
other things you didn't think about originally (ouch!, we need to develope 
a proper logging module, or find one that works - we forgot to account for 
this in the time tables).

and the important thing is - check out how well you work by the work plan. 
don't change the timing every few days - if you start slipping - cut 
features, or write the code less optimally - rather then stretch the time 
table. with time you'll find, that if you do this truly, wihtout trying to 
lie to yourself, your predictions turn more and more accurate. and your 
ability to devise such predictions for larger and larger projects, will 
increase.

but then again - many people find this boring, and don't do it. they can 
be programmers - but they are not engineers. they can be much more 
productive then good engineers - which is why you sometimes would prefer 
one hell of a hacker, then a pair of engineers. ofcourse, you can't run a 
company without some minimal predictability - but you can run free 
software projects in this manner.

-- 
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

---

From: Oleg Goldshmidt <[email-masked]>
Date: 28 Nov 2002 16:56:17 +0200

Omer Musaev <[email-masked]> writes:

> The trick's that while some engineering disciplines are fully
> developed, e.g.  mechanical, civil or aerospace engineering, the
> "software engineering" still sounds like a buzzword. You can find
> the term used at many occations; however there is no such thing as
> engineering duties upon software engineering.
> 
> I would like to know the list's opinion (prefferably backed by
> evidence, common sence and citations) on the topic.

Without writing a long rant on the topic (which seems interesting and
important to me), let me just mention that these issues are actively
discussed among members of various engineering organizations,
including the software engineers (whatever that means). I am a member
of IEEE, and I see such discussions in IEEE literature. I have not
seen a clear statement that would resolve the question for me.

Note that some engineering organizations pride themselves on running
programs of professional certification of engineers. IEEE doesn't, but
the British IEE does, for instance. As far as I can tell, such
certifications are taken seriously by engineers. I don't really know,
but I would not be surprised if it were not unlike being a member of
the Bar for lawyers.

The differences include a degree, a period of internship, independence
of vendors, and, I suppose, a degree of responsibility for one's work.
(Has anyone checked s/w vendors' warranties lately? If a program does
not work as expected or as advertised, the vendor bears no
responsibility. I'd like to hear about counterexamples.) 

Some difference is that the ordinary civil or construction or
electrical engineer deals with issues related to people's safety
regularly, whether he/she builds a bridge or a house or a power plant.
Very few software engineers deal with safety issues. Where they do,
they often do a good job. Remeber Feynman's account of his
investigation of Challenger disaster? The software people came out of
it with flying colors for the most part.

IEEE also has an ethical code - quite an interesting read, if you
care,

http://www.ieee.org/portal/index.jsp?pageID=corp_level1&path=about/whatis&file=code.xml&xsl=generic.xsl

- it may seem obvious, but think how many times you've been pressured
by management to break, for instance, paragraph 3. There is
also

http://computer.org/tab/code11.htm

which includes *a* definition of software engineer, and the notion of
approval of software for use, among other things.

Recently, there was a little bit of fuss because one engineering
organization (in Canada, I believe), objected to the use of "engineer"
in MCSE:

http://www.theregister.co.uk/content/28/28040.html

http://www.theregister.co.uk/content/28/28109.html

The computing professions have become so common and so easy to enter
over recent years, and in such explosive a fashion, that any sort of
professional guild that would maintain professional quality standards
did not appear - yet. 

I think that this is a crucial point - the existence of a professional
guild that would strictly enforce professional standards, conduct, and
ethics, effectively resisting pressure from, say, software vendors.

I would venture an opinion that no one but software professionals
themselves can create such a guild. It is not clear to me how
evaluation of software engineers should be handled. Something tells me
that somehow open source would be essential (any serious evaluation
should be based on the "show me the code" principle).

I wonder if there is any interest in trying to work out the beginnings
of such principles. I can get in touch with the Israeli chapters of
IEEE and IEE, for instance, and ask for pointers to how to start. But
it must be a "guild" effort, not an individual's initiative.

-- 
Oleg Goldshmidt | [email-masked]

---

From: guy keren <[email-masked]>
Date: Thu, 28 Nov 2002 17:40:24 +0200 (IST)

> seen a clear statement that would resolve the question for me.

why do you need _others_ to solve these problems for you? when i have a 
questoin that does not have a 'strict true answer' - i'd rather trust my 
own judgement, then the judgement of people i'm not even familiar with.

i know, i have a problem with trusting people - perhaps you don't ;)

> responsibility. I'd like to hear about counterexamples.) 

now, requireing a degree is rather stpid. what should be required is 
knowledge - not papers. on the other hand - that's how almost everything 
else is handled - so i guess we won't be able to keep the papers from 
taking over software engineering as well.

[ .. snip ..]

> by management to break, for instance, paragraph 3.

this is only the hsort version of their code - not very representitive of 
IEEE documents, is it?

> There is also

and then look at this line form the above 'code':

----------------------------------------------
 4.02 Only endorse documents either prepared under their supervision or 
within their areas of competence and with which they are in agreement.
----------------------------------------------

i would think this document falls into the same category - so i could 
apply this statement in order to reject the document itself. but then - i 
reject it based on the contents of the document which i just rejected... 
hmm ;)

i was once asked at work to sign on this document (or some variation of 
it) - and i refused, because i can't sign somehting which my boss (that 
told all of us to sign it) keeps leading us to break what's stated in this 
document. eventually, one person (i think) signed this document - not out 
of their own free will.

[ .. snip ..]

> it must be a "guild" effort, not an individual's initiative.

the question is actualyl - do _you_ have such an interest? i know i don't. 

heck, lets form up the steering commitee! ;)

-- 
guy

---

From: Shlomi Fish <[email-masked]>
Date: Thu, 28 Nov 2002 17:59:18 +0200 (IST)

What Oleg raises is interesting. Like I stressed earlier, I do not see
a B.Sc degree a necessity to be call someone an engineer. Furthermore,
some graduates of Engineering schools are not engineers as far as their
profession is concerned.

Usually, I don't refer to myself as a software engineer. I prefer the term
programmer (or Metakhneth in Hebrew) which is more plain and less
ambitious. I occasionaly use the term "software engineering" instead of
programming, computing, CS, or whatever to stress something. Either it can
mean managing a software team, constructing software well, etc.

For instance, I have a hard time qualifying an american hacker I work
with, who graduated from EE studies in the 40's and gradually converted to
programming (he is now a grandfather who also makes a living from
programming software for Windows) as a "software engineer". He is simply
unaware of many important techniques and methodologies (pointers, OOP, FP)
and his code is very unmodular and unclean. So I simply say that he is not
really a software engineer, but he is a knowledgable and experienced
programmer.

Then there is software engineering as managing a team of programmers,
which is something entirely different. Being a tool, software can be
engineered like everything else: a bridge, a building, a microprocessor
(which is mostly a variant of software), so I don't see the term as
inappropriate or contradictory. Of course, like my former fellow worker
said, Engineering was taken out of Mechanical Engineering and extrapolated
to other fields. (or maybe it evolved from the engineers who handled the
train's engine - I don't know).

In any case, to become I see being a good software engineer (in the
software construction sense) as a necessity for being a good programmer. A
great programmer is by necessity a good software engineer. And a good
software engineer is a good programmer.

Regards,

	Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: Oleg Goldshmidt <[email-masked]>
Date: 28 Nov 2002 18:26:41 +0200

guy keren <[email-masked]> writes:

> why do you need _others_ to solve these problems for you? when i
> have a questoin that does not have a 'strict true answer' - i'd
> rather trust my own judgement, then the judgement of people i'm not
> even familiar with.

Omer asked a question that seems interesting enough to you and me,
judging by the fact that we both posted responses. I am afraid that
you are misreading my posting, Guy. I did not urge you or the whole of
hackers-il to endorse IEEE's documents or anything of the kind. I
simply pointed out that the question is being actively discussed, both
by the software engineering community and by the general engineering 
community. Striving to be a good software engineer [grin], I am all
for code reuse and self-education.

> i know, i have a problem with trusting people - perhaps you don't ;)

If you insist that you are not interested in what others think of an
issue, and what solutions have been proposed - fine. I am. Somewhere
in the back of my mind a suspicion lingers that so are you,
provocative statements to the contrary notwithstanding.

No, I don't trust anyone blindly. Nor do I assume that I can solve any
problem that comes my way correctly and efficiently without learning
what others, some of whom could by some strange whim of fate be just
as smart or smarter than me, have done in the field. I might even
agree with some of their conclusions in the end. ;-)

> knowledge - not papers. 

I think you are missing the point. A degree is not enough. And a
degree is useful for the vast majority of people. It is a rare case
when a talented autodidact reaches a high level of professional
competence in a technical field.

Suppose you go straight for the apprenticeship stage, come to an
experienced engineer, and ask to be accepted into his shop. An answer
"go study the basics first" seems perfectly valid to me in most cases.
After that, the knowledge and skills you gained at a university are
not deemed sufficient all and by themselves. Nor is your diploma.

And by the way, the big difference that systematic education makes is
not lectures, it's exams.

The system of apprenticeships is at work inside the academic world,
in the form of advanced degrees and postdoctoral fellowships. In most
academic fields, at least in exact and natural sciences, you cannot
get a tenure-track position anywhere before you pass these stages.

The engineering professions deem practical, industrial apprenticeships
necessary, in addition or instead of (advanced) academic ones. So do
the medical and the legal professions. But in all these cases getting
systematic education is - justifiably, IMHO - a prerequisite. 

Implicit in all this is the assumption that diplomas mean
something. That is why there is a difference between the Technion and
a distance-learning university that will give you a nice-looking piece
of paper for a reasonable amount of freely convertible currency. I
would assume that the Technion is striving to preserve the difference.

> this is only the hsort version of their code - not very
> representitive of IEEE documents, is it?

I think it is in fact the only version. ;-)

> > http://computer.org/tab/code11.htm

Here, you see both the short and the long versions. The long one is
not too long, either. ;-)

---

From: Gilad Ben-Yossef <[email-masked]>
Date: 28 Nov 2002 21:28:21 +0200

> 	What are the criteria that can be used to judge quality of a

A programmer is someone that has some mastery of systematically altering
a formal (or quasi-formal) system to do his bidding.

He is a good programmer if he or she has good understanding of the
mechanisms involved and if he or she can use this understanding to
predict the results of his or her actions in relation to the formal
system.

> however there is no such thing as engineering duties upon software

IMHO, programmer denotes anyone that programs. He might be programming
the next Linux kernel or programming his VCR. The term is *usually*
applies to peopel who program on a regular basis and have acquired some
mastery of the art involved and understand at least some of the beasic
concepts of the science behind it (two quite unrelated things btw).

Software engineer on the other hand (again, IMHO) is someone that
programs software on a proffesional basis - it is his job. It denotes
formal education or equivilient expreince. Of course, every software
engineer is also a progrmmer. The opposite is not always true.

You can be a progrmmer that knows nothing os software - biologists that
conduct genetic manipulation are DNA/RNA programmers. People who engage
in mematic engineering might programmers if they do that systematically
and so on and so forth.

> 3. Let's take the first question, and s/programmer/software engineer/g it.

s/quasi formal system/software/

Gilad.

-- 
Gilad Ben-Yossef <[email-masked]>
http://benyossef.com

 "Geeks rock bands cool name #8192: RAID against the machine"

---

From: Gilad Ben-Yossef <[email-masked]>
Date: 28 Nov 2002 21:34:31 +0200

> own judgement, then the judgement of people i'm not even familiar with.

"And what is good, Phaedrus,
And is not good-
Need we ask anyone to tell us these things?"

These are the opening lines of "Zen and the art of Motorcycle
Maintainance" - a MUST READ book for anyone who thinks about issue of
"what is a good X", because it deals with the question of what is "good"
in general.

I guess that if I was Phaedrus (the protagonist of the book, not the one
from Plato), I would answer Omer like this: I will tell you what what a
good programmer is if you can tell me what "good" is - to ask what has
quality, one must understand (if not define) quality itself.

Gilad.

> To unsubscribe from this group, send an email to:
> [email-masked]
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
>