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 looking 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
Top comments (10)
You hit me with #1, but I agree on the rest too. It really is frustrating to work on something you don't really like/want. But for me managing freelance work is way worse, at least for now, so.. yeah, bite the bullet 🤷♂️
Unfortunately this is the way 😔
Great write up. I really felt the second idea here. You have to know that you have value to bring to a project discussion and it is up to your supervisors and your colleagues to ensure your voice is heard. A really good manager would ensure that everyone has the ability to speak. If you are not getting that from your job then your growth will be stifled.
Great write up! A few things I'd add from my experience...
1) don't disregard ideas because of who presents them either. I've seen many times perfectly good ideas be squashed (by the whole team!) just because the team had negative feelings for the person proposing the idea.
2) if you see a delay coming, ensuring you are building the bare minimum, functional solution first, and adding to that allows you to go to your client/ project manager/ product owner with "we can't give you everything by but we can give you this much by then and the rest is projected for " instead of "sorry it's just not ready" this is almost always better recieved.
3) we have begun giving a green, yellow, red status for every ticket in our iteration during stand up. This allows us to identify potential delays early (even for unstarted tickets) so that resources can be reprioritized or conversation of expectation can be had sooner (also something clients/ project managers/ product owners really appreciate)
Really good take on the solutions to the problems above. ❤️x100
These are amazing points - thanks for writing :)
Thanks very much! 😁
Very nice read, thanks for sharing!
Glad you enjoyed!
This is gold.