How should a junior dev handle critical decisions as a sole developer on a large project?

Question

I am a 2 year experienced web developer, I mainly worked on backend stuff (API,java logic , etc etc), and I work as a consultant.

Since 2 months I was sent to a company to work on their front-end using some framework that I'm not a complete newbie at, but basically not an expert.

Project is large, but I estimate my code is at 'junior' level.

Here comes the problem, as long as I am the only front-end dev in this group, all critical decision on this project are deferred to me (choosing a pattern of code, instantiate new libraries or importing some code from external resource or so on).

As I said before, code is not difficult, but I feel that these kind of decision are too important to be deferred to a junior of this framework, due to the software is very big and handle sensitive data of a big company.

Note that I already talked to my boss, and he basically told me "just work as you want and as you wish, but the project must be ready at date XXX"

My fear is that I can product code that works NOW, but TOMORROW will have bugs or so on due to my lack of experience, and as a consultant, I'll leave a bad reputation beside me.

How do I handle this situation? What should I do?

Answer 1

You're not a Junior any more - you're a Senior.

Congratulations on your promotion!

If it hasn't been already, chop the project tasks up into bite sized chunks of work. Analyse each one and assess whether you understand enough to completely it, how long it'll take you. Take those time estimates and add at least 50%.

If those estimates don't fit into the timescale requested, then you need to raise this as a risk - either you need help, or something needs to be dropped from the project.

You also need to raise a risk for every task that you're not sure about. You'll get more points for forward thinking and being honest than hiding everything and failing at the end.

If you need help, then build a sound business reason and ask for that help.

Use this as a great learning experience, not many juniors get this opportunity.

Answer 2

As the only front-end developer, you may be the closest thing to an expert. Expertise is relative, so even if you feel you don't know that much, you may need to own the solution. Consultants are expected to be able to solve problems and this may be your opportunity to shine.

Do your best with the skills and knowledge you have. Do some research about the framework and best practices for using it. If the framework is used much at all, there should be plenty of research you can do on the internet, either from the vendor, a working group or some site like StackOverflow.

Make sure you document your research and how you arrived at the decisions you needed to make. Share this documentation with your technical and/or administrative supervisor so that they know what you have done and can manage the risk.

If after the research, you believe there is a schedule risk, let them know now before the situation gets worse. Use the research you have done to provide a timeline you can make and leave it to them to then manage the project timelines at a higher level.

Answer 3

My fear is that I can [produce] code that works NOW, but TOMORROW will have bugs or so on due to my lack of experience[.]

Yes, you will write bugs. You will fix the bugs you find. I am sure you have experienced this already.

You can mitigate this risk by building an automated test suite. It does not need to be a sophisticated 100%-coverage test suite. It just needs to be able to catch the bugs you have already found, so that you know that you didn't slip up and make the same mistake again. If it covers the standard happy paths as well, it will save you some embarrassment.

If you are comfortable with a UI-level test harness like Selenium or Microsoft's Coded UI Tests, great. But you can get decent test coverage one layer down in your system, by testing that your model produces reasonable outputs given the sorts of inputs that you expect the UI to feed it.

Answer 4

You will have to go through bad designs to achieve good ones. This is a key point in this problem that you have to live with.

Now: Is "bad" code going to burn bridges? Unlikely. Never seen that happen ever. Worse case, you'll be asked for the reason of doing this, and you can justify.

In the programming business, we all understand constraints and motives for some bad code. One thing that you'll learn in the future is:

The perfect code doesn't exist.

Code loses quality over time, and history of programmers can be seen in the code, and keeps getting worse until the cost of maintaining a program becomes higher than writing a new one, which is when people do that.

How can you help make best decisions? If you're really concerned to make your code the best (assuming that won't affect the time limits, which it will, but anyway). The answer is simple. Look at examples online and discussions about the issue... LOTS of them! Try to follow the consensus on many forums.