Okay, I have more questions & responses

[T. Hoskins]

Hi Jeff and Elena,

In this post, I have combined my responses to some of the posting you both
have made to this thread, as well as, my questions. Elena and Jeff, I will
leave it up to you as to what topics (if any) you wish to respond to.

Maybe it is just my opinion, but I believe these are the type of questions
and discussions are what a software development career forum should have
on them. I suppose there is nothing wrong with asking a question, such as,
"What programming language should I learn". Even so, I have been very disappointed
with the lack of quality discussions (outside of how do I this) that exist
on the web.

<Q> What was your motivation for wanting to move away from the big iron development?

My reasons were simple:
1) Having mainframe only technical skills limits your employability to companies
that have or use a mainframe computer.
2) I felt (know is probably a better word) that I would be trapped maintaining
legacy systems for the rest of my I.T. career. For several years, I worked
as a salaried employee for a large consulting frim tasked with maintaining
dozens of complex software systems that nobody really understood very well.
Some of these systems were pure mainframe systems (with dozens of subsystems),
some were pure PC desktop applications and/or two-tier systems, and some
were hybrid systems (had PC and mainframe elements to them). Of course, the
people who built these systems were no longer around and there was little
if any system documentation available for me to look at.
3) I was tired of being known as a jack-of-all-trades master-of-none type
of consultant (see reason #2). Also, I felt the work that I was doing (maintenance)
was severely limiting my employment opportunites.

I have been monitoring the job boards, local newspaper ads, etc. for several
years and I can't remember seeing even one ad explicitly stating they needed
a maintenance programmer. Several years ago, I remember reading several articles
about how valuable a person would be if they possessed both mainframe and
PC development skills. I think we all know what a bunch of baloney that
statement turned out to be. The only thing that I know of that works when
applying for an advertised job is to reword your resume to make it appear
as if you are "the perfect fit" for the advertised position. If you don't,
you can pretty much forget about getting an interview.

<Q> What attracted you to software development as a profession? Money, fame,
toys, independence, intellectual challenges, etc.? What did you eventually
find?

Money (seemed like a decent way to make a living) and intellectual challenge
is what attracted me. Nowadays, I have been spending an excessive amount
of time thinking about how I can get out of this messed up industry.

The following is just some of what I have found to be the case in this industry:
Unrealistic deadlines, clueless management, long pointless meetings, no training
or mentoring, carpal-tunnel syndrome and severe eye strain, cut-throat colleagues,
long hours, and life as a social outcast.

<rant on>
Software engineers/developers/programmers (or whatever a person wants to
call themselves) have freely admitted themselves into what I call "the cubical
asylum". In doing so we seem to have pigeonholed our profession into a category
that does not necessarily lead to our professional hopes or dreams. Money,
respect, and proper responsibility seem rather scarce nowadays while unrealistic
deadlines, clueless leaders, endless meetings, stress, and anger are in abundance.
Bill Gates, Steve Jobs, and Larry Ellison may have exceeded their dreams.
But they do not engineer software (at least not anymore), they make money
off of software engineers. Their true talent and success is in business,
not software engineering. What profession (if you can what we do a profession)
adopts Dilbert as its poster boy?
</rant off>

>It took me 8 years and 3 or 4 job changes

Unfortunately, your struggles to re-invent yourself sound all to familiar
too me.

>I do agree with the "being a unit" observation. A lot of developers want

>to stay "technical", which is not entirely the same as being an
>individual performer rather than a manager.

Jeff, I am not sure what you mean by the "individual performer rather than
a manager" statement could you expand on this? I do agree with an earlier
assessment you made when you said that large consulting firms don't have
much respect most PC developers. Of course, the reasons why this seems to
be true vary. I guess it all comes down to the amount of money you are generating
(or helping to generate) for the firm. People involved in the "big projects"
(web-based, mainframe, or client-server) will probably always be treated
differently.

>The more senior people in my group (senior being a matter of position
>rather than age) still do a fair amount of coding, but they do an awful

>lot of dealing with the customer and other vendors, leading projects from

>the technical side, estimating, and high-level design. This is on the
>larger types of projects that you mention. Many people don't want to mess

>with those tasks - they want to have a task already defined fairly well

>to the point they can sit at their desk and design, code, and unit test

>it.

Agreed. Most techies simply want to design and code (I know that is what
I would like to do) applications and would like to have the task at hand
already specified for them. If I had to guess, I would say that the majority
of the people who post in this newsgroup only do these two activities (design
and code). To me, the reason why most developers don't want to "mess with
those tasks" is simple.

* It is very difficult for one person to "do it all" in a professional
manner even on a small project. Lack of experience doing the various

messy tasks is only one reason why this is true.
* There is a dozen different ways to do each of those messy tasks. That

is, it can be hard to know which technique to use or even which is
appropriate for a given task.
* In the PC world there is just too much to learn and technology is
constantly changing.
* Coding can be a fun and for many an obsessive activity. Unless you are

doing the same thing over and over again - coding is a very challenging

activity.
* Developers are expected to be technically proficient so it seems only

natural to me that a person would spend most of their time on an
activity that keeps them employed. Now, some companiess may use many

other factors to judge a developers overall performance, however, these

other factors generally tend to be of secondary importance.

A lot more could be said on this subject, unfortunately, I don't have that
kind of time.

>On one site, they had a survey to fill out in addition to my resume, and

>I checked that I had received some training in Java. I got several calls

>asking about my Java experience, like how many years I had coded in Java,

>even though this info was not even on my resume!

That is one reason why I called staffing firms and the recruiters who work
for them vultures. How can these guys call themselves professionals when
they don't even attemp to understand the industry in which they are employed
or the product they are trying to sell? Churn and burn baby seems to be
their motto.

>There definitely is a difference. Some people cannot handle the
>larger-scale applications, while some cannot handle the smaller ones.
>Some people are fine in both environments.

Hmmm... Define handle for me? I know that I wouldn't have made it in your
current group. Personally, I think it takes about 2 years before a person
can be considered to be proficient in Visual C++. Of course, I am including
learning MFC and/or ATL in this estimate. For VB client/server development,
my guess is somewhere around a year. I suppose it all depends on the roles
and responbilities a person is tasked with on a project.

>I was doing a lot of data modeling for the data warehouse stuff so I just

>said - - fine - - if you are going to keep me stuck on this stuff there's

>nothing that says I have to continue to do my modeling in FOCUS, COBOL
>and SPUFI.

<Q> Exactly what type of work were you doing? Data modeling positions --
as I understand them -- generally require the person to model business objects
or data and usually have little if anything to do with coding. Sound as if
you were performing a lot of data extraction work.

>That was enough to get me a job in a company that needed analysis &
>design as well as coding skills.

Hmmm.... No offense, but I think you got lucky on this one. I say this only
because analysis and design in the mainframe world (i.e. Structured Analysis,
Data Flow Diagrams, Structure Charts, etc.) tend to be very different from
the desktop and client/server world (OOA, OOD, UML, etc.). As you know,
designing a COBOL/CICS application that has a 3270 green screen is very different
from developing a desktop application that has several GUI screens. My guess
is that the company that hired you (small consulting firm) probably had a
bunch of young and inexperienced PC developers on their payroll. That is,
they might be a code a C++ or VB application but they couldn't (due to lack
of experience) take a project from concept to code in the manner the company's
clients wanted/needed.

>The company is too small to own a mainframe so I was guaranteed not to
>get any more assignments in that stuff.

Well, so far, I think your assumption has worked out quite nicely for you.
I made this same assumption once and wasn't so lucky.

--------------------------------------------------------------------------
My story of why some people should think twice before accepting a salaried
position with a small consulting firm.

I decided to work for a small consulting firm (who shall remain nameless)
because I ASSUMEed that I was guaranteed not to get any more mainframe assignments.
I believe that I was the only technical person in the company who had a
mainframe background. Anyway, when the PC work that I was doing for one
of their clients dried up, the company tried to place me on a mainframe development
assignment. I was working in the company's office when one of their salesmen
placed the local newspaper's help wanted section in front me. When I looked
at the newspaper, I noticed that a mainframe development help wanted ad had
been highlighted. I was told by the salesmen that he had already set up
an interview for me with the company that had placed the ad. Of course,
I realized why the salesmen had done this (billing is king and bench time
brings in no revenue). I spoke with the company's only manager (an account
manager not a PM) and told him that I wasn't going to go to the interview,
but that I would be willing to sit on the bench for FREE. Well, I am sure
you know what happened next. This person didn't want to talk to me about
my comprise and told me I had no choice in the matter so I quit/got fired?
I think it might have been the latter, but I like to think of what happened
as a mutual business decision.

My comments on this story:
It can be said that helping out in a pinch is what being a team player is
all about. Personally, I think all salaried employees should probably accept
all assignments given to them as long as the work only takes a relatively
short time to complete and it really is a one-time sort of thing. The danger
that I was wary of (and rightly so) is that I might get stuck performing
mainframe development indefinitely. If I took this assignment there was
a good chance all of the following would happen to me:

* My PC development skills/knowlege would quickly deteriorate and/or
become obsolete.
* Working on mainframe applications would keep me away from working on
new skills and technologies within my chosen speciality.
* My employer might forget entirely about my chosen specialty and career

goals.
===----------------------------------------------------------------------

[Jeff]

I agree that this particular board has been lacking in the deeper types of
questions lately. When I first found it, it was because of a link in one
of the DevX emails, and I am not receiving that particular newsletter anymore
for some reason (I didn't decide not to get it). If they dropped that newsletter,
that may account for the lack of the more substantive posts.

As for your questions...

>>I do agree with the "being a unit" observation. A lot of developers want
to stay "technical", which is not entirely the same as being an individual
performer rather than a manager.

>Jeff, I am not sure what you mean by the "individual performer rather than
a manager" statement could you expand on this? I do agree with an earlier
assessment you made when you said that large consulting firms don't have
much respect most PC developers. Of course, the reasons why this seems to
be true vary. I guess it all comes down to the amount of money you are generating
(or helping to generate) for the firm. People involved in the "big projects"
(web-based, mainframe, or client-server) will probably always be treated
differently.

A manager has control of people - they handle all the administrative tasks
involved with dealing with people, such as salary, bonuses, evaluations,
hiring/firing, and all that stuff. Anyone who is not a manager is considered
to be an individual performer. An IP may have some budgetary responsibilities,
and they may have people responsibilities too (they just don't administer
the items I mentioned above), and they may be very influential. But if they're
not a manager as defined above, they're an individual performer. At least
where I am, managers do not handle the same technical tasks as the developers.
They don't code (even though some were very good coders). Well, they made
"code" a spiffy Excel spreadsheet from time to time to satisfy their coding
urge. But they are strictly hands off in the real work. They may get involved
in some meetings that determine how many people to allocate to what task,
but that's about the extent of their project-based work.

As you mentioned, a lot of developers want to design and code. They don't
want to be on the phone or in meetings with the customer trying to convince
them to do things a certain way. They don't want to have to be at the mercy
of a vendor's whims. They don't want to have to deal with issues like this
because they are "people" issues. And that's why I say that developers remaining
in an individual performer role are not necessarily going to "stay technical"
unless they want to limit their career growth. Those two phrases are used
interchangeably around here, when really they should not be.

Four years ago, I switched from a small PC-based application (BASIC in a
DOS environment - it was fun but not going to increase my marketable skills)
to a large COBOL application. I did take on more responsibility by being
the lead developer for three projects, but I don't really think that I worked
any harder or was any more productive that I would have been had I stayed
put. I received $4000 in bonuses, plus a large salary increase. I do not
think I would have gotten the bonuses on the smaller application, and my
salary increase would probably have been less. So, what you do is often not
as important as where you do it.

>>There definitely is a difference. Some people cannot handle the larger-scale
applications, while some cannot handle the smaller ones. Some people are
fine in both environments.

>Hmmm... Define handle for me? I know that I wouldn't have made it in your
current group. Personally, I think it takes about 2 years before a person
can be considered to be proficient in Visual C++. Of course, I am including
learning MFC and/or ATL in this estimate. For VB client/server development,
my guess is somewhere around a year. I suppose it all depends on the roles
and responbilities a person is tasked with on a project.

What I mean is that some people clearly perform better in one of those environments
that the other. Some people have to have a total understanding of an application
before they are comfortable working on it. Some people do not like to have
to explain their actions and choices to a large development team. Some people
would prefer to deal with as few people as they have to. These people are
better on a smaller application. Other people have to be around more experienced
developers - they are not comfortable making a decision without a consensus.
Some people thrive on the interactions with other team members - asking them
questions, explaining things to them, discussing the merits of one approach
over another. They like being in charge of the work done by a team. They
don't mind all the ambiguity involved in a large project. They think working
on a small independent project is boring. These people are better off on
a larger application. Some people work fine in either environment, some can
perform well in only one or the other.

Let me know if you have any more questions. This is good stuff to discuss.

[Elena]

<Q> What was your motivation for wanting to move away from the big iron development?

Jobs were drying up fast and the ones that remained weren't that interesting.
That is, of course, a broad generalization - - there certainly are pockets
of mainframe work here and there but for the most part it's on the decline.
I talked to enough recruiters and employers to get the message. We may
be heading for some intermittent shortages as the mainframe programmers in
their 50s leave and there aren't enough younger people to fill in, but I
still think the writing's on the wall.


<Q> What attracted you to software development as a profession? Money, fame,
toys, independence, intellectual challenges, etc.? What did you eventually
find?

I like problem-solving and this is a problem-solving job. The money has
been OK - - certainly not spectacular but better than a lot of other professionals
make. Also despite the current economic downturn, the field has expanded
steadily since my college days in the late 70s.

>>The following is just some of what I have found to be the case in this
industry: Unrealistic deadlines, clueless management, long pointless meetings,
no training or mentoring, carpal-tunnel syndrome and severe eye strain, cut-throat
colleagues, long hours . . . <<

Except for maybe the carpal-tunnel, you'd probably get the same complaints
from attorneys, medical professionals and engineers. I'll bet your hours
were nothing like the first 5 years of a doctor's career. A lot of attorneys
never get away from the massive OT. And while some doctors and attorneys
make huge salaries, the majority do not. Doctors have to fight the HMOs,
attorneys climbing the corporate ladder face far more infighting and politics,
etc. etc. My point is that very few professions are a bed of roses.

>> . . .and life as a social outcast. <<
This seems to be a non-sequitur to me. Why should working in IT make you
a social outcast?

>> Money, respect, and proper responsibility seem rather scarce nowadays
while unrealistic deadlines, clueless leaders, endless meetings, stress,
and anger are in abundance. <<

Again, these are things that EVERYONE complains of regardless of profession.
As for Gates, Jobs and Ellison, they were (are) very unique individuals.
Part of their success was in their own extraordinary capabilities and part
of their success was in the timing - - they recognized and seized business
opportunities that others missed. If you want to build a "Bill Gates" fortune
today, you can't do it writing PC software. That market is saturated. You
have to find a new market, a new business opportunity. Someone will do it.
It won't be me because I just don't have the vision.


>>It is very difficult for one person to "do it all" in a professional manner
even on a small project. . . Developers are expected to be technically proficient
so it seems only natural to me that a person would spend most of their time
on an activity that keeps them employed. <<

Actually, most developers that work in smaller organizations routinely "do
it all". They must understand both the business and the technical side.
Now, we don't have all the fancy tools to work with, but we take projects
from concept to roll-out on a regular basis.

There's a couple posts in this forum about the sky falling in on the IT profession.
I don't really agree, but if you are only interested in coding then you
are headed for trouble. Coding to predefined specs is precisely the work
that is most easily shipped overseas.


<Q> Exactly what type of work were you doing? Data modeling positions --
as I understand them -- generally require the person to model business objects
or data and usually have little if anything to do with coding. Sound as if
you were performing a lot of data extraction work.

Data modelling can mean different things. In my case, I was not designing
business objects at all. When you work on data warehousing projects, you
are basically scouring various corporate data sources looking for data than
can be scrubbed and transformed into useful strategic information. You compare
multiple sources looking for trends and contradictions and then try to resolve
the questions this raises. I used the words "data modelling" in the way
you might use the words "statistical modelling". You get a theory, you crunch
data from as many sources as you can to determine if your theory is any good.
You develop processes to present the information (in the warehouse) so that
the business leadership has the best information available when deciding
where to invest, where to pull back. This requires a lot of ad hoc extraction
as you search for the "truth" in the vast piles of numbers. And you need
to understand the business behind the data or your initial theory will be
off track. Perhaps there is another name for this exercise - - that's the
best one I have. I've also heard people use the word "Data Base Analyst"
in this context.



>That was enough to get me a job in a company that needed analysis & design
as well as coding skills.
>>Hmmm.... No offense, but I think you got lucky on this one. <<

Gee, after 8 years and 4 job changes - - I don't call that particularly lucky.
Anyway, as I described above, I wasn't doing the Structured Analysis thing
and the presentation layer for the data warehouse was PC-based client-server,
not 3270 green screens. I just wasn't the one coding the presentation layer.
But I had to design the data structures and populate the tables to support
it.

>>My guess is that the company that hired you (small consulting firm) probably
had a bunch of young and inexperienced PC developers on their payroll.

No. The majority of our people (at the consulting firm) have 15 years or
more. They generally stay away from newbie programmers because they can
only charge commodity rates for them and we leave that to the big body-shops.
It's the CLIENT that is very small, not the consulting firm.

However, I did have several jobs with companies that did not yield the opportunity
originally advertised. Two of these companies were Fortune 50. It's not
size of the company that determines this. It's a combination of factors
related to changes in the business environment, changes in the organization's
structure, changes in top management, etc. Alas there is no clear way to
lock this down when you hire in. You ask all the questions you can in the
interview process and make your best analysis. That's all anyone can do.



Regarding your difficulties in finding the work you want to do . . .

This struggle goes on whether you are a consultant or FTE, working for a
large company or small. There are no guarantees of employment for anyone.
Any time some manager tells you "4th quarter we'll have an opening in area
X" or something like that they are usually just giving you their best reading
of the crystal ball. Sometimes you get someone who intentionally deceives,
but I believe in my case, most of the "promises" (that word might be too
strong) were broken because of one or more of the following reasons:

1. The company was acquired by a new parent with a different strategy
2. The market conditions changed drastically and the company had to adjust
accordingly
3. A new executive came in with a dramatically different philosophy about
what types of projects should be done, what platform should be used, etc.


You give each opportunity some time and then you move on. And remember that
companies are in business to do business, not to make your dreams come true.
That's up to you.

Some of this comes down to your philosophy of life. I always come back to
the words "life, liberty and the pursuit of happiness". Emphasis on pursuit.
No guarantees for anyone. You can go thru life angry and disappointed or
you can adjust and discover whatever interesting things come up along the
way. If you lock on to a very specific goal - - "I must work with this technology
or for that size company and make a particular salary" then you might end
up disappointed. Or you might realize your precise dream and live happily
ever after.

Reading your post I'm wondering if you would be happier working for yourself
rather than for others. I have friends and family members that have done
this and some find it greatly rewarding even if they didn't make a pile of
money. But then you REALLY have to be ready to "do it all"!

I hope you find what you desire.

Elena

[simon]

"Elena" <egermano@comcast.net> wrote in message
news:3cc473b4$1@10.1.10.29...
<snip>
> Except for maybe the carpal-tunnel, you'd probably get the same complaints
> from attorneys, medical professionals and engineers. I'll bet your hours
> were nothing like the first 5 years of a doctor's career. A lot of
attorneys
> never get away from the massive OT. And while some doctors and attorneys
> make huge salaries, the majority do not. Doctors have to fight the HMOs,
> attorneys climbing the corporate ladder face far more infighting and
politics,
> etc. etc. My point is that very few professions are a bed of roses.
>
The neighbor's grass always look greener. =)

simon.