Software Engineering - What do you do as a software engineer?

Author

What do you do as a software engineer?

Susan.MKLau@gmail.com

2005-11-22, 7:00 pm

Hello, I'm currently enrolled in software engineering at Mohawk College
in ontario, canada and I'm wondering what you do at your job? Comp-sci
is a pretty broad field, but I'm having trouble getting an idea of what
you do for the companies yoru work for or where I could possibly end up
career-wise in a few years.

David

2005-11-23, 3:57 am

Hello,

On Tue, 22 Nov 2005 23:35:58 UTC, Susan.MKLau@gmail.com wrote:

> Hello, I'm currently enrolled in software engineering at Mohawk College
> in ontario, canada and I'm wondering what you do at your job? Comp-sci
> is a pretty broad field, but I'm having trouble getting an idea of what
> you do for the companies yoru work for or where I could possibly end up
> career-wise in a few years.

If you have some free time, try to contact a local company and spend
some time with them. Ideally they should be involved in some engineering
aspect and perhaps computer related. Actually spending time with someone
and asking questions is a good way to learn. You can even visit a group
on campus. It is a very good idea to understand what your opportunities
your chosen career might offer.

I grew up with an engineering and computer background and graduated many
years ago. While I started out performing application work I quickly
graduated to more complex tasks. I've been in the telecom, medical,
military, and operating system disciplines. An engineering approach is
very good for my tasks because the products I choose to create and
maintain must always work and perform well. While it might be acceptable
for a GUI application to slow down or perhaps crash, the products I work
on can affect peoples lives. Not everyone works on such products, but
an engineering background will help you manage the risk involved in
your work and generally perform better.

I am currently responsible for my entire product line's development
and maintenance. Obviously there are sales and management issues of
concern too, but I try to make sure that what we product is as usable,
manageable, and reliable as possible. I still code and verify everyones
work. The designs are generally mine and it is my stamp of approval
that goes on the products... and my responsibility when things go wrong.

So while you are exploring your computing and engineering interests
and later your first career opportunities, keep in mind what it is you
want to do and what you are capable of at the time. We build on what
we know and are always learning.

Good luck with your education and chosen career,

David

H. S. Lahman

2005-11-23, 6:59 pm

Responding to Susan.MKLau...

> Hello, I'm currently enrolled in software engineering at Mohawk College
> in ontario, canada and I'm wondering what you do at your job? Comp-sci
> is a pretty broad field, but I'm having trouble getting an idea of what
> you do for the companies yoru work for or where I could possibly end up
> career-wise in a few years.

"Pretty broad" is a bit of an understatement. B-) There probably more
disparate specialties than Medicine.

My advice is not worry about it until 2nd term Junior Year. Until then
just sample as much as you can in electives and then specialize the last
1-1/2 years doing what interests you most. However, there are some
broad categories that might help prune things.

Hardware Control (aka Real-Time/Embedded). It usually helps to have an
EE degree but it isn't essential. (I spent two decades there with
training as a geologist but the learning curve is a long haul.) If you
want a challenge in getting things to work, this is it. Most of the
Good Practices we take for granted today grew up here because it is a
very unforgiving environment. Thinking in terms of bits, concurrent
processing, and asynchronous communications tend to turn one's mind to
mush. It is also often a very tough environment to work in because
often one doesn't have the convenient tools. (Trying debugging a 3 MLOC
application in the field in Assembly because one doesn't have the
sources and the OS doesn't support 3GL debuggers anyway.) Be prepared
to do a lot of debugging with an oscilloscope and voltmeter looking at
hardware registers because the hardware Guys usually regard software as
the best way to debug the hardware. [In fairness, a lot of hardware
control nowadays is so complex that it is done on very hefty computers
where only one small layer actually talks to the hardware.]

Scientific. This is classic algorithmic number crunching, typically in
Operations Research specialties. If all you are doing is encoding
existing algorithms it tends to be a bore. But if you get into leading
edge problems without conventional solutions it can be fascinating. (I
spent a decade doing simulation models in a variety of domains and I
would recommend that because each domain is unique.) Computer game
graphics is a classic cutting edge example where one needs to invent the
algorithms as one goes. However, one needs really strong math.

Information Technology (aka Management Information Systems; aka Data
Processing -- they keep changing their image). This used to be the
realm of USER/CRUD processing where big corporate shops had acres of
entry-level COBOL programmers churning out reports. In volume most
processing still is USER/CRUD, but it is often handled using RAD IDEs
and most of the core systems are sold OTS rather than being built
in-house. So today IT is solving much more complex problems like
inventory control that look a lot like Operations Research. It is also
beginning to look a lot like hardware control because of networking,
interoperability, and whatnot. So the traditional view of IT no longer
applies and there are a lot of challenges. For variety you get a lot
closer to solving major customer problems and the main learning curves
are in computing space technologies. (Note that MIT's Sloan School
became a preeminent B-School by being one of the first to emphasize
crunching numbers on a computer as a management tool.)

Software Process. I spent 40-odd years in the business doing IT,
Scientific and hardware control. In the end it all looked pretty much
the same; one was just pushing bits from one pile to another. So for
the last few years before retiring I got interested in the process side.
That is, the process of constructing software itself.

IMO, the industry is facing a major paradigm shift over the next decade
or so that is already partially manifested in outsourcing and offshore
development. Cheap labor rates only get a conversation started because
the hidden costs of arm's length specification and project management
are huge. What is causing the outsourcing and offshore migration is the
fact that those shops are more likely to deliver a quality product on
time than most ad hoc in-house shops. So the Customers of software are
beginning to notice that the only thing that breaks in their lives is
software and they are looking around for somebody to do the job better.

Though the offshore shops may be better at schedules and quality because
they started up with a lot of hindsight, they are far from perfect and
that is what will drive the paradigm shift on the way software is
developed. So if you want an area with a lot of long-term potential,
focusing on how software is developed rather than specific product
arenas may pay big benefits.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

Arnold

2005-11-24, 6:58 pm

H. S. Lahman wrote:

> Software Process. I spent 40-odd years in the business doing IT,
> Scientific and hardware control. In the end it all looked pretty much
> the same; one was just pushing bits from one pile to another. So for
> the last few years before retiring I got interested in the process side.
> That is, the process of constructing software itself.
>
> Though the offshore shops may be better at schedules and quality because
> they started up with a lot of hindsight, they are far from perfect and
> that is what will drive the paradigm shift on the way software is
> developed. So if you want an area with a lot of long-term potential,
> focusing on how software is developed rather than specific product
> arenas may pay big benefits.

Mr. Lahman

I am also considering Software Process as a long-term career goal.
Currently I am an MIS developer.

How would you suggest I go about getting into the 'process' side of things?

I would imagine I should attend software process improvement courses,
get certified as a CMM (or similar) assessor or get to work on process
improvement projects at my current employer.

Thanks in advance for you advice.

H. S. Lahman

2005-11-25, 6:59 pm

Responding to Arnold...

> I am also considering Software Process as a long-term career goal.
> Currently I am an MIS developer.

<marginally related aside>
Back in the mid-'90s I attended an ASM conference where the emphasis was
on quality. I took my own informal survey by talking to people from
shops that were known for software excellence. Two things were striking
in that survey. First, all the best-in-class companies (at that time)
were primarily hardware companies -- HP, Motorola, IBM, etc..

Perhaps more insightful, when I talked to people from those companies it
turned out that software quality varied a great deal within those large
companies. Thus the same company might have one group that was CMM L5
and another group that was CMM L1. The interesting thing about that
disparity was that the groups with the best quality were invariably
dealing directly with hardware (e.g., building device drivers) while the
groups with the worst quality was as far away as one could get (i.e., MIS).

FWIW, I have a theory to account for that. As I noted in my original
post, hardware control is a very unforgiving field and good practices
are a matter of survival rather than convenience. Thus many Good
Practices (modularization, layering, APIs, etc.) that we take for
granted today grew up in that environment. In addition, the hardware
people had just completed a very traumatic period of catch-up in quality
after getting the crap knocked out of them by the PacRim nations in the
late '70s and early '80s.

So the hardware people had their act together and managers of Systems
Development started asking the software people why they didn't have
their act together in the same way. Therefore, because of direct
pressure, inherent need, and close association the hardware control
people were they first ones to learn about process control from the
hardware people. Gradually successes migrated through the corporate
structure away from the hardware control arenas within those large
organizations.

My point in this anecdote is that you may have a hard row to hoe. B-)
Though there are exceptions nowadays, it is much tougher to find an MIS
shop that takes process control seriously than in other arenas. Which
segues to...
</marginally related aside>

> How would you suggest I go about getting into the 'process' side of things?

The best way is by getting a job at a shop that is militantly practicing
some form of process control. It doesn't have to be CMM; there are
several process-oriented frameworks like TQM, Baldridge, and Six-Sigma.
There tends to be a long step between the theory presented in books
and training and the actual practice. So getting practical experience
in an environment that is doing good process control would be very valuable.

Alas, there aren't that many such shops yet and the competition to get
into them tends to be stiff. So the next best thing would be...

> I would imagine I should attend software process improvement courses,
> get certified as a CMM (or similar) assessor or get to work on process
> improvement projects at my current employer.

....the academic approach. Sadly, there aren't that many schools yet
that do a good job at this sort of thing yet and even fewer that provide
a degree or certificate specialty in it. It's also kind of expensive.
That's the problem with being on the cusp of a paradigm shift. B-)

Actually, I got my start back in '84 by instigating process improvement
in the shop where I worked. Unfortunately I didn't have a clue how to
do it so it was not real efficient. The company bought into TQM in the
late '80s and that provided a much-needed framework. Even more
structure was provided by going with CMM in the late '90s, but by then
we already had a good culture in place.

[In '84 we had a disastrous release that missed a 9-month schedule by 24
months, the mean time to crash was about 40 minutes, and we were in
perpetual Crunch Time with 70-100 w

s. From a professional viewpoint
it was embarrassing as hell. When I retired in '00 we got an award for
600 systems running over a decade with MTTF of 2.7 years, we hit
schedules a year out +15/-5%, and hardly ever worked overtime. So there
was a pretty huge payoff for that effort, fumbling as it might have been
initially.]

The moral here is that if you decide to continue with your current
employer, you could get much further along that I was when starting out
by simply researching the alphabet soup of process control frameworks
for tools, goals, philosophy, etc.. However, I have to caution you that
it will take a lot of sales work and potentially there will be a lot of
resistance. That is, you are going to have to put in a lot of hours on
your own. Improving the process is the easy part; the tricky part is
getting a good opportunity to do so. IOW, building the right culture
for process improvement is crucial but it takes awhile. So you need a
Plan once you finish your research

From my personal experience I would strongly recommend taking things
very slowly. Don't try to sell an entire process framework. In fact,
don't even mention it except as a peripheral source for "good ideas to
try out". When you implement some practices, do it small scale and in a
controlled environment where you can provide hard data to demonstrate
the benefits. That is essential for building credibility. Then keep
nibbling at the problems until you have a fait accompli implementation
so you can call in the assessors.

[BTW, IMO calling in assessors for a CMM L1 shop is a real good way to
waste $100K. All the assessors are to tell you is what you will already
know after reading the book: the shop isn't doing most of the things it
should be doing. So implement the CMM to the point where you think you
are most of the way there before calling the assessors in. Then their
criticisms will be focused enough to be useful and you will already have
the infrastructure in place to act on them efficiently.]

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

rodneyhoffman@gmail.com

2005-11-28, 7:00 pm

Susan asked:

> ... I'm wondering what you do at your job?...

Try this:
<http://campus.acm.org/crc/cri/categ...d=61&CFID=25374>
"To learn what a typical day is like in a particular profession, please
visit A Day in the Life and Profiles of Professionals."

-- Rodney

Sponsored Links