[TheMonarch]

Have you read the Pragmatic Programmer? They talk about how to handle a situation like this. From what I remember it said to build a pocket of excellence in your dev workspace first, and then expose everyone else to it.

Set up the CI/build server on your machine, have it email everyone when the build fails. They will see the use of the tool then, and when the team accepts it they will hopefully get an official server to host it on.

Write tests for your code, and when other devs work with you on issues, or break things, write tests and send to them "Hey, i wrote this test that shows the code you wrote is failing, can you make it pass?" Also ask others to make unit tests. You will have to write the bulk of tests. You probably know which others on the team are open to writing tests and working with you on the pocket of excellence. Get them involved first, and then the idea will spread. A good idea would be buy them copies of Pragmatic Programmer too.

No, you aren't process oriented. A software team that doesn't at least like the idea of automated builds, and tests is crazy. As far as if it's a good place to work and improve one's skills? That depends. In some teams you might never get them to adopt the pocket of excellence. If you are working in a place like that, then it's probably not a good place to work. But if you have a shot at converting them by just doing it on your own first, then it would be a great opportunity to get experience with setting up these aspects of a software shop. And you can put that on your resume, blog about it, etc. In that case it would be a great experience.

[anonymous-dev]

I heard about the Pragmatic Programmer book. I guess it is now time to read it.

About CI server, it is on its way but only for production release. No continuous build for now mainly because there is no unit test infrastructure setup.

About writing test, well, no one uses unit-test for the reason above. It maybe a good time to introduce that and get to show them the light :)

"In some teams you might never get them to adopt the pocket of excellence. ". I am a bit afraid of that. Why ? I have spent some time trying to change things and yet I see little or no effort from others.

What are you thoughts on documenting things ?

[TheMonarch]

Very high level documentation is good. Things like, what are the steps to get the app to build, what tools do you need to install, frameworks, etc. What's the directory structure, so that a newcomer knows how to approach the project.

I'm a fan of self documenting code. Trying to document code is nice, but rarely possible to keep up to date. I do like to put short comments on a method if the name and class its in don't provide enough info. It's better to spend time writing code and tests than documentation.

You can't always convince people to do things they don't want to do. Some people don't care about putting more than the minimum of effort into work. Most people hate change. But if you just go ahead and create the pocket of excellence, people tend to notice why its good and if you get momentum then the rest will follow. Who are the influential people on your team who if they started using these good practices, the rest would follow? How do you think you should best convince them? For some people, find out what motivates them, and then see if you can explain to them how adopting these practices would benefit them.