I wrote this post as an exercise during a meeting of IndieWebClub Bangalore.

During my first week of work with a new client, I like to push a very small, almost-insignificant change into production. Something that makes zero difference to the org’s product, but allows me to learn how things are done in the new environment I’m going to be working in.

If my client already has a working webapp, this change could be as simple as fixing a typo. If they don’t, I might build a tiny “Hello world!” app using a framework of their choice and make it available at a URL that’s accessible to everyone within the company (or at least everyone who is involved in the project I’m working on).

This exercise helps me figure out everything I need to navigate the workplace and be productive within its constraints. It’s better than any amount of documentation, meetings, or one-on-ones.

• Where is the source code hosted? How do I get access to it? Who will give me access?
• How do I build and run the software on my dev machine? Is there documentation? Is there somebody who can guide me through the process?
• What does the version control strategy look like? What workflows am I expected to follow? Are there special conventions for naming branches?
• Does the codebase have automated tests? Is there a CI server?
• What’s the process for getting a change merged? Should I open a PR and wait for a code review? How long do code reviews typically take? Who reviews my code?
• Is there a staging server? When does staging get merged into production?
• How can I provision new servers if I need them? Who will help me do that?
• Are there any third-party services in play? What providers does the org use for auth, CDN, media transformation, LLMs? How do I get access to these services? Alternatively, how do I mock them in development?

Doing this work after I’ve already spent weeks building out features is frustrating. When I’m in the middle of solving a problem, I want to iterate fast and get my work in front of users and managers as quickly as possible. I like to go into meetings and stand-up calls with working prototypes that people can play with on their own computers, not with vague promises of code that kinda-sorta works on my own machine.

This work also brings me in contact with a variety of people from across the organization, which is always helpful. I like being able to reach out to my co-workers when I’m stuck. As an independent contractor, I can only do that if I put in the effort to build relationships with my team. I also like to have a sense of camaraderie with my co-workers. I want to see my co-workers as more than just names on a Slack channel, which is only possible if I actually talk to them.

Pushing the smallest possible change into production helps me do all this and sets the tone for a fruitful working relationship. Plus, it’s always satisfying to end your first week of work at a new workplace with something tangible to show for it.