I have yet to work in a more-than-one-developer shop. I'm curious, of the web (front- and back-end) developers out there, who works in what sized shop.<p>Also, if you have any tips or perspective on thriving / surviving in a one-developer shop, I'm all ears.
I work in a one developer shop. Short story, nothing nice was setup when I showed up. Here are my tips and what I have done.<p>1. Force yourself to follow a set of rules.<p>2. Force yourself to follow a set of rules.<p>3. Setup a test server.<p><pre><code> - When I took over all the projects were updated on the
the production server.
- The test server should be a clone of the production
and regularly updated.
</code></pre>
4. Setup another server (hardware or VM) for your "department"/yourself. This is your "production" server for yourself/"department".<p>5. Setup some kind of ticket tracking system. Be sure it
supports multiple projects, time tracking, scm tracking,
and some kind of wiki/documentation.<p><pre><code> - Start your wiki listing how you are cloning your
production system.
- Create projects for the projects currently in production
- Document those projects
</code></pre>
6. Setup some kind of SCM.<p><pre><code> - Pick one. Which one? Mercurial? git? subversion?
[ commercial ones not listed, because more than likely
you have a zero dollar budget ]
It honestly doesn't matter. Just pick one and stick
with it no matter what people say. When asked why you
picked one over the other. Just say "I needed it."
- Learn SCM strategies.
- Write policy for your SCM strategy.
- Follow your own policy
</code></pre>
7. Educate the users on how to submit bug reports.<p><pre><code> - Inform then that emailing you does not get the problem
fixed
- Bug reports let them track your progress and allows
for open two-way communication.
- It also gives your superiors a way of monitoring and
measuring your success in the workplace.
[ if they don't "see" your worth then you are worthless ]
</code></pre>
Last, remember that you are a policy maker as the sole
developer. Implement policy that helps you set standards and
expectations not only for yourself but for your users.<p>good luck<p><i>edited for formatting</i>