Ttdfjt

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!

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.

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.

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 - 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 myy 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.

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.

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.

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.