I have recently joined a growing enterprise on its way to 50 employees approx. 2 months ago as the first internal web developer of the company.

Since I am the only one right now, it is going to be extremely likely (given management perspective) to have another collegue in the team within the first months of 2019.

As the acting Lead Developer, what skills and things do you suggest me to implement to make sure that I'll be ready for that task, and especially that the team will function properly and smoothly?

In other words, how do I set everything up for the future in the proper way?

We are currently working on Kanban and the main product is games, so Web Development will only have a support role / side role in the company (ie. internal tools, web shops, etc).

The management perspective is to reach eventually allow me to reach a senior position, and eventually team leader in the web team.

  • 2
    1. Suggest to management that what they need to be hiring in 2019 is a lead developer. 2. Do the best you can until the lead developer is hired. 3. Learn from the lead developer when they start. – Philip Kendall Jul 3 '18 at 9:24
  • We do have a lead developer right now, but it's a generalist and it's mostly connected to the game department. The idea is to myself become the Lead Developer eventually, so that's why I am asking this question. – GiamPy Jul 3 '18 at 9:25
  • Do you want to be the Lead Developer yourself, or are you hoping to have someone more senior hired into the Lead Developer position and continue the work you started? – Juha Untinen Jul 3 '18 at 10:21
  • If everything goes well, I should become the team leader of web development, so I am trying to prepare for it. – GiamPy Jul 3 '18 at 10:52

As a Developer, these are the things I look for when joining a team:

Good structure

Ie. the day-to-day life is not a chaotic mixture of "do it yesterday!" ad-hoc work and massive tickets that were not in scope. Since you have already implemented Kanban, it is a good start. Optimally you will follow the format even when you are the sole developer. It will take some extra effort, but don't cut corners. Ideally adding someone else to the workflow will not affect the workflow beyond the obvious increase in tickets.

Adequate documentation

It should be possible for a new developer to jump right in by following a step-by-step (and tested!) checklist to get the basic environment up and running. Then from a stable basic env, you can continue to other repositories that are related to the work. Each repository should of course have its own readme file with instructions on setting that up, with notes if something depends on the basic setup.

Clear todo list / sprint plan

There should be a clear list where you can see the backlog, and priorities, of the tickets and expected work. It should be clear what the developer should work on next and the tickets should have good description of what is expected. A one-liner eg. "Implement product catalog." is not enough.

Good introduction / boarding

All the expected things and general guidelines should be clearly explained. Optimally they also exist in an easy-to-find document in some interal site eg. Confluence where you can always return to. This should also contain a high-level picture of the project, eg. what components there are, what kind of data goes in and out from them, what tools are used, and so on, in high level - leave the details into the repositories.

Deployment procedures

Should have clear instructions on how each component is deployed to Staging, Production, whichever. Optimally you don't need to ask someone how to deploy this to that.

Clear workflow in the versioning system

You should have defined ways how the integration goes. Ie. fork this, create a feature branch, do a PR to upstream master, get approval, merge. Deploy from Jenkins project ABC to Staging. Check that tests pass. Then Deploy to Production. Whichever style you use.

| improve this answer | |

Beyond having knowledge of the applicable technologies, it'll probably make sense to buy and read a few books on team management and get a decent grounding in Project Management processes.

While you're doing that, adjust your current processes so that they'll be easily scalable when you get more team members on board (and it's good practice anyway).

| improve this answer | |

They're quite some solutions specially on the technical side.

On the technical side, you could have a full disk image with everything setup or tons of others stuff.

However on the workplace side there is basically one answer : choose the setup in which your developer will evolve, and document it. You don't need expensive lengthy text of documentation however you need to document :

  • To what need the current platform in its state answer, and eventually does not answer yet ("continuous integration is planned but not handled yet).
  • How it is setup mainly diagrams and some general explanations, no need to explain each configurations files.
  • All necessary step to add one developer (machine installation, add the user into the git, the jenkins, the ldap,...).

The term "lead developer" may have differents meaning, so I'm not answering on the leading/managing side.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged .