snydeq writes: Good-bye, programming peers; hello, power to abuse at your whim, writes Bob Lewis in a send-up of an all-too-familiar situation: The engineering colleague who transforms into a greasy political manipulator upon promotion into management. 'It’s legendary: A CIO promotes his best developer into a management role, losing an excellent programmer and gaining a bad manager. The art of management isn’t so much about assembling a dream team, helping others be successful, or solving technical problems. It’s about aligning everything you do in service of the business—the business of yourself.' What tales do you have of colleagues who broke bad all the way to the top?
snydeq writes: InfoWorld's Peter Wayner takes a long-term view of today's trends in programming to give a sense of where programmers should place their career bets in the years ahead. 'Now that 2017 is here, it’s time to take stock of the technological changes ahead, if only to help you know where to place your bets in building programming skills for the future. From the increasing security headache of the internet of things to machine learning everywhere, the future of programming keeps getting harder to predict.' How do you see technologies impacting the work of programming in the years ahead?
snydeq writes: 'It’s been said that the uncharted territories of the old maps were often marked with the ominous warning: “Here be dragons.” Perhaps apocryphal, the idea was that no one wandering into these unknown corners of the world should do so without being ready to battle a terrifying foe,' writes InfoWorld's Peter Wayner in a roundup of seven gnarly corners of the coding world worthy of large markers reading, 'Here be dragons.' 'Programmers may be a bit more civilized than medieval knights, but that doesn’t mean the modern technical world doesn’t have its share of technical dragons waiting for us in unforeseen places: Difficult problems that wait until the deadline is minutes away; complications that have read the manual and know what isn’t well-specified; evil dragons that know how to sneak in inchoate bugs and untimely glitches, often right after the code is committed.' What are yours?
snydeq writes: Whoever said working hard is a virtue never met a programmer, writes Peter Wayner in his roundup of tools and techniques that prove the power of lazy programming. 'Coders who ignore those “work hard, stay humble” inspirational wall signs often produce remarkable results, all because they are trying to avoid having to work too hard. The true geniuses find ways to do the absolute minimum by offloading their chores to the computer. After all, getting the computer to do the work is the real job of computer programmers.'
snydeq writes: The creator of Linux talks in depth about the kernel, community, and how computing will change in the years ahead, in an interview commemorating the 25th anniversary of Linux. 'We currently have a fairly unified kernel that scales from cellphones to supercomputers, and I've grown convinced that unification has actually been one of our greatest strengths: It forces us to do things right, and the different needs for different platforms tend to have a fair amount of commonalities in the end,' Torvalds says. Read the interview for Torvalds' take on OS updates, developing for Linux, the competition, containers, and more.
snydeq writes: Paul Venezia offers an eyewitness account of the rise of Linux and the open source movement, plus analysis of where Linux is taking us now on its 25th anniversary. 'I walked into an apartment in Boston on a sunny day in June 1995. It was small and bohemian, with the normal detritus a pair of young men would scatter here and there. On the kitchen table was a 15-inch CRT display married to a fat, coverless PC case sitting on its side, network cables streaking back to a hub in the living room. The screen displayed a mess of data, the contents of some logfile, and sitting at the bottom was a Bash root prompt decorated in red and blue, the cursor blinking lazily,' Venezia writes. 'Those enterprising youths were actively developing code for the Linux kernel and the GNU userspace utilities that surrounded it. At that time, this scene could be found in cities and towns all over the world, where computer science students and those with a deep interest in computing were playing with an incredible new toy: a free “Unix” operating system.' What's your personal history with the rise of Linux?
snydeq writes: Cheaper, faster, better side effects — sometimes a bad idea in programming is better than just good enough, writes InfoWorld's Peter Wayner. 'Some ideas, schemes, or architectures may truly stink, but they may also be the best choice for your project. They may be cheaper or faster, or maybe it’s too hard to do things the right way. In other words, sometimes bad is simply good enough. There are also occasions when a bad idea comes with a silver lining. It may not be the best approach, but it has such good side-effects that it’s the way to go. If we’re stuck going down a suboptimal path to programming hell, we might as well make the most of whatever gems may be buried there.' What bad programming ideas have you found useful enough to make work in your projects?
snydeq writes: InfoWorld's Roger Grimes lends insight on how to recognize the signs of your child's involvement in malicious online activity before the authorities do — and offers advice on how to help them direct their skills and curiosity into a more positive (and ethical) direction. The advice is based on Grimes' personal history helping reform his stepson, a former hacker, and in mentoring a number of other young ex-hackers as an IT security veteran. 'Hacking can provide a new world of acceptance and empowerment, especially for smart teenagers who are not doing all that well in school, are bored, or are getting harassed by other teens or by their parents because they "aren't working to their full potential." In the hacking world, they can gain the admiration of their peers and be mini-cyber rock stars. It's like a drug for them, and a good percentage can turn permanently to the dark side if not appropriately guided.'
snydeq writes: InfoWorld's Bob Violino offers several hard-learned lessons of devops implementations gone awry. 'There are plenty of examples of how devops works well and delivers tangible improvements for companies in a variety of industries. But sometimes it doesn't work well. Things can go wrong with devops just as they can with any other aspect of IT. Following are some examples of devops initiatives that failed on at least some level and what the organizations involved did to address the problems or prevent them from happening again.'
snydeq writes: Ever wonder what motivates people who swindle others on Craigslist? Roger Grimes did, so he set up a fake Harley Davidson ad on Craigslist, and requested an interview with each scammer who replied to the ad. One agreed, and the man's answers shed light on the inner world of Craiglist scamming: 'If you mean how often I make money from Craigslist, it depends on the day or week. Many weeks I make nothing. Some weeks I can get five people sending me money. But I respond to a lot of ads to get one email back. I’m not only doing Craigslist — there are many similar places. I haven’t counted, but many. It takes many emails to get paid. That’s what I mean. Some weeks I lose money. It’s harder than most people think. But I don’t have to go into a place at a certain time and deal with bosses and customers. I can make my own time.'
snydeq writes: Misconceptions and 'best practices' may have your team spinning wheels rather than continuously churning out productive code, writes InfoWorld's Steven Lowe in a round-up of agile practices gone wrong. 'The problem with most approaches to agile is not a problem with agile; it's a problem with Agile, the Capitalized Methodology. Agile isn't a methodology. Treating it as one confuses process with philosophy and culture, and that’s a one-way ticket back into waterfall — or worse.'
snydeq writes: Tools masquerading as languages, maddening syntax, dusty code that won’t die — InfoWorld's PeterWayner discusses seven programming languages we love to hate even though we can't live without them. 'From Gödel and Turing, we’ve learned that logical mechanisms have edges where scary things occur. Sure, maybe it’s our own fault, we humans, for misusing or misprogramming. But if the programming languages force our brains into weird yoga poses, it’s hard not to blame them for our ills,' Wayner writes. 'And we often can’t do anything about it. The installed base may be too large for us to jettison the language that irks us. The boss may love a stack so much he can’t hear the screams coming from the cubicle farms. The cruel truth is that there may be no better options.' What languages have you shaking your fists at the console?
snydeq writes: InfoWorld's Dan Tynan offers an inside look at how high-tech software vendors such as Adobe, Oracle, and IBM play hardball over software licensing, pushing customers to 'true up' to the tune of billions of dollars per year — and using the threat of audits as a sales tool to close lucrative deals. 'When it comes to software audits, the code of omertà prevails,' Tynan writes. 'It’s not a question of whether your organizations’ software licenses will get audited. It’s only a question of when, how often, and how painful the audits will be. The shakedown is such a sure thing that nearly every customer we contacted asked us to keep their names out of this story, lest it make their employers a target for future audits.'
snydeq writes: Youth may be what HR wants, but nobody bangs out code like a longtime programming pro, writes InfoWorld's Peter Wayner in a second look about what we can learn from our programming elders. 'Alas, the computer industry has a strange, cultish fascination with new technologies, new paradigms, and of course, new programmers,' Wayner writes. '[But] programming geezers have valuable wisdom you can’t absorb simply by watching a TED talk on YouTube or fast-forwarding through a MOOC. They understand better how computers work because they had to back when computers had front panels with switches. They didn’t have the layers of IDEs, optimizing compilers, and continuous integration to save their bacon. If they didn’t build it right from the beginning, it wouldn’t run at all. The young punks won’t know this for years.'