Saturday, January 28, 2012

What's gonna work? Teamwork!

Sooo... What do I know about teamwork?  I will start off by saying that this team that I'm in now,while not perfect, probably has the best teamwork of a team that I've had here at WSU.  I've had pretty good teams, and some really bad teams, and this one just seems to gel really well.  I'm glad I was able to get the team that I have.

I think what makes this team work so much better than teams I've had in the past is that everyone WANTS to contribute; to have a hand in the success of this project.  In other groups that I've had, everyone wanted success, but not everyone wanted to contribute to that success.  In this group, it seems that everyone is willing and eager to get their hands dirty, if you will.  I think part of that is the maturity level of our team; I think we're all non-trad students, with the possible exception of Daniel, so that might be what the difference is.

I have been a supervisor before.  I supervised about 13 people.  It was my responsibility to make sure that my people were trained (continuous training for new procedures), and that morale was good.  It was my responsibility to ensure quality on my shift.  It was also my responsibility to enact and enforce policies on my shift.  The number one thing I learned from this?  I don't want to be a supervisor.  I don't want to be a team leader.  I don't want to be put in a position where other people are subordinate to me, no matter how shallow the levels of the organization.  The reason for this is that I have very high expectations of myself, and I have a hard time lowering these expectations when it comes to others.  In other words, I expect my subordinates to have as high expectations of themselves as I have of myself, and that is almost never the case.  Some good advice I got one time said, "unmet expectations lead to frustration."  How true!  So I am perfectly content to be a cog in a machine.  I don't need the recognition, good or bad, that a leader receives.  That may sound unambitious, and it is, but my priorities for success lay outside the realm of work.  As long as I can provide for my family in a moderate way (we don't need to be rich), then I'm happy.

You ask about teamwork as it relates to software engineering - I would say that it's very important.  Communication (interpersonal) is very important when working on something that can be as abstract as software.  You must be able to convey your ideas to your colleagues.  It has happened to me several times that I would suggest something, and apparently not convey the idea well enough because then someone else says the same thing differently a short while later and everyone is wowed.  It's interesting when this happens to me; it causes me to reflect on how the other person conveyed their idea, and I try to learn from that so that in the future, I can communicate more effectively.

Another thing you ask about is conflict management.  I am a big believer in not being a baby.  That's about all I can say about that.  I like to be dealt with honestly and I deal with others in the same way.  If I don't like someone, it doesn't mean I act like a child about it, it just means that I do my work and let them do theirs and call it good.  I don't believe you have to be buddies with someone in order to work well with them.  I do think it's nice when that happens, but I don't think it's something that is entirely necessary.

The last thing I will touch on is managing stress.  I am still working on figuring that one out.  It seems to help me that I have one day a week (Monday) that I don't have to worry about homework or the kids or anything, and I just do what I want to do.  I look forward to that Monday's quite a bit throughout the week, and often spend a few minutes a week planning for that day.  I usually spend Monday nights with some buddies playing games, and it's a nice release.

That's it for now.  Hope that works!

Saturday, January 7, 2012

Initial Post

This is a blog that our professor has asked that we keep over the course of this semester.  I am terrible at journal keeping, so I'm sure this will be a bit of a struggle for me.  :)

The question has been asked, "What is the best way to think of software development?"  Here are my thoughts on the matter:


Software development, in my opinion, is using software to meet a customer or clients needs.  The development process consists of interviewing the client and using pointed questions to try and determine their needs.  This process takes time, and over a period of time, the requirements will become more clear.  It's important to continue to ask questions and really get down into the minutia of things to really see what the client is needing.  I think of software development as a refinement of a process to make it as streamlined and efficient as possible.  This idea can be carried over to things other than creating software as all.  


Some things I have learned over this last semester are that the only way to really understand what the customer wants is to develop psychic powers, or to do their job until you are an expert at it.  Since neither of these options are very feasible, it's important to make sure that the interviewing process is maximized, and that communication is constant with the client.  The client needs to see what you're doing in order to determine if you're on track or not, and you need the customer to communicate this with you so that your view of the final product becomes more and more clear.  


Bryan has been the primary point of contact in our group, and I imagine that he's got a very good idea of what the client is looking for.  Bryan communicates this information to us very well, never the less, he should intrinsically have a deeper understanding, as he has been speaking with the client the most.


So, can this be taught in the classroom?  I would say that the fundamentals of this can indeed be taught in a class (if not the classroom), utilizing several techniques.  This class and 3750 have been a great way of introducing this idea to students.  Another way would be to have the teacher act as the client, including some specification changes and what not.  


I don't think that communication with clients is a requirement for a Software Engineer to get a job; however, I do think that if you are able to communicate effectively, you will be an infinitely better software engineer, and are much more likely to get and keep a job.  I also think that being able to communicate will greatly increase your marketability as a software engineer.  I have heard of several people in the CS department taking a communications minor, which I think is a good idea.  I would probably do that, but I don't have time.  :)


I hope this is a satisfactory post, and will meet the requirements the professor is looking for.  I guess we'll find out!