Follow Slashdot stories on Twitter


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Some good points. (Score 1) 269

Oh absolutely, yes: Quite a few have become very good, and regularly correct me. This is how I learned, too. Just as a great programmer knows that the code isn't done when it works -- that's when you start -- writing doesn't end with the first draft.

Verbal advice is ephemeral. It's easy to not-notice something said in passing. And while there have been situations in which I learned at a master's feet in person -- particularly when he didn't realize he was teaching -- the grunt work of getting better at my job is a processing of making small improvements. So the opportunity to see, on the page, how someone changed the text, and why... that lets me compare before-and-after at my own pace, without anyone standing over me.

Needless to say I'm still close with those who mentored me and with those whom I've mentored. But "how to mentor" is, perhaps, a different discussion.

Comment Re:I get it. (Score 1) 269

> The whole idea is a pretty radical change from the established order. Better tools need to be built. Better protocols need to be in place more consistently. Better practices need to be thought up and deployed, because the state of it now is objectively bad at the corporate level.

I'm interested in what changes you feel need to be made to improve the process, particularly if I left them out of the white paper (to which the article linked). As you may imagine, the topic is one that interests me greatly.

Submission + - The real reasons companies won't hire telecommuters

Esther Schindler writes: Those of us who telecommute cannot quite fathom the reasons companies give for refusing to let people work from home. But even if you don't agree with their decision, they do have reasons — and not all of them are, "Because we like to be idiots." In 5 reasons why the company you want to work for won’t hire telecommuters, hiring managers share their sincere reasons to insist you work in the office—and a few tips for how you might convince them otherwise.

Submission + - Making one-on-one meetings actually USEFUL

Esther Schindler writes: All too often, managers and team members reject a regular check-in because they think it's a waste of time. But when done well, one-and-one meetings are a great way to build trust and rapport. That weekly time slot is a predictable time for feedback and coaching. Even when a manager and team member get along well, a regular one-on-one is an opportunity to impart information privately, to raise emotional issues before they fester, to address career challenges, and to help managers make better decisions with team input.

But way too often, those manager-and-team-member meetings are a waste of time. Here's three ways they go wrong.

Submission + - 31 Ways to Know Your Project is Doomed

Esther Schindler writes: We've all been there: The project went horribly wrong. Nobody was happy with the application or product (if it ever did ship). And you're ashamed to let anyone know you had anything to do with it. Especially since, with hindsight, you realize that the Signs Of Doom were there all along, and you missed them. When THIS happened, you should have known....!

This article shares 31 project danger signs you should recognize, so you can decide if it's possible to fix them or bail. But oh, we can be so certain that there are plenty more to add...!

Submission + - Don't be fooled by Opera browser claim of 150% battery life (

richi writes: The Opera Web browser has a new 'power-saving' feature. Opera claims you can get 'up to' 50% more battery life — but is that likely? Uh, NO!

Yes, the actual software tweaks will make a difference, but the tests Opera's quoting are skewed, unscientific, and compare apples to oranges. But what do you expect from a company that's trying to get bought by a Chinese consortium for more than $1.2 billion?

Submission + - Would YOU Fire This Person? (

Esther Schindler writes: If “Tracy” were on your team, how would you handle her?

Among a project manager’s most painful tasks is firing an employee. Nobody enjoys the experience, even when the employee clearly deserves to be booted. But it’s much worse when an individual is a drag on the team, not a complete failure. Few of us are certain when it’s time to say, “I give up. I must get rid of this person.”

It’s an age-old management dilemma, but we can all learn from the way other people handle such situations. Here’s the story of a real team “problem child” and the troubles “Tracy” caused her manager. You get the opportunity to decide what you would do if you were the project manager. Then you can compare notes with other managers – before you learn how the story really ended.

Submission + - Things Sysadmins and Developers Would Change About One Another

Esther Schindler writes: Even in the best of organizations, the development and operations departments have friction. Each has its own goals, metrics for success, and team culture. Plus, ops is in the business of making things predictable and unchanging, while developers are in the business of changing everything. Those opposing priorities make it harder for dev and ops to communicate freely. Despite the industry’s ongoing efforts to bring the communities together, developers continue to grumble about ops, who simultaneously grumble about devs.

Grumbling doesn’t help to resolve the tension (or desire to throttle someone). Understanding does. So both developers and sysadmins were asked to imagine that they were granted a single wish: You have the power to give your company’s [ops team | development team] an understanding of one thing — just one thing — that currently irks you. What spell would you cast with that magic wand?

The results are in two articles: 3 Way Ops Can Help Devs: A Developer Perspective and 3 Ways Devs Can Help Ops: An Operations Perspective. Maybe it's not surprising that the shared component is: Listen to each other more. Share what you're up to, and what the goal is. (Kumbaya optional.)

But maybe some of the specifics can help you grok where the other folks are coming from. For instance:

As a developer named John writes, “Software development sometimes needs to be allowed to bend the rules/regulations in order to operate efficiently/quickly. Too many times, the rules (e.g., who has access, when, what can be installed, etc.) cause ridiculous delays in cycle time for development or support.”


A classic example is when developers assume always-on connectivity. “The network is not a static monolith that never changes,” one ops staffer noted. “We’re planning a data center network upgrade. It will require disconnecting every server and reconnecting them to the new switches.” That could cause some apps to think the entire world has ended and crash in an untidy heap.

Would you have included different magic spells?

Submission + - Google's Ray Kurzweil wants to live forever, and he thinks it includes nanobots (

Esther Schindler writes: Whatever else he is, Ray Kurzweil is undeniably fascinating, with intriguing predictions about the future — some of which might be accurate. In a Playboy interview, he discusses life extension and technology, as well as how he thinks they'll be connected.

When people talk about the future of technology, especially artificial intelligence, they very often have the common dystopian Hollywood-movie model of us versus the machines. My view is that we will use these tools as we’ve used all other tools—to broaden our reach. And in this case, we’ll be extending the most important attribute we have, which is our intelligence.

Part of what I like is that he sees ways to use technology for good and not for evil:

By the 2030s we will have nanobots that can go into a brain non-invasively through the capillaries, connect to our neocortex and basically connect it to a synthetic neocortex that works the same way in the cloud. So we’ll have an additional neocortex, just like we developed an additional neocortex 2 million years ago, and we’ll use it just as we used the frontal cortex: to add additional levels of abstraction. We’ll create more profound forms of communication than we’re familiar with today, more profound music and funnier jokes. We’ll be funnier. We’ll be sexier. We’ll be more adept at expressing loving sentiments.

Great read.

Submission + - Microsoft is really trying hard to play nice with Linux and open source. Really.

Esther Schindler writes: They're trying, honest they are. In 2016 alone, writes Steven Vaughan-Nichols, Microsoft announced SQL Server on Linux; integrated Eclipse and Visual Studio, launched an open-source network stack on Debian Linux; and it's adding Ubuntu Linux to its Azure Stack hybrid-cloud offering.

That's all well and good, he says, but it's not enough. There's one thing Microsoft could do to gain real open-source trust: Stop forcing companies to pay for its bogus Android patents.

But, there's too much money at stake, writes sjvn, for this to ever happen. For instance, in its last quarter, volume licensing and patents, accounted for approximately 9% of Microsoft's total revenue..

What say you? Has Microsoft become a good open-source citizen? Do you think it's possible for the company to do so?

Submission + - 8 ways to become a kick-ass programmer

Esther Schindler writes: We all want to get better at our jobs (whether it's software development or something else), but how do you go from "good" to "great"? Too many people aim for improvement without any sense of how to get there. Esther Schindler offers eight actionable guidelines that can act as a flowchart to improving your programming skills, such as "Stop trying to prove yourself right" and "'The code works' isn’t where you stop; it’s where you start."

Submission + - 11 Things Computer Users Will Never Experience Again

Esther Schindler writes: Why sure, who has resist geek nostalgia? Because "kids these days" only know about all-in-one computers, wherein you can destroy thousands of dollars of equipment by pouring a cup of coffee into a laptop keyboard. But, O Best Beloved, once upon a time, microcomputers weren't all-in-one devices. They were put together from standalone components, each with its technical merits. And we had to know all about every one of them. So take a short trip into the WayBack machine — via this collection of old computer hardware ads and photos of rats-nests of cables — to remind yourself how much better things are today.

Slashdot Top Deals

Algol-60 surely must be regarded as the most important programming language yet developed. -- T. Cheatham