What I would expect when joining the new project?

Here is the computer, here is your username/password, please set up the machine and we will talk tomorrow.

Code is our documentation and everything you can find inside the codebase.

It’s funny to wait a whole day for accessing the wiki system for getting the information, or for the mail being set up. Great fun!

Well, we have some documents to read firstly. After a week we can talk about it, enjoy!

There was no time to draw pictures about architecture because it’s very complex and analysts don’t have a time for it.

Sorry, but I have no time for you, I have more urgent tasks right now so you’ll need to find someone else.

There is your first mission, it’s about this thing (2-minute intro), and it’s quite easy.

We aren’t fans of the comments as the code should be self-descriptive. And it is our opinion.

We are using some CI server, and there is everything to reach.

Well, there are industry standards, you know. So we are following them, and there is no need for having own one.

We need to ensure that you know everything about having the ability to code something.

Having one drawing of the business components playing with each other brings a lot overview of the project. Even if someone is talking about the project, rarely he is not using the pictures (even handmade).

The historical perspective is crucial and overseen very often. Good description of historical milestones, names and persons on the project gives you feeling that you are starting on the project where are individuals who cares. Even inside codebase, you’ll find historical terms and names, so it’s useful to know if they are legacy, historical or present.

This don’t need to be an essay for hundred pages but in one or two pages explained which technologies, technical components, communication, third-party services are used.

It’s same as before mentioned point. In one or two pages you should be able to realize what is the goal of the project, business what is the project doing and set of links for more information. After reading such overview, you should know how the project is earning money.

How the application (output of the programming effort) is delivered to the clients? Is there used CI? Where are the artifacts are uploaded? Is there a goal to meet the CD? Briefly, the overview should contain all the answers for these type of the questions to be sure that newbie knows what to do if anything is wrong and can deliver an application to production.

Is very useful to have an initial set of tasks which were done in past with very well description, comments and code attached inside. It helps to realize the amount of work needed for a particular tasks, area touched inside codebase and overall style of the communication between the author of the task, programmer and maybe verifier of the task.

For the even smallest project you need persons to ask. And for not bothering every people in the room and figuring out who is capable of answering your question in the particular area, is ver useful to have a list with person <> business area for such cases.

It’s the same as above but only for the technical perspective and implementation.

I’m used to collecting the answers in written form from the very start of the project. After one or two days I have between 30 and 50 questions (even the simplest ones for the URL to the canteen). And getting the answers for such questions is critical for having the good perspective of the project.

On the start of the project you are about to make assumptions for the areas which weren’t discussed too deeply or only touched. And you are making assumptions how these areas, components, whatever is working and maybe this is wrong. So the list of the surprising or hacky areas which aren’t following some standard would be useful not to be surprised if I touch anything from this list.

There are always places which are somehow legacy. These should be documented with the description of the future improvements, the tasks inside tracking issues system for having the clear picture how the legacy code will be handled and when.

What is the code flow? What is taken into account in code review and how it is done? By documenting how the code review is done I can quickly find out what are the expectations for the quality and what is the process after my code is somewhere checked in.

Well, whenever I see comprehensive Coding Style document, it’s pleasure to work with the code following such standards. Every single projects has own rules upon the general one so this document (and shared settings for most favourite IDEs) is extremely important to have clean code.