fieryeagle

Very good read that highlighted the current state of the industry - G and FB reign as kings. I'd expect the fraud cycle to restart in gaming industry seeing that display and mobile are essentially saturated.

Expected people skills, business domain knowledge, architecture and security as well. Good articles based on the arguments but fell short of covering the major points.

Their drivers (majority of the workforce) have no welfare to speak of. Wait until Uber becomes really big like 90s' Microsoft then you'd see the rest of the Walmart deeds. It's the expected inherent big Corp SOP, nothing new.

I have been through very similar situations like yours during my early day jobs. It's that fire that we always had, fresh out of colleges and into the workforce, the drive to do good things, build cool stuff. Makes you very susceptible to be manipulated into doing more for free. If you think they pay well (just in certain pockets of the world anyway), the ROI from all that you do are multiples of what they gave you.

Here's the thing - your management know exactly what frustrated you and also know that it's the most efficient cost-cutting move, and it simply doesn't overlap with their interests to do something about it.

Not from me, you aren't. I'm an old soldier in this game (by webdev standards of 6 months for a new framework) and I have tended to switch over to the latest stuff almost every year (projects, job change etc). It's just a common disease and herd mentality in this field to sling the latest cools. Our productivity is generally shit because instead of cranking out working code, we try to fit more tools to the box, probably to combat the repetitiveness and boredom. At the end of the day, it doesn't matter what language or frameworks we use, things still get fucked up because we never spend enough time to know the ins and outs of our tools.

Yeah, such a poignant read that cuts to the heart of the problem - our needs to associate and express.

When you have the unique skill, you're better off being labelled as 'consultant'. The terms might be used interchangeably yet I've seen the power dynamics being consultant > full-timer > part-timer > contractor.

Same argument for enterprises can be had here. Way too risky to let the existing house of cards (stack) to perch atop a product that can be discontinued at anytime (I'm looking at you, Microsoft!). Google needs more revenues since ad money is shrinking so they would make sure that you get vendor-locked. Once shit happens, you are provided with a more expensive alternative, or consultancy services provided by certified vendors (again, looking at you, Microsoft!).

Contractors are second-class citizens at best, at any places so what was she expecting exactly? I don't mean to deride the writer but I'm honestly not sure if the janitors would think that working at FB is the opportunity of a lifetime, and I place more values at keeping places clean and tidy than curating news with an obvious bias (hint - I don't read them). There is nothing world-changing about picking out articles as a stepping stone for being replaced by algorithms. If you can't speak up, it means you are weak, the environment is toxic or both. So do something about it, or walk away like what the men do.

Here's where expectation should be set for both candidates and interviewers. The point of solving Fizz Buzz problems is to open up angles for discussion. What would you do differently with this problem, at this scale, for this integration etc etc. If someone writes crude code, I'd ask if they follow style guides or conventions. If someone writes overly fancy and clever stuff, I'd ask if they ever have to maintain shit. There is not much value in talking if all candidates would write "import fizz-buzz-solver from 'fizz-buzz-solver';".

You see, the whole Fizz Buzz is nothing more than a prop to allow me to find out what this candidate can actually do. Anyone can include a package and critical thinking differentiate smart ones from the pack. Heh, if there is a package for any and everything, most devs would be flipping burgers instead of doing original work.

Believe me, most problems you think of as original, aren't original. It's not about solving problems either, it's about repacking the solutions into something to sell, or making it popular enough so you can make money off it.

I would give those candidates the FizzBuzz problem just to see if they can actually code from scratch or `require('fizz-buzz-solver');`. I care more about their competence than what 1 or 10-liner packages they maintain.

On the contrary, I would certainly mark "maintains moderately popular open source project" as a calculated career move, just like how prostitutes would dress up right for the cliente. Sorry for the crude example but I am not placing the blame on the devs here but the absurd notion of employers considering a GitHub repo the 'in' thing before actual capability. Candidate - Brah I got 10 of those packages with 10mil downloads in total but I can't code for shit. Hiring manager - Since we are suckers who look at stats, you're hired!

The problem with this nanomodules approach is that it results in complacent and naive developers that eschew the basics and just publish random crap. Anything can make it to be a NPM package and be judged by...popularity? Since when is code turning into pop music :)?

<rant> The problem here is JS developers have baked in the notion of having NPM as the alternative to Google + StackOverflow + own thoughts. It's really a no-brainer (literally) to just slap another package than to bother thinking about what a piece of code does, the edge cases and pitfalls. Move fast and break things, right?

Sure there was some argument about Unix philosophy, small module doing one thing and does it very well. Did anyone bother considering the quality of most NPM packages? Quality is not reflected with passed Travis CI or extensive community testing and feedbacks. Not at all. Look at the those packages on apt-get. They are modular and robust. They do what they were supposed to do.

Now take a long hard look at the state of NPM. What do we have? People clamoring for reusability and whatnots. Most of them don't even know what they're talking about, just reciting the latest hip statement from the Internet. Being mature about development means accountability for what you do, not pushing shit around that you don't even have knowledge off. As a self-proclaimed polyglot, I love JavaScript as a language but not the ecosystem. It's like watching a dog chasing its tails:

- Endless loops of discussion that help stroke the egos but not improve anything else.

- Craps for resume/repository padding, not for actual developers to use.

- Bandwagon mentality that just pushes the latest fad along, and the herd towards the cliff.

The notion that JS developers are kids playing grown-up, has been reinforced with this NPM incident. If we want to discard that notion slowly, we need to be more mature developers. It's that simple. Here's what I think we could do: - Have a clear idea on what dependency you need. Browser, IDE, terminal etc are dependencies. Basic type checking is not. - Be better craftsmen. Roll and maintain your own toolboxes. Only share a working hammer, not a broken nail or a wood chip. - Note that for each package you publish, thousands more hours would be spent on learning, adapting, using and reporting mistakes. Collectively, the current community wastes so much time with finding the right things to use. Often times, we learn much more by playing with code, even posting on StackOverflow. That's hands-on, `npm i` is not. - Own the code better. The idea that teams like Babel and React devs with all the brilliant developers choose to put their eggs in a private corp's whims is just scary. You can't hope to build robust software while playing Jenga tower.

Yes, until people stopped publishing isInteger and isArray as `packages`. Plus, stdlib is standard library. Can you cite one for JS? NPM is not.