Slashdot Mirror

← Back to Stories (view on slashdot.org)

Tech Segments Facing Turbulence In 2016 (dice.com)

Posted by timothy on from the constant-change dept.

Nerval's Lobster writes: David Foote, an analyst who accurately predicted the tech industry's job growth in 2015, is back with some new predictions about which segments will do well in 2016 (Dice link). At the top of his list: DevOps, cloud and software architects, and cybersecurity experts. Those that won't perform well? SAP specialists, storage 'gurus,' and network managers could all face some headwinds. 'Companies are continuing to outsource infrastructure and that will reduce the need for network specialists except for network security which will remain in-house,' he says. Whether or not he's right about which parts of the tech industry will do better than others, there are also increasing signs that things could get very tight from a funding perspective for startups, as even the so-called 'unicorns' risk seeing investor money (and customers) dry up.

72 comments

  1. In other words by halivar · · Score: 2, Insightful

    Bullshit and buzzword titles rise to the top. It has always been thus.

    1. Re:In other words by Paradox · · Score: 1

      Well, no. There's some truth to this. I'm part of the reason why.

      See, I am what you could call an "architect" and "cloud services engineer". I prefer the term, "Distributed Systems Specialist." I've been focused on this since I learned under a bunch of ex-Yahoo! engineers at a company called Powerset, quite some time ago now. While my story is maybe unusual, my job and my general set of values are anything but.

      And my goal is to eliminate operations personnel, "Storage Specialists", and to hasten the disappearance of the dying breed of "one machine data scientist." I'm also hoping in the next 5 years we can flush out most of the unmanaged language programmers from any place they don't need to be (unless performance constraints are so tight they outweigh potential security and scheduling implications, I resist the use of languages like C++*, C and Fortran). If life is truly sweet, we'll phase out Java or at least threaten to so Oracle will stop brutally mismanaging that project.

      The "why" of it is complicated and reasons vary, but in general I'm very busy tearing down old crappy processes and infrastructures to make way for lightweight processes and efficient distributed infrastructure. This means things like making engineers have deploy rights (and responsibilities!) on their own code, making sure that data is effectively managed so that it's secure but still accessible to the folks who want to do statistical analysis, and that code gets written quickly and confidently.

      So yeah, if you (being any reader) one of those people I am your enemy and the beneficiary of this climate all at the same time.

      --
      Slashdot. It's Not For Common Sense
    2. Re:In other words by blue9steel · · Score: 2

      my goal is to eliminate operations personnel

      There are two ways to accomplish this:

      1) Call them something else, they're still operations but now they have a fancy new name

      2) Actually get rid of them, at which point you find out that the people you pushed the responsibility to have other things to do with their time and then it goes badly

      Now, automation can reduce the total number of operations folks you need by making the existing ones more productive and of course more expensive, but total elimination is impossible prior to strong AI.

    3. Re:In other words by vel-ex-tech · · Score: 1

      Well, I realized a while back that the purpose of my job is to eliminate jobs. I've been meaning to get into massively distributed systems for a while now out of sheer curiosity. Anybody who writes a program, even if that "program" is an Excel sheet, is eliminating jobs, even if the "job" eliminated is a fraction of a job.

      One thing before my main rant: I disagree about C++. I'd say it's more an issue of knowing which features to use and which to avoid. For example, std::string and std::unique_ptr/std::shared_ptr, RAII good. strlen, malloc/new bad. (Unless, like you said, it really is necessary, but then I'd argue that one should be using straight-up C instead). Oracle may be bad, but it would be difficult to replace the Java open source ecosystem, especially all the Apache Commons stuff (just use IcedTea?). Also, the sooner we decide to completely scrap Javascript as the programming language of the web, the better.

      My biggest fear is the people will become unable to function without all these dashboards and reports and high-level process management apps that we're cooking up. What I mean is that it seems like the more advanced and abstracted these things get, the more people forget the processes and policies we've modeled and automated. I've run into this before when something just works too well. People forget what policies and rules they decided on that the system is modeling.

      There's a lot of magical thinking here too. The most frequent thing I get is that when there's been a data entry error, people will think there's a bug in the system causing the data to be reported incorrectly. Sometimes it's a simple typo in a name or date of birth I can point to and correct. What I really hate is when it's an intricate issue involving difficult to use proprietary software where workers on the floor frequently make the same mistake. I have a few "favorites" that I have to explain the same thing to over and over again, but because the explanation is more complex than two sentences, they always forget it.

      As an example, the shifts of the workers out on the floor are now scheduled by computer program, and nobody really understands what the computer is doing, only that it makes their existing metrics look better. We found out that there were some data that were being included in the computation that shouldn't have been because it never occurred to people that $special_project_x would throw off the historical data. That went on for a few months before the metrics were impacted, they assumed there was a bug in the program (never connected that what was actually happening on the floor, but hey, it's not like the people who call the shots need to actually know what the workers do), and after some digging and some calls to the vendor, we identified the anomalous data that were being included. It turned out one of our "leap before look"ers did what they do best and leaped before looking (once again).

      What I'm getting at is just the complete failure to comprehend how all of our dashboards and reports arrive at their conclusions and how that failure of comprehension can lead to actual impacts on the business end. Perhaps it's because one person has taken on too many different roles because each of those roles only needs a fractional worker due to the skyrocketing productivity we've been delivering. I'm not sure what the answer is other than hoping my cynicism about this supposed "singularity" is misplaced.

      Then when there really is a bug or some other systemic issue (a policy that sounded good on paper with poor results in practice), they'll spend hours trying to figure out what they did wrong or trying to work around it. I'm thinking this one may be more related to the fact that nobody outside of my department can seem to understand what the words proprietary closed source mean. It may happen because they think if they pressure me and irritate me enough, that I'll break a licensing agreement and possibly eve

    4. Re:In other words by MightyMartian · · Score: 1

      You mean, the kind of infrastructure that, when some moron with a backhoe slices through the fiber, renders your infrastructure unreachable, and everyone simultaneously calling the badly undermanned IT department, including managers who will still continue to blame the poor fuck who no longer has any control over any of these wonderful "distributed" services, instead of people like you.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    5. Re:In other words by Paradox · · Score: 1

      Sorry, I disagree strongly.

      You don't need strong AI to actually implement monitoring, elasticity, and write software that fails in a method amenable to self-repair and in extreme cases, quick diagnosis.

      I've been frontline on Pagerduty at the company I founded for 5 years. There were some rough times during the first few apple features. No longer, though. Most of our systems self-heal or are designed to tolerate and report outages and partitions gracefully. Some categories of failure do knock us offline, but they're total failures and the system knows to go into an exponential backoff mode in that case.

      Sad part is, most of that code was trivial to write, universal over our entire app (we have one common shared library called "tragedy" that regulates nearly all of this). I wrote it years ago, and it has required only a handful of fixes over time.

      People who say it's impossible usually don't understand what's actually hard about it, don't keep up with current research in the field, and say things like, "No one understands zookeeper" and "Multi-PAXOS is over-engineered" and "backpressure is what broken systems need." I try to help educate people on this stuff, but I have a strong financial incentive not to, so... I generally let other people do it and laugh at the useless hand-wringers talking about how we should give every engineer a piece of a broken bridge or some shit.

      --
      Slashdot. It's Not For Common Sense
    6. Re:In other words by drolli · · Score: 2

      What you talk about is a solution by a thinking human, and not "big data - the massive cloud will solve it" pixie dust.

      IMO: If your system dependencies and requirement links are so obfuscated that you can not make fall-back rules by hand, i would bet there is no AI which will save you.

    7. Re:In other words by Paradox · · Score: 1

      One thing before my main rant: I disagree about C++. I'd say it's more an issue of knowing which features to use and which to avoid. For example, std::string and std::unique_ptr/std::shared_ptr, RAII good. strlen, malloc/new bad. (Unless, like you said, it really is necessary, but then I'd argue that one should be using straight-up C instead).

      I disqualify languages that do this to the extent C++ does. It's like programming in a minefield. Despite the fact I love the power of C++ and the elegance of Haskell, I do not expect most software shops to actually reliably ship on them.

      My biggest fear is the people will become unable to function without all these dashboards and reports and high-level process management apps that we're cooking up. What I mean is that it seems like the more advanced and abstracted these things get, the more people forget the processes and policies we've modeled and automated. I've run into this before when something just works too well. People forget what policies and rules they decided on that the system is modeling.

      But it's also a testament to a good system when the abstractions become central. Engineers already function at a pretty high level of abstraction for the most part. I don't think we should be too afraid of embracing that so long as the underlying methodologies are open sourced and well-understood.

      tl;dr That scene in Idiocracy after Not Sure tanks Brawndo's stock by using water on crops and Brawndo's system starts automatically firing everyone.

      That's already how it is and it's not that bad. Bad things happen, and they're corrected. This is not unusual for the human condition.

      --
      Slashdot. It's Not For Common Sense
    8. Re:In other words by Paradox · · Score: 1

      By the way, edit: 4 years. Sorry, simple typo I missed. Were that I were as diligent as my software.

      --
      Slashdot. It's Not For Common Sense
    9. Re:In other words by Paradox · · Score: 1

      You mean, the kind of infrastructure that, when some moron with a backhoe slices through the fiber, renders your infrastructure unreachable.

      What the hell are you even talking about? If my product is unreachable, then someone can't reach it. I can propose workarounds to this (multi-datacenter solutions with replicated databases and carefully tuned distributed consensus systems). During a true catastrophy (e.g., US-EAST going down due to flooding) the most important thing I can do is make sure that the data the system manipulates retains integrity through the event, and that the system can resume operation once connectivity can be restored.

      We operate under the assumption that software and networks WILL fail, not in the fear that they MIGHT. Indeed, understanding the failure modes is the majorty of my time spent when designing distributed systems.

      and everyone simultaneously calling the badly undermanned IT department,

      Who said anything about not having a robust service department? Not me. I have zero interest in having your argument with you. It seems like you're quite capable of carrying on by yourself.

      --
      Slashdot. It's Not For Common Sense
    10. Re:In other words by pr0fessor · · Score: 1

      Allow me to translate this for those that aren't sure what this means:

      I'm also hoping in the next 5 years we can flush out most of the unmanaged language programmers from any place they don't need to be (unless performance constraints are so tight they outweigh potential security and scheduling implications, I resist the use of languages like C++*, C and Fortran).

      "I'm also hoping software developers will be replaced with uneducated under-paid employees using limited frameworks and wysiwyg editors to churn out solutions that barely work in the least amount of time possible and is outsources to a service that I directly profit from"

      I'm very busy tearing down old crappy processes and infrastructures to make way for lightweight processes and efficient distributed infrastructure.

      I'm busy replacing your infrastructure with a cloud hosted services which I profit from, but is unlikely to be able to provide all of the services you require.

      So yeah, if you (being any reader) one of those people I am your enemy and the beneficiary of this climate all at the same time.

      I have a vested interest in companies that outsource your job and I need to destroy you so that I can make money.

    11. Re:In other words by blue9steel · · Score: 1

      What you're describing is how to increase the productivity of your operations staff, not how to eliminate them. Sure, a good setup may reduce your staffing needs considerably, but that doesn't eliminate the function.

    12. Re:In other words by Paradox · · Score: 1

      If you want to say, "Operations people are the people who wake up at 3am to deal with a page" then that'd be me. But that's a pretty archaic and artificial boundary.

      Engineers who design systems should be responsible for their continued operation. This has a lot of positive outcomes. Hence the term, "Devops." But I wouldn't hire an operations engineer who couldn't have at least in principle written the system they're managing, which means I don't hire most people who claim the title. Especially so in this day and age when containerization is effectively the annihilation of differences between local and remote operational environments.

      --
      Slashdot. It's Not For Common Sense
    13. Re:In other words by Penguinisto · · Score: 1

      I'd like to add a more important one:

      3) You discover that the folks you handed this pile over to are far too prone to prioritize 'ooh shiny!' over things like system stability, capacity vs. budgeting, security, and more than a few other aspects to keeping the system up and running .

      See also the headlong chase to make everything that's not welded to the floor into {insert some-widget-barely-out-of-beta here}... even when it makes zero sense to do so. Yeah, devs love the hell out that shit (because it makes constructing their test envs drop-easy)... but adding unnecessary overhead and complexity in the name of the almighty Buzzword is just as bad as having PHBs do it (or worse, you get Architect and PHBs alike saying ZOMG let's turn our Oracle RAC cluster into Docker containers running teh MongoDBz!!!11!! ...with zero thought beforehand as to whether or not that's actually doable, let alone necessary. )

      Mind you, I do the DevOps thing for a living, and quite well, judging by the amount of crap I have turned into automated goodness thus far. However, turning devs into ops people w/o any sense of training or experience is fucking moronic - most of them lack the perspective, skill and foresight to run a home router, let alone a production-critical system.

      By the way, now that I think about it, #2 (that you presented) is pretty big, and I've seen it first-hand. The result is usually sad unless you get management's buy-in to enforce it (...the typical answer: Marketing is too busy breathing down their neck to add new features, and the codebase really needs a good refactoring before it explodes, and now you want the devs to do sysadmin shit too!? Are you high!?)

      Who knows - GP may be in a unique and incredibly lucky situation (e.g. a smallish company still relying on something like AWS/EC2 for their heavy-lifting). I'm betting that it damned sure ain't typical no matter the case.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    14. Re:In other words by Paradox · · Score: 1

      "I'm also hoping software developers will be replaced with uneducated under-paid employees using limited frameworks and wysiwyg editors to churn out solutions that barely work in the least amount of time possible and is outsources to a service that I directly profit from"

      No. Nice try fearmongering though. I'm the antithesis of an "outsourcing" mentality for software. I'm busy "un-outsourcing" as many things as I can at my current employer because the value loss is just so extreme.

      But you keep trying to pretend that C++ is somehow tied to good programming.

      I'm busy replacing your infrastructure with a cloud hosted services which I profit from, but is unlikely to be able to provide all of the services you require.

      Whatever we can't get, we write. Isn't that how everyone works? What we don't need are silly single-role ops people who have no say in the actual development of software but don't have the skills to participate in its creation or maintenance. That's makework.

      I have a vested interest in companies that outsource your job and I need to destroy you so that I can make money.

      Sorry, but I have little pity for people who lose their jobs in technology to improvements. Unlike many people, you have the resources to self-educate and keep abreast of the times and state of the art. You just elect not to.

      --
      Slashdot. It's Not For Common Sense
    15. Re:In other words by blue9steel · · Score: 1

      You're going the fancy labels route. You've merely rediscovered that hiring a few good sysadmins beats hiring a bunch of low end ones, good for you.

    16. Re:In other words by Paradox · · Score: 1

      Claim victory however you like. I think dedicated sysadmins are not necessary for the majority of situations in the world of commercial software now. If you're maintaining your own data center, things change. Most people aren't, so they don't need them.

      --
      Slashdot. It's Not For Common Sense
    17. Re:In other words by Paradox · · Score: 1

      Who knows - GP may be in a unique and incredibly lucky situation (e.g. a smallish company still relying on something like AWS/EC2 for their heavy-lifting). I'm betting that it damned sure ain't typical no matter the case.

      I'm a "Director of Software Engineering for Capital One. You might have heard of us. I was brought in awhile ago through one of the many acquisitions as the company flushes its legacy tech policy and tries to pivot to be a technology company. You have enough data to find my phone number now. Feel free to give me a call if you're interested in helping me out and can write code.

      As an aside, AWS/EC2 is probably not the right choice for small companies anymore. GCE and Azure are way better for little ones because their service set and management tools are way richer. Amazon's willing to play ball with super-big companies at a scale even Microsoft isn't quite ready to embrace, as evidenced by my current workloads. And if the recruiter spams in my inbox are any indication, several other banks want to follow suit.

      --
      Slashdot. It's Not For Common Sense
    18. Re:In other words by unimacs · · Score: 1

      I run a small IT department. We will continue to keep some services in house but frankly the same sort of incident you refer to is the kind of thing that being able to turn up services in the cloud can help deal with.

      Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and Software as a Service (Saas) each comes with their own set of risks and rewards, but so does managing all that internally. You need to have your eyes wide open. If a company can save a significant amount of time and money all while improving availability by moving something to the cloud, eventually they probably will. It would be stupid of them not to.

      If you work in the IT field you need to understand that your most important skill is being able to adapt to a constantly changing technology landscape. There are folks who can make a living taking care of legacy stuff but personally that's not a position I'd like myself or anyone on my staff to be in.

    19. Re:In other words by Paradox · · Score: 1

      I have no idea what your objection or argument is. Sorry.

      --
      Slashdot. It's Not For Common Sense
    20. Re:In other words by pr0fessor · · Score: 1

      Unlike many people, you have the resources to self-educate and keep abreast of the times and state of the art. You just elect not to.

      Personally I have spent more than a half my lifetime in school and I'm a grandfather, so I do agree that if you have the means to educate yourself then you should.

      It's good that you are not trying to profit off of outsourcing to under-paid uneducated and usually under appreciated employees cranking out inferior products. It neither benefits the business or the employees however it is entirely something in line with what those that manage by profit margins and bottom lines would do.

      But you keep trying to pretend that C++ is somehow tied to good programming.

      Good programing isn't tied to the language however C, C++ are both good tools when used properly and shouldn't be avoided because development times and cost when it is the best tool for a particular job.

      As far as managed code goes there is nothing wrong with it in general however when you give even a qualified person a wysiwyg editor like visual studio or business intelligence and start having them crank out software with high pressure and short deadlines you end up with problems.

    21. Re:In other words by blue9steel · · Score: 1

      If you're managing the operations side of things and doing primary development for your money making product you're either A) Really small or B) Doing it wrong.

    22. Re:In other words by Paradox · · Score: 1

      See: I'm saying that if you're splitting it, you're wrong. You did it wrong at the start and now you have no choice but to keep doing it wrong.

      So I guess we agree to disagree, since you can't offer anything other than bland arguments and appeals to a largely ineffective status quo.

      --
      Slashdot. It's Not For Common Sense
    23. Re:In other words by Paradox · · Score: 1

      There is nothing more inhetmrently wrong with "WYSIWYG" editors than there is with C++. Judicious, appropriate use is implied. I think the industry over-relies on unmanaged code, appealing to "performance" as a crutch for bad designs and algorithm selections. The results speak for themselves.

      --
      Slashdot. It's Not For Common Sense
    24. Re:In other words by pr0fessor · · Score: 1

      I'm not going to deny that the world is full of poor decisions and poor code C and C++ included, it does not change the fact that the right tool for the right job is the best way to do things. It doesn't excuse the use of WYSIWYG development to override quality for quantity either or more simply to put off actual development.

      A great example would be handing a bunch business users a sharepoint site with site ownership and sharepoint designer and saying have fun hope you can make something useful for your team... because this is what happens in the real world some slick marketer talks up all the amazing features and some business type buys it hook line and sinker and they end up with an expensive file share.

    25. Re:In other words by blue9steel · · Score: 1

      Time spent on operations work takes away from time spent on the money making product. One of them is going to end up getting de-prioritized with poor results. Since money comes first, this is usually going to be operations work. It'll look great for a while until the technical debt builds up too large then you'll have a series of horrible failures (security, infrastructure, etc.). To think otherwise assumes that organizations never have conflicting priorities or politics of any kind, which I can assure you is not true. Now, does there need to hard silo separation, of course not, and some of the trend in DevOps is about breaking down or spanning that divide, but to suggest that a large organization can get by with just one team that does both is ridiculous. If you're big enough to have more than one manager in the IT Department then you're too big for the one team approach.

    26. Re:In other words by Anonymous Coward · · Score: 0

      You learned from ex-Yahoo! engineers about "making engineers have deploy rights on their own code"? No wonder Yahoo is going under. You sound like a moron.

    27. Re:In other words by Cederic · · Score: 1

      Heh, completely with you on that. Time to run up a sizeable debt on my Capital One card, there's a decent chance they're going to screw up so massively I wont need to pay half of it off.

    28. Re:In other words by Cederic · · Score: 1

      t I wouldn't hire an operations engineer who couldn't have at least in principle written the system they're managing

      According to http://www.soe.org.uk/ you don't have a fucking clue what an operations engineer is.

      Hire good system administrators. It's a different skillset and mindset to good software engineers. Hire those two. Get them to work together and presto: DevOps happens.

      But don't go hiring people with top end software engineering skills to be ops people. It's a waste of their skills, you'll piss them off, and you'll lose them.

      At Capital One you'll also need people with proper computer science skills - some of the algorithms get interesting. Again, nowhere fucking near the ops skillset or mindset.

      I'll get in touch with my friends at Capital One, suggest they find out what the fuck you're up to and add some sanity.

    29. Re:In other words by Anonymous Coward · · Score: 0

      We, uh, were scoped to writing software. What does SharePoint admins have to do with this? I suspect you and I are thinking of slightly different problem domains. For example, Android Studio's visual ui editor is considered acceptable, and if you buy into the storyboard concept XCode is the same. Visual Studio's interface editor thing Blend is similarly acceptable.

    30. Re:In other words by Anonymous Coward · · Score: 0

      You're right. To counteract this, both stability and performance are quantified as product features. This helps enormously.

      The weakness of my approach in this case: Once requirements are met its difficult to put in the effort to keep modernizing the ops infrastructure, because the user requirements are met. I am combatting this mostly by folding modernization efforts into other new features.

      For example, I'd like to migrate us off Zookeeper to Consul for a variety of reasons. This is very hard to get done because we trust the distributed locking and orchestration of zookeeper and no user could ever notice this. My solution is to fold the upgrade into our inclusion of Vault into our infrastructure, which is required for certain new types of security features we want anyways.

    31. Re: In other words by Anonymous Coward · · Score: 0

      Let me know how that works for you when you're programming on a smart phone.

    32. Re:In other words by Anonymous Coward · · Score: 0

      Not to worry, neither do they. But they're scared and unsure why or how to change that. Change is not an option. Really, we're a bunch of Luddites. This is how we've always done it and anything less is folly. We've no time for your games, we've no time for your fancy inventions, we've no desire to learn anything new. We've been there, done it, seen this all before, and it won't be any different today.

      We had dumb terminals. We had leasing time on the mainframe. We had fail-safe and graceful failover. We've seen the new languages. We know the new paradigm. We're beyond that now and you, and your ilk, are just getting in the way. The good news is we might get a vacation while they try your latest and greatest solution.

      Really, that's what we think. We used to appreciate the magic. We used to be happy to be on the cutting edge. We used to push the envelope. We were the ones that made a difference.

      Then we stagnated. I don't know what happened but the spidey sense tingles and tells me this is true. Hmm... I'll post this as AC, I guess.

    33. Re:In other words by Anonymous Coward · · Score: 0

      Now we need some vikings to crash through.

    34. Re:In other words by Anonymous Coward · · Score: 0

      If that's true you don't really have any developers.

      A large part of the quality of a system stems from the knowledge, vision, dedication of only several people. All of your concerns on (3) are simply aspects of running your service area, well. If you don't have them it superficially looks the same, but with more handwaving and people who love process.

    35. Re:In other words by drolli · · Score: 1

      Should have made more clear that i agree with you.

    36. Re:In other words by netwiz · · Score: 1

      Great, so not only are you paying for a 24x7 staff to watch your ops, you're also paying someone else's overhead and profit margin. In the long run, it's still cheaper to bring things in-house once you're big enough.

    37. Re:In other words by netwiz · · Score: 1

      Your'e forgetting something: in most cases, managing operations is exactly what's required to continue "making product." Those that forget this are doomed to failure. Momentum may keep you going for a while, but eventually you'll hit the wall.

    38. Re:In other words by Anonymous Coward · · Score: 0

      Actually get rid of them, at which point you find out that the people you pushed the responsibility to have other things to do with their time and then it goes badly

      At Netflix, "devops" means you architect, design, implement, deploy, and SUPPORT(24/7) your code. If your code goes tits up in the middle of the night, you get called. The flip side is I see a lot of $200k-$250k salaries.

      Can you get rid of your ops? Yes, by getting better programmers who understand ops and design their shit to actually work in production. Got 10 senior Devs, network admins, and server admins stuck trying to figure out a problem for 2 days? Ohh, I so happen to overhear the issue and promptly tell them where to look and the problem is fixed. I have no background in their code, I have no idea how any of the servers are setup or the networks are configured, I just use some fucking thinking. And I work at a company that has well above average competent programmers.

      There is a reason talent is on a power curve.

  2. Programmers will suffer by Anonymous Coward · · Score: 1

    Not designers, or system analysts, but the code cutters working from specs. You're all facing replacements from India, where vast coding pools using those with limited skills will do your job for <10% of your salary. The crap that comes back will then be beating into shape by the few local coders before being deployed.

    1. Re:Programmers will suffer by Opportunist · · Score: 1

      Just wait 'til management notices that they can't be held accountable for any damage that crappy code that Bob-from-Kansas with that weird singsong accent wrote. Then the "beating into shape" part will be cut from the process.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    2. Re:Programmers will suffer by Paradox · · Score: 3, Interesting

      This part of the thread is like some kinda racist time machine. It's nearly 2016, folks. This kind of garbage is called what it is now. Conflating trained software engineers with call center support is another great example of the kind of demeaning bullshit Americans do to anyone foreign: collapsing them into a demeaning caricature. You both should feel ashamed. Doubly so because you're comically wrong and outdated.

      First of all, outsourcing as a primary source for software has been on a sharp decline for years. A far greater problem is that the vast majority of services simply aren't writing code at all. They're buying 5-10 year old whitelabel software with confusing adapters to modern patterns or simply outsourcing entire products and then letting daily batch processes weld things together. A great example of this is most small banks and credit card providers in the US.

      Second of all, there's no reason people from India can't make great software. Go to any laudable US Compsci program and you'll find people from that country in every grade bracket of every division, if you "require proof" that humans are humans. The business model is the problem, not someone's skin color or language. Outsourcing firms (of which there area LOT in South America now, by the way, so maybe it's time to listen to Trump's rhetoric?) aren't effective because their model is making payroll, not delivering great software to their clients. Many companies are realizing this, and converting to a contracting supply model, which makes a lot more sense in an environment where good talent is hard to find.

      --
      Slashdot. It's Not For Common Sense
    3. Re:Programmers will suffer by Anonymous Coward · · Score: 0

      You're missing the point. There is no reason that people from India can't make great software. However, much of the software coming from India is crap. So, do some math.

    4. Re:Programmers will suffer by Paradox · · Score: 1

      Thanks for your grade school statistical analysis, anonymous coward. Why not just crawl back in the time machine and enjoy the 90s before you hear some Friends spoilers? You're farcical in this day and age, and I'd laugh at you were it not for the tragedy of how your how sharp and painful little words hurt some people who work harder than you've ever had to, just to stay in the US.

      --
      Slashdot. It's Not For Common Sense
    5. Re:Programmers will suffer by netwiz · · Score: 1

      Unfortunately, the bulk of them are working harder sucking at writing software. Ask me how I know.

    6. Re:Programmers will suffer by Anonymous Coward · · Score: 0

      You missed the point again. It's not so much that Indian programmers are bad, it's just almost all programmers in the entire world are bad. The only difference is if you want to treat your own programmers like replaceable cogs, Indian programmers are cheaper.

  3. Weird Account Issues by binarylarry · · Score: 1

    Anyone else having strange issues with your Slashdot account? Like certain pages say you aren't logged in... but you can't login. BUT when you go to a story, you're logged in?

    Some kind of new cache change or something?

    --
    Mod me down, my New Earth Global Warmingist friends!
    1. Re:Weird Account Issues by Anonymous Coward · · Score: 0

      Same here. Seems like /. comes down with a case of the beta flu once per month or so.

      *sigh* posting AC because I can't post at the moment while logged in. There has to be some weird meta thing going on here. As Opportunist pointed out, management doesn't give a crap about code quality because they don't have to. Besides, one can learn how to code in an hour, and then everything else one needs can be copy-pasta'd from StackOverflow, right?

      -- vel-ex-tech

    2. Re:Weird Account Issues by XXeR · · Score: 1

      Anyone else having strange issues with your Slashdot account?

      I've had to re-login several times over the past few days on the same device.

    3. Re:Weird Account Issues by MightyMartian · · Score: 1

      I can't reach the My Comments page from my Android devices. It goes to m.slashdot.org, and enters an endless loop.

      Once again, the idiots that write this site are implementing untested changes.

      But worst of all, I have no ads checked, and yet two stupid ads keep appearing on the main page. It's almost as if Dice just wants to kill Slashdot now.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    4. Re:Weird Account Issues by The-Ixian · · Score: 1

      This was happening to me yesterday. I thought my account had been compromised because my password was failing.

      The password recovery did not send me any e-mails either.

      But then, magically, midway through the day, the session cookie must have been accepted again and I was suddenly logged in.

      I, of course, changed my password... but I assume it was some server-side disruption.

      --
      My eyes reflect the stars and a smile lights up my face.
    5. Re:Weird Account Issues by Hognoxious · · Score: 1

      Were you getting the thing where even if you were logged in it was telling you the captcha was wrong, when there wasn't even one visible? And both submit and preview buttons disappeared?

      There was a similar bug a while back, maybe even before beta was introduced.

      For me, it sometimes works if I log on from the main page and if I want to open a story or post a reply I do it by opening a new tab. Makes you wonder if dimothy and his crew test anything, ever.

      I think they let the work experience boy frig around with the code again. The one who was supposed to be getting experience in the canteen.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  4. So, in a nutshell by Opportunist · · Score: 3, Insightful

    The experts in the flavor of the month technologies (i.e. the buzzwords of which have arrived at the C-Level table) are in demand, the experts in the flavor of last year technology not so.

    That's really astonishing. Who would have thought? How insightful, how unexpected!

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    1. Re:So, in a nutshell by Tablizer · · Score: 1

      Is Node++ on Cloud MongoRails still "in", or is that passe? I lost track.

      --
      Table-ized A.I.
    2. Re:So, in a nutshell by chispito · · Score: 1

      The experts in the flavor of the month technologies

      Infosec has been the flavor of the last five years. Unfortunately, recruiters still have no idea what they're looking for so they'll keep copy-pasting 'CISSP' into postings for every level of position, regardless of pay or whether it's a management job.

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    3. Re:So, in a nutshell by luis_a_espinal · · Score: 1

      The experts in the flavor of the month technologies (i.e. the buzzwords of which have arrived at the C-Level table) are in demand, the experts in the flavor of last year technology not so.

      That's really astonishing. Who would have thought? How insightful, how unexpected!

      No. The prediction is not just about buzzwords, but about trends that are taking place now (in particular DevOps and the "cloud" - I hate that term.

      Anyways, whether those trends are for better or worse are beyond the point. I can see a dip occurring in 2016 and 2017. And we are bound to have one if we expect a 4-year cycle between dips and our last dip was in 2012 (a mild dip) preceded by the much worse dip of 2008.

      Some places are more immune to such cyclic occurrences than others, but the general rule seems to apply. Expect a dip every 4-6 years. I've been through enough of them (and managed to get through them more or less in good footing), by paying attention to those cycles, to the trends and to always keeping my skills up to date.

      Unless you are of Linus Torvald's caliber, ignore this at your own peril.

  5. I thought Dice was selling slashdot, please hurry by netsavior · · Score: 1

    Please hurry, I am so sick of Dicedot

  6. Engineers lose, douchebags win by Anonymous Coward · · Score: 0

    Been this way for a decade now. Buzzwords win, brains lose. Indians win, Americans lose. Governments win, people lose.

    1. Re:Engineers lose, douchebags win by Tablizer · · Score: 1

      Don't worry, PHB's and hypsters will invent some new fad or gimmick that will create new "standards" or product categories that F everything up and create security gaps, requiring engineers to fix.

      Chaos is your friend.

      --
      Table-ized A.I.
  7. Re:I thought Dice was selling slashdot, please hur by vel-ex-tech · · Score: 1

    Prediction: some place like Reddit or code.org will buy up Dicedot. Not going on any real evidence, just a hunch.

    At any rate, hopefully the site will stop wonking out for a day or two every other month. Either that or it would be the tipping point for a mass migration to the red site (maybe even a bump for the blue site, too).

    Can I post this one while logged in? Let's see!

  8. His prediction was 16 things? by Anonymous Coward · · Score: 0

    Hang on! He predicted 16 area of IT? And some of them grew? That's a little too vague to be convincing. He basically predicted everything would grow, which is a safe bet since IT was unlikely to contract. Many of his categories were vague, too. With prescience like this, he can hardly get it wrong.

  9. It's going to get much worse for IT.... by dablow · · Score: 1

    CS departments are pumping out graduates like a mill.

    Corporations are pushing hard for H1B visas....

    Outsourcing still going strong....

    Massive consolidation into data centers.

    Tech field is a total disaster. Anybody studying in it right now should switch ASAP to another field.

    There is some money left to be made however it's going to be the extremely rare exception rather than the rule.

    1. Re:It's going to get much worse for IT.... by Tony+Isaac · · Score: 1

      I lived through the dot-com bubble bursting. From about 2001-2005, it got really tough out there. Only those who truly loved software development stayed in. All in all, it had a good result--the quality of the people still in the business went up dramatically.

      This time around is nothing compared to that time period. Yes, I do think we're at the peak of another bubble, but not as big. This time, people actually know they want software, and why.

      If you're ready to leave the industry, please do! I for one am sticking around.

    2. Re:It's going to get much worse for IT.... by dablow · · Score: 0

      This is not a bubble bursting.

      It's an entire industry transforming itself. A paradigms shift.

      We are living in a post PC world, and it's never going to come back.

      With everything centralized, the hardware commoditized...there will not be any decent jobs left in this field (for somebody that lives in a Western nation).

    3. Re:It's going to get much worse for IT.... by dablow · · Score: 1

      Just to clarify:

      It's not that IT jobs will not exist. They will. It's just that the majority of the labor will be off shored, and what cannot be well they will have hundreds upon hundreds of graduates competing again H1B's (or your nation's equivalent) for the little remaining jobs.

      Kinda how like farming works in USA and Canada. You know where they fly in temporary workers from Mexico and then ship them back when the season is done.

    4. Re:It's going to get much worse for IT.... by Anonymous Coward · · Score: 0

      Right. They are going to fly in temporary workers into the US to work on "commoditized hardware" and then fly them out again when the "commoditized hardware" season is over? What does "commoditized hardware" have to do with jobs anyway? Hardware has been commoditized for two decades. The number of PC's out there is at a record high, so I don't know what you are talking about.

    5. Re:It's going to get much worse for IT.... by luis_a_espinal · · Score: 1

      This is not a bubble bursting.

      It's an entire industry transforming itself. A paradigms shift.

      We are living in a post PC world, and it's never going to come back.

      With everything centralized, the hardware commoditized...there will not be any decent jobs left in this field (for somebody that lives in a Western nation).

      Then ride that shit. That's how we get through times (source, survival of several paradigm shifts.)

  10. In other news... by ZeroWaiteState · · Score: 1

    Tech industry in slump because tech startups discovered everything they planned to design or build in 2016 is now illegal. However, rental properties, mortgage backed securities, and marijuana farming all looking promising in the coming year.

  11. I'm an IT Manager by Anonymous Coward · · Score: 0

    And I keep hearing "the hottest new trend is outsourcing the network" ... this defies logic. The computers need to plug into SOMETHING. Wifi or cabled ethernet, you're going to need APs/Switches/Routers under your roof. The closest I've seen is something like Meraki gear where they host a webpage that you pay for access to ... but you still do the work. Need to upgrade images? Same service window selection and management as before.

    This seems like 99.9997% bullshit. Am I missing something?

    1. Re:I'm an IT Manager by dablow · · Score: 1

      It means your company rents the network or wifi from a 3rd party.

      There are different variations (some where you own the hardware, to them owning the hardware) and they manage it for you with their expertise.

      Thing is is the network was large enough to require a full time person on it, this requirement will not change. So you will be stuck paying full time worker + overhead of 3rd party who needs to profit. Also at the end of the day you will pay the hardware costs many times over because again the 3rd party is there to make a profit, not be your friendly business partner.

      However, if these mega service corps properly lobbied their local gov for some special tax exemptions, this might actually be cheaper in the long run than paying a person directly. But it comes at the expense of service (you have an SLA, if you have to wait, you wait, they will not prioritize you business over others, unless of course you are willing to pay much more).

    2. Re:I'm an IT Manager by Anonymous Coward · · Score: 0

      Pretty much what I'm seeing - I still have all the cost of the same hardware that I had before, and the local person to manage the network (specifically, the interface of the business TO the network), but now I have the privilege of paying a fee forever to access a cloudy management console and get some configuration recommendations.

  12. Outsourcing network operations by Anonymous Coward · · Score: 0

    Almost never works if you really care about how long your outages are.
    You will just wind up bringing it back in especially global scale.