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.

I suppose this is how you gain fame these days, writing sensational counter-arguments instead of coding? Oh right, the author is a 'Ruby Activist', he couldn't help it. PHP has won, Node has won and now yet another language up to debate? Having something with its own niche and cult doesn't mean anything if it's not suitable for work. It does help populate shortcut-seeking approaches such as Heroku and more CRUD apps than ever before so Rails has its places.

Here's a piece to deflate any ego issues http://www.paulgraham.com/identity.html.

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.

I doubt something like 'wrote npm package that averages stuff' would be relevant without fluffing it up to impress the non-tech hiring manager. Still would ring alarm bells with devs though.

Just sugar-coated kool aid I'm hearing. Community benefits? First of all, I'm coding to get paid and this recent madness proved that JS ecosystem is semi-garbage. Back to the original question - do people really can't program that they need packages like left-pad or is-integer which had their own dependencies? Before writing those cool toolchains (which would likely work in a specific machine with a specific setting with all the real world testing the community has) can we at least pretend that we know the computer science basics?

Good point there. Pseudo-anonymity (or should I say, pseudonym-based) is the first step towards better privacy and decentralised transactions, not the solution. Still, we have the means to do so, if we really want to. With bank accounts, everything traces back to you by default without much improvement to be done. Different systems, different purposes.

Only if I publish my address and leave patterns behind. Agree that it's debatable then again, wouldn't you agree that in a relative sense, pseudo-anonymous is better than bank accounts tied to your name?

TL;DR cashless with anonymity and decentralisation. Sounds like Bitcoin.

This Dilbert strip says it best http://dilbert.com/strip/2011-04-14.

1) Don't expect 9-5 work if you are in anything remotely high-impact like software or sales.

2) Hard to specify since it varies on the kind of company/sector. PM me if you have something specific to check.

3) Company pays for basic coverage, no International and maternity for 99% cases (take my own estimate with a grain of salt). There are additional packages you can buy on top of company insurance.

Labour cost for services is fairly high in Singapore too, not as high as North Europe but about as much as, UK and Germany.

That's both pleasant and disappointing to hear. Believe me, if they offer you S$90k base, that's already considered a fat salary.

I silently added those who said that to a certain blacklist. Been through enough of 'Me - I'm in Software not IT. Them- But it is IT since you work with computer right?' ping pong matches. Ignoramuses, really.

Disagreed. In a free-for-all environment like FOSS, collective lack of details means more time wasted to gather/request for relevant information. Maintainers have the rights to request for such things before sifting through a potential mess of mostly incomplete issues/PRs. Their time is better spent anywhere but gathering correct versions to chase down a bug. People should have the common sense to provide those beforehand but alas, many do not.

Not money, shares.

Any public letters are carefully crafted pieces of PR, intention notwithstanding. The criticism probably stemmed from that angle.

Second this, but Joel Spolsky said it much better http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...

Professional fall-out tended to be due to professional reasons. If the root causes could be fixed or overridden with a greater cause, why could they not work together again?

A way to look at cable TV is like a buffet. Everything is paid for in advanced. In a buffet, you can eat until you bust and the restaurant would still break even with the food cost at worst. Most cases, profit. The rest of users always make up for the revenue 'losses' caused by a small set of anomalies. This double income from ads and data only happened because your carriers were allowed to get away with placing data caps on wireless. In some distance past, we used to get limits on broadbands too, remember?

As cliched as it may sound, it...depends on how is the API consumed? Is the error code going be processed further and passed onto logger or other sub-systems? Are there possible cases of collision with other existing enumerations or type restriction (magic handling relies on error code being of a certain value, for example). Most common way is to have an array of enumerated constants in code and that also adds a maintenance debt across front and back ends to sync up unless there is a separate micro-service to enquire about those enumerations which translates to extra development cost. It could get complicated fast and so on. Oh, hopefully the documentation (or code comment) stays up to date as well.

Tell them about the wonders of tethered phones or whispering quietly Internet dongles.