Starting a new job - learning on the job, and learning new systems, getting competent [closed]

Question

I am starting a new job soon as a junior software engineer.

The new team maintains a large code base, and will be using libraries I'm not familiar with.

E.g. they do a lot of OpenGL work, and I've previously mostly done data processing.
I'm not expecting this to be a problem - I was very up front at the interview about what I did an didn't know, but it will require some learning.

How does Stack Exchange get competent at a new job?

How do you learn the structure and conventions of a new code base?
I am considering asking to spend my first weeks writing unit tests, unless they give me a self contained little module to write.

How do you learn new libraries and concepts?
Is it acceptable to ask for downtime to learn them (at your work? at your friends?)?

What rookie mistakes should I avoid, so that my greenness does not effect the overall project?

Answer 1

I use sharpening and task flow to get up to speed as quickly as possible. These are the methods I learned from working in high speed, high pressure enterprise IT support.

I've since started working at places that are lower speed and lower pressure, but I've found that these techniques work equally well, and let me hit the ground running very quickly with lots of technologies I wasn't already familiar with. The basic idea is to build yourself a set of drills and deliberate practice that you go through everyday to better your retention and understanding of something new.

This isn't just for new jobs, however. It works for keeping things going long after you're new, and also in taking on any new skill (at work or elsewhere), in my experience. The hardest part about it is simply having the discipline to follow through on your plan to learn something new.

Answer 2

Everyone expects that new people will have questions and most people will be fairly gracious about helping you get started as long as you don't come acoss as a user (Imean this isn the sense of someone who manipulates people not a software user) who isn't even trying but exppects everyone else to drop everything and do his job too.

One thing you will want to figure out first is how and where to commit code changes and how often the organization expects you do it. Get a good solid feel for how to use the source control system as a priority espcially if you havent used one with a large group before.

Ask if they have a coding stadard and where it is documented. If it isn't documented, try to figure out the basic standard from the code as you work through it. WHatever you do, do not use the standard from your previous jobs or univeristy experience if it conflicts with what most or all of your colleagues are doing. It really annoys people and makes the code harder to maintain. Yes some standard companies use are stupid and annoying, use them anyway.

Do some observing of the corporate culture in your first few days. Do people prefer to talk in person or through email or through IM? Do people all wear headphones and hate for someone to talk to them?

You may or may not be assigned a mentor. That is the person to go to with your questions. If they don;t assign one, you can ask the folks around you for help but if they clearly don't want to be disturbed, then ask you boss. It is his job to see that you have what you need to do your job.

Then dig into the codebase and whatever technical documentation you have. Take notes. If the documentation is lacking, try creating some for yourself and then pass it to someone else on the team and see if your understanding is correct.

Try to control your reaction to the software. Large complex problems tend to have lots of things in them that aren't the way you would have done them. Many people starting in a new job with a legacy project are appalled at the state of the code. Try to remember that some of that code was written ten years ago when certain techniques were not available and it has been working all that time. Yes you may see places to improve things, but keep your mouth shut on that until you have proven yourself as capable and competent. You have to have respect first before you have the credibilty to push through changes.

Even if they don't have a formal code review system in place, get your work code reviewed. Better to learn what not to do the first month than do it wronng for months or years before anyone notices.

Answer 3

This isn't as hard as it seems when you're about to begin. Getting familiar with the current code base might seem very hard, but you just need to take short steps. You don't get to know a whole system in a week, but it'll all eventually come into place.

Try getting assigned easy/short tasks, specially if they require you to learn how the whole system is built. They'll probably do this anyways but, if you feel overwhelmed, feel free to ask your manager about it.

If your team is as teamworking as mine, they won't mind you asking short questions like "where is the window controller located?". These kind of questions will get you up to speed in a hurry! Also, get your hands in as much documentation about the project as possible. You should spend some time as soon as you arrive getting familiar with your team's workflow too. Just watch, ask and learn. It won't harm if you get to know a colleague who can guide you through this.

One important thing is getting information organized. I use Ubuntu's notes. I set up a new note for each subject and add as many little snippets of information as I can to it. Even if you think you'll never forget it, you will! Once it's done (or, for some reason, it's no longer something you must remember) just erase it. As as I finish some piece of work (or if it stalls for some reason) I take a quick tour over my notes, clean them and decide what I'm going to work on or research about.

I've been involved in projects with short iterations and a lot of time pressure and it worked for me: nobody expects you to get up to speed as soon as you arrive. Just relax and learn.

I think that learning new technologies (languages, libraries, version control systems...) is part of your career. I've always devoted my own free time to learn those, but you'll learn in work too! It won't harm using your free time too: you'll learn faster and, after all, it's a skill set you'll carry out from job to job.

As you said, you were very up front about your skills, so I don't think their expectations are that high. You might want to take advantage there: go above their expectations and they'll have a nice surprise.