29

I joined a new job two weeks ago where I was hired after an interview based on generic JavaScript programming knowledge with my past work experience close to two years. For the initial 12 days, I was asked to go through some generic training videos about their system which I completed. Though I started doing hands-on practice just a day ago as I was provided access to that system only yesterday.

Now suddenly my manager says they have some clients who require lot of work to be done. So I can have only have 1-2 days to do as much hands-on practice I can before he will start giving me real work. He expects me to take a significant workload as we are trailing behind schedule for those particular clients.

The problem is that since their in-house system, on which I have to work, is completely new to me and is very vast with a lot of functionalities. I feel 1-2 days hand-on is not enough time to dive into real work. I am not given any specific set of things to focus on and I feel lost.

Since everything is new, I am having small-small doubts related to each and every thing. The other employees are either busy in their own work or not too helpful to ask each and every thing. The manager also feels slightly passive-aggressive from his tone. I feel very overwhelmed and have started to feel I made the wrong choice to join this company. How should I navigate this situation?

Some technical details regarding my work:

  • I was hired on basis of generic JavaScript knowledge with prior experience close to two years.
  • They have their own in-house software / system over which I have to write JavaScript scripts.
  • Using these scripts, things can be controlled / changed in their system.
  • They have their own internal libraries (nothing open source) from which I have to call classes, functions, etc. and use them in my scripts. The documentation of those libraries is not very thorough.
  • They expect me to figure out lot of things just by tinkering, viewing old scripts made by others, copying code from old scripts, etc.
Improve this question
8
  • 47
    Generally: They knew what they hired. They know you're still learning. Just do the best work you can, ask for guidance when you need it, and ask your manager whether you're falling behind where s/he expects you to be. EVERY new hire goes through this learning curve.
    – keshlam
    Aug 14 at 19:21
  • 24
    I suspect the only expectations you've failing are your own, and those were set unreasonably high. No matter how much experience you have, a new project is a new project and bootstrapping takes time.
    – keshlam
    Aug 14 at 21:35
  • 11
    @keshlam, you'd be surprised how often managers have completely unreasonable expectations. From what I gather, he's had 12 days of worthless corporate videos, and 2 days of real access to systems. That's not remotely reasonable to induct a developer to work independently - and he's clear he is struggling to get access to existing staff and their understanding. He's also quite clear that the management are following the classic folly of adding fresh labour when already behind.
    – Steve
    Aug 15 at 6:44
  • 4
    No, I wouldn't be surprised. But until there is evidence of that, worrying about it is a waste of energy. If you are concerned, ASK if they're satisfied with your progress and what they think you should focus on doing better if so. The answer may surprise you.
    – keshlam
    Aug 15 at 7:13
  • 9
    Does your team have a code review process? We are currently on-boarding people onto a very complex code base (couple million lines of code for something very technical) and we’ve found the best way is to start with a small task and get it in to code review where the more experienced people can help. It’s hard sometimes to get people to put up something less than perfect, but when there isn’t time to pair program with a new hire, it’s easier to teach the system by looking at something that’s already been started.
    – ColleenV
    Aug 15 at 11:31

6 Answers 6

Reset to default
98

Reading documentation and staring at thousands of lines of code is unlikely to lead to enlightenment however long you do it.

Often the best way to learn how something works is to have a specific task to perform, and then to fathom out what you need to change to make it happen. That way you're a lot more focused on a specific goal.

The first few tasks will probably take a lot longer than they should. Nothing can be done about that.

Also, when you do need to ask others about something you don't understand, at least you will have a specific question about a specific problem.

Improve this answer
4
  • 5
    100% agree, and they already said they are behind schedule, no need to rush things and try to catch up, it won't be possible anyways.
    – encryptoferia
    Aug 15 at 9:01
  • 41
    To give a number: I personally consider that it takes 3 to 6 months for a software developer to reach cruise speed when starting on a new project. It's completely normal to start slow. It's also completely normal, even after 6 months, to have entire parts of the systems largely unknown: if you've never had to delve in them, "here be dragons".
    – Matthieu M.
    Aug 15 at 9:29
  • 2
    @MatthieuM. I think it depends a bit on what one defines as "real world" work. I have some generic UI applications that are mostly maintained by offshore external workers. They are expected to be productive with real world tasks after at most 1 week of onboarding. Does this mean talking to business to refine requirements and implementing complex tasks? No. It means an internal employee with experience can analyze a bug and give it to them as "it does X, it should do Y"and they can implement it in the UI according to our standards.
    – Yanick Salzmann
    Aug 15 at 18:37
  • 1
    ... that being said, I completely agree with you otherwise, for the typical more senior developer I see the same numbers, 6 months is the usual.
    – Yanick Salzmann
    Aug 15 at 18:47
19

I am writing this answer on top of Simon B's answer.

This is a very common situation. It takes many years of experience with programming to get the feel of a work environment quickly, even then it requires the environment to be following their own rules to the letter, which is a rarity. It seems you are hired to speed the project up, which generally doesn't work. If it does, you might be hailed as a hero. In any case, it will be a great work experience.

There are few things you could do to survive without creating mayhem.

  1. Whatever you do, commit very often for every little task. This will help to isolate any problematic part easily. Work in a separate branch and merge your tasks once you are more confident. Do not forget to update your branch with the recent changes by other members. Do not make final merge a chore.

  2. Try to ask them more isolated tasks, this way, if you are going slower than they expect, you will not be slowing down anyone else.

  3. Read code of others along with the commit messages. Try to get the feel of the project. If you do not understand a section, ask the owner of the code. Try to have a non-confrontational approach, tell them you are trying to learn first. They may think you are nitpicking or policing their code.

  4. Find the testing people, bring them a coffee and tell them to skip no details when it comes to your parts.

  5. If you still cannot keep up, do a bit of overtime (no more than an hour a day) until you get more confident. Use extra time to read code, going over what and how the others are doing their tasks. Ask questions if a particular section doesn't make sense to you.

Improve this answer
5
  • 3
    See also: en.wikipedia.org/wiki/Brooks%27s_law
    – SirHawrk
    Aug 15 at 11:39
  • 1
    @cem, why do you suggest not more than 1 hour? I think it is reasonable to avoid burnout but I am curious
    – heretoinfinity
    Aug 15 at 15:24
  • 3
    @heretoinfinity not Cem, but it's important to set expectations early on. If at the start of your career you immediately start doing 3-4 hours per day of extra overtime, then you'll be expected to sustain that pace for as long as you can, and if you don't you're going to get comments on that. Also, in just about every working environment, overtime needs to be compensated, either by additional paid vacation days or by additional payment at the end of the month or year, and I think for a company like this that flies by the seat of their pants they're probably going to be hesitant to do this.
    – Nzall
    Aug 15 at 21:42
  • @Nzall compensation for overtime varies. In the US, "exempt" employees are exempt from overtime pay requirements. Some companies have an official compensation policy (money or time off), some managers have an unofficial policy, others just expect you to be on basically 24/7. I had a manager who, after she had a long week, would walk out the door at noon on Friday and tell us all that it was a bad week and we all needed to leave now even if the rest of us had a very light week. I do agree with you on setting expectations early, though.
    – FreeMan
    Aug 16 at 13:51
  • 1
    Even 8 hours of work as a software engineer is too much. Obviously not all work cut equal. Stretching it too much will just tire you out and you will not benefit from extra time. You need to have enough time to rest after the work. But an extra hour a day will be quite beneficial as your manager cannot ask you to do anything in that extra hour tahat you are not getting paid, and you will have a peaceful time that you can use to learn.
    – Cem Kalyoncu
    Aug 17 at 9:26
5

These are not at all unreasonable expectations.

No in house software project has good documentation, no in house software project only uses open source libraries, and no programmer is able to grok a pile of mud just by reading it.

I have a good deal of professional experience in the field, and I pride myself on being able to generate value for a new company after only two weeks. As a new developer, it's expected that you will take a long time to generate more than you cost.

In my opinion, that you were given two weeks to watch youtube instead of being given bugfixing tickets or documentation writing tasks is incredibly soft. I would advise you to not expect that in future, and to take a more proactive approach to learning your codebase.

Improve this answer
2

You should ask yourself: If I worked here for twelve months and these conditions stayed exactly the same, how would I feel?

Unfortunately, how things begin is often how they will continue. It is very, very unlikely the situation will improve, at least not from a top-down level. It's been two weeks, and you are getting stuff dumped on you due to the team being behind schedule? Expect that kind of behaviour to happen roughly... every two weeks.

Your colleagues are busy or unhelpful now? They will be busy and unhelpful always. It is rarely possible for any new starter to get anywhere without significant, early, and ongoing support. It's rarely possible for anyone to make progress without the support of their team.

If the answer is "get me the hell out of here" (and it sure sounds like it) then you should be preparing an exit strategy.

I'm sure this place started waving some red flags at you, try and figure out what those are, and use them to your advantage. A question I have on my list when interviewing is "can I see what you are working on today?" it should give you a sneak-peak at how things actually are on the front-lines, not just the sanitised slop that ends up in the training videos.

Good luck.

Improve this answer
2
  • 5
    The good news is that after a year in a position, things are rarely ever "exactly the same" as when you started. First and foremost, you, the new hire, aren't the same person you were a year ago - you've learned a great deal about your new environment, the code, the people, the expectations, etc. In my many years of experience, I have found that how things begin is often how they will continue to be a false premise upon which to make an employment decision, especially after only 2 weeks.
    – FreeMan
    Aug 15 at 16:42
  • 1
    I think this answer does point to an important fact that while everyone has an ability to change we cannot expect 180, especially from a group of people. I would only add that the steps I would take is to wait a little bit longer (2 weeks is a short period), but start looking for other job offers right away. No one says you have to take them if you get them, but if things don't change, you have a way out sorted.
    – vspmis
    Aug 21 at 7:07
2

Ideally, I expect my new hires to have made a commit that has reached production within their first week. Ideally, their first couple of days. If that's not the case then our onboarding process is either inneffective or too long. (To be clear, I don't expect it to be a big commit).

You're never going to learn by staring at docs and code, the only way you can learn a codebase is by writing code in it.

You'll be slow at first and make mistakes, but nobody expects otherwise. Ask for help when you need it, and don't worry that you're "bothering people", you'll be up to speed in no time.

The general ramp-up speed for an engineer on a complex code-base is 6-12 months, nobody is under any illusions on this.

Improve this answer
0

My solution to this problem is to perform an audit of the entire codebase in the first couple of days before I start coding in a new project.

I tell the manager what I'm going to do, perform the audit, and then summarize my findings in a powerpoint and present them to the manager.

This has several benefits:

  • You learn key pain points of the current codebase quickly
  • You figure out what you don't know, and get those questions answered
  • You take some control over your work schedule, and avoid getting pushed around like a code monkey
  • You find out if your manager is someone you can work with. If the manager is offended by your findings, you know you are not a good match.

I pay close attention to things like code complexity. For example, I count the number of if-tests I find in the code. I count the number of globals. I locate areas of obviously unnecessary duplication. I note the particularly difficult to understand code blocks.

What I've found is that most of the time the rest of the development staff agree with my findings are are anxious to get on with a technical debt reduction.

What I've also found is that if my key findings aren't addressed, they will still be major issues: ignoring them is a mistake.

These days I am biased toward "coming in hot" like this. Everyone benefits.

Improve this answer
2
  • What if that is impossible? Our codebase has over 1.5 million lines of highly complex, technical code. Our customer dgaf what the source code looks like... they have work they need to get done that depends on us delivering. Addressing technical debt is important, but the new dev trying to point it all out to us like we don't know it's there instead of actually getting the task done that we hand-picked for them according to their experience and knowledge is not constructive. Do you feel like all the teams you join are full of incompetent people you need to save?
    – ColleenV
    Aug 23 at 20:11
  • @ColleenV Maybe they saw this stuff but needed an extra person to say this to sway management to make a change. Sometimes people with a bad manager leave things to rot until someone else complains so that it doesn't make the previous employees look like complainers.
    – heretoinfinity
    Aug 30 at 12:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .