The Rules Of Work.

Before we begin, I'd like to say that all these points may not resonate with you, but I'm 100% sure that a few will.

The 'rules' (and I say this very lightly) will vary depending on where and as what you are working as, or choosing to work as. These are things I've noticed moving between smaller (startup type) companies and larger organizations.

Let's kick this off, we have a lot to cover.

You are going to make things that you don't like/ don't want to.

This is probably the point that will resonate with most unless you're working on your own project. You are writing code for someone else. You are in charge of creating their vision, whatever it may be. There will be times when you will disagree, offer alternatives, and sometimes get bluntly shutdown, this is normal. It's part of the job. IF this is the case and you can't work like that, I suggest you go freelance where you can decide and pick up the work that you like, but even then the client is in control, they will extend a list of functionality that they want to be implemented and it is your responsibility to implement. Bluntly, you'll have to take some s**t and bite the bullet.

You will/should disagree with seniors - sometimes

First and foremost, this is fine. There is nothing wrong with disagreeing with anyone in your workplace but there are ways to do this correctly which is what I see being missed by too many people. When disagreeing with someone is it just because you don't like the idea? or is it because it doesn't make sense? You know or have a better way of doing the proposed something? If this is the case layout your argument in this order.

• "I know of a better solution which is XYZ"
• "This will allow us to save money/ have better, reuseable code, improve security, etc."
• "Can we combine ideas/solutions?"
• "I suggest we at least explore the alternative, plan both out and come back to discuss and pick the solution that works better"

I see too many junior developers that have a wealth of knowledge hold their tongue because of a heirachy. If you cannot speak freely without the fear of being mocked, or ridiculed I suggest you move and move fast because you will be miserable.. Trust me on this.

There are always delays

Delays... A sore subject for Project Managers, and/or Product owners but they are conversations that are needed to be had. Delays happen, more so than not. And this is OK as long as you have justified reasons, Is it because you and your team were learning new things? Experimenting with new tech? As the agile saying goes, "We ran into Unknown Unknowns". Deadlines are there as a "We may have this finished by this timeframe but probably not" and they can and most probably will move. If you're working or looking to work in a large organization delays are inevitable, most of the time this is of no fault to you or your team but rather waiting for other 3rd party teams to implement something.

You will spend A LOT of time planning and designing

This one is a given. You will spend a ton of time planning and designing the code/ services you will write. This is a good thing, a plan of action, a map that you will follow. I recommend you do refinement as a team and ensure that everyone, regardless of job roles/titles understands what the piece of work is, this is especially important for junior developers. I used to get lost in my code or implementing things that are not needed because I would go off the rails and just jot down a few bullet points that I kept revising. Now, I know that designing/documenting is not fun, I hate it haha, but it is very important and should not be neglected.

These are a few things that I thought new/junior developers should be aware of. There are a number of further points which I may address later, but these to me are some that stood out and should expect regardless of where/who/what you work for/as.

No gin this time,

Rus