12

I am a software engineer for 4 years, and I just changed my company for the first time.

Company works with pair programming, and it's been 3 days, I couldn't even write a single line of code. It's so frustrating for me because I was very productive at my previous company.

The codebase is large, they are using 5-6 languages/tools that I am not familiar with, like rspec, haml, jasmine and others. But still, I feel awful.

This weekend I created UML to get better understanding of the application, but still I am guessing I'll not be able to write decent amount of code this week.

Is this normal?

What is your experience when you change your job, and dive into a large codebase written with languages/libraries you are not familiar with.

Of course I am not asking for exact time required, but past experiences or things to make the process would be great.

Btw, I've already read below questions&answers, How do you dive into large code bases?

https://stackoverflow.com/questions/215076/whats-the-best-way-to-become-familiar-with-a-large-codebase

https://stackoverflow.com/questions/214605/the-best-way-to-familiarize-yourself-with-an-inherited-codebase

UPDATE

All great suggestions! I just came from work, I've worked a lot!

About pair programming:

Generally they write code, and I am trying to not miss even a second! If I try to write the code, I know it's gonna take forever, because I don't even know which files should I edit, but beside that, as I said, they are using 6-7 languages/frameworks that I'm not familiar with, and learning all these syntaxes at one is not easy.

How well the company prepared for engineers:

I can't say they are well organized, they kind of expecting me to start writing code immediately.

Taking notes, being proactive:

I'm always taking notes when they write a new command/or anything about data models. My peers are very smart and kind people, and I'm trying to ask lots of questions, even lots of stupid questions sometimes.

Is this common?:

@Telastyn, thanks for your answers, it made me feel a little better. It seems like my problem is not that uncommon, but I was really productive before this job, and now I really feel useless and not smart.

I hope I can start solving bugs/implementing issues very soon.

About frameworks/languages they use:

I was really honest about that, I didn't say I know something that I don't know actually. But I wasn't expecting that much different things, and since I started working at the day I accepted the offer, I didn't have time to prepare myself.

@Southpaw Hare, thanks alot for sharing your experience. You are absolutely right. There is no guarantee that I'm going to learn all of these stuff, but I'm trying. At the end, it's is hard to learn all of the syntax at once, and I think that is the main problem too. Because I can navigate in ruby code well since I know that language, and I navigate in js codes thanks to browser inspectors, but the problem is writing the actual codes with the frameworks/languages I don't know.

Community
  • 1
Robert Johnson
  • 155
  • 6
  • Since you mention [How do you dive into large code bases?](http://programmers.stackexchange.com/questions/6395/how-do-you-dive-into-large-code-bases), what is in the answers there that does not cover your case? – gnat Apr 01 '13 at 15:33
  • 3
    Since you are pair programming, you don't have to write code to be productive. You can be quite useful just observing someone else write code. Soon enough you will know enough to start writing code yourself. – kevin cline Apr 01 '13 at 15:41
  • @kevincline if he's pairing as the new developer, he should darn sure be the one at the keyboard otherwise that would be a pretty bad pair setup... – Jimmy Hoffa Apr 01 '13 at 16:12
  • If this is how the company does things, you really have no choice. Make sure you know what they expect you to know when the time comes. Ask questions. Get feedback. You can waste a lot of time if you're not careful. – JeffO Apr 01 '13 at 21:22
  • @JimmyHoffa, I know that'd be better for me, but in that case, I'd slow my peer down a lot. Since I'll have to ask every syntax, actual file that I need to edit, data model or something else, it will slow down my peer. – Robert Johnson Apr 02 '13 at 05:58

5 Answers5

10

This depends on things like the complexity of the system and how well the organization is prepared to onboard new programmers. It can take anywhere from 30 minutes to multiple weeks. It's not necessarily anything you're doing wrong and you shouldn't feel bad about it.

What you should do, however, is be proactive about fixing it for yourself and others. Tell your manager about your frustrations and work together to overcome them and to improve the process for other new hires.

Write notes about the things that you are struggling with, brainstorm ways to fix them or get around them, and document your process. Keep other people who can help you up-to-date with your progress and reach out for help. There's nothing shameful in asking for help.

Rein Henrichs
  • 13,112
  • 42
  • 66
  • 1
    Multiple months is not uncommon for complex, large (1 million+ SLOC), especially is the domain is also niche and/or complex. – mattnz Apr 01 '13 at 20:45
  • 1
    +1: Some companies have mentors assigned to new hires no matter how much experience they have for specifically these reasons. I always sucker in the person sitting closest to me that is willing to help and ask them TONNES of questions - and then I openly pimp them to my/their manager when they help. – Steven Evers Apr 01 '13 at 20:48
  • @mattnz Yep. Multiple months are just lots of multiple weeks though. ;) – Rein Henrichs Apr 01 '13 at 20:49
5

Is this normal?

For most codebases it is. Hell, at my company you are meeting with HR for 2 days before you're allowed to touch a computer. That's an outlier, but consider how long it takes to get the development environment setup, get vaguely familiar with the domain, code structure, team norms...

As a team lead, I expect you to do effectively nothing for 1 (two week) sprint, and work at ~50% for the next 1-2 sprints.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
2

swing to the other extreme.. I worked at a company that had only 2-3 languages but it took the better part of a year before programmers were let loose on the code base, probably 1 or 2 months before they committed their first line of code.

Don't beat yourself up over it, if you were honest in the interview about your lack of knowledge on these platforms they knew what they were getting themselves into. It takes time and time cannot be expanded, cut short or compressed, just make sure you make the most of it.

gnat
  • 21,442
  • 29
  • 112
  • 288
Newtopian
  • 7,201
  • 3
  • 35
  • 52
1

It really depends on the job you are doing and the role that you're in.

If you're doing contract-based work, you're expected to literally hit the ground running, using all the skills at your disposal to get the work done. Contract work is generally well defined and you're (usually) able to do this, at least in my experience.

On the other hand, I've started at one place that had an enormous legacy code base with a huge learning curve. We weren't expected to be writing production code for the first six months we were there.

Be patient, absorb as much as you can and put it to good practical use when you do get to start coding. If you're inpatient or rush there is a good chance in such a large system you might end up breaking something, particularly if their test coverage isn't brilliant.

Sam
  • 6,152
  • 2
  • 20
  • 34
0

Some amount of time is absolutely normal in order to get used to something so completely unfamiliar - I would not blame yourself or feel bad. However, it's important to be willing to accept the possibility that this job may not be within your skillset. This isn't necessarily the case, it's just worth leaving the possibility open in your mind.

The problem may not be in the codebase size, but in the fact that you do not know the languages involved. In my own personal experience, I had a job at one company where I didn't know any of the languages being used in a rather extensive codebase. Unfortunately, I wasn't ever able to learn this sufficiently after 5 months or so, and went to another company instead. There, I was proficient at the primary language, and despite the codebase size being comparable, I've done quite well.

When it comes to learning new languages, people usually think it's easier than it actually is, and hold themselves to high standards of learning them quickly. It's likely that it will take you longer than you think it will, so just keep that in mind regardless of what you decide.

Southpaw Hare
  • 1,106
  • 2
  • 10
  • 23