Juniors are a fun bunch to work with.
Over confident, hero complex of that fresh graduate high, and then thrown in to the real world! Where there hopes and dreams are crushed in minutes when they see what monolithic applications really look like!!

But don't let that overwhelm you, your not going to be changing all of it any time soon, hell some of this code hasn't been touched in 5+ years and still works without fail.

Don't stress about the work load, you can only write 1 line of code at a time anyway, and hell, even seniors make mistakes.

The key about being able to manage this beast is simple, break it! Because the more you break it, the more you'll understand how a project is put together, for better or worse. Learn from the examples in front of you, and learn what not to do in the future 😎

But more importantly, plan your changes, whiteboard the high level logic of what it is you want to add, then whiteboard in the current codebase and determine where to slice this bitch up, then when it all looks well and good, take out your scalpel and slice and dice time.
Don't worry, your changes aren't going to production anytime soon, hell, you'll be lucky to get past the first pull request with this working 100% the first time, and that's a good thing, learn from tour short comings and improve your own knowledge for the next time!

1. You don't code to add a feature or whatever. You do it to solve Users' problems. It's a User-centric system.
2. You read more code than you write. So help yourself and write code intended to be read.
3. If people don't know you did something, you did nothing!
4. Never answer a call at 3 am if you're not paid to be on night call-duty. You'll become the guy who answers at 3 am.
5. Remember the big difference between you and me is that I failed to do stuff more times than you have tried to do.
6. When you start shaving the yak, stop!

Read the error message before closing it and/or asking for help.

Shut that computer off and go home. You'll think clearer in the morning.

Get your code reviewed by as many good devs as you can. Tell them to be harsh, swallow your pride, expect the code to be torn apart. Then rinse and repeat.

It brings the "know it all" fresh grads down a peg or two, and often brings those with low self esteem up a peg or two (when they realise their code is better than they thought.) Anyone can write code that works. But writing decent, clear, well-tested code that stands up to scrutiny is a different ball game - and it's important to learn that quickly.

Always under promise and over deliver

Reinvent the wheel, then throw it away.
Best way to understand a concept

1. Trust no one even yourself
2. Ask questions even if they are stupid
3. Test your solutions, even manually
4. Write comments
5. Take your time to solve problem, even if it looks like easy see point 1
6. Take some time during work to get familiar with code and read something about technology that is part of your current work - even if you know it - see point 1
7. Always try to see a big picture - see point 2 - why is it implemented is more important then how is it implemented

Don’t put pressure on yourself to understand everything. No single person understands it all, that’s why there’s a bunch of us.

Don’t work here.

- There are no stupid questions. Please feel free to ask.
- You don't have to memorize, but try to understand.
- Document so you never have to remember.
- Teach so you will master and never forget.
- Even if we have different responsibilities do not ping pong issues because overall the client only sees one company name so we work as one.
- Do not disturb while on vacation leave unless it's life or death.
- Relax, sleep and have a happy weekend.

Do not assume that the current codebase is perfect, or even remotely close to an example of acceptable style/structure.

Put away the keyboard. Think about what you're going to do, chart it out, work through the logic and then, when the entire construct is before you, you start typing.

Yes it will take longer, you're a junior, enjoy that nobody expects you to do miracles (yet) and take the time, you'll get it back when you're so used to working through logical problems that it happens on its own as soon as you hear about the problem.

Cutting corners and "hacking a quick solution" without fucking over the entire system is an art form. Before you do art learn your damn craft.

There's no such thing as an expert programmer. With time you just get different kinda errors. As long as you're not getting same error, you're making progress.

1. Hit everything you do. You will learn more faster. Don't accept things at face value, care about why things work.

2. Study and experiment constantly. Be aware of your surroundings and what is going on. If you're not ready with a solution when a power vacuum appears, you will always be a grunt. Or worse, eventually a manager who everyone hates because you constantly tell the people who report to you how "back in your day," your code was amazing, there were no bugs and your shit doesn't stink.

3. Be honest with yourself: If you just want to keep your nose to the grindstone and make manager so you don't have to code anymore:

Quit. Stop now. Do not pass go, do not become a cancer on the industry.

Go get a job as a PM, you'll have a better career and you won't be the weak link holding everyone else back.

Tl;dr When the shit goes down, you better be ready.

Bring me some coffee.

- Family (and you) first. We’re all human, despite what our product manager is about to say to you.

To anyone new to the corporate world I have this advice: there's a game no one tells you about in school or university. It's a game of politics. The good news is that you can choose not to play the game. The bad news is that others who do can change that decision for you, if you give them a reason to. So here's my tips to keep yourself from common bad situations:

* Some people will say they'd "prefer that people were honest". This is an outright lie.
* Be guarded - if a scenario could be taken out of context assume it will be.
* Mimic the office culture, don't try to rock the boat.
* Be polite, but always stay neutral between colleagues, picking a side means you're playing the game. Unless that side is your company vs another company in which case-- you are 100% on the company side and everyone else is stupid and incompetent.

Question everything!

Comments lie.. sometimes code does too.. Customers..they lie the most..and are sloppy..

Don't be like customers, don't be sloppy. If you were sloppy own it & don't lie about it!

Pick your fights (trying to fix vs rewrite the shit out of it)..you will know what to do more with experience..

RTFM & docs.. If things still unclear, ask before your dick gets stuck in a toaster!

Ask away, learn about the customers & how they use your product.. you'll be surprised how something intuitive to you might be a rocket science for them..meaning more room to fuck things up when using it..more ways you can adapt & prevent things..

Most of all, don't fuckin lie.. ever!!
If you lie on you're CV, we will find out.. If you fuck up something & lie about it, we will find out.. but it will cost us precious time when solving it from scratch.. People fuck up..that's a fact..how you go about it is what makes/breaks it for me. So don't ever fuckin lie to me!!

And don't be arogant.. if you complain about fixing bugs, this is not a job for you.. if you can't even fix the obvious ones you've put there in the first place..twice as bad..

So think before you code..what do you want to do, how you want to accomplish this, is it reusable, can it be extended, does it introduce new technology into the project, will it fuck up current setup.. once you have this shit figured out, code will write itself..

Did I mention already you're not to lie to me, ever?!

And don't try talking about me behind my back either..I've seen it backfire before, results were not good..

Be skeptical of best practices. "Best" comes with assumptions, which may not apply to you.

* KISS (keep it super simple)
* don’t try solve a problem you don’t already have
* admit if you messed up. We can solve a problem early and minimise the damage. People should never be scared to admit when they mess up. No one is perfect.
* voice your opinion. You’d be surprised how helpful this can be to your team, as we need to look at things from all angles.
* help your team. If you see something wrong, make the team aware of it.
* ask if unsure, don’t assume

Code quality is not related to your self-worth.

Never ask "How to start with X?". It's a dumb open-ended question with vague open-ended solutions.

Rather ask "I'm at X, want to do Y, I have Z proposed solution. Does that sound good?"

Builds context, focusses on action and is more efficient.

I'm not qualified to say anything here, I'm a junior as well, but something general that I picked up:

Not everything needs to be object oriented.
Writing 5 functions and calling it a day is often much better than needing 13 classes and 4 interfaces.

Work on projects and read a lot of source code like if you are reading a book.

Listen, before you talk...

Nope, too young.

Though some smaller kids than me DID come and ask for advice on how to start learning and I told them that they have an entire internet to learn from, there are guides online, and everything that stands between them and success is their DESIRE to learn computer science. And if they really do want to learn CS - really stick to it along the years and try to get as much head start as they possibly can.

I learned in my limited experience in software development (for the uninitiated, I am 16, started coding at 12), that you must want to learn it DEEP DOWN, because if solving problems is not your cup of tea and you don’t like thinking big, then GTFO lol.

Comment your code, you'll thank me for that next week.

There are no stupid or dumb questions. A lot of headache has been and could have been saved by one person asking what seemed like a stupid question.

I would now expand on this to say that if the question is procedural in the sense that it’s asking “what” or “how”, you should make every attempt to come to an answer yourself and then ask for clarification. If the question revolves around “why”, there are no stupid questions. A lot can be overlooked in a cascade of moving pieces.

It is easy to believe something is over-engineered as a junior. You open a solution and get slapped in the face with a wet fish of many classes, with strange names, doing very little, with everything coming together in ways you don't understand.

My advice is to learn about design patterns, clean code, clean architecture, and model driven design. Until that point I don't think you can make such a distinction. And indeed once knowledgeable of patterns and techniques as well as the domain, the same solution can look obvious, elegant and readable.

In a field where everyone is saying 'dont over-engineer', one must be able to tell if something is actually bad, or just uses techniques you don't recognise.

Telling your senior you think something is over done just because you don't understand it is not good. First learn techniques, understand the code, then form opinions that are at least relevant then.

From someone who committed that crime.

Being a junior myself before all I can say with others that came after me was:

- Keep your head down
- Don't take everything as an offense
- People are rude or angry, but that's just how we are: we deal with normal users' BS everytime that we just wanted a break.

Time spent getting to grips with your OS is usually time spent well. While you're not operations, it really helps being able to solve general problems yourself without calling support.

Oh, and: Set up a good bashrc, and put it on the servers you're working with.

You sure you don't like doing other things and really want to work here?

Very well, my advice is this: Use the library restrooms, they get cleaned every 2 hours, if you use the one here in our building make sure you go before the D man or else it will be unbearable.

Have fun bitch

If you think you found a solution, think twice.
If the implementation is taking too long (too many changes in different functions and classes to fix a single bug) there may be a better solution, it's never too late to reverse the changes and start again, it's not a shame, in the worst case you will reimplement the same solution, but better, in the best you'll find an easier and better one.

Don't run, even if there's a deadline.
It's much worse having to deal with negative feedbacks later.

Don’t write documentation for other people, write it for yourself! It may all seem obvious today, but six weeks from now you’re not going to remember what you were thinking or why you wrote the code the way you did.

I'm still a junior myself, but some fundamentals I've told my coworkers:
* Commit more, regret less
* Yes, you can remove a commit, if something goes wrong.
* No, I'll not explain again how to undo a commit you pushed typo to you feature branch. Feel the shame of pushing "Fix typo" commits
* ask, if you are stuck or unsure.
* don't do deployments at 5pm Friday. 6pm results in less crashes in production for some reason /s
* Don't be like me. Go to sleep at appropriate times

Idk despite whatever my resume may suggest, I think I'm still a Junior. Dunno if that'd ever change tbh. I mean, that's the downside of "cutting edge tech", right?

I don't have any advice.
Everything important has already been said by somebody out there.

One advice I've given to most junior developers which they've practically benefited from is...
"Avoid duplicate comments between interfaces and their base class at all times".
As a smartly-lazy dev, you shouldn't enjoy writing same thing multiple times... be it code or comment, don't write it twice!

Code is a highly detailed description of what a computer should do. If that description becomes inaccurate we will remove inaccurate parts. Take pride in writing good code, recognize that it was useful for a while, but don’t get attached to it. It will stay in the git history.

If you see code as your baby, know that the team might need to kill your baby.

<<prev. #wk235 advices>>

~ Study the Error log deeply, Google each line if needed. Don't give up.
~ Learn by doing. Don't just read/watch.
~ Practice breaking down the problem statement first in different components and hierarchies. Don't jump into coding right away.
~ Write some, review some. Don't put off review for later.
~ Even if you don't exactly follow the best security practices - always ensure that your program is safe for use. Especially for user-inputs, etc, pay attention.
~ Never distribute code with passwords/keys written in it.
~ Don't hard code stuff, use Config file, environment variables, etc.
~ Try to automate repetitive stuff like build and deploy etc
~ Save and backup you code.
~ No one knows everything, also, today's knowledge gets outdated tomorrow. Continuous learning is synonymous with this field.

<<next #wk235 advices>>

Always use the Scotty Principle.

Never take an advice from anyone if you did not specifically ask, this one included.

"Many already Know this, but from this point on, Google is your wife."

I can't say how many times there has been a question which had a straightforward answer with one search.

Choose a language/toolkit to be your scalpel and learn the hell out of it

Try out all sorts of things/technologies and find what interests you the most. Go after being an expert in that particular domain. Also, learn by doing.

Know the basics of the tech, don't just dive in with some off the shelf blackbox buzzword then find yourself crippled when you need to debug it going wrong

Learn what blobs, trees, hashes and the concept of "commiting" (transactions) are.

Then learn how to use diff/patch.

Then learn Git.

In that order.

Just do it

Im not “senior”, but I’m maybe middle level but anyway....
Learn good object oriented design!
Have a decent computer science background!
If you don’t know a certain framework or “tech”, google it and learn it quickly! Most of the “hot new techs” can be learned rather quickly by anyone who has a strong foundational understanding of programming and computer science. Its not sacred knowledge reserved to the chosen software prophets lol

Good quality is more important than fast delivery.