What Your First Month at a New Developer Job Actually Looks Like

You have accepted the offer, you have been through the introductions, and you have a laptop in front of you. Somewhere in the back of your mind is the assumption that the difficult part is over and the coding starts now.

It usually does not, at least not straight away.

What happens instead is a long sequence of small obstacles that have nothing to do with programming. You cannot log in to the thing you were told to read. Your build fails on a certificate error. The package manager cannot reach the registry. The emulator will not open a network connection. An access request has been sitting with someone who is on holiday.

None of this is a test, and almost none of it is about you. It is the ordinary friction of joining an organisation that was built before you arrived and configured for people who already know where everything is.

My own first week at a large organisation recently went roughly like this. I arrived on the Monday and was handed a brand new laptop that could reach the internet and little else. I then spent two days trying to get through to tech support as something had gone wrong with my authenticator app, and I could not connect to the VPN. Which meant I could not access my emails. By Wednesday afternoon, that was resolved, and I had raised a dozen access requests for various software, read the same few Confluence pages several times over, and begun to wonder whether I'd ever make sense of this.

Weeks three and four went much better, and the reason they went well was down to the preparation I did in that first useless-feeling week.

This series is about that period. It is deliberately practical, because most of the advice written for new starters stops at "ask questions and be enthusiastic", which is true but doesn't deal with the technical realities we're sometimes presented with when joining a new organisation.

The honest shape of the first month

Every company is different, and I will come back to that in a moment, but there is a rhythm that shows up often enough to be worth naming.

Week one is mostly waiting

Your accounts are being created, your access requests are in a queue, and your machine may still be arriving.

The work available to you is reading, listening and note taking, which is worth doing properly because the mental map you build now is what you will use to interpret everything afterwards.

The people who use week one well spend month two visibly ahead of the people who spent it dithering around.

Week two is breaking things

You have a machine and some access, so you start trying to run the system locally.

This is where the proxy, the certificates, the package registry and the build credentials all take their turn to create some havoc.

It is frustrating and it is also the fastest learning you will do, because every failure teaches you something real about how the organisation is wired.

Week three is your first contribution

Something small. A bug fix, a documentation correction, a test. The value is not the change itself, it is proving the whole path works end to end: you can get the code, build it, change it, get it reviewed and get it merged.

Week four is when the picture starts coming together

The acronyms mean something. You recognise the systems being discussed. You are not fluent, but you are no longer lost.

If your first month runs slower than that, the cause is usually a dependency outside your control: an approver on holiday, a hardware order, a licence that has to be bought.

Almost everything that blocks you is one of three things

Here is the argument that runs through the whole series, and the single most useful thing I can give you up front.

When something does not work in your first fortnight, it is almost always access, trust or configuration.

Access

The server may know who you are but still deny access because your account is not in the required role or access group. A 401 usually means your credentials are missing, invalid, or expired. A 403 means your identity is valid, but you are not authorised to use that resource.

In many companies, Single Sign-On, or SSO, is used to prove your identity across multiple systems using the same corporate account. You sign in once through something like Microsoft Entra ID, Okta, or another identity provider, and that identity is then trusted by internal applications.

SSO does not necessarily mean you have access to everything. It proves who you are, but your roles and group memberships determine what you are allowed to use. You might successfully sign in through SSO but still be denied access to a GitHub repository, an internal website, a cloud environment, or a particular application because your account is not in the required group.

In many companies, access groups control which internal websites, repositories, cloud resources, and applications you can use. Until your account is added to the right group, a tool or website may not load, a repository may remain hidden, or an application may not appear in Software Center. Once the group membership is granted and propagated, those resources become available without changing anything locally.

So when access is controlled centrally, the fix is usually to get the correct permission or group membership rather than changing your local configuration. In my most recent job, there was an organisation-wide marketplace where employees could request access to different applications, internal websites, and services.

There was also an employee portal where you could see the permissions and groups assigned to your account.

Trust

The connection is established and the TLS handshake fails. Your machine received a certificate, walked the chain of signatures upwards looking for an issuer it already holds in a trust store, and did not find one. Most corporate networks cause this deliberately: a proxy decrypts your traffic to inspect it, then re-encrypts it with a certificate signed by the company's own authority, which no public trust store contains. The tell is a message naming the chain rather than the server, such as unable to get local issuer certificate or x509: certificate signed by unknown authority. This is covered in full in Fixing TLS Certificate Errors at Work.

Configuration

Sometimes the connection fails because the application is using the wrong settings. A common example is GitHub in a company environment. Your organisation might use a private GitHub Enterprise address, but your Git remote or tooling is still pointing at github.com. Your credentials may be valid and your network may be working, but the tool is still trying to connect to the wrong server.

The same thing happens with package registries. A company might require npm to download packages through an internal Artifactory registry rather than directly from the public npm registry at registry.npmjs.org. If your .npmrc points to the wrong registry, npm install can fail even though the machine itself has network access. curl might work perfectly against one address while npm fails because it is configured to use another.

Similar problems can happen with proxies, API endpoints, certificate settings, and other tool-specific configuration. Different applications read settings from different places, so changing one setting does not necessarily affect every tool.

The three have distinct signatures, which is what makes the question worth asking before you open any source code. Access usually fails with an HTTP status such as 401 or 403. Trust usually fails with a certificate or TLS error. Configuration problems are more varied: the tool may connect to the wrong host, fail immediately with a resolution or connection error, or hang until it times out.

None of this is universal

I need to say this clearly and early, because a series like this can easily read as though there is one correct way to onboard.

The experiences behind these posts come from a large, security-conscious organisation: managed laptops, a corporate proxy, an internal package registry, access requests, a lot of process. Plenty of people reading this will join somewhere that looks nothing like that.

At one end of the spectrum, a thirty person startup might hand you an unmanaged laptop with full administrator rights. There is no proxy to configure because there is no proxy. You could be deploying to production on day two.

At the other end, a bank, a hospital trust, a defence contractor or a government department might take a fortnight to issue a machine, run background vetting before you touch anything, segregate the network so the build agents cannot reach the public internet at all, and route every release through a change board. That is not an IT department being awkward. It is the audit, and someone signs their name against it.

Most companies sit somewhere in between, and the same company can be strict about one thing and completely relaxed about another.

There are other things you ought to be mindful of: