most companies will prefer that you do a _successful_ project - i.e. that you'll get, eventually, something that does what you planned to do, or that will make some kind of (even the tiniest) break-through. however, achieving this in a research project is not very likely.

when people here said "learn something new", they did not mean "invent something new" - they meant "learn something that is new for _you_".

there is a common mistake for undergraduate students (as well as for many graduate students) that they will make something grand with their projects. only very few of them manage to do that (and those people will most likely have no problem getting a job, going to graduate school or whatever). if you have such aspirations - do try to achieve them - but you should not to it "to get a better job" - you should do it because you have an internal drive for that kind of work.

--guy

Boris shtrasman wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi ,
I renamed the subject back (some how it returned back with a different
subject).

shlomo bauer wrote:
HI,

As a former professor teaching software engineering, I was bit
surprised by your posting -- perhaps I misunderstood your intent.

In the end of my studies i need to choose a field of research (or
implementation)
and now im searching for the right way to do it.

After reading in a few ML and forums i noticed that many fail by
choosing too complex project
or having problems to find employment after the degree (B.Sc).
First i wish to understand what people that work in the real world prefer
and from the answers i guess that i understand right :
Many prefer a research rather then an another implementation for a
common solution.

Today i had been told that the preferred field should be chosen from
a pool of fields
(but i still have the ability to choose what project).
So i try to understand what field will better (since all sound
interesting) .
Although software engineering in the large is more about process than
code that's not always the case. For example, software systems
benefit from code refactoring. An example of refactoring
is finding sequences of code that are repeated in a variety of places
and replacing them with
a function call.

The resulting code has the same "meaning" but a different text -- the
refactored code is easier to understand, etc.

Writing a compiler inandofitself is not a software engineering project.

A good project for you might be to look at a tool like valgrind.
Consider how such tool can be incorporated in the software development
life-cycle. Having done so, you might then try to
find a taxonomy of defects (NIST in america published) by frequency,
severity, etc. The
interesting question then is what set of tools would be useful in
helping uncover defects likely
to be encountered by customers as well as ones that are catastrophic.

If you really want to write code. why not do a comparative study of
perl and haskell for a variety of scripting. Why these two? Because
haskell was a big win for perl 6 (I'll leave it to you to find out
why). from a software engineering perspective, language selection
should be based on something more than, "all our code is in perl."

Shlomo
- --
------------ Boris Shtrasman -----------------
|Gnu/Linux Software developer |
| IM : bori...@jabber.org |
| URL : myrtfm.blogspot.com |
| linkedIn : www.linkedin.com/in/BorisShtrasman|
-----------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkowIMwACgkQHiYkXfwAFktwEACfYx9TdNmODytQsjuOF7r2Knc+
O54Anj/VuTV8/SSdcH2fEvBwvVqHLsEi
=lul1
-----END PGP SIGNATURE-----


_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il


_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Reply via email to