D
David W. Fenton
I found that this little Coding Horror post encapsulates the most
important lesson I've learned over my 10+ years of professional
Access development:
http://www.codinghorror.com/blog/archives/001033.html
Quoting there from Bruce Eckel:
Usually the things that make or break a project are process and
people issues. The way that you work on a day-to-day basis. Who
your architects are, who your managers are, and who you are
working with on the programming team. How you communicate, and
most importantly how you solve process and people problems when
they come up. The fastest way to get stuck is to think that it's
all about the technology and to believe that you can ram your way
through the other things. Those other things are the most likely
ones to stop you cold.
The article later continues to say:
It may sound trivial to focus on the people you work with over
more tangible things like, say, the actual work, or the
particular technology you're using to do that work. But it isn't.
The people you choose to work with are the most accurate
predictor of job satisfaction I've ever found. And job
satisfaction, based on my work experience to date, correlates
perfectly with success. I have never seen a happy, healthy,
gelled, socially functional software development team fail. It's
a shame such teams are so rare.
This is so much in line with my recent experiences that it's
shocking. My most long-term clients are the ones that I really,
truly enjoy working with. The ones that have fallen by the wayside
or not continued for very long are ones that I found it difficult to
work with. In no case were technical problems ever the source of
issues, but it was always personality and communication issues that
caused problems that made it unpleasant working for these people.
Fortunately, I have fairly good people skills so don't have too much
problem even with the difficult ones. But it's key to be able to
tell when you're running up against a problem with the people that
may be disguised as dissatisfaction with your application or
programming work.
important lesson I've learned over my 10+ years of professional
Access development:
http://www.codinghorror.com/blog/archives/001033.html
Quoting there from Bruce Eckel:
Usually the things that make or break a project are process and
people issues. The way that you work on a day-to-day basis. Who
your architects are, who your managers are, and who you are
working with on the programming team. How you communicate, and
most importantly how you solve process and people problems when
they come up. The fastest way to get stuck is to think that it's
all about the technology and to believe that you can ram your way
through the other things. Those other things are the most likely
ones to stop you cold.
The article later continues to say:
It may sound trivial to focus on the people you work with over
more tangible things like, say, the actual work, or the
particular technology you're using to do that work. But it isn't.
The people you choose to work with are the most accurate
predictor of job satisfaction I've ever found. And job
satisfaction, based on my work experience to date, correlates
perfectly with success. I have never seen a happy, healthy,
gelled, socially functional software development team fail. It's
a shame such teams are so rare.
This is so much in line with my recent experiences that it's
shocking. My most long-term clients are the ones that I really,
truly enjoy working with. The ones that have fallen by the wayside
or not continued for very long are ones that I found it difficult to
work with. In no case were technical problems ever the source of
issues, but it was always personality and communication issues that
caused problems that made it unpleasant working for these people.
Fortunately, I have fairly good people skills so don't have too much
problem even with the difficult ones. But it's key to be able to
tell when you're running up against a problem with the people that
may be disguised as dissatisfaction with your application or
programming work.