62

I learnt programming at home and was a brilliant bootcamp graduate (that is, by the standards of that bootcamp, which is certainly not as good as top US bootcamps*), I found a job fairly easily considering how hard I think it should have been. The interview went really well.

Now I work for a tech company that basically has one main software it writes for other very large companies, and it poses a few challenges: 1) it's tough for me to grasp what everything is doing (they have been writing/updating this software for years now), 2) I'm seeing code written in ways I'm not use to, and finally 3) I don't understand all the code at first glance, sometimes not at all. My main task for the next 6 months will be to write unit tests then integration tests because "you need to get used to our software", which I think makes perfect sense, although my interview had nothing to do with that. Most people are really nice and friendly, and there is a good atmosphere in this company.

My problem is that I have to write tests for methods that I don't understand most of the time, I don't always understand which parameters they have to take, what it returns, I don't know what I have to mock in order to make my method unit-testable, and I don't always understand the instructions I'm given. After two weeks, I can say with confidence that I clearly didn't create value for this company and the other developers that helped me could have done my job instead of spending time with me.

I am quite frustrated because I am quite hungry to learn, however, it's not by watching videos on Pluralsight/read articles that I will get better at what challenges me (or am I wrong?), so I can't even practice at home. I think that I embarrass myself whenever I ask a question so I tend to be stuck a lot, staring at the screen and trying to make sense of what I'm reading. I feel like an impostor surrounded by people that 'get it', and to be honest my confidence has taken quite a big hit (I went from being arguably the best in class to definitely the worst in a company). During bad moments I sometimes catch myself wondering if going into software development was a good idea, and if I'm not a victim of a sunk-cost fallacy (as in, "I spent too much time learning this to quit now").

My questions:

  1. Is it normal?

  2. What can I do better?

  3. How could I express this (or part of it) to the management and colleagues without coming across as a fraud?

Edit:

I have worked there only 2 weeks, it's my 3rd job. Previous jobs lasted 7 months & 1.5 years.

*I wasn't clear and didn't want to come across as arrogant; I don't think this bootcamp is exceptional, so being brilliant at it probably doesn't mean much on the job market, unlike the top of the US bootcamp. This bootcamp is Europe based, and I'd say it's average. Moreover, I believe a huge reason I was successful was that I was learning programming for 1 year and people next to me had no idea what a 'variable' was, so I had a huge head-start and it was overall much less overwhelming than for my fellow students.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Mister Positive Apr 30 at 15:25
  • To clarify, your prior jobs were not tech/programming related? – GalacticCowboy Apr 30 at 16:45
  • Hi @Michel12 Writing tests is a great way to understand code and add value to a code base you are unfamiliar with. This will also expose you to the different ways people in your company write code. You're doing and thinking the same things all of us have done. :) – MarkJL Apr 30 at 22:06
  • 4
    I just want to chime in and say yours are the struggles that every junior dev faces in any large organization ever. It's so, so common. Just keep chugging away and stay positive and intellectually honest, and you'll be fine. – Slothario May 1 at 15:34
  • 2
    I know how you feel. I've been a developer for just under 2 years, in a large team on an old product, and there are 2 things people of the team have said to me. First, if you feel like you aren't contributing enough: "In a big team, on an old product, we expect you to be wasting our time asking questions and we don't expect you to be a net contributor to the team until you've been here about 3 years" And if you're ever worried about embarrassing yourself by asking questions: "If you aren't asking questions, we assume you aren't working." You embarrass yourself if you don't, so ask :) – Azrantha May 2 at 12:44
106

After two weeks, I can say with confidence that I clearly didn't create value for this company and the other developers that helped me could have done my job instead of spending time with me.

You will not create "net positive" value for the company for much longer than that (even when I hire senior developers I assume they aren't net positive for 6 months).

Everything you mentioned in your question are actually good signs - it sounds like they are making interesting and non-trivial software, meaning there are many opportunities for you to learn, and it means that they are invested in you - by giving you the time and space to get up to speed.

Writing unit and integration tests are a fairly common way to onboard new junior employees. You will learn the IDE, source control system, build process, and all the various formal and informal workflows of how they develop software, while focusing on relatively bite-size chunks of work. You also get to learn a lot about the business functionality their software provides.

1 - Is it normal?

Yes. You are not an impostor, and there is no reason to think going into this field was a bad idea. In fact, from the fact that they hired you, and want to invest in you, it seems like it was a good idea. The most important thing is to get over the naive belief that just because you were "arguably the best" in your boot camp, that meant you were prepared to walk into a development shop day one and start producing value. The boot camp provided you with the basic foundation of programming - there is a lot, lot, lot more to being a professional developer, which you can only learn on the job.

2 - What can I do better?

I think there are two "scopes" to this. The first is stuff you can do on your own. Invest your own time in learning the language you are programming in - the fine points, the advanced features, etc. Even if your boot camp was in the same language you are now working on, there is a lot to learn (I've been programming in the same primary language for >10 years and am still learning new things every day). If any of the other tools they use are publically/freely available (the IDE, the source control tool) practice with those too. Also, send time learning about the basics of computer science (algorithms, data structures). Even if you aren't using that knowledge right away, it will always come in helpful.

The second, while not specifically related to the testing you are doing, can be done as part of that work. That is to develop the ability to "analyze" a piece of code. Take the simplest test you can find, testing the simplest piece of code, and try to work out the control flow of that piece of code. Run it through a debugger, stopping on every line, and see what it is actually doing. Modify the test slightly and see how it behaves differently. Try and come up with a test that will test a different if-branch (etc.). Use your IDE source control tool and look at the most recent commit which changed that code. See if you can understand what that change did (especially useful if you can link back to the ticket which documented that change). Move to a slightly more complex test and repeat. Now, take the piece of code they want you to test, and conduct that analysis beforehand. Use that to write your first test.

If you need help, ask the author of the test or code you are looking to provide you an overview.

3 - How could I express this (or part of it) to the management and colleagues without coming across as a fraud?

No one is born knowing how to code. Therefore your colleagues and managers all started at a similar place as you did. As long as they aren't jerks (and you already said they aren't), they know and expect you to ask them for help.

Of course, you'll need to find the right balance between asking too many questions, and not asking for help early enough. I've often told my juniors "don't waste 3 hours trying to figure out something I can help you with in 5 minutes". Conversely, don't waste my 5 minutes if you haven't spent some time trying to figure it out on your own.

If you don't already have one scheduled, ask your manager for a weekly 30 minute meeting. To quote another answer I've written here:

your manager's job [is] to do his/her best to give you the opportunities to succeed - this can only happen if you two have regular and frequent conversations, and if during those conversations you are open and honest about where you are having difficulties, where you need support, where you are getting stuck, and where you learn what he/she is expecting from you.

One of the most important things to ask is "where should I start" and "who should I bother for help"

Good luck!

  • 7
    FWIW, one of the best suggestions in this great reply is to use the debugger. There is no other way to really get a feeling for a piece of code than to run it, set some breakpoints and step through the code, down into the guts, looking at the variables, seeing how the change. It will be overwhelming at first, but if you stick with it you will get to understand the code much more deeply than even the original authors did. Remember, this code took YEARS to write, and you are concerned you don't get it after two weeks? Give yourself a break. – Fraser Orr Apr 30 at 21:38
  • 3
    +1. I would also suggest that if you haven't already, spend some time getting really familiar with whatever source control system is in use at the company. You could even set up your own repo and struggle through getting it to work. I know when I first started at my company I had zero experience with or understanding of source control, and it took me a looong time to become confident. That confidence only came because I learned (through trial and error and a lot of googling) what I can and can't do with our source control system, and what breaks things. – Clonkex May 1 at 3:45
  • The most important part of this answer: One of the most important things to ask is "where should I start" and "who should I bother for help". – FreeMan May 1 at 12:35
44

I worked there only 2 weeks

You need to give it a lot more than just 2 weeks.

  • Everyone feels a bit overwhelmed when they initially start a programming job.
  • Your first few weeks/months will involve unlearning lots of things you were taught in school/bootcamp and learning how real software work is done.
  • Nobody understands all the code at first glance. Sometimes existing code is poorly commented and indecipherable to everyone except the original author.

Take things gradually. You'll almost certainly find that each week is a bit more comfortable than the last.

Take advantage of the nice and friendly culture. Ask for help when you need it.

And don't be so hard on yourself. If you learned programming on your own, then went on to be brilliant at bootcamp, you'll most likely be fine with a bit more patience and hard work.

  • 1
    At my absolute best (years and years into my career) it's taken at least a month to start actually producing tangible material that benefited the project. Two weeks is nothing to worry about. The only time I've done better was when I'd just come from a project that was materially identical (same tools and similar tasks) to the one I was entering into with the new company. In that case, I didn't know much of the code-base, but I knew the best-practices better than the existing team and was able to contribute at that level. – Ruadhan2300 Apr 30 at 11:08
  • 3
    This answer was my gut reaction, too. And, it's not just programming. Any job in any field, above maybe unskilled labor, is going to require some degree of onboarding. The employer doesn't expect you to walk in the door and add value minutes later, they know it will take weeks/months for you to get up to speed - at a cost to them. And, importantly, (for your self esteem at least) the fact that they've hired you means they're willing to make this investment. – dwizum Apr 30 at 14:42
  • 3
    "Nobody understands all the code at first glance. Sometimes existing code is poorly commented and indecipherable to everyone except the original author." if you are lucky, if no one can understand it, chances are the author can't either after some times has passed – Rémi Apr 30 at 15:45
  • 1
    Sometimes code is so horrific nobody understands it. (Looks at own code from the past, shudders.) If you get in there and decipher it, you're adding significant value to the company! – FreeMan May 1 at 12:38
18

Welcome to the Jungle. :)

Yes. It's normal. You're a junior. It's expected that you will not have a clue, and that's why they're having you do what you're doing.

Ask questions. Get the understanding. Ask what you can read on your own time to help you develop an understanding. Be willing to work hard even by spending a few hours outside of work. I'd be concerned about a junior developer that DID NOT ask questions. I'd be willing to bet that any of your coworkers who are seniors started just as you have.

Ask questions, and learn. In time you won't have to ask questions. It will just click and you'll get it.

  • 7
    Also take notes when you get an answer. – Jay Apr 30 at 10:44
  • 1
    @Jay Thats the most important advice. I am always happy to help on any problem once. Ask me the same question a second time and you get (mental) minus points. Follow up questions are actually appreciated. – lalala Apr 30 at 20:48
9

Like everybody is saying, two weeks is nothing. You will take far longer than that to get up to speed. And your manager and colleagues expect this.

I would like to grab one sentence to comment on:

My problem is that I have to write tests for methods that I don't understand most of the time, I don't always understand which parameters they have to take, what it returns, ...

As I see it, this is a failure of documentation. Which is also dreadfully common. In an ideal world, there should be a description of all that available, but very often there isn't.

So, your first question should be if you have missed some documentation. The most likely answer is "no", but it is worth asking.

I would suggest writing that documentation before making unit tests. This makes it possible to ask "did I understand the purpose of this function correctly?" The documentation itself will be valuable to the company, and the unit tests are more likely to test what they should be testing.

It can be hard to work up the courage to interrupt a busy colleague with a question that is probably trivial. As it should be, interruptions suck.

Instead you should schedule a meeting. That way it is only one interruptions instead of many. If you have a question that blocks your work, put that aside and find another task.

Go prepared for the meeting. Have a list of questions, exact references to any relevant sources or documents involved and so on.

In the beginning you will need many such meetings, but things will get better as you grow more familiar with everything.

  • 1
    Also, talk through the code line-by-line. (Look up "rubber duck debugging".) Within each line, talk through expression by expression or operation by operation. Once you have reasoned out how that line works, advance to the next. Don't just sit there reading without comprehension and staring at the screen through glazed eyes. – GalacticCowboy Apr 30 at 16:51
  • 2
    It's more than a failure of documentation. Code being testable is a function of thinking about how to make it testable as it's being written. Even if you're not strictly practicing TDD, the developer who originally wrote the code should have written the unit tests before it was merged. Writing unit tests long after the fact is crazy. Assigning the task to a junior developer new to the project is triple crazy. – TKK Apr 30 at 23:16
6

1 - Is it normal?

Yes. Sitting there, staring confused at alien code and asking yourself what you are doing is normal at all levels, even after decades of experience. What changes is how you handle it.

2 - What can I do better?

Keep at it. Two weeks is really nothing to worry about. I was once the teamlead / lead dev for an application like yours, and new people would take upwards of two months to get somewhat productive, sometimes it took years. People may take a week or more to only initialize their development environment, becoming able to compile the source, on legacy applications, and further weeks to get them to run on their Laptop. And so on.

3 - How could I express this (or part of it) to the management and colleagues without coming across as a fraud?

You don't talk about how you are feeling a fraud; you talk objectively about the task at hand. Try to work out possible solutions, and if you cannot decide yourself, then ask your boss or lead dev. If that means that you have to ask your colleague all day, every day, then so be it. If and when your colleague gives you the feeling that it is too much, then ask your boss who else to ask, or if they have other sources for information, or if he is fine with you taking a lot of time to stumble around in the dark.

Be transparent; make sure your "stakeholders" know what you are doing. (It is an art to do this in a way to not get on everybodies nerves - maybe a topic for another question; one way would be to keep a one-pager that you keep current, and just send around once a week or every other week, or something like that. Also really depends on your company culture.)

This is a two-way street. Throwing the new guy at undocumented source code is a nice exercise to get the "juices flowing", but at the end of the day nobody would expect magic to happen here.

If you have concrete technical questions, better ask in one of the more technical stack exchanges.

  • talk objectively about the task at hand this is the best advice, repeating to yourself that you don't understand is unproductive in the worst way. The only way to understand alien code (love that phrase) is to talk it through, and once you think you understand it, go to the author, explain what you think it does or how it works and listen to their feedback. Don't be afraid to use paper to draw diagrams only you understand while trying to work things out either. – MarkJL Apr 30 at 22:03
3

I've worked on some massive and ancient codebases (3D CAD in C++ some of which was auto-generated from FORTRAN) and I've been mostly a dev for over 35 years. Anything negative I say below comes from feelings and situations I have been in!

As others have said, you're not alone. I have similar advice to Stig but with some important nuances.

First, it's important for your self-esteem and possibly for your job to show you're not just sitting there staring at code, feeling lost.

There are three things you can write to show what you're doing:

  1. Write a diary, even if never shown to anyone else. If you think you will be showing your diary to people, keep a private one where you describe to your future self how you are lost or if you understood something that day.
  2. Write actual tests, even if they are stupid trivial ones, that exercise a bit of code. Where you don't understand the restrictions on parameters, mock something up to get the test to run and document those restrictions. Ensure the tests include a readme or central document so it's easy for someone else to get started to run them.
  3. As others suggested, write documentation. Depending on the language, you should be able to get some kind of automatic documentation tool such as Doxygen which will generate overall callgraphs. If you can't then start with a piece of code and trace back where it is used. If you can run the code and invoke a debugger, use breakpoints to see a call stack down to that point. If you have to search manually, pick something with unique names so you can search the entire codebase.

Things to avoid

Don't criticise their existing documentation practices. This is an area which is often very controversial. People may have their own strong opinions and have had them rejected. You would be amazed how deep the feelings can be around documentation practices (and how to write tests).

Don't ask someone for advice and seem to ignore it. If someone gives you advice and you don't understand how to apply it, think about it and at the very least write some notes on how you tried to apply it.

Don't try to understand everything. Just don't. This is probably the biggest weakness of the limited code people are exposed to in education (not just bootcamps). Very few places teach you how to program without expecting you to understand everything. That's just not possible in big programs. Let that need to understand go.

  • 5
    Your last paragraph is great advice that every developer needs to learn. – Player One Apr 30 at 23:14
  • 2
    I remember a very experienced developer who was part of a team I was teaching C++ and OO GUI in 1996. I walked into his office to find him almost in tears with the ENTIRE MFC and PowerPlant OO framework class diagrams literally papering his walls. The advice is not just for beginners, but by now most experienced people have learned the lesson. – Andy Dent Apr 30 at 23:39
2

I think that I embarrass myself whenever I ask a question so I tend to be stuck a lot, staring at the screen and trying to make sense of what I'm reading.

I think this is the only place you're going wrong. New people need to ask lots of questions, it's the easy way for the experienced guys to judge what you need to know next.

When you find your self staring at the screen - write an email (or slack message, or whatever). Treat it like a Stack Overflow question; describe the problem and what you've done, and show that you've put some effort into it. Half the time this may suggest something you've not tried, or a topic you can research, and you won't have to send the email. If not, send it, and move on to another problem while you wait for a reply.

Email allows other people to answer when it's convenient to them - but ask them to call you when it's convenient for you to go to their desk, then go and talk to them. You'll get more information this way, and build important relationships.

Spread your questions around rather than using up one person's time, and ask people to show you how they'd go about solving the problem, rather than just for 'the answer'. You should also ask people how long they took to learn the system, and how much of it they know. That should convince you that you're doing OK.

Also, when you find a poorly documented function and spend a while learning about it, you should write down what you learn. This could be comments in the code, official documentation, a team wiki or an unofficial note (in that order of preference). Then you're adding value and helping the next guy. You can also keep notes on areas that are overdue for refactoring, and any bugs you find.

0

2 - What can I do better?

I totally agree with the other answers, 2 weeks is basically nothing, so stop worrying about that. But there's one thing you can and should do better at:

I think that I embarrass myself whenever I ask a question so I tend to be stuck a lot, staring at the screen and trying to make sense of what I'm reading.

THIS is what you need to work on. There are some things that you can figure out on your own, and it's generally better for you to do that if possible, of course. But there are other things, like historical reasons for some twists of the code, that you cannot possibly figure out. You have to ask about those things without spending days stuck looking at them.

Now I'm not saying you flit about the office like a mosquito buzzing everyone in your path. When you come across some such problem, make a note of it. Get someone (your manager usually) to tell you who is the expert on this or that. Then try to find a time when you're not interrupting them (like make an actual appointment?) and go through your list of relevant questions with them. They won't be annoyed as by a constant stream of questions, but you'll still have a chance to get up to speed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.