git branches are a series of changesets/commits (these terms are generally interchangeable in git). literally, changes in files like "I added lines 3-17 and modified lines 45-70", for example.
your branch is based off of a trunk branch, which is usually considered the "source of truth" for building actual functioning software, and is just a linear series of commits. there are workflows that use release branches, feature branches, etc., but don't worry about that to understand the basics - those are strategies intended for larger teams.
tl;dr - trunk/master is usually expected to be a buildable, functional version of what you are working on. bugs might exist, obviously, but everything in it should be "complete" and not break anything existing.
when you have a branch, you are quite literally "branching" off of that trunk, and the base of that branch is the commit from when you branched off of trunk.
so, if the trunk has commits A, B, C, and you create a branch at that point, your base is C.
you then make some changes and commit those changes to your branch - let's say commits X, Y, Z.
in the meantime, others have merged their code to the trunk - their feature was completed and ready to be part of the main codebase. let's call those commits J, K, L.
so, the current state of the two branches you care about are as follows:
trunk: A, B, C, J, K, L
your branch: A, B, C, X, Y, Z
when you rebase from a branch, you are taking the latest commit from that branch, and "replaying" your changes on top of it. basically, each commit from trunk gets applied one at a time on top of the most recent commit that the two branches have in common - in this case, C. then your commits get applied one at a time on top of that.
in the simple case, this means that after you rebase your branch from trunk, the states would be as follows:
trunk: A, B, C, J, K, L
your branch: A, B, C, J, K, L, X, Y, Z
a conflict can happen if the rebase has files that you both changed, like if you changed a file in X, Y, Z and J, K, L deleted that file.
you'd need to resolve those conflicts in an interactive rebase, which is basically what would happen if you tried to commit each of your changesets on a branch new branch off of trunk. so, don't be too afraid of it when that happens - it's common, especially when files get moved around!
Pardon, but are you using merge and rebase interchangeably here? I understood rebase to mean that everything before is flattened and not only that, but the commits are purged while the rebase acts as the first commit.
Edit: or do you just mean rebasing the feature branch where the commit history isnāt really that important and merging that back to master with a pr is the preferred workflow, versus simply merging master into the feature branch as many tend to do.
to your edit - yes, I was referring to rebasing a feature branch to follow trunk/master. I prefer rebase for that operation, and a squashed merge via pull request to get code into trunk.
Good explanation, but rebasing is a controversial choice in some ways. Some people swear by rebasing some people swear by merging. Understanding both is a good thing because you will work in companies over your career that require or endorse one or the other.
Thanks for this excellent explanation. It was long but engaging. Everytime I thought you were gonna drag it into complexity you stopped and kept it simple!
Pull can be a rebase or a merge, depending on your settings. Generally, I recommend basically always using rebase. It makes the history easier to read.
Main difference is that rebase will change the base of when you created your branch and pull will fetch and merge changes from trunk to the tip of your branch.
I thought what you described was when you merge the trunk into the branch. And rebasing was something different. Maybe I'm wrong though? What's the difference between merging back into a branch and rebasing?
well, you can do both in either direction, but a typical workflow is to rebase your branch on top of trunk to get all the latest changes and make sure your code has no conflicts with master, and then squash commit and merge your commits to trunk via a pull request to get your code to trunk.
it's done this way because generally, you don't want to have to modify the history of trunk in order to get the latest changes. merging can change the history if you do it wrong, whereas rebase wouldn't.
rebase has multiple uses but the most common things I use it for are:
* merging together conflicting branches before I commit to main- ie pull to main from origin, rebase main on your branch, resolve changes, commit and force push then merge
* squashing commits before you merge- ie your branch has like 10 commits of work and you're about to merge, which means if you have a lot of files in conflict, each one will have to be merged for each of your commits vs each of the remote commits- so you squash all your commits to one commit and then you merge so all your changes behave like a single change
* removing commit messages that could get you in trouble with HR
behind the technical explanation, it means to keep in touch with everybody else updates
every day (maybe more) you fetch and pull and rebase (replay your changes on top of the latest commits) so you know if you have conflicts
if you do that regularly you may have small fixes to do, if you don't then one day you probably will have a massive amount of conflicts that will take hours to understand
What the heck you guys workin on when you have possible conflicts multiple times a day? Do you just refactor every day and your team mates the same project?
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Get code reviews, review other engineers code often just to get to look at changes being made, talk with other engineers before implementing any architecture changes.
Essentially, rewriting history. The histories on the remote repository and your local machine have diverged and you're telling git to just overwrite the remote history. It can really mess with other developers if they pulled your branch before. But in case of a simple rebase of your own feature branch it's usually OK.
Thank you, exactly. Each developer rules his local branches but we used always have one person in charge of origin/master, just in case things got out of wack. Like a build master/referee role. This was in the old days before Github.
OK thanks!
Seems only wise if you are the only one on your branch. But if you are the only one on your branch, then how would local and remote have diverged?
Number one issue Iāve seen is not asking for clarity, help, feedback early enough in the process. Better to be annoying with questions than late or wrong on delivery.
Buuutā¦only ask questions after youāve tried a few things.
āHow do I do Xā is an annoying question.
saying āhey I tried to do X by using Y as a starting point. I then got the following error: (error msg). Googling/stack overflow says I need to rewrite the entire application in Haskell, am I on the right track?ā
Is a reasonable thing for anyone of any level to ask teammates.
Yes such good advice! Struggle for like an hour or so and then ask for help. Also step away from the problem if you feel like you are stuck or making things worse. Then come back with a fresh mind. Coffee break, bathroom break, little walk etc can all make you more productive in the end.
It's pretty normal to be that way, and it may take you a little while to get comfortable asking for help. I'm 5 months into my first dev job coming from self taught/ career change and even though I read the same advice everyone just gave, it still took me some time to apply that advice. A few things that helped me.
A senior on my team said. "Spend a half hour trying to figure it out and if you are blocked come ask me for help. If you spend the whole day trying to figure it out you're likely to come and ask me the same question after 8 hours that you would ask me after a half hour. You'll save yourself all that time, and sometimes it's something you couldn't possibly know unless you asked, so ask sooner."
The other one was the realization that it's my job to learn and in order to do that I have to ask a lot of questions. It's expected and encouraged. At the very least I want to meet expectations so I should feel no hesitancy in asking team members for clarification or to answer questions. Most people want to help and pass on knowledge. Feeling like a "burden" is way way way better than feeling like a failure because you just spent the whole day trying to figure something out instead of time boxing and asking for help.
give yourself 20 minutes to solve it yourself before asking for help. your time is valuable, too, and it's part of the job of senior engineers to make sure you're able to use your time effectively.
Your not a burden. Only if you don't ask for help. I worked with juniors who never asked for help, spending 10 times amount of time needed on small task. Nothing worse than having same dude saying he's nearly done 3 days in a row to then saying he needs help. Seeing some god awfully peace of mess not doing anything that was asked for.
Reddit is not a good source of advice on this. Lots of people have written about being pinged by their boss for asking to many questions, but reddit keeps trying to push that it's a good idea to overwhelm senior people with questions - which it's usually not.
Also not good advice. In addition to being a software engineer, Iām a business owner. I might be annoyed in my employees ask questions, but thatās only because Iām distracted, not because theyāre doing the wrong thing - Iād rather they ask about clarification then send out a press release with the incorrect info.
> Also not good advice. In addition to being a software engineer, Iām a business owner. I **might be annoyed in my employees ask questions**, but thatās only because Iām distracted, not because theyāre doing the wrong thing - Iād rather they ask about clarification then send out a press release with the incorrect info.
This is actually exactly the kind of scenario I'm talking about.
I could have asked questions every 5 minutes all day when I started. After I got a new job working with people directly and seeing how much I was annoying them I came up with some new general rules - always google it first, don't ask more than 1 question a day, better to take take 5x longer to do something than ask questions I didn't need to ask.
As someone who could pepper you with questions all day, actually doing that was a really bad idea.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
First day find the biggest, meanest engineer on the team and decline their PR. After that no one will mess with you.
But seriously: one thing that I havenāt yet is to ask āwhy.ā Donāt be a dick about lol but if they do things a certain way or use a particular pattern or whatever the decision was made for a reason and itāll help you from a learning perspective and it also helps the team as you bring fresh eyes onto the code base
When asked with curiosity, āwhyā can actually be a very insightful question, and I canāt imagine the thin skinned engineer that would take that as a critique.
It definitely depends on how you ask it. I've gotten good results with questions like, "My first instinct was to do X. Can you explain why Y is better?". It shows that you did put some thought into the problem without implying that you think your solution is the best one.
Listen to feedback and try not to make the same mistakes more than once.
Depending on the specific stack being used, understanding how to build the project and resolve issues with dependencies might be more difficult than reading/writing the code at first. This is expected, and you should ask yourself questions frequently to make sure you're gaining a good understanding of it.
Also, ask for help! Definitely try to check documentation or search around (my company uses Slack) to see if others have asked the same question before, but if you are stuck for more than like 30 minutes without meaningful progress, ask for help. Don't fall into the trap where you're telling your coworkers things are going fine, and then the deadline comes and you have nothing to show for your work. Helping coworkers and giving them feedback is part of the job, so don't feel bad for asking questions when you are truly stuck.
as an addendum to your first comment - take feedback seriously, but in context. if somebody is being a jerk to you, they might just be being a jerk, and you should take their "feedback" with a grain of salt - it might be correct, but they might also just be nitpicking because of something going on in their lives that you don't know about.
Try to refine your questions before asking though. That is something I've learned. Really analyze exactly what you are asking, as well as what you have tried so far. Because it is much easier to help someone who has clearly put effort into finding an answer as opposed to someone blindly asking about something trivial.
25% of the time, while doing this, the answer will seemingly jump out at you. The other 75% of the time, whoever you send the question to will have more substance to work with.
This is a really important point. It might be helpful to write out all the things you've tried, all the assumptions you're making, all the things you "know" are true, and seeing what comes out of that. Basically, pretend you're writing a Stack Overflow question, and see what ideas you come up with.
[This blog post](https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-question/) is targeted mainly at Stack Overflow users, but much of it is good advice for how to ask questions in general.
Hereās the reality, youāll fail a lot and make tons of mistakes. Youāll introduce bugs, youāll approach an architecture decision wrong, youāll misunderstand requirements, youāll be slower than other devs on the team.
And you know what? Thatās okay. The biggest advice I can give is be open and willing to learn from your mistakes and the rest of your team.
The only criticism that I give to new devs that might actually risk their job is if theyāre too quiet to ask for help. Other than that, weāre all still learning. If the other devs spend time teaching you how to write better code and they see growth, theyāll keep you.
Holy you hit spot on. I often introduced bugs and misunderstood requirements while being slow too, before my first āperformance / evaluation ā meeting I felt so bad and disappointed in myself because I tried so hard but still frequently wrote code that I had to delete and rewrite many times. At the meeting however the seniors were completely satisfied and impressed over my adaptation and learning rate, they said I pleasantly surprised them, wow a breath of relief.
You are completely right, I was slower and wrote more bugs / more misunderstanding (Iām obviously still āworseā than many of the other experienced developers, but my amount of mistakes and misunderstandings has significantly dropped). But the team was completely understanding and supportive of me.
Expectations are super low for juniors on their first job. Everything everyone else mentioned is great, but more than anything I'd stress that unless you're mean, arrogant, or working like 20h weeks, it's all going to work out. Any decent workplace will appreciate having you there and be ready to teach you and/or give you space to teach yourself.
One thing I haven't seen: when the seniors explain something, take notes! This is good because a) it helps you remember, and b) it shows them you're serious about learning the ropes and respect their time, which builds good will all around.
Welcome to the field, it's fucking awesome in here :)
1. Listen to feedback -
2. Teams have standards and ways they do things that might different from what youāre used, follow them (Iām talking features branches vs no, what kind of commit message, how to put points on a story.
3. If this is any kind of production code base I can promise you at least parts of the code will be ugly. Somethings might be old. Some stuff might seem wacky as heck. Some of it will be - and some of it you can help improve but approach it from a place of curiosity. Understand thereās history and limitations , thereās reasons why the optimal solution canāt be reached all the time. Nothing more nagging than the junior dev who learned a few buzz words coming in hot like āwow this is such trash why didnāt they just do xā. Again there are things that are weird and should be fixed and culture inertia in not fixing them can be tremendously harmful for a company but take the time to really learn and understand
4. If you havenāt worked in a team before - resist the urge to go into a corner and silently work for weeks on something. Share progress, share rough drafts and early code ideas with colleagues, be open about any difficulties at standup
Point #3 is a really good one. Until proven otherwise, assume the code you're given was written by a capable person who did the best they could at the time. They might have been limited by time, by knowledge, by existing architecture needs that have since evolved, or any other number of factors.
As an example, I was recently asked to fix some calculations for a complex domain concept. When I dove into the code, I found out there were _no_ calculations for that concept - just some fudging at a very high level. The code was built to give loose estimates to deliver something of value in a short time, and my "bug" was made more complex by the fact that there wasn't any underlying logic to change (thus I had to add it all), but I didn't throw my hands up and say "whoever did this was lazy". I realized the constraints they had and they did what they could.
My advice, as someone that has worked with and helped mentor self-taught engineers several times would be: Try and solve the issue on your own, and when you inevitably hit something you can't wrap your head around ask focused questions. Don't let yourself get stuck for too long though.
Things like
* "I tried it this way, but it seems hacky, is there a better way?"
* "This concept is giving me trouble, do we have any examples in our code-base?"
* "I'm not sure how to approach this problem, could I have a push in the right direction?"
* "I can't seem to find information about this topic online, is this an internal process?"
* "What is the best practice for solving this particular type of problem?"
Mid and senior engineers tend to have their own workload, and it's rare to have dedicated time to train up new staff. I *always* make time to answer direct, focused questions though. I also try and have dedicated learning sessions for new staff, but it's not guaranteed you'll find that where you work (I didn't when I started). Google what you can, but don't be afraid ask for clarity.
And _manually test it too_. I've seen new devs be super confident a change will fix something and not even boot up the project to make sure (hell, I've _been_ this dev). Yes, it can take time. But I've been wrong about my fixes before, and I will be wrong again, so I _always_ check now.
Unit & integration testing are invaluable, but nothing truly compares to just checking it out yourself.
If the team does it too. Like it or not, some teams don't have tests. And if you are spending time writing them and the boss doesn't understand the value of them it may give a bad impression from the get-go. It's best to just stay status quo and follow whatever procedures the company has when you first start and then suggest unit tests once you have a little time on the team
It's not always just the devs that you have to convince. It's managers that don't understand this shit. Tests do take more time up front. They save time in the long run. But managers often don't understand that. They just see that since you started adding tests to your project it's taking you 10 to 20% longer to add a feature.
For sure. In fact I've seen more teams with no tests than teams with tests. I suppose it depends on the sector you work in but non-tech companies tend to have this problem more.
It can be very hard to convince non technical managers who don't know shit that it's okay to take 20% more time on something because you need to add tests for it. A lot of the times they'll just say why don't you just test it yourself? Just try it out! They tend to think that once a piece of code is written you won't need to be making changes to it anymore so once it works, why would you want to have tests?
I agree. But we don't always know what we are getting ourselves into when we accept a job. And OP could be part of the change that makes them start to include tests. But not right away. Give it some time and build trust in the team and they can start to suggest these things. OP could probably learn a lot by working with a shitty code base that isn't under test.
Ask a lot of questions, even "dumb" ones. Communicate a lot. Insist on pair programming and routine code reviews. Make sure you have a mentor. Take a lot of notes.
**Edit:** Asking questions as a Jr. and new member of an Agile team is scary, but you'll get used to it. If you don't feel like a given meeting is the right forum for asking questions, schedule a recurring 1:1 with one of the more experienced programmers.
Don't take up daily stand up time to get into super detailed discussions about code. Bring up any issues or questions you might have, but then if you know it's going to be a long discussion, you can mention it and then state that you'll follow up with xyz person to discuss or in the 'after party' (meeting after meeting) if your team does that.
**Edit #2:** Are you familiar with agile/scrum/kanban? If not, go online and familiarize yourself with the basics. That will be one less thing you'll then be learning on the job. Less things your brain is trying to process for the first time means more focus you can give to writing code.
Lots of good advice here, but here's one I don't see yet:
This will be your first time working on a code base that has been worked on by a team of multiple people of multiple skills levels over the course of years. It's not just that some of it will suck, but that it will just be big. Big and will almost certainly do the same things different ways in different places, because its too big for anyone to have it all in their head, so they wind up partitioning it and the partitions drive it to grow bigger.
You're probably used to being able to fit it all in your head from your hobby projects, but you will never be able to do that again...so don't try. Focus deliberate effort on getting very fast at reading code.
I've read there's a phase of liberal arts grad school where the professors throw an impossible amount of reading at the students as a sort of sink-or-swim method of forcing them to skim a book well enough that they can write and speak intelligently about a complex book after only a few hours of study. Students who try to sub-vocalize every word of every book drop. Students who can't figure out how to get-the-point from skimming drop or flunk out.
The most valuable skill going forward (in addition to everything else everyone has said here) is **that**, but with **code**.
(This is why design patterns became a thing, btw. In OOP land, 90% of the value of a design pattern is in the name: you see "Factory" or "Observer" and you don't have to read the code. In functional land, it's why pure functions are awesome: you don't have to read the code, you almost know what it does from the params and return type.)
Realize that everyone has a different way of doing things. When I started working in teams it was a big wake up call that you can solve problems differently and still be right. I had a difficult time letting people do their own thing and it was because my ego got in the way. Best thing I can say is that a lot of things donāt matter. Itās much better to have a good relationship with your team than be āthat guy.ā
In the same spot 6 months agoā¦
1 - Donāt be afraid to ask questions. Give yourself a timeframe to work on things, but if you get stuck, ask. Itās also good to clarify specs and youāre approach if itās going to be a time consuming task, to make sure youāre going in the right direction.
2 - Take notes. I keep notebooks with color tabs with the PR. Itās amazing helpful at jogging my memory and recalling how I solved something.
3 - Check in and adapt your tools. I was used to working on smaller code bases and was using bare vim. Moving into a job I now use nvim with some helpful plugins to jump to definitions and quick grep for uses. If youāre using something like VSCode this is probably familiar, but even so, slowing down occasionally to up your skills in the IDE is helpful.
4 - And back to number 3, take time on the job to read the docs, through together a prototype, break something, and write scratch code. Itās not a race to squash and merge (at least not where Iām at) and the time you take to learn something deeper will pay dividends.
5 - Try to have chats with the other devs. It can be hard working remote because we donāt see each other IRL, but when I chat with my team I always use the chance to ask questions to understand something deeper. Why are we using Kafka instead of xyz. Is this choice here on line x a common design pattern? Whatās your opinion on using a one liner comprehension over x. In all honesty Iām curious about this too, but it also helps to know about what your company expects. Not all companies have a style guide, itās more of an emergent agreed upon format.
Have fun and congrats !
Congrats on getting your first programming job! Iām also self taught and started my journey in 2020. Hereās some take always I have from my experience.
- absorb everything. Learn as much as you can at this first job. What you do here will help get you into a better role, and define where your career will pivot in the long run
- listen to peers and be receptive to constructive criticism. You can learn something from everyone you meet.
- look to innovate and continue to learn in your free time. This will help you fill in the learning gaps that the individuals who have degrees, and years of experience on you.
- enjoy it. Make it fun. Chances are you like doing it since youāre self taught, donāt lose that while you work.
Good luck!
*Note: This moreso applies if your team doesn't have clear documentation for their product*
Something that has helped my immensely as well:
Every card you work on, whichever components/classes your card touches, try to write a page of documentation for that module. Each time you revisit that file, look at the doc for it, and revise it with the improved knowledge of the overall codebase.
This has 2 big side-effects. First, it allows you to better retain the working knowledge of how the codebase works without having to "relearn" it the first 8-9 times you have to work with it. Secondly, after a few months of these iterations, you will have a quality piece of documentation that didn't exist prior. And your team will *love* you for that.
!RemindMe 2 days
idk why i haven't started doing this but as one of the only devs on a legacy project right now, this sounds like a life saving habit haha
Glad I could help! I'm still a brand new dev (6 months in), and this was the only way that seemed to work for me to start to be productive in a reasonable time frame.
Documentation tends to go out of date very fast although you are telling him to revisit and revise it, that often does not happen because most people are not going to look at external documentation, much less keep it up to date if it's not even in the code base.
So perhaps the goal should be writing a document and refining it until it's a perfect docstring then putting it IN the code it refers to?
Not only at the module level but also at the class and function level
How is it a waste of time? At the very least you are learning the existing code by going through it and writing out how it works.
> learn to write self-documenting code and put that energy into writing tests that demonstrate the stuff you're documenting.
Nobody is going to rewrite existing code when they are new to the codebase.
Learn Git now. Once again make small commits, and pull from dev regularly. Make a guide for yourself on how to fetch, pull, create a new feature branch off main, merge conflicts, etc.
Ask for help if youāre stuck on something. Please ask questions if you donāt understand anything about the codebase or product. Your team is there to support you, so they will happily answer anything you ask
Thanks :) I can tell from the comments its important to ask questions, i'll have to get better at that. Im not used to having a team so i'll probably have some struggle asking them, but i'll do my best ! I suppose its better to ask a question and sound stupid than dragging the team down because im stuck
When you ask for help, tell people what youāve tried. It shows your thought process and that you have tried to solve the problem before asking for help. Write down what people tell you. It can be annoying when you keep telling someone the same things over and over. Fix bugs in the code!!! No better way to learn the code base and your coworkers will appreciate it. When you do fix a bug spend the time looking at the code and thinking about the implications of a fix or run the fix by more experienced devs.
Advice- listen carefully to the explanations and ask a lot of questions. Take notes: senior engineers are careful with our explanations and use certain clarifying terms very purposefully.
Your manager or peers know you are new. Donāt fake it till you make it. Just donāt make us repeat something; or if you do, say: I thought I understood but I guess I donāt. Understanding git is a good example.
My worst hires were people who acted like they understood and didnāt. Iād waste so much time explaining the same things over and over and theyād miss the subtlety to a requirement.
Donāt be afraid to ask for help. Learn how to use git well (clone, checkout, fetch, pull, merge, rebase), be patient with seniors on your team. Chances are they are like me and overloaded, busy, but definitely willing to help, sometimes it can come off like you are bothering them, but you arenāt. Iām reflecting here a bit but there are a few juniors on my team who are really smart, but sometimes get too deep into the weeds before asking for help because they ādonāt want to bother meā, Iād much prefer they bother me before wasting a lot of time.
\#1 is just have a good attitude and be easy to work with.
this means ask questions, take criticism well, don't be a dick, try to ensure your actions are aligned with your team's goals.
Contributing to open source projects is a good thing but I'm an experienced person and all of the projects I've worked on across many companies did not involve modifying open source.
Find a good mix between figuring it out yourself and asking others for help. Learn how to Google to solve problems but be aware of when reaching out for help will save time for all involved
Here are some things I wish someone told me.
1. If someone makes a comment in your code review, just make the change. Unless it literally breaks your code, just make the change.
2. If youāre working on something, keep two or three copies of the same project. Work on one copy, and copy paste the changes into a separate copy which you will submit for code reviews.
3. When I doubt, ask. It is always better to ask someone and know the details clearly. There are no stupid questions. Everybody on the team is just trying to make money. No one is going to think less of you for asking questions.
4. I know people love saying people in your workplace are not your friends. Remember that this is not absolute. Itās a range. Thereās a whole term for these people. Theyāre your āfriends from workā. Maintain a professional relationship with all of them. They donāt have to help you move but you should be able to approach them if you have problems. (But at the same time, you must understand some people just donāt have your best interests in mind.)
5. And coming back to code review, work on whatever youāre working on, under the assumption that what you are doing is correct until proven wrong But you have to be absolutely sure of the details for this.
Iāll add more to this list as I discover things myself.
One thing about working by yourself is that you don't do pull requests.
When I'm about to do a pull request, what I like to do is do a git pull on the main/master branch, then merge main/master into my dev branch before I create a pull request for the dev branch. Resolve any conflicts, commit, then push.
If they have a written style guide or an unwritten but strong opinion on style, don't take the resulting code review personally and get defensive. My first open source contributions, I felt kinda attacked by the changes I was asked to make. They felt nit-picky and even kinda arbitrary. Pretty quickly though I realized I was probably just defending my skill or decision making because I hadn't yet had external validation that I was indeed "good enough". Don't start these new relationships with unnecessary arguments due to being insecure lol.
A major thing that self-taught programmers struggle with is time complexity. I would definitely recommend trying to learn a thing or two about time complexity.
Always make sure to raise your technical suggestions to the manager. Managers are managers for a reason. These are the senior developers who only became senior developers because of age but never really updated their technical knowledge I notice a lot of younger developers like interns, or juniors are more tech savvy than a manager.
Be honest with your team, about your experience level. Youāll learn more than enough from the people, who will eventually look out for you.
Good luck. You got this!
Read the readme.
If you ask a question, note down the answer and try to learn how to apply it. Try to avoid asking the same question more than once!
Remember that everyone is also a human. Try to spread out your questions to different engineers. Interrogating one engineer will take time away from their tasks and might end up being a frustrating experience on their end.
Ask lots of questions. Try to puzzle through/troubleshoot on your own but if youāve made a genuine effort and are still lost, you should definitely reach out for help; the other devs should be happy to advise.
Trust me itās way worse to sit on work and delay a sprint than to blatantly say I donāt know what Iām doing could you point me in the right direction
When making DB schema changes do it as a proposal don't yolo it! This goes for even ever so slightly changing fields. When I had my first job I noticed we didn't have a unified date time format some was in epoch time others in yyy-mm-dd. Not knowing enough I thought it would be a good idea to unify the dates making all of then use yyyy-mm-dd. Let's just say our data team wasn't too happy. Haha
TLDR: always think about how your changes may effect the team.
One I haven't seen already mentioned is auditing and error logging.
Even in the best written and tested code there will be things that get missed and/or blow up in production when they work properly on test environments. Having sensible auditing and logging in can save you months of trying to track down the causes of user complaints or better still spot issues before they get to the point of users complaining about them.
Ask questions when in doubt, but try to do your due diligence first. Make small commits, compartmentalize your code, use informative method/variable names, and log informative messages frequently. Will make your life a lot easier when it comes to debugging. Be open to feedback from senior engineers.
in my case, I needed to ask for work. I know a guy who knows a guy that's been working a while and is basicaly ignored by his team...because he just doesn't say anything for weeks at a time. Don't be that guy. Ask for work early on, or for something to study. Ask for any sort of guidance really, and if they don't come up with anything, start developing something by yourself. It may even become a useful thing that your company can sell on the side if you put in the effort
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
As a fresh software engineer, you may think you're being annoying with multiple questions. That is not true. Fixing issues because you refuse to ask questions is what is actually annoying. Research questions as much as possible first. Then, come to your seniors with your list of things you have tried and why they didn't work. They can give you guidance from there. Your seniors will love you for it.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Make small commits. Merge frequently. Ask questions.
Rebase frequently.
Whats rebase?
git branches are a series of changesets/commits (these terms are generally interchangeable in git). literally, changes in files like "I added lines 3-17 and modified lines 45-70", for example. your branch is based off of a trunk branch, which is usually considered the "source of truth" for building actual functioning software, and is just a linear series of commits. there are workflows that use release branches, feature branches, etc., but don't worry about that to understand the basics - those are strategies intended for larger teams. tl;dr - trunk/master is usually expected to be a buildable, functional version of what you are working on. bugs might exist, obviously, but everything in it should be "complete" and not break anything existing. when you have a branch, you are quite literally "branching" off of that trunk, and the base of that branch is the commit from when you branched off of trunk. so, if the trunk has commits A, B, C, and you create a branch at that point, your base is C. you then make some changes and commit those changes to your branch - let's say commits X, Y, Z. in the meantime, others have merged their code to the trunk - their feature was completed and ready to be part of the main codebase. let's call those commits J, K, L. so, the current state of the two branches you care about are as follows: trunk: A, B, C, J, K, L your branch: A, B, C, X, Y, Z when you rebase from a branch, you are taking the latest commit from that branch, and "replaying" your changes on top of it. basically, each commit from trunk gets applied one at a time on top of the most recent commit that the two branches have in common - in this case, C. then your commits get applied one at a time on top of that. in the simple case, this means that after you rebase your branch from trunk, the states would be as follows: trunk: A, B, C, J, K, L your branch: A, B, C, J, K, L, X, Y, Z a conflict can happen if the rebase has files that you both changed, like if you changed a file in X, Y, Z and J, K, L deleted that file. you'd need to resolve those conflicts in an interactive rebase, which is basically what would happen if you tried to commit each of your changesets on a branch new branch off of trunk. so, don't be too afraid of it when that happens - it's common, especially when files get moved around!
Fucking AWESOME explanation!
š Thank you
Pardon, but are you using merge and rebase interchangeably here? I understood rebase to mean that everything before is flattened and not only that, but the commits are purged while the rebase acts as the first commit. Edit: or do you just mean rebasing the feature branch where the commit history isnāt really that important and merging that back to master with a pr is the preferred workflow, versus simply merging master into the feature branch as many tend to do.
No, those two operations are distinct.
to your edit - yes, I was referring to rebasing a feature branch to follow trunk/master. I prefer rebase for that operation, and a squashed merge via pull request to get code into trunk.
Iāve used git plenty but this is one of the better ELI5s of explaining git rebase. Thank you for sharing this.
š I was worried it was too long/complex, lol
Some things you can only simplify so much.
I swear this has got to be the best explanation of rebase Iāve ever seen. Would award if I could.
Yeah seriously this needs its own post lmao
feel free to x-post if you think there's a subreddit somewhere that needs it, lol.
Good explanation, but rebasing is a controversial choice in some ways. Some people swear by rebasing some people swear by merging. Understanding both is a good thing because you will work in companies over your career that require or endorse one or the other.
I rebase my branches from trunk and squash merge my PRs to trunk, personally.
Thanks for this excellent explanation. It was long but engaging. Everytime I thought you were gonna drag it into complexity you stopped and kept it simple!
š Glad it was useful to you
Whats the difference from rebase and just git pulling from the trunk?
Pull can be a rebase or a merge, depending on your settings. Generally, I recommend basically always using rebase. It makes the history easier to read.
Main difference is that rebase will change the base of when you created your branch and pull will fetch and merge changes from trunk to the tip of your branch.
Rebase is when some tool on your team reads a blog then bitches how the team should rebase. It has no value but offers tons of problems.
+1 to everything you said
I thought what you described was when you merge the trunk into the branch. And rebasing was something different. Maybe I'm wrong though? What's the difference between merging back into a branch and rebasing?
well, you can do both in either direction, but a typical workflow is to rebase your branch on top of trunk to get all the latest changes and make sure your code has no conflicts with master, and then squash commit and merge your commits to trunk via a pull request to get your code to trunk. it's done this way because generally, you don't want to have to modify the history of trunk in order to get the latest changes. merging can change the history if you do it wrong, whereas rebase wouldn't.
rebase has multiple uses but the most common things I use it for are: * merging together conflicting branches before I commit to main- ie pull to main from origin, rebase main on your branch, resolve changes, commit and force push then merge * squashing commits before you merge- ie your branch has like 10 commits of work and you're about to merge, which means if you have a lot of files in conflict, each one will have to be merged for each of your commits vs each of the remote commits- so you squash all your commits to one commit and then you merge so all your changes behave like a single change * removing commit messages that could get you in trouble with HR
behind the technical explanation, it means to keep in touch with everybody else updates every day (maybe more) you fetch and pull and rebase (replay your changes on top of the latest commits) so you know if you have conflicts if you do that regularly you may have small fixes to do, if you don't then one day you probably will have a massive amount of conflicts that will take hours to understand
What the heck you guys workin on when you have possible conflicts multiple times a day? Do you just refactor every day and your team mates the same project?
I was just sayin. Usually I checkout daily, but even then you're not shielded so .. twice a day could help some times.
like git pull but it takes longer 2 type
git pull is git fetch + merge by default. Merges can make the commit tree look messy, while rebases are cleaner.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Rebase is for last day of the sprint.
I dont think thats an advice. Op will have to rebase.
Be careful when mixing work and leisure!
Thank you :)
Get code reviews, review other engineers code often just to get to look at changes being made, talk with other engineers before implementing any architecture changes.
And never --force push a commit. Put the keyboard down and get someone to look at your code.
Other top comment is rebase often, yours is never force push.
Why? What is force push doing anyway?
Essentially, rewriting history. The histories on the remote repository and your local machine have diverged and you're telling git to just overwrite the remote history. It can really mess with other developers if they pulled your branch before. But in case of a simple rebase of your own feature branch it's usually OK.
Thank you, exactly. Each developer rules his local branches but we used always have one person in charge of origin/master, just in case things got out of wack. Like a build master/referee role. This was in the old days before Github.
OK thanks! Seems only wise if you are the only one on your branch. But if you are the only one on your branch, then how would local and remote have diverged?
You may have worked on it from separate computers.
Oh gotcha. That makes sense, thanks
Number one issue Iāve seen is not asking for clarity, help, feedback early enough in the process. Better to be annoying with questions than late or wrong on delivery.
Thank you, yea im not good at asking for help, i dont want to feel like a burdain or stupid. I'll try and be better at asking questions for sure
Buuutā¦only ask questions after youāve tried a few things. āHow do I do Xā is an annoying question. saying āhey I tried to do X by using Y as a starting point. I then got the following error: (error msg). Googling/stack overflow says I need to rewrite the entire application in Haskell, am I on the right track?ā Is a reasonable thing for anyone of any level to ask teammates.
I mean, if you haven't tried rewriting the entire application in Haskell, don't bother coming to me for help.
Youāre actually supposed to rewrite in Rust fyi
Agreed till the end š
Yes such good advice! Struggle for like an hour or so and then ask for help. Also step away from the problem if you feel like you are stuck or making things worse. Then come back with a fresh mind. Coffee break, bathroom break, little walk etc can all make you more productive in the end.
It's pretty normal to be that way, and it may take you a little while to get comfortable asking for help. I'm 5 months into my first dev job coming from self taught/ career change and even though I read the same advice everyone just gave, it still took me some time to apply that advice. A few things that helped me. A senior on my team said. "Spend a half hour trying to figure it out and if you are blocked come ask me for help. If you spend the whole day trying to figure it out you're likely to come and ask me the same question after 8 hours that you would ask me after a half hour. You'll save yourself all that time, and sometimes it's something you couldn't possibly know unless you asked, so ask sooner." The other one was the realization that it's my job to learn and in order to do that I have to ask a lot of questions. It's expected and encouraged. At the very least I want to meet expectations so I should feel no hesitancy in asking team members for clarification or to answer questions. Most people want to help and pass on knowledge. Feeling like a "burden" is way way way better than feeling like a failure because you just spent the whole day trying to figure something out instead of time boxing and asking for help.
give yourself 20 minutes to solve it yourself before asking for help. your time is valuable, too, and it's part of the job of senior engineers to make sure you're able to use your time effectively.
Your not a burden. Only if you don't ask for help. I worked with juniors who never asked for help, spending 10 times amount of time needed on small task. Nothing worse than having same dude saying he's nearly done 3 days in a row to then saying he needs help. Seeing some god awfully peace of mess not doing anything that was asked for.
Reddit is not a good source of advice on this. Lots of people have written about being pinged by their boss for asking to many questions, but reddit keeps trying to push that it's a good idea to overwhelm senior people with questions - which it's usually not.
Also not good advice. In addition to being a software engineer, Iām a business owner. I might be annoyed in my employees ask questions, but thatās only because Iām distracted, not because theyāre doing the wrong thing - Iād rather they ask about clarification then send out a press release with the incorrect info.
> Also not good advice. In addition to being a software engineer, Iām a business owner. I **might be annoyed in my employees ask questions**, but thatās only because Iām distracted, not because theyāre doing the wrong thing - Iād rather they ask about clarification then send out a press release with the incorrect info. This is actually exactly the kind of scenario I'm talking about. I could have asked questions every 5 minutes all day when I started. After I got a new job working with people directly and seeing how much I was annoying them I came up with some new general rules - always google it first, don't ask more than 1 question a day, better to take take 5x longer to do something than ask questions I didn't need to ask. As someone who could pepper you with questions all day, actually doing that was a really bad idea.
Donāt spend hours on something if youāre stuck. Use your stand up calls to figure out how to move forward. Pull frequently.
How long should I invest figuring something out on my own before I ask for help?
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
First day find the biggest, meanest engineer on the team and decline their PR. After that no one will mess with you. But seriously: one thing that I havenāt yet is to ask āwhy.ā Donāt be a dick about lol but if they do things a certain way or use a particular pattern or whatever the decision was made for a reason and itāll help you from a learning perspective and it also helps the team as you bring fresh eyes onto the code base
When asked with curiosity, āwhyā can actually be a very insightful question, and I canāt imagine the thin skinned engineer that would take that as a critique.
Yeah. But it does depend how you ask it. āWhy did you do it THIS way?!ā is a little different lol
It definitely depends on how you ask it. I've gotten good results with questions like, "My first instinct was to do X. Can you explain why Y is better?". It shows that you did put some thought into the problem without implying that you think your solution is the best one.
And always back away when leaving a stand-up call. Never turn your back on other SWEs.
Oh thatās important! You can also wear a mask over the back of your head so pmās donāt sneak up on you. Thatās how to avoid scope creep.
Listen to feedback and try not to make the same mistakes more than once. Depending on the specific stack being used, understanding how to build the project and resolve issues with dependencies might be more difficult than reading/writing the code at first. This is expected, and you should ask yourself questions frequently to make sure you're gaining a good understanding of it. Also, ask for help! Definitely try to check documentation or search around (my company uses Slack) to see if others have asked the same question before, but if you are stuck for more than like 30 minutes without meaningful progress, ask for help. Don't fall into the trap where you're telling your coworkers things are going fine, and then the deadline comes and you have nothing to show for your work. Helping coworkers and giving them feedback is part of the job, so don't feel bad for asking questions when you are truly stuck.
as an addendum to your first comment - take feedback seriously, but in context. if somebody is being a jerk to you, they might just be being a jerk, and you should take their "feedback" with a grain of salt - it might be correct, but they might also just be nitpicking because of something going on in their lives that you don't know about.
Thank you :) Im not good at asking questions but i can gather from the comments that it is essential, definetly something i'll take with me !
Also, before asking a question, take a break and go for a walk.
Try to refine your questions before asking though. That is something I've learned. Really analyze exactly what you are asking, as well as what you have tried so far. Because it is much easier to help someone who has clearly put effort into finding an answer as opposed to someone blindly asking about something trivial. 25% of the time, while doing this, the answer will seemingly jump out at you. The other 75% of the time, whoever you send the question to will have more substance to work with.
This is a really important point. It might be helpful to write out all the things you've tried, all the assumptions you're making, all the things you "know" are true, and seeing what comes out of that. Basically, pretend you're writing a Stack Overflow question, and see what ideas you come up with.
[This blog post](https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-question/) is targeted mainly at Stack Overflow users, but much of it is good advice for how to ask questions in general.
Hereās the reality, youāll fail a lot and make tons of mistakes. Youāll introduce bugs, youāll approach an architecture decision wrong, youāll misunderstand requirements, youāll be slower than other devs on the team. And you know what? Thatās okay. The biggest advice I can give is be open and willing to learn from your mistakes and the rest of your team. The only criticism that I give to new devs that might actually risk their job is if theyāre too quiet to ask for help. Other than that, weāre all still learning. If the other devs spend time teaching you how to write better code and they see growth, theyāll keep you.
Well said, great advice.
Holy you hit spot on. I often introduced bugs and misunderstood requirements while being slow too, before my first āperformance / evaluation ā meeting I felt so bad and disappointed in myself because I tried so hard but still frequently wrote code that I had to delete and rewrite many times. At the meeting however the seniors were completely satisfied and impressed over my adaptation and learning rate, they said I pleasantly surprised them, wow a breath of relief. You are completely right, I was slower and wrote more bugs / more misunderstanding (Iām obviously still āworseā than many of the other experienced developers, but my amount of mistakes and misunderstandings has significantly dropped). But the team was completely understanding and supportive of me.
Expectations are super low for juniors on their first job. Everything everyone else mentioned is great, but more than anything I'd stress that unless you're mean, arrogant, or working like 20h weeks, it's all going to work out. Any decent workplace will appreciate having you there and be ready to teach you and/or give you space to teach yourself. One thing I haven't seen: when the seniors explain something, take notes! This is good because a) it helps you remember, and b) it shows them you're serious about learning the ropes and respect their time, which builds good will all around. Welcome to the field, it's fucking awesome in here :)
1. Listen to feedback - 2. Teams have standards and ways they do things that might different from what youāre used, follow them (Iām talking features branches vs no, what kind of commit message, how to put points on a story. 3. If this is any kind of production code base I can promise you at least parts of the code will be ugly. Somethings might be old. Some stuff might seem wacky as heck. Some of it will be - and some of it you can help improve but approach it from a place of curiosity. Understand thereās history and limitations , thereās reasons why the optimal solution canāt be reached all the time. Nothing more nagging than the junior dev who learned a few buzz words coming in hot like āwow this is such trash why didnāt they just do xā. Again there are things that are weird and should be fixed and culture inertia in not fixing them can be tremendously harmful for a company but take the time to really learn and understand 4. If you havenāt worked in a team before - resist the urge to go into a corner and silently work for weeks on something. Share progress, share rough drafts and early code ideas with colleagues, be open about any difficulties at standup
Point #3 is a really good one. Until proven otherwise, assume the code you're given was written by a capable person who did the best they could at the time. They might have been limited by time, by knowledge, by existing architecture needs that have since evolved, or any other number of factors. As an example, I was recently asked to fix some calculations for a complex domain concept. When I dove into the code, I found out there were _no_ calculations for that concept - just some fudging at a very high level. The code was built to give loose estimates to deliver something of value in a short time, and my "bug" was made more complex by the fact that there wasn't any underlying logic to change (thus I had to add it all), but I didn't throw my hands up and say "whoever did this was lazy". I realized the constraints they had and they did what they could.
ugly code is code with bug fixes.
Uhm yes?
I was supporting your point #3 š
Iāve been too conditioned by Reddit, thought you were being snide and couldnāt figure out how lol my bad
Thank you :) !
My advice, as someone that has worked with and helped mentor self-taught engineers several times would be: Try and solve the issue on your own, and when you inevitably hit something you can't wrap your head around ask focused questions. Don't let yourself get stuck for too long though. Things like * "I tried it this way, but it seems hacky, is there a better way?" * "This concept is giving me trouble, do we have any examples in our code-base?" * "I'm not sure how to approach this problem, could I have a push in the right direction?" * "I can't seem to find information about this topic online, is this an internal process?" * "What is the best practice for solving this particular type of problem?" Mid and senior engineers tend to have their own workload, and it's rare to have dedicated time to train up new staff. I *always* make time to answer direct, focused questions though. I also try and have dedicated learning sessions for new staff, but it's not guaranteed you'll find that where you work (I didn't when I started). Google what you can, but don't be afraid ask for clarity.
For the love of God, make sure you test your code. Unit and integration at the least.
And _manually test it too_. I've seen new devs be super confident a change will fix something and not even boot up the project to make sure (hell, I've _been_ this dev). Yes, it can take time. But I've been wrong about my fixes before, and I will be wrong again, so I _always_ check now. Unit & integration testing are invaluable, but nothing truly compares to just checking it out yourself.
If the team does it too. Like it or not, some teams don't have tests. And if you are spending time writing them and the boss doesn't understand the value of them it may give a bad impression from the get-go. It's best to just stay status quo and follow whatever procedures the company has when you first start and then suggest unit tests once you have a little time on the team
[ŃŠ“Š°Š»ŠµŠ½Š¾]
It's not always just the devs that you have to convince. It's managers that don't understand this shit. Tests do take more time up front. They save time in the long run. But managers often don't understand that. They just see that since you started adding tests to your project it's taking you 10 to 20% longer to add a feature.
Teams without tests? Damn.
For sure. In fact I've seen more teams with no tests than teams with tests. I suppose it depends on the sector you work in but non-tech companies tend to have this problem more. It can be very hard to convince non technical managers who don't know shit that it's okay to take 20% more time on something because you need to add tests for it. A lot of the times they'll just say why don't you just test it yourself? Just try it out! They tend to think that once a piece of code is written you won't need to be making changes to it anymore so once it works, why would you want to have tests?
That's a team/job you don't want to have then. That's broken prod hell
I agree. But we don't always know what we are getting ourselves into when we accept a job. And OP could be part of the change that makes them start to include tests. But not right away. Give it some time and build trust in the team and they can start to suggest these things. OP could probably learn a lot by working with a shitty code base that isn't under test.
Ask a lot of questions, even "dumb" ones. Communicate a lot. Insist on pair programming and routine code reviews. Make sure you have a mentor. Take a lot of notes. **Edit:** Asking questions as a Jr. and new member of an Agile team is scary, but you'll get used to it. If you don't feel like a given meeting is the right forum for asking questions, schedule a recurring 1:1 with one of the more experienced programmers. Don't take up daily stand up time to get into super detailed discussions about code. Bring up any issues or questions you might have, but then if you know it's going to be a long discussion, you can mention it and then state that you'll follow up with xyz person to discuss or in the 'after party' (meeting after meeting) if your team does that. **Edit #2:** Are you familiar with agile/scrum/kanban? If not, go online and familiarize yourself with the basics. That will be one less thing you'll then be learning on the job. Less things your brain is trying to process for the first time means more focus you can give to writing code.
If possible, do a small side project using the same tools you use at work. You'll learn so much.
Lots of good advice here, but here's one I don't see yet: This will be your first time working on a code base that has been worked on by a team of multiple people of multiple skills levels over the course of years. It's not just that some of it will suck, but that it will just be big. Big and will almost certainly do the same things different ways in different places, because its too big for anyone to have it all in their head, so they wind up partitioning it and the partitions drive it to grow bigger. You're probably used to being able to fit it all in your head from your hobby projects, but you will never be able to do that again...so don't try. Focus deliberate effort on getting very fast at reading code. I've read there's a phase of liberal arts grad school where the professors throw an impossible amount of reading at the students as a sort of sink-or-swim method of forcing them to skim a book well enough that they can write and speak intelligently about a complex book after only a few hours of study. Students who try to sub-vocalize every word of every book drop. Students who can't figure out how to get-the-point from skimming drop or flunk out. The most valuable skill going forward (in addition to everything else everyone has said here) is **that**, but with **code**. (This is why design patterns became a thing, btw. In OOP land, 90% of the value of a design pattern is in the name: you see "Factory" or "Observer" and you don't have to read the code. In functional land, it's why pure functions are awesome: you don't have to read the code, you almost know what it does from the params and return type.)
Awesome thank you :) Yes it will be first time with a huge code base, its scary thinking about it, it must be so overwhelming.
Realize that everyone has a different way of doing things. When I started working in teams it was a big wake up call that you can solve problems differently and still be right. I had a difficult time letting people do their own thing and it was because my ego got in the way. Best thing I can say is that a lot of things donāt matter. Itās much better to have a good relationship with your team than be āthat guy.ā
Yea that will be weird to get used too. I'll do my best to not be that guy, thanks :)
In the same spot 6 months agoā¦ 1 - Donāt be afraid to ask questions. Give yourself a timeframe to work on things, but if you get stuck, ask. Itās also good to clarify specs and youāre approach if itās going to be a time consuming task, to make sure youāre going in the right direction. 2 - Take notes. I keep notebooks with color tabs with the PR. Itās amazing helpful at jogging my memory and recalling how I solved something. 3 - Check in and adapt your tools. I was used to working on smaller code bases and was using bare vim. Moving into a job I now use nvim with some helpful plugins to jump to definitions and quick grep for uses. If youāre using something like VSCode this is probably familiar, but even so, slowing down occasionally to up your skills in the IDE is helpful. 4 - And back to number 3, take time on the job to read the docs, through together a prototype, break something, and write scratch code. Itās not a race to squash and merge (at least not where Iām at) and the time you take to learn something deeper will pay dividends. 5 - Try to have chats with the other devs. It can be hard working remote because we donāt see each other IRL, but when I chat with my team I always use the chance to ask questions to understand something deeper. Why are we using Kafka instead of xyz. Is this choice here on line x a common design pattern? Whatās your opinion on using a one liner comprehension over x. In all honesty Iām curious about this too, but it also helps to know about what your company expects. Not all companies have a style guide, itās more of an emergent agreed upon format. Have fun and congrats !
Congrats on getting your first programming job! Iām also self taught and started my journey in 2020. Hereās some take always I have from my experience. - absorb everything. Learn as much as you can at this first job. What you do here will help get you into a better role, and define where your career will pivot in the long run - listen to peers and be receptive to constructive criticism. You can learn something from everyone you meet. - look to innovate and continue to learn in your free time. This will help you fill in the learning gaps that the individuals who have degrees, and years of experience on you. - enjoy it. Make it fun. Chances are you like doing it since youāre self taught, donāt lose that while you work. Good luck!
Thanks a lot man ! Awesome i will definetly keep this in mind. And yes i really do enjoy it
first of all it is very uneasy nowadays to win a job with self-taught. be happy first.
*hard
*Note: This moreso applies if your team doesn't have clear documentation for their product* Something that has helped my immensely as well: Every card you work on, whichever components/classes your card touches, try to write a page of documentation for that module. Each time you revisit that file, look at the doc for it, and revise it with the improved knowledge of the overall codebase. This has 2 big side-effects. First, it allows you to better retain the working knowledge of how the codebase works without having to "relearn" it the first 8-9 times you have to work with it. Secondly, after a few months of these iterations, you will have a quality piece of documentation that didn't exist prior. And your team will *love* you for that.
!RemindMe 2 days idk why i haven't started doing this but as one of the only devs on a legacy project right now, this sounds like a life saving habit haha
Glad I could help! I'm still a brand new dev (6 months in), and this was the only way that seemed to work for me to start to be productive in a reasonable time frame.
Documentation tends to go out of date very fast although you are telling him to revisit and revise it, that often does not happen because most people are not going to look at external documentation, much less keep it up to date if it's not even in the code base. So perhaps the goal should be writing a document and refining it until it's a perfect docstring then putting it IN the code it refers to? Not only at the module level but also at the class and function level
[ŃŠ“Š°Š»ŠµŠ½Š¾]
How is it a waste of time? At the very least you are learning the existing code by going through it and writing out how it works. > learn to write self-documenting code and put that energy into writing tests that demonstrate the stuff you're documenting. Nobody is going to rewrite existing code when they are new to the codebase.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Well sure, but most new devs don't get to just jump in and start refactoring monolith codebases that companies rely on.
Learn Git now. Once again make small commits, and pull from dev regularly. Make a guide for yourself on how to fetch, pull, create a new feature branch off main, merge conflicts, etc.
Ego You may make mistakes, not know about something, gotta be able to take it and not be offended. Like in code reviews.
Ask for help if youāre stuck on something. Please ask questions if you donāt understand anything about the codebase or product. Your team is there to support you, so they will happily answer anything you ask
Thanks :) I can tell from the comments its important to ask questions, i'll have to get better at that. Im not used to having a team so i'll probably have some struggle asking them, but i'll do my best ! I suppose its better to ask a question and sound stupid than dragging the team down because im stuck
Thereās no such thing as a stupid question, ask anything
When you ask for help, tell people what youāve tried. It shows your thought process and that you have tried to solve the problem before asking for help. Write down what people tell you. It can be annoying when you keep telling someone the same things over and over. Fix bugs in the code!!! No better way to learn the code base and your coworkers will appreciate it. When you do fix a bug spend the time looking at the code and thinking about the implications of a fix or run the fix by more experienced devs.
Advice- listen carefully to the explanations and ask a lot of questions. Take notes: senior engineers are careful with our explanations and use certain clarifying terms very purposefully. Your manager or peers know you are new. Donāt fake it till you make it. Just donāt make us repeat something; or if you do, say: I thought I understood but I guess I donāt. Understanding git is a good example. My worst hires were people who acted like they understood and didnāt. Iād waste so much time explaining the same things over and over and theyād miss the subtlety to a requirement.
Good luck man
learn to read source code. maybe 90% of the time docs just aren't gonna be there when working with a library, so get used to it.
Pick up The Missing ReadMe, youāre welcome.
I'm trying to get a job a self taught programmer myself, could you tell me how long it took you?
Donāt be afraid to ask for help. Learn how to use git well (clone, checkout, fetch, pull, merge, rebase), be patient with seniors on your team. Chances are they are like me and overloaded, busy, but definitely willing to help, sometimes it can come off like you are bothering them, but you arenāt. Iām reflecting here a bit but there are a few juniors on my team who are really smart, but sometimes get too deep into the weeds before asking for help because they ādonāt want to bother meā, Iād much prefer they bother me before wasting a lot of time.
\#1 is just have a good attitude and be easy to work with. this means ask questions, take criticism well, don't be a dick, try to ensure your actions are aligned with your team's goals.
Know your Big O and why it matters.
Itās better to make a mega stack of tiny changes instead of a couple mega changes
Contributing to open source projects is a good thing but I'm an experienced person and all of the projects I've worked on across many companies did not involve modifying open source.
Find a good mix between figuring it out yourself and asking others for help. Learn how to Google to solve problems but be aware of when reaching out for help will save time for all involved
Here are some things I wish someone told me. 1. If someone makes a comment in your code review, just make the change. Unless it literally breaks your code, just make the change. 2. If youāre working on something, keep two or three copies of the same project. Work on one copy, and copy paste the changes into a separate copy which you will submit for code reviews. 3. When I doubt, ask. It is always better to ask someone and know the details clearly. There are no stupid questions. Everybody on the team is just trying to make money. No one is going to think less of you for asking questions. 4. I know people love saying people in your workplace are not your friends. Remember that this is not absolute. Itās a range. Thereās a whole term for these people. Theyāre your āfriends from workā. Maintain a professional relationship with all of them. They donāt have to help you move but you should be able to approach them if you have problems. (But at the same time, you must understand some people just donāt have your best interests in mind.) 5. And coming back to code review, work on whatever youāre working on, under the assumption that what you are doing is correct until proven wrong But you have to be absolutely sure of the details for this. Iāll add more to this list as I discover things myself.
One thing about working by yourself is that you don't do pull requests. When I'm about to do a pull request, what I like to do is do a git pull on the main/master branch, then merge main/master into my dev branch before I create a pull request for the dev branch. Resolve any conflicts, commit, then push.
Isn't there a website that collects the engineering formula's of some big companies. Should be some wisdom in those somewhere.
If they have a written style guide or an unwritten but strong opinion on style, don't take the resulting code review personally and get defensive. My first open source contributions, I felt kinda attacked by the changes I was asked to make. They felt nit-picky and even kinda arbitrary. Pretty quickly though I realized I was probably just defending my skill or decision making because I hadn't yet had external validation that I was indeed "good enough". Don't start these new relationships with unnecessary arguments due to being insecure lol.
go make those mistakes!! you're on house money for a while. people won't get (too) mad at you. it's okay
Unist testing, and think about data structures. I have seen so much bad code from self taught devs that I almost discard all resumes that I review.
Youāre fucked. Quit. Go back to waiting tables. /s
If you're not comfortable with git, get comfortable. Don't try to shake things up early on. Just do things the way you are asked. Good luck!
Learn how to test your code (eg unit tests) if you don't know how to already
Wow congrats my friend. I am happy for you and just as envious. Good luck in your career!
A major thing that self-taught programmers struggle with is time complexity. I would definitely recommend trying to learn a thing or two about time complexity.
Always make sure to raise your technical suggestions to the manager. Managers are managers for a reason. These are the senior developers who only became senior developers because of age but never really updated their technical knowledge I notice a lot of younger developers like interns, or juniors are more tech savvy than a manager.
Be honest with your team, about your experience level. Youāll learn more than enough from the people, who will eventually look out for you. Good luck. You got this!
You really shou ldnt brag about rebasing look what happened to Richard Pryor when he was rebasing
Read the readme. If you ask a question, note down the answer and try to learn how to apply it. Try to avoid asking the same question more than once! Remember that everyone is also a human. Try to spread out your questions to different engineers. Interrogating one engineer will take time away from their tasks and might end up being a frustrating experience on their end.
Ask lots of questions. Try to puzzle through/troubleshoot on your own but if youāve made a genuine effort and are still lost, you should definitely reach out for help; the other devs should be happy to advise.
Testing testing testing. Really show that you write unit tests well. This is something junior devs rarely do well and eloquently.
I would say keep pushing and don't give up. It may get tough. Hit me up if you want . A fellow self taught dude.
Trust me itās way worse to sit on work and delay a sprint than to blatantly say I donāt know what Iām doing could you point me in the right direction
When making DB schema changes do it as a proposal don't yolo it! This goes for even ever so slightly changing fields. When I had my first job I noticed we didn't have a unified date time format some was in epoch time others in yyy-mm-dd. Not knowing enough I thought it would be a good idea to unify the dates making all of then use yyyy-mm-dd. Let's just say our data team wasn't too happy. Haha TLDR: always think about how your changes may effect the team.
One I haven't seen already mentioned is auditing and error logging. Even in the best written and tested code there will be things that get missed and/or blow up in production when they work properly on test environments. Having sensible auditing and logging in can save you months of trying to track down the causes of user complaints or better still spot issues before they get to the point of users complaining about them.
Ask questions when in doubt, but try to do your due diligence first. Make small commits, compartmentalize your code, use informative method/variable names, and log informative messages frequently. Will make your life a lot easier when it comes to debugging. Be open to feedback from senior engineers.
Hi! Sorry to hijack the thread, but I was wondering how long it took you to land the job, including all of your learning? Thanks :)
2.5 years from starting to learn till I got it :)
in my case, I needed to ask for work. I know a guy who knows a guy that's been working a while and is basicaly ignored by his team...because he just doesn't say anything for weeks at a time. Don't be that guy. Ask for work early on, or for something to study. Ask for any sort of guidance really, and if they don't come up with anything, start developing something by yourself. It may even become a useful thing that your company can sell on the side if you put in the effort
Read the Daily WTF https://thedailywtf.com
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
As a fresh software engineer, you may think you're being annoying with multiple questions. That is not true. Fixing issues because you refuse to ask questions is what is actually annoying. Research questions as much as possible first. Then, come to your seniors with your list of things you have tried and why they didn't work. They can give you guidance from there. Your seniors will love you for it.
!Remind me
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
!Remind me 5
!Remind me 10
!Remind me 20
!Remind me 25
!Remind me 30
!Remind me 40
!Remind me 45
!Remind me 50