New guy on team - wants to replace progressively enhanced pages with jQuery plugins only - am I being unreasonable?

First off apologies for the huge post. I kinda feel a bit of back story is useful.

By trade I’m a sysadmin at a small (<10 employees) company. At work we have a small internal tool that is largely CRUD based, and was written very quickly nearly 10 years ago with few changes since. About a year a go I decided to use my spare time to experiment rewriting it from PHP (Zend Framework v1) to Phoenix to modernise it and use things like channels to solve a few real world issues we had. (Also what better to play with a new language than something you know?)

For frontend I went for a combination of Turbolinks and recently replaced the few bits of raw JavaScript to using Stimulusjs to give a little more structure.

Recently I was given the go ahead to use in-hours time to finish up the app, as well as a new junior has been assigned to help as I’ve got lots on. Which I felt was great.

The first few weeks he was getting accustomed to our business and he’s done small changes to the existing PHP app. These first weeks were full of complaints about a framework having been used at all.

He’s now progressed onto the Phoenix version. He wants to replace functioning parts of the frontend with jQuery plugins. I’m not hugely bothered about most of it, because who cares about datepickers, etc. I’d honestly prefer no jQuery since we don’t really need it, but if he understands it better that’s fine.

What does bother me a little is that he wants to start replacing stuff like server rendered tables (with filters and sorting, and pagination already working) with jQuery datatables that fetches vía Ajax only. But he can’t tell me why. Hes not really receptive to my feedback that it’s functional already and this adds nothing but extra code for no benefit. He’s starting to get a reputation within the company of just doing what he wants regardless of what he’s been assigned. He’s also started to demonstrate he can’t read or folllow existing Javascript well (something he claimed to be very experienced with according to my boss) nor does he understand how to structure code into reusable functions (by his own admission).

I’m trying to decide if I’m being too negative, unreasonable, or protective over what was a pet project, or if the project is actually starting to go off the rails.

I could do with some input and honestly I didn’t know where else to ask.

If I’m not being unreasonable, I’m not sure how to start coaching the guy. I wasn’t really planning on having to spend significant amounts of time with him, and I’m not used to formal things like code reviews as it’s usually just me.


If you are the project lead, surely what you decide on the best course of action is what should be followed?

Perhaps kindly but firmly state this is the case and that while you are open to being persuaded otherwise (with well reasoned argument) you’d be grateful if he could follow your guidance and instruction. If he feels strongly about a certain course of action, he should be able to convince you why that is the avenue you should pursue.

If he doesn’t really know what he’s doing, or lacks the necessary experience, it could be you who is left to pick up the pieces :101:


If this was a side project and not one you are doing for a paying customer (your work), I would entertain the idea and let him make a branch and see where he goes.

However, since this is a project that is for your employeer and being worked on during work hours, I would not allow it. If an employee, especially one that has been unable to prove themselves either in industry or in your company, cannot come up with a single reason why some change MAY lead to a better product, it is not worth the time to implement and test. Especially if something is working already. If he can do some research (preferably on his own time) and make the argument for the switch, depending on what he comes up with, it may be worth the switch. Most importantly, you appear to be the lead in this project. You are most likely going to need to be the one to maintain the application once it is “complete”. You are going to have to be comfortable making changes to the application in the future.

I also firmly believe that a team succeeds or fails together. Unfortunately, management doesn’t always see it that way. I hate saying it, but at some point you need to protect your own job.

TL;DR giving people creative freedom is great, but a lead needs to manage what gets freedom and what doesn’t.


Thanks for the input guys, especially so rapidly. I really do appreciate it as I feel out of my comfort zone and it’s been playing on my mind all week.

I’ll take what you’ve both said on board and see where things go <3


Sounds to me like his skill set is focused entirely on manipulating the DOM inside the browser while he is generally uncomfortable with server side rendering technologies - so the goal is to make his own life easier by strictly sticking with what he knows - rather than expanding his skill set to the technologies that are already in use.

If this can be believed jQuery may effectively be on the downtrend so it’s not the best time to become even more dependent on it’s aging ecosystem.


This certainly seems to be the case - Rails dropped jQuery over a year ago, too.


@theangryangel I’m the newest guy on this board and your junior probably knows more than me but I’ve been a business owner for many years and I would NOT appreciate somebody potentially screwing up my companies’ codebase, causing the engineers wasted time/energy and most importantly, WASTED MONEY for the company.

This video from Uncle Bob was a major reason I started focusing on clean code paradigms which ultimately led to Elixir.

Good luck


Have him make an actual written proposal for the changes he wants to make and then evaluate it point by point. Odds are he won’t actually follow through and he’s out of your hair. If he does, you’ll actually get an honest view point to debate with.

Adding JS for no reason has never been a good idea.


If I had this person on my team, and I was in charge, he would be gone pretty quickly. If you don’t have the power to do that, I suppose it would be best to just make sure he doesn’t damage your work, or take it to to management. Team members going rogue can be really draining on morale and money. If he cannot do what he is supposed to do, he has no business being in the team.


While I don’t necessarily disagree with any of the posted advice - you have to look at the antithesis - and the companys organizational skills/culture…

You have a struggling junior - who is maybe a “bad hire” - not being onboarded properly - no mentoring - being juggled around by the senior staff - not being giving small and concrete tasks to complete…

If we seniors tend to suffer from “impostor syndrome” - what does a junior feel.

The junior had and found some success - and now wants to go down that path - juniors also appreciate “things you can see” more than refactoring some backend code…

I would talk with your management about the failure in hiring/onboarding/mentoring… And how you can rectify the situation, most likely give the junior small concrete tasks (preferably “things you can see”) - give the junior some succes and feel of belonging, contributing and accomplishment.

It’s really weird that the junior is not being given tasks, but are left to come up with their own tasks - if I were the junior I would feel redundant - not part of the problem solving nor the team…

I would run the junior in a scrum-ish way mon-friday or fortnightly - monday you have some tasks that you and your product needs solved and you find the best ones for the junior to undertake… every day (or most days) you review and help/guide the junior towards the goal - friday you review, and celebrate :tada: (positive feedback - and sharing the pains/frustration of hard problems go a long way…)

While you might have a “bad hire” - you certainly have “bad hiring” - seems the junior is not being placed - and given solid ground to grow on.
Talk with management about where the junior should be placed, and given a foundation to grow from - a junior is NOT a net-benefit short term - but long term they can really add both productivity and happiness to your work…

So figure out whose wings this junior should fly under… or let him fly freely.

ps: all caveats apply of limited information etc etc. - just wanted to present the antithesis to the “bad hire - fire the junior” - by all means you might have a hopeless hire on your hands…


Thank you all to the advice given in this thread. As someone who wasn’t intending to be in this position at all criticism is welcome and appreciated.

You’re 100% right on the on-boarding process. I can and should’ve done better. I’ll easily hold up my hands to that.

The last month has been a perfect storm of issues for us, and too many weekends and evenings consumed over the last 3 weeks dealing with them. I will figure out some way of making more time for him and lower my expectation of independent work right off the bat.

[quote=“outlog, post:10, topic:12425”]
It’s really weird that the junior is not being given tasks, but are left to come up with their own tasks[/quote]
Yeah thats definitely not the case. There are plenty of assigned tasks with what I believe are clear deadlines and goals/expectations to be met. It just seems that some of the higher priority but less interesting seem to be intentionally slipping whilst interesting ones at the bottom are being picked up. Something that should’ve been dealt with by now and is again on me and my boss to not have dealt with it by now.

Ultimately I think you’re right outlog that this is just as much on me and my boss as it is the new hire.


This sounds like there are only “targets” - but no clear paths. This person may be junior enough to not be at the level to chose a path that is a consistent solution within the established environment.

It just seems that some of the higher priority but less interesting seem to be intentionally slipping whilst interesting ones at the bottom are being picked up.

Give him two tasks - no more. One high priority one which should get most of the time and another to work on when the first on is blocked (with the understanding that one should “Never Be Blocked”).

Something that should’ve been dealt with by now and is again on me and my boss to not have dealt with it by now.

I think you need to make it very clear to your boss that for the time being you haven’t been given someone to help you but someone that you need to spend a considerable time training which inevitably will divert a significant amount of time and effort away from your other day-to-day responsibilities.

By the sounds of it you are going to have to manage the delegated task in detail, discuss the solution approach and review the completed work - all of which will probably use up more time than if you would do the work yourself - especially if you add the mentoring needed to develop the JavaScript skills and how to do server side solutions.

That can be tricky in a small organization like yours and will only work if your junior is receptive to it.


HTML5 has a standard built-in browser support date picker now, why would anyone use javascript for that, which entirely screws up on mobile and a few other cases? o.O

Well that will entirely break when javscript is disabled or you need a text browser or you need to curl into scripts or anything like that (although a json endpoint is not bad, but phoenix supports content type negotiation for a reason).

Even less reason to let him mess with javascript in my opinion, especially if wanting to add jQuery in a day and age where jQuery is being removed from everything… I’d really question why he’d want to touch jQuery anyway, perhaps he needs to be taught proper web design ways, so this might be a good teaching occasion?

Although it doesn’t sound like this is a good way to start, working with others is definitely a skill worth building. :slight_smile:


And as an aside, I’d pick unpoly.js over turbolinks. ^.^
/me is a fan of full progressive enhancement

And get rid of jQuery entirely, it’s harmful in this modern age rather than helpful.


I know you are perfectly aware of this - but you can’t get rid of jQuery entirely if you adopt unpoly :wink:
But you should be able to isolate yourself from it - apart from the occasional jQuery object unpoly hands you. But it also leaves the temptation to just use jQuery because it’s already there. Not difficult for the disciplined person but …

Yeah they only use it internally for some things like promises and so forth, but they have been slowly removing it piece by piece, and it is an entirely internal affair in any case. :slight_smile:

The bit about unpoly is it’s near entirely declarative, no javascript to write in 99% of cases. :wink:

I honestly don’t understand why everyone here is so negative towards having a junior developer experiment with altering existing project structure. If your company depends so much on the work he does then its the company’s fault, not his. As a senior developer I would encourage that guy to open up a new branch and rewrite the app, say using vue.js or react, or some other front-end framework, if he wants to work in javascript. It will be a valuable lesson for him, if he succeeds, it means you got a good developer, if he doesn’t, he will be more responsive, tail between legs sort of thing.

@theangryangel I’ve seen lots of older developers who worked a lot longer than me, and their code was horrible mess. They were just as defensive about it as you are here, but given I’m not a junior developer, I ended up refactoring entire applications, stuff they worked on for years, just deleted it and started from scratch. In fact right now I’m working on ArcGIS platform that’s going to replace a project written in .net that is maintained by a team of nearly 30 developers in India for the past 7 years. It took me about 6 months to recreate almost entire functionality in elixir, right now I’m working on enhancements, that from management’s point of view were entire years of planning and expenses up until this refactor.

So just keep an open mind, and let the junior developers actually develop their skills if they have the drive for it, they’re not going to learn how to develop reading other people’s shitty code…

1 Like

Well for me it’s not the altering of the existing project structure, that’s perfectly fine it it is a good change, however the change that was being proposed was adding in antiquated and slow libraries while also making the site far more hostile toward javascript-disabled browsers (noscript) or browsers that don’t have javascript (elinks) or just simple downloaders (curl/wget) for seemingly no reason whatsoever. Vue.js/React would have the same detriment to usability, again for no reason. They have their places, but server-generateable content is not that place.


@OvermindDL1 pretty sure you don’t use lynx to browse elixir forums :smiley:

Yeah he did propose to use antiquated libraries, but in that case its up to senior developer to channel that on something more useful. If users don’t need something more advanced in terms of interface, there’s no need for js frameworks.

All I was saying is its good to let people experiment. 9 times out of 10 that experiment will fail. But they will appreciate it in the long run…

If your company depends so much on the work he does then its the company’s fault, not his.

The company pays a salary because they expect to get value. Juniors get paid less because they are expected to be less productive as they will spend a lot of time learning. But that doesn’t mean that the company expects to get little to no value out of them.

if he succeeds, it means you got a good developer, if he doesn’t.

In a company with less than 10 employees there usually isn’t that kind of slack that can tolerate that level of likely non-productivity. Now a developer with initiative could potentially try this outside of business hours. However if the outcome is successful compensation can be tricky unless there is some pre-existing arrangement to track hours and get time off in lieu.

I’ve seen lots of older developers who worked a lot longer than me, and their code was horrible mess.

I’m not sure you’ve got the correlation right. Developers produce software. There are plenty of examples of people who’s coding activities are primarily motivated by the attached paycheck and little else. And even individuals self-motivated to produce a quality product are sometimes coerced by their management to hand over barely functioning and therefore unfinished software before being pressed into the next task.

written in .net that is maintained by a team of nearly 30 developers in India for the past 7 years.

Again, developer attitudes, management styles and working environment can all play a big part in this type of result. Also by going from 30 people to 1 you’ve just drastically reduced the communication overhead required to conduct this type of effort. It’s well known that larger teams tend to have many more problems. In terms of developer quality some languages are seen as “self-selecting”. Languages like C#, Java, Python and JavaScript are not self-selecting languages from a hiring perspective.

It took me about 6 months to recreate almost entire functionality in elixir

Larger organizations can absorb this type of outlay and risk - smaller organizations cannot.