Summary: accepting objections is one of the most valuable skills a manager can learn, and yet the role models we get fail to highlight this
As many other geeks, I have always been fascinated by aviation and its history. One of the things that kept intriguing me was a simple question: what could cause the dramatic decline in the number of plane crashes attributable to pilot error?
I recently found an answer to that question in a How We Decide by Jonah Lehrer, crediting two different factors for the increased safety.
Looking for a job in the tech sector is a challenge. A lot has been written about the process itself and its quirks, ranging from programming puzzles to whiteboard interviews. However, there are still a few details that are often overlooked by most companies and can make a significant difference for perspective applicants.
Even when recruiters try to do all they can to make the application and hiring process as easy as possible, it is extremely common that the jobs or careers sections of their websites do not contain all the information applicants would need to make an informed choice. And when the information is present, it is often arranged in a way that is not effective or clear enough.
This article contains a selection of the most frequently neglected details; information that is valuable for applicants but, for a combination of good and bad reasons, is often hidden or not present at all.
If your company is hiring, try to figure out how easily a candidate can find an answer to these questions by looking at your website:
If the answer to any of these questions does not come immediately, the careers section of your website may be cleverly designed and communicate a great image of your company, but it is probably disconnected from the needs of its users: the people you are trying to hire.
As I already had the chance to write in a previous post, I really appreciate distributed version control systems; I consistently use them at work and for many of my side projects. I typically switch between git and mercurial repositories, with the former being my primary choice lately, and there is one specific command that always troubles me when I do that: pull.
There is one wonderful piece of inconsistency between the two systems, one that often leads to confusion for new adopters and unnecessary hassle for experienced users. If you are familiar with both systems, you may already be thinking about the culprits. If you are not, you may be more careful about the pull and fetch commands after reading this post.
Last Friday, a blog post on Channel 9 announced Achievements for Visual Studio, an extension for the Microsoft IDE that tracks the actions of programmers as they write code and unlocks badges based on their behaviour.
Now that the concept of Gamification has become (even too much) mainstream, it is not surprising that this is not the first time an idea like this is proposed. Jason Rudolph has published an excellent blog post about programming achievements. Websites like coderwall already inspect source code repositories on GitHub and others in order to build achievement-based profiles for coders. There even is an earlier project, called Strokes, that added achievements and challenges to Visual Studio.
Introducing mainstream achievement support right within the IDEs, however, can have a stronger effect on the way we write software, as those tools can inspect code right while we are writing it. The strong link between action and reward lead to a stronger feeling of accomplishment when we earn those achievements, and programmers are likely to be receptive towards game mechanics (most of us have a background as gamers). But there is more than that.
While issue trackers originate as tools to manage projects more effectively, during the last years of work I have been through some situations where their misuse backfired.
Tools originally conceived to improve workflows and project lifecycle became a significant burden for the team using them, occasionally making difficult situations even worse.
This post is a collection of bad patterns I have seen happening. It is not a survey of all the possible situations that can occur. It is not meant to be an argument against issue trackers (if it tells anything, it will probably be about the teams I was part of), but rather an overview of things that went wrong because of the way a particular team used those systems.
In retrospective, most of the problems were due to a lack of discipline and experience of the project teams, and they are less frequent – if present – in a team of seasoned professionals. But, while training and education can certainly help, I would love to consider a different aspect: the issue tracking systems were not helping as they could have.
I still remember one of the most interesting questions I have been asked last year when I was interviewing for a Software Engineering position:
How would you explain to a 12 years old what an API is?
At first, I was surprised: it certainly sounded like an uncommon question for a Software Engineering interview. And yet I tried to answer as best I could, trying to come up with a concise definition that could convey what I meant, but without assuming any specialist knowledge about computers and software.
As I progressed with the interview, it became evident what kind of ability my interviewer was trying to test.
There is one thing that often frustrates me and yet it happens quite often: I am driving and listening to the radio, and at some point they play a song I like. I would love to buy it, but I don’t know neither the song title nor its author.
Sometimes radio announcers say it immediately after, but some other times (most, actually) they do not, leaving no alternatives other than firing up Shazam to discover what is the song you like. And, well, if you are driving, that generally is a poor choice.
Now, just think about how we could redesign that process to make it more effective, using present-day technology and infrastructure.
Here is one possibility I would love to see happen.
I have received my Kindle as a gift at the beginning of this year, and it quickly became my favorite gift of all time.
That can be quite surprising, knowing me. I own many different devices, gadgets and computers, but I have always been fond of the smell and feeling of paper books. Knowing that, some people were ready to bet that I would use the Kindle for just a few days and neglect it shortly after for something else (e.g. my iPad).
I must admit that I am sure this is exactly what would have happened with any other e-reader device. My experience with the Kindle, however, was (surprisingly) awesome, and it due to reasons I didn’t expect.
During the course of the last months, we have seen frequent news of security breaches, with many websites falling victims of malicious attacks. While this by itself is not a news, the frequency and scale of this kind of attacks hardly passes without notice.
Sony’s example is probably the most visible example of this trend, as Kevin Mitnick points out.
I lost count of all the Sony attacks. CORRECTED: Sony Scoreboard: Hackers 12, Sony 0, Source: http://tinyurl.com/6dcugje— Kevin Mitnick (@kevinmitnick) June 5, 2011
But they are not the only ones: the attacks on Citigroup and security company RSA are even more alarming. If even those companies that should be dealing with security issues every day are not impenetrable, chances are everyone’s data is at risk. Or, at least, that’s the message that most of the newspapers appear to be conveying.
While it’s easy to dismiss those people as fools, those facts should teach us something different: there is no such thing as a secure system.