6 ms·

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 you

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 14y ago
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 14y ago
  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.
  - anonymous-dev 14y ago
    About the first paragraph, that's exactly what I am trying to get going. About the second paragraph, I 100% agree with this. I did create this pocket of excellence (myself only) and lead the way for some time. Yet no one notices it and the ones who do, well, they don't care about it - both for junior and senior developers. IMO, the most influential peoples are so called "rockstar" developers within the company and they clearly stated they don't see the interests. I already talked to them and attempted to convince them. I am running out of ideas.
    - TheMonarch 14y ago
      Why are the rockstar dev's not interested in things like automated builds, and unit tests? Are they really "rockstar" dev's? It might be political. Maybe they like being the only ones who know how to build the product, or that it has to be done on their machines. Sometimes people shoot down ideas of those below them because they don't want to see a "threat" rise up to compete with them. Maybe if you can't convince the rockstars, just get everyone else onboard. So you created the "pocket", are you getting anyone else involved? If you already tried to get official adoption of these practices and that didn't work, I dunno. You might just get it done. A lot of times managers ignore requests like this because they don't want to bother with change. THey don't realize the benefit, or they don't want to try to force change on a team (maybe they don't want to adopt anything the rockstars aren't into).

anonymous-dev 14y ago

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 14y ago
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.
- anonymous-dev 14y ago
  About the first paragraph, that's exactly what I am trying to get going. About the second paragraph, I 100% agree with this. I did create this pocket of excellence (myself only) and lead the way for some time. Yet no one notices it and the ones who do, well, they don't care about it - both for junior and senior developers. IMO, the most influential peoples are so called "rockstar" developers within the company and they clearly stated they don't see the interests. I already talked to them and attempted to convince them. I am running out of ideas.
  - TheMonarch 14y ago
    Why are the rockstar dev's not interested in things like automated builds, and unit tests? Are they really "rockstar" dev's? It might be political. Maybe they like being the only ones who know how to build the product, or that it has to be done on their machines. Sometimes people shoot down ideas of those below them because they don't want to see a "threat" rise up to compete with them. Maybe if you can't convince the rockstars, just get everyone else onboard. So you created the "pocket", are you getting anyone else involved? If you already tried to get official adoption of these practices and that didn't work, I dunno. You might just get it done. A lot of times managers ignore requests like this because they don't want to bother with change. THey don't realize the benefit, or they don't want to try to force change on a team (maybe they don't want to adopt anything the rockstars aren't into).