Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: I don't think that's what Snowden is saying (Score 5, Interesting) 196 196

The poster's interpretation seems completely off-base to me; not only is Snowden not encouraging us to blindly trust Apple et al with our privacy, he explicitly warns of the very danger the OP brings up.

As an iOS developer, my perception is certainly not that Apple is trying to grab our data instead of the government - in recent years, they have started a major cultural shift toward real protections of user data - simply not collecting it, encrypting it in transit, etc., etc., even if it's a burden on third-party developers to make the transition. This is a Good Thing, full stop. Props to Apple (as well as Google, who is also making its own efforts).

Comment: Typical Business Insider Conspiracy Theory. (Score 2) 260 260

The makers of this article clearly have no background in computing, or journalism either for that matter. I'm surprised I didn't see a reference to the Illuminati in there somewhere. Bizarrely, the article doesn't even mention Dart, which is no doubt due to the two-minute Bing search that I'd imagine formed the entirety of their background research.

When considered against the status quo for their purposes and eras, all of these languages show significant, useful advances in programming. And if we're going to declare all languages that are created by a for-profit corporation invalid, say goodbye to Java, C#, C++, and C. Hell, even the Jacquard Loom was meant to make money.

Comment: We all knew Java was a sinking ship (Score 0) 223 223

...since 2009, and we shouldn't be too shocked here.

I am a longtime Java engineer and was genuinely furious at the slow, humiliating decline I knew was coming for the language when the Lich King decided to buy Sun Microsystems. But I am past that, and for years have been preparing for the day when I would step off that ship instead of going down with it, as I think any engineer who's aware of the industry ought to be doing.

The main complication here is Google's insistence on keeping it alive, and even doubling down on it rather than taking the much smarter approach that Apple did with Objective-C. Go and Dart are both solid languages, but Google just isn't taking them seriously enough to make either the new lingua franca of the 2020s (yet).

Comment: Agile was always a scam. (Score 3, Insightful) 507 507

Why would anyone take something seriously that was created and peddled by consulting outfits at $700-per-hour bill rates? I had the misfortune of being incarcerated at Pivotal Labs for a month by a misguided boss who thought their bizarre religion was the answer to all of life's ills. Boy, was that eye-opening.

As many people rightly point out, that doesn't mean we can't pick up some new ideas from it - my company now does short daily meetings and have a chart with everyone's daily tasking on it, and those have proven very effective. But the other 99% of what the Snowbird 17 vomited forth upon our industry is empty zealotry and jingoism. It was like Scientology right in our codebases, and worked about as well. And no, for god's sake, it wasn't because we just weren't doing it well enough.

We do have shockingly dramatic quality issues in the software industry, but they will never be addressed by the next dumb-ass management fad. We need to sit down and re-think the ways that we learn to code, get serious about "Software Engineering" degrees in our colleges, and let go of fetishized code patterns as the primary unit of engineering ability. In my own experience, we know plenty enough design patterns, but almost no one understands how to exercise coding judgment in the context of a team or long-term project.

Comment: Good grief. (Score 2) 270 270

FYI, I'm an iOS developer who uses a mix of languages, including Ob-C, every day. My coworkers and I met Swift with a mildly positive reaction - it's a decent, if imperfect, effort. It's not the second coming of Christ, but it definitely isn't a bad thing to try to modernize some of Ob-C's age-related shortcomings. The notion that we'd re-write code just to use it is utterly laughable, but we could certainly see ourselves using it to start a new app, or maybe at our next jobs.

The OP, though, sounds like a marketing intern wrote it. To add a little historical perspective: our apps are a riotous mix of C and C++ (for Android portability) and Ob-C. We chose to do it this way, within the last 3 years, so this is not a legacy issue. Both C++ and Ob-C were, at one time, meant as "replacements" for C, and we know how that turned out.

Swift may very well become the preferred language over Ob-C within, say, 5 years, for Apple-specific development. But the breathless "it'll replace C!" rhetoric is just silly. Over the coming decades, C will surely fade, but it will be replaced by other, newer, even more amazing tech, not just Swift.

Comment: Did 'Em a Favor (Score 1) 407 407

Utilities are renowned for being dysfunctional political quagmires that are deserts of innovation - my wife worked at one for a few years and hoooo boy, the stories she could tell. Frankly, this is probably a *boost* to those US engineers' careers.

Comment: Not even close to a "first" (Score 1) 326 326

E3 did this more than ten years ago. Revenues at the conference obviously went through the floor, and they went straight back to the fanboy mosh pit everyone knew and loved from before.

That said, I didn't think the RSA conference would have the same demographic of attendees as E3. Perhaps it makes more sense for them; who knows. At the end of the day, business is business, and this is ultimately about money, not any social statement. They are simply betting that changing their appeal will raise their stature among security experts, attract attendees and media favor, and drive the all-important bottom line.

Comment: 70% "Failure Rate"? (Score 4, Informative) 133 133

Gimme a break. One talking head wants to publish a "study" and suddenly it's canon? What does "failure" of a virtual team even mean? Probably, less money for the talking head.

Virtual-enabled teams, in my own experience, may not result in any massive, curve-jumping gains suitable for a click-baity headline, but I do think they are at least as good, and decisively better in a few key ways, as traditional, rigidly office-bound teams. They are cheaper facilities-wise, and result in vastly higher morale and loyalty among the employees who are able to work from home. They do not result in goofing off or falloff of productivity, except among employees who were worthless anyway.

Ultimately, virtual-enabled teams amplify whatever is good or bad about the leadership and quality of the hires. Good hires become great hires because they don't waste their work house stuck in ever-increasing traffic. Do-nothing managers become disaster managers. And the morons who represent the failure of the hiring process will spend their days at the beach and be discovered far earlier than they would have.

Virtualization is a Great Thing. But it highlights how the current state of management and hiring in software is a Terrible Thing. Don't believe the haters.

Comment: Go eat your applesauce, Grandpa (Score 5, Funny) 205 205

The software industry just isn't a place for changing direction or starting new things. I mean, come on - learning a new skill is disloyal to the older skills. If everyone just learned things willy-nilly, who would sort the punch cards anymore?

Just keep your head down - you probably only have 2 or 3 more good typing years left before you're too old to sit up or retain bowel control.

Comment: Study: This Study Is BS (Score 3, Insightful) 247 247

Making a judgment about "refactoring" as a single, simplistic concept is like making a judgment about "food" or "government" without going into any further detail. Umm, it's kind of not that simple.

Refactoring in real life is a whole array of different, nuanced activities. Any of them can be wise or foolish depending on the situation. Well-written code requires less of it, but some degree of it will always be needed as we can't tell the future. Each instance is a judgment call with no concrete right answer.

Comment: A many-headed cultural problem (Score 1) 158 158

Thanks for bringing this up and giving it a name, first off; it needed one.

Over the years I have seen this mentality a lot, but it's almost always pushed onto a team from management rather than home-grown in the minds of the engineers. I see it as a systemic issue at software companies that the leaders see their own engineers as the least preferable choice to actually build new things. I think this arises from a few factors:

- open-source software has so successfully marketed itself as better than third-party enterprise software that managers think they are supposed to prefer it over in-house solutions that are informed by the knowledge of their own business. For obviously generic components like JSON parsers, this is true, but leaders often take this mentality to comical lengths.

- resume-building is about keywords, because that's all recruiters understand. Junior engineers realize that if they build their own components, they will not "get credit for it" later. But put Spring and Hibernate on your resume and the recruiters will come. So why not cram as many third-party components in as possible and really build that skills section?

- it can appear easier to manage a team that is struggling under the bloat of a third-party framework rather than creating something better. PMs feel more in control; managers don't have to think as much, and the engineers get their keywords for their resume. Everyone wins!

- a single phrase: "don't re-invent the wheel." I think this one sentence is responsible for the suppression of countless creative ideas. PMs and managers use it like a weapon to keep control; consultants use it to poison the reputations of in-house engineers in the minds of the managers whose money they want. Senior engineers even use it to squash down the ideas of competitors for their position. If we engineers did nothing but thoroughly discredit this phrase, turning it into a shared joke ala "what could go wrong?", the world would be a better place.

Comment: 95% of research is fluff, research shows (Score 2) 411 411

This sounds like the same hand-wavy BS that spawned our current infestation of Agile consultants.

They aren't even trying to be scientific here; this is just baldfaced click-bait, likely commissioned by some unproductive company who wants to look like a "thought leader." What are they even defining as "wheat" and "chaff"? Who decides which lines of code are which? Who decides who gets to decide that? What does it even mean to describe what code "does"?

Smart people can disagree about best practices and what constitutes "good" code - ultimately, I think most of it boils down to personal taste rather than any notion of objective correctness or big-picture productivity. Personally, I feel most productive in Java - but that's because of an interlocking mesh of many subtle reasons and has nothing to do with how many bytes my code files take up.

Comment: Re: Then be corrected of the error of your ways. (Score 1) 376 376

I hate to say it, but you're only reinforcing the pattern I've seen: I obviously wasn't in any way saying age discrimination "does not exist," as that would be moronic. But your attempt to twist my words into such a simplistic straw-man argument was the same sort of passive-aggressive victim-theater that I've heard a lot around this topic. It seems most alarm-raisers of age discrimination (that I've read, anyway) have this same sort of feel.

Please, are there any debate points on this subject that aren't obvious fallacy or appeal to emotion? My guess is, they exist, but are buried under the histrionics.

The star of riches is shining upon you.

Working...