It's ironic, but my workplace is not the better place to work.
I'm a programmer. I don't do any sort of intensive physical handwork; I work with my brain, in fact, my job is thinking; when there is a problem I have to think about a solution, and I need to concentrate to find the most suitable one. And in order to concentrate I need silence, but that's something very unusual at my office (in fact, it's something very unusual at every office).
Because of the noise, many times I end up working with background music, but that only works for me when the task I'm performing at that moment is mostly mechanical, e.g., building a new binary release and uploading it to the versioning system. But when I really have to concentrate I do need silence and turn the music off. As soon as I quit my headphones I start noticing workmates conversations, incoming phone calls, a motorbike at the street, the printer,... the office is full of disrupting noises.
Something has to be done about noise at the office. I'm not claiming for a "noise police" but I'd like to promote a "culture of silence". And I think some little steps can be made in that direction. For example, everyone should silence the mobile phone. Usually, the first thing I do when arriving at the office is to silence my phone and leave it between the screen and the keyboard, that way, if someone phones me the phone screen flickers and I'm the only one who notices it.
Do you have any other little solutions to encourage silence and achieve a better workplace?
Software Development Thoughts
Some of my thoughts about software development.
Written by Manuel Fernández Sánchez de la Blanca
lunes, 6 de septiembre de 2010
miércoles, 25 de agosto de 2010
Is your name googeable?
I've just finished reading Linchpin. Are you indispensable?, by Seth Godin. The book is about the importance of not being like the rest of the people, but being your own brand, an unique brand. The author states our goal should be becoming irreplaceable.
Ok, that's the goal but, how can we achieve it? Godin says there aren't any stablished rules, nor scripts to follow, nor maps,... that everyone must find his or hers own way; not of much help. But he gives a basic start point: are you on Google's first page of search results? and, what does it appear when you type your name in the search box and click "Search" button? Is it good or bad?
I made the test and, to be honest, I am quite satisfied with the result. I never cared about it before and my name populates the two first pages (here's a tip: double-quote your full name). If you search my name (it's below the blog's title) you'll see my LinkedIn profile and questions and comments I made in programming forums. Now, I'm more interested in improving my what people can find about me, my "web presence".
Today, I was telling a workmate about all of these and he said "You're lucky. For me, it's much more difficult, my name is too common". I hadn't think about it, but it's true. My second surname (Sánchez de la Blanca) is long and rare. However, his full name is quite common, at least here in Spain and, I'm afraid, in Latin America too. We searched his name and there were really a bunch of results including his name, but none of them was about him.
How many "Juan García"s (not his real name) or "John Smith"s do exist? -- at least we, Spanish, have it easier than in another countries, we have two surnames--. How will people with very common names solve this problem? Nicknames?
Ok, that's the goal but, how can we achieve it? Godin says there aren't any stablished rules, nor scripts to follow, nor maps,... that everyone must find his or hers own way; not of much help. But he gives a basic start point: are you on Google's first page of search results? and, what does it appear when you type your name in the search box and click "Search" button? Is it good or bad?
I made the test and, to be honest, I am quite satisfied with the result. I never cared about it before and my name populates the two first pages (here's a tip: double-quote your full name). If you search my name (it's below the blog's title) you'll see my LinkedIn profile and questions and comments I made in programming forums. Now, I'm more interested in improving my what people can find about me, my "web presence".
Today, I was telling a workmate about all of these and he said "You're lucky. For me, it's much more difficult, my name is too common". I hadn't think about it, but it's true. My second surname (Sánchez de la Blanca) is long and rare. However, his full name is quite common, at least here in Spain and, I'm afraid, in Latin America too. We searched his name and there were really a bunch of results including his name, but none of them was about him.
How many "Juan García"s (not his real name) or "John Smith"s do exist? -- at least we, Spanish, have it easier than in another countries, we have two surnames--. How will people with very common names solve this problem? Nicknames?
domingo, 22 de agosto de 2010
Programmers who don't like programming.
There is something about software developers I cannot understand: the high amount of them who don't like programming. I am not talking about those who don't like their current company; I am not talking about those who don't like their current project or task; I'm talking about those developers who don't like programming at all.
They usually go to work just to keep the chair warm, waiting for the day to pass. They take the tiniest opportunity to stop working and go to talk with another employee; if someone enters the door or an unexpected sound occurs, they have something to begin a ten minutes conversation. The never put any enthusiasm in what they do at work.
I understand that people performing heavy physical jobs are tired of them, but they don't usually have the chance to work on something else. But, programming? The great majority of programmers went to university to study about it. But why did they go if they don't like it? Programming is quite difficult and demands being always reading and learning about new technologies, which is a big effort. But why do they work as programmers if they don't want to make that effort? They prefer to stay in a job which, almost certainty, makes them unhappy instead of working on a totally different thing.
It makes no sense for me.
They usually go to work just to keep the chair warm, waiting for the day to pass. They take the tiniest opportunity to stop working and go to talk with another employee; if someone enters the door or an unexpected sound occurs, they have something to begin a ten minutes conversation. The never put any enthusiasm in what they do at work.
I understand that people performing heavy physical jobs are tired of them, but they don't usually have the chance to work on something else. But, programming? The great majority of programmers went to university to study about it. But why did they go if they don't like it? Programming is quite difficult and demands being always reading and learning about new technologies, which is a big effort. But why do they work as programmers if they don't want to make that effort? They prefer to stay in a job which, almost certainty, makes them unhappy instead of working on a totally different thing.
It makes no sense for me.
martes, 17 de agosto de 2010
Don't break the oath.
When designing a distributable API, even if it is going to be distributed only inside you company, you must take special care on the public interface. The public interface is the entry point to the API, it says what can and cannot be done and which result the user can expect in case she provides appropriate input. It's a contract, an oath between you, the API developer, and the users.
The public interface should never be changed, except for adding new methods. If you change a public method's signature or, even worse, delete a public method, every source code using the API will break when updating it, and a lot of developers will dream about you and all your family.
So, what can you do if you detect a flaw in you API public interface? Well, the first thing should be keeping that public interface to the minimum; don't make a method public nor protected if you can avoid it; that way, you will have fewer things to worry about later. The second thing is: don't change a public method signature. You should mark it as deprecated and override it. If overriding is not possible, make a new method, but never never never do change the original one.
Be a developer of your word, don't break your oaths.
The public interface should never be changed, except for adding new methods. If you change a public method's signature or, even worse, delete a public method, every source code using the API will break when updating it, and a lot of developers will dream about you and all your family.
So, what can you do if you detect a flaw in you API public interface? Well, the first thing should be keeping that public interface to the minimum; don't make a method public nor protected if you can avoid it; that way, you will have fewer things to worry about later. The second thing is: don't change a public method signature. You should mark it as deprecated and override it. If overriding is not possible, make a new method, but never never never do change the original one.
Be a developer of your word, don't break your oaths.
sábado, 14 de agosto de 2010
Is it a number?
Today, while browsing http://stackoverflow.com/, I found someone asking about how to store a phone number in an integer variable while not losing the leading zeros, i.e., he stored the value 02478829 in an integer, but when printing he got 2478829. Some users gave him "tricks" like using number formatters, implementing his own PhoneNumber class which takes care of it,... That's wrong!
Yes, it's true that the user can achieve his goal with the provided tricks, but the problem is more than a technical issue. The problem is misunderstanding what a phone number really is.
A phone number is not really a number, there is no sense in performing arithmetics operations with them. Phone numbers are codes, which usually happens to be represented like numbers, but that's just a convention. Maybe, in the future, phone numbers include letters too; in fact, international prefixes begin with a + (plus sign) or with 00, indistinctly. So, the adequate way to store a phone number is using a String.
Before coding, it's important to do some thinking about the nature of the things we want to translate into software, so we can choose the most suitable structures to represent them.
Suscribirse a:
Entradas (Atom)