If he liked the product you built, but is stuck up on your use of Backbone, you both need to have a conversation about the desired tech stack.

As developers, we ought to use tools that are readily available, and consequently, smoothly move our flow of work. If he expected you to build the front-end from scratch, he should have been explicit and had good reason.

The fact that he initially enjoyed the product is proof enough that you did well and are “smart” enough.

tl;dr You did well. Talk to your senior and see what he expects from you.

He doesn’t seem very “senior” to me to make a snap judgement call like that. I always tend to use a proper framework instead of the “Reinvent the square wheel” anti-pattern. If he was truly senior he would understand and know the value of a good framework. At best I would expect him to question Backbone.js choice over another MVC JavaScript framework and much earlier in the process. He failed in properly mentoring and checking up on you as a junior and help you along the proper development path (in his mind.)

It sounds like you made the right choice in developing the project given the lack of direction on his part (assumption) and are working towards being a more competent developer. I would think there might be value in explaining to him your choice of framework, why you felt a framework was appropriate, and point out that the project was done and to his satisfaction in part because of using well documented and supported framework. If you can’t make progress perhaps there is no value in appearing better in his eyes. Only you can answer that.

Majority of the answers and comments have the right idea in that you and the senior would need to have some sort of discussion and that it may be important for you to step up and defend your decisions, even if your senior does not agree with your choices.

To answer your question on what i would like to see as a senior:

I would like to see if my junior developers can stand up and defend his decisions, even if faint disappointment. If i were happy with the product but not with the implementation then i would expect the juniors to point out that i should have then been more specific in my specs when giving them the product. I would like them to be able to stand their ground but also to admit they may not have made the right choice should that be the case.

PS:
I must mention that i am a senior who loves to be proven wrong on a professional level as that grants me the opportunity to learn something new. And i like to be aware of how others in my team do things so that there are no / less surprises at the end of a Sprint / task.

First of all, I think this needs to be seen as an opportunity, not a failure. There’s obviously a mismatch in expectations and it isn’t clear where that comes from, what needs to happen to get everything back on track and the like.

Secondly, if you take this as a current failure or that you aren’t as smart as you think that sets up power relationships you don’t want. So if you made decisions you believe are defensible you need to be willing to defend them up to a point.

While I agree with duggieawesome that you want to have a conversation, that’s not enough. You have to be prepared to go in, discuss your design ideas, explain why you did what you did, and defend the reasoning. You also need to accept that there isn’t only one right answer and that the senior programmer may have valid reasons for preferring a different design and so you want to go in being willing to listen to those reasons without conceding that your decisions were bad based on what you knew (unless you decide that you should have known better, and then that’s another matter).

Keep in mind that design is usually a question of tradeoffs. You want to be willing to discuss what the tradeoffs are, and see what you both can do to ensure you can discuss design tradeoffs in the future. Maybe you two are just expecting you are more on the same page there than you are? Maybe your boss is an idiot (it might happen sometimes)? Maybe you really did make a decision that was wrong given what you knew about the requirements? Go in with an open mind and with confidence however, and be willing to really talk about this.

Edit: I want to add something about being smart. The smartest people I know are people who figure they have something to learn from everyone. People who are closed off and believe there is only one right way don’t end up making imaginatively good decisions in areas like design and they can’t connect things together the way that people who are willing to learn from everyone can. Going in and being willing to share and even bounce ideas back and forth is a sign of both being smart and confident. Differences in design do not necessarily become matters of one being better than the other. Assuming competent designers, different designs will be differently optimized.

I’m with the general opinion here that you haven’t done anything wrong. As the senior developer, he should have taken an interest in how you were developing the application as well as the results. To come in after a project is completed and say he doesn’t like how it was done isn’t very professional on his part.

But, to answer your main question: how do you gain back a senior’s opinion of you after it may have been lost? First of all, ask how they feel you should have done it. Ask questions if you don’t understand and take notes. Show that you want to learn.

Second, on your next task, if there is something that has been left out of the description, come up with your ideas then run them by the senior dev. Don’t flat out ask how to do it, b/c this won’t help their opinion of you. But, if you come up with your own ideas and your own solutions, then ask them if you’re on the right track, it will show them that you are trying and that you do have the skills to get the job done. This can be as simple as a quick email saying “Hey, I am planning on using x when doing y. Any thoughts?”

Third, when they pop their head in to see how you’re doing, don’t let them leave without looking at your code.

Basically, open the lines of communication. Your senior developer doesn’t seem to be the type to be on you or your code, so you need to step up and be the person to communicate. It is better for everyone involved to find out something isn’t exactly originally thought sooner rather than later.

One thing you need to find out right off the bat is whether he’s disheartened because you couldn’t give a comprehensive defence of your choice of framework, or if it’s because you used a framework.

In the former case, it’s important that you learn how to evaluate and select third party code for inclusion in a project, and that you know how to articulate that decision to your superiors and be prepared to stand by it with justification. This is a tricky skill to learn, but it comes with experience. It’s also a good skill to learn because as soon as you include a third party library into a project you introduce a component that may not be fully understood by the other developers, that they don’t have full control over, and may contain bugs, security holes and other things that they need to be aware of.

If he’s disappointed because you didn’t write it from scratch then that’s a different issue entirely. It may be that he has good reason to discourage the use of frameworks (such as the ones I described above), or maybe there’s a company policy against them or limiting the choice of frameworks you can make. Either way he should have communicated that to you and the fact that he didn’t indicates a failure on his part. On the other hand he may just have a case of framework prejudice, because in spite of the issues that frameworks can lead to, they also have major benefits as I’m sure you know. He may just think you should make everything yourself, even if that means redoing work that’s already been done and made publicly available due to “Not Invented Here syndrome”.

That he didn’t explain why he’s disappointed in you for using a framework is certainly a failure on his part to communicate effectively. He’s left you wondering what you’ve done wrong, when the answer could well be “nothing”. He’s also caused you to question yourself, and that’s bound to make you less inclined to use your own initiative in the future. If there’s one trait a good programmer can’t afford to have, it’s a lack of initiative. And while I’m sure it’s unintentional, his attitude is damaging morale as he’s suddenly withdrawn praise for a job well done over one small detail of how you accomplished the task.

Just because he’s the senior programmer doesn’t make him infallible.

Your follow up comment that said the boss is upset he has to learn something new….

Unless there is more to it that you haven’t mentioned, I’d be annoyed at HIM.

Learning new technologies is a great part of our job and every team should embrace learning and self improvement.

BUT, management have other things to worry about. They have deadlines to meet, they have limited or no training budgets.

From a man-management point of view, it might be someone else working on phase 2 of your project instead of you. You boss might have someone else ear marked for doing that work, and he knows that person now has a learning curve for something new.

And now a BUT on the previous BUT……. this is your bosses fault. If you are new and junior, he should have provided at least some guidance. To a lesser extent, you could have asked for guidance on the tech to use as well.

If you’re a senior programmer and have lost confidence in the ability of
your junior programmer, what would you like to see from your junior to
gain the confidence back?

Given that you’ve said that he didn’t want to learn how to use the framework you’ve used, I think the question should be: “If you’re a senior programmer and you’ve lost the ability to learn from your junior programmer, what should you do to sort yourself out?“

As a professional developer you do not stop learning. Ever. If you do, you are going to stagnate. And that might be fine in some areas. Banking has a lot of legacy systems in operation that need maintained so knowledge of old systems that move very slowly are fine. A friend of mine was editing COBOL for a bank to discover that the source code he was fixing hadn’t been touched in about 30 years (and the original author was our COBOL lecturer at university)… That said, he still has to learn new stuff as old systems have to be integrated into new systems.

Back to your senior developer. You said “he was upset about having to learn something new“, and in my opinion that is a rings some pretty loud alarm bells.

I’m always learning. While I’d really like my employer to pick up my education bill each year it is rare that they spend anything close to what I feel I actually need, yet I know that I must remain employable so I spend somewhere in the region of £2000 GBP (roughly $3000 USD) on my own education every year.

If your senior is not learning new things then they will start making poor decisions (maybe they already are) and the quality of the code you are dealing with will go downwards because they are stuck in a rut and don’t feel the need to get out of that rut.

One of the best developers I ever worked with was a junior developer who knew all sorts of stuff I’d never had a chance to look at. He brought so much to the table I was often overwhelmed. But I appreciated his efforts and I was never “dis-heartened” by any of it. I was pleased that he took the time to appreciate all the possibilities and present them to the team. He now leads a team and he keeps telling me about developers that bring stuff to the table and what he’s learning from them.

Your senior developer needs to learn things. They need to learn not to use emotive words (like “dis-heartening”) to hide their own inadequacies, because that will knock others’ confidence. They need to learn new frameworks (even if they can’t learn the whole thing, learn what it does and how it solves a problem, and if they need it in the future then they can invest the time in learning more deeply). And they need to learn that they are in a job where they will have to keep learning all the time.