HN user
Software developer from Berlin, Germany.
As a german, I see a problem within our culture. We are a people of envy and jellousy. Great people often get discriminated...a brilliant developer?...no he's an arrogant academic...a smart manager?...just a renegade not playing by the rules.
This is the typical german mindset. You better be avarage, following the german mediocrity.
I believe it was H. Ford who said "If we'd asked people what they wanted, they had said 'faster horses'"
A good product matches people's desires, is easy to use and of high quality.
Visual Studio Code, Make or SCons (depending on project size), GCC and GDB
no. react solves no real problems. stick with vanilla
To me this sounds just like someone not being a good developer. As a freelance developer myself I know what value I offer my clients. I've seen so much code from others in the last 15 years, that I can tell the results will likeley not be equal. I am proud of my work and I deliver well documented, stable and easily maintainable software. If a bad paid dev can do the same job as you, I doubt your abilities , disciplin and passion
Let down someone for his opinion is never a right thing. I believe it was a political decision, but ethically (and maybe economically in the long term) a very wrong one.
And another ranting against JavaScript claiming it to be a horrible language... The author does not give any evidence why JS would be a bad language.
I write JS-code on a daily basis for over 10 years now, mostly in a functional fashion, and I get things done on time without much headache. Also I know the platforms well and their issues.
The bad side of JS is not the language or the underlying platforms, but the huge amount of substandard programmers creating aweful libraries and frameworks which are used by even less capable hackers.
This question cannot be answered easily. It depends on so many details... Are the original authors still there to guide new employees? Is the overall design clear and simple?
Experience doesn't need to be an indicator for productivity. Also often you can find programmers who seem not productive at all, but without their contribution the whole project might fail.
The best thing to do is to set your milestones, and put trust in the people you hired. Then check your progress regulary. Talk and listen to your employees. Be trustworthy yourself.
You don't want to know how much code a new hire can put out in a month. It doesn't matter. You want to know weather you reach your business goals. So communication, trust and transparency will improve every contribution of your engineers.
First, code written in a rush, caused by tight deadlines will push nearly everyone to write sloppy code. That doesn't make someone a nnpp. Even the best hackers will create substandard work under heavy pressure.
What you can do is start writing tests. Cover the pasta you're working on and use common coding standards. With some examples at your hand on how to improve things, meetup with your lead and explain him your sorrows without criticizing him. Tell him what makes it hard for you and others to work with the code. He'll also have valuable ideas for improvements.
Real nnpps are less common than you might think.