It has been a while since the last time I did some coding in my OPP project, and today I am returning. One thing that is always problematic for developer is creating the context in which they are developing. Experiments have shown that an uninterrupted task takes twice as long and has twice as many errors as an uninterrupted task, and that it takes about 10-15 minutes for a programmer to start “working” after an interruption. And an interruption of more than 2 weeks? sometimes it takes me a lot more than 10-20 minutes to pick things up from where I left them.
Thankfully, the Eclipse ecosystem has created a great tool to create context when we are developing, so it is easier and faster to get back to work: the Eclipse Mylyn project.
Mylyn creates a “task-focused” interface which monitors your programming activity. The main focus of the interface is a task, the unit of work that you are currently executing. This is the first step in creating context, since it already focuses on what you were doing the last time you left the workbench. The second thing that this Mylyn gives is a filter for your project view. When you activate the task focused interface, Mylyn filters the project view and leaves only the elements that are “interesting” for your current task. Going one step further, it can also create focus in the java editor by folding all code that it is not “interesting”. The third you get (when you are using github, like I am) is that the task is automatically connected to your github commit, so you can see which commits were done when the task was active.
Another great tool, for a great platform. Happy coding.
Survivor bias is defined (by wikipedia) as “the logical error of concentrating on the people or things that survived some process and inadvertently overlooking those that didn’t because of their lack of visibility“. This subject came to my mind after a long talk with a friend that works in one of the “cool” companies around here (at least for those not in those companies). A company that has Culture. But he is somewhat tired of working there, even if the company has Culture. Like me, he is subscribed to many tweet feeds and RSS feeds, and we both noticed that there is lately a lot of talk about Culture and how this makes or breaks a company. But I think that we have here a very good case of survivor bias playing on us. How many start-ups are there that have great culture but still fall and burn? Probably most of them. And there are very big companies that “don’t have a great culture” but are still making a lot of money, paying a lot of money to developers, and growing every day.
So beware of investing too much on your culture, and not enough on your product. Culture may help you keep great developers, and makes people happy, and that is VERY important. But don’t think that if you have a great culture, you will succeed.
I’m repeating myself, so I guess I will stop here. Have a great culture
I have written a couple of times about programming language and how they are only part in the large toolbox (or arsenal) used in software development.
Another very important tool are IDEs (well, there are some that say that real programmers don’t use IDEs, but I’m not one of them, although I really like emacs keybindings). But seriously, a good IDE can make the difference between a good and bad programming experience. For Java development I use the Eclipse IDE, and here is a list of the things that I get from it:
- Autocomplete – Do I really have to remember all the methods of that class? My memory is already full with pictures of funny animals. And it also will also help me fill the parameters if I have appropriate variables available. And it matches a return type if I am assigning a function to a variable. The Juno version of Eclipse includes an event better autocompletion – Code Recommenders, which analyzes your code and recommends you the best method based on the usage pattern detected in your code. Sweet!
- Refactoring – I wrote a post on the subject a while ago. Another thing you don’t need to worry about (you already have enough).
- Source Control – Why do you have to go somewhere else to do source control? You finished editing, check the changes, add the files to the commit, write a comment, commit, and push! And never leaving your IDE.
- Reduction of Learner’s Pain – IDEs make life easier for programmers when they are starting in the language. They don’t have to learn what command compiles, builds, executes, etc. They just click here and here and things work. This DOES NOT mean that they don’t have to learn those details later, but it is better to take things one step at a time.
- Visual Debugger – Have you ever tried debugging an application in a textual debugger? I have, and trust me, it is not fun. It may be a good experience for life, but not something you want to do every time you want to analyze how some code works, or why your program behaves in a completely different way from what you thought.
- Centralization – doing all things in the same platform (when things are done right) saves time and headaches. I write the code, compile it, test it, commit it, check it out, comment it, debug it, and all in one place, with a unified interface.
This is not to say that programmers can’t do great stuff using only vi and the command line. I’m sure they can. But why make life harder? Software is the tool you use to solve a problem, not the problem itself. So use your time and brainpower to solve the problem, and let the tools give you a hand.
This post was inspired by this article on the I Programmer web site. They have a very good newsletter, with hidden pearls now and then. I also found this interesting article on the same topic. The war is still on.