When you first join an organisation, it can be very easy to spot points of friction everywhere.

For me these have been things like:

• Documentation, or lack thereof.
• Component discoverability.
• Friction getting access to systems.
• Lack of tests.
• Parts of the application that are written in JavaScript.
• Undocumented processes.
• Out of date frameworks or dependencies.

It can be tempting to jump right in and point at these things to say 'we need to fix this!'.

But:

Consider that some of these things might just fix themselves as you get more familiar with the organisation and the codebase.

Take something like component discoverability - after a year there's a good chance that you'll know your way around all the components.

It depends on the average tenure of the developers

If it's an organisation that is constantly hiring new developers, then yes, there is more value to be had in fixing some of these problems.

However, if the organisation does not hire new people very frequently, the people that they do hire tend to stay, then it's worth asking whether it's worth the effort in doing whatever uplift.

This might be the only time you touch that thing

That gnarly JavaScript file that would be easier if it were converted to TypeScript - sure it would be good to tidy that up, but this might be the only time you're touching it - and the risk of breaking something as well as the time spent might make it not worth it. Being new to the organisation you don't know how often you're going to be touching the thing.

Fresh eyes are a one-time opportunity

The organisation would do well to make use of the fresh vigor and fresh perspective that a newcomer provides.

A common technique is to have a new hire's first task be to update the onboarding documentation with anything that was missed or can be improved.

My advice for the organisation:

Encourage an outlet for any observations or suggestions for improvements.

My advice for newcomers:

Give whatever patterns exist 'the ol' college try' - don't allow your preconceptions to dismiss a thing out of hand.

Document whatever friction you encounter. It's better to document this in a personal workspace (eg. the space that exists under your user in Jira, still visible to your colleagues, put clearly not part of project documentation) rather than in a common area - it stops muddying the common documentation.

If you are encountering the same kind of friction frequently, this is a good candidate for something to be changed.

Questions? Comments? Criticisms? Get in the comments! 👇