Software developer’s worst enemy

Coding Horror has an insightful article on the software developer’s worst enemy.

[…] the real problem isn’t the code. The code, like a newborn babe, is blameless and innocent the minute it is written into the world. Code isn’t our enemy. You want to see the real enemy? Go look in the mirror. There’s your problem, right there.

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you’ll be.

I know you have the best of intentions. We all do. We’re software developers; we love writing code. It’s what we do. We never met a problem we couldn’t solve with some duct tape, a jury-rigged coat hanger, and a pinch of code. But Wil Shipley argues that we should rein in our natural tendencies to write lots of code
[…]

There are quite a few things which seem obvious, that you can’t really disagree with, but which I also didn’t define or form on my own for some reason.

CakePHP 2.0 released!

I’ve been a bit all over the place these last few days, but I knew that this was coming shortly – CakePHP team released the new and much improved version 2.0 a couple of days ago. There are a lot of changes. And I do mean a lot. Here are some of my favorite:

  • PHP5 support. CakePHP was working with PHP before, of course. But in this release, support for PHP4 was dropped and all code has been updated to utilize PHP5 goodies.
  • Lazy class loading. Previous versions of CakePHP could easily get slow with a lot of models. There were solutions like Containable behavior and others. But it was annoying never the less. CakePHP 2.0 is much improved in this regard. It only loads things that are actually needed and used. That is a huge performance improvement.
  • Improved Console. The new Console is so much better that I’m even considering using CakePHP 2.0 for some of my non-web-based projects. It’s that good!
  • PHPUnit. Previous versions of CakePHP were using SimpleTest framework for unit tests. CakePHP 2.0 switched to the de facto standard PHPUnit. Tests are now easier to write. And integrating CakePHP projects with other Quality Assurance tools should be a breeze.

There are, of course, more changes. These are just the top few that I am particularly glad about.

Also, CakePHP 2.0 release is special to me. It’s been a long while since I participated in the development process of an Open Source project. I usually just report bugs and provide help via forums and blog posts. I did more than that with CakePHP 2.0. I actually wrote a couple of patches that were accepted and merged into this release. They were no rocket science, but a contribution nonetheless.

If you haven’t tried CakePHP before, now is the perfect time to do so. If you have tried older CakePHP versions, you’ll find this one to be much of an improvement. If you have tried it already, please share your thoughts in the comments. Let me know what you think of it.

Dennis Ritchie, RIP


I’ve just learned of yet another great loss – Dennis Ritchie, who passed away a few days ago at the age of 70. It’s difficult to describe his contributions and achievements to non-technical people, but anyone with even a grain of knowledge of computer history and modern affairs can appreciate what this man have done. Here is a quote from the Wikipedia page:

Ritchie was best known as the creator of the C programming language and a key developer of the Unix operating system, and as co-author of the definitive book on C, The C Programming Language, commonly referred to as K&R (in reference to the authors Kernighan and Ritchie).
Ritchie’s invention of C and his role in the development of Unix alongside Ken Thompson has placed him as an important pioneer of modern computing. The C language is still widely used today in application and operating system development, and its influence is seen in most modern programming languages. Unix has also been influential, establishing concepts and principles that are now well-established precepts of computing.
Ritchie was elected to the National Academy of Engineering in 1988 for “development of the ‘C’ programming language and for co-development of the UNIX operating system.”

Thank you Sir for all your hard work. Rest in peace.

Project management tips from Linus Torvalds

Linus Torvalds shares some of his thoughts on software project management in this interview. I have two favorite bits in there. One is on the obsession of the code quality control:

“The other thing—and it’s kind of related—that people seem to get wrong is to think that the code they write is what matters,” says Torvalds. Most software development managers have seen this one. “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”

Just a few years ago I would have completely missed this point. Or argued passionately with it. But not anymore. After spending the last few years working with very dynamic software projects, I realized that no matter how much effort you spend on the code quality control, it will still degrade with time. And even if it becomes horrible and hard to look at, it will still work and you’ll still be able to maintain it. But the time and effort that was lost would have been so much more useful in supporting user requests and improving their experiences.

Even knowing this now, I am still a slave of my habits. I still need to control myself, set tight deadlines, and learn to ignore a lot of things that would have caused me a heart attack back in a day.

The second point that I found interesting in the interview is similar.

I also asked Torvalds about Software Configuration Management (SCM) tools like his own Git version control system. He replied, “I don’t think tools are all that fundamentally  important.”

“Now, what is important is that there’s a good workflow for the project, and tools can certainly help with that,” said Torvalds. “But most projects don’t necessarily really need tools. There’s a lot of projects that simply don’t have enough changes to really require any tools at all for their work flow; if you only have a few hundred patches per release, you can maintain those just about any way you want, including entirely by hand.”

Again, a few years ago (and even sometimes now) I would argue and fight for the perfect setup and ideal toolbox. These days I seem to care less. As long as the work is being done and the project is moving on, I don’t really care which tools are being used. I have my preferences, of course, and I would try to push them through to be used by majority of participants, but I am much more relaxed on this subject than I used to be.

One other thing that I wanted to mention is the difference in perception. In Linus’ world, it seems, changes are always distributed as patches. To the effect that it would even be considered a specialized tool – everyone is using it. And I understand – all of the people with who he works are very experienced technical people and there is indeed no other way. But for the rest of us things aren’t as rosy. On several occasions I worked in a team where people weren’t using any tools. Literally. They had no idea about patches, diff, scripts, merging, version control, any of that. Changes in those projects were maintained by hand. And there would be nothing similar in concept to a release. Which didn’t help.

There was indeed one particular project.  Do you know how I remember it?  I was at one of those PHP conferences somewhere in Europe. And one of the talks I attended was on how to use unit testing during the re-factoring process.  The presentation was filled with examples of ‘horrible’ code which was then surrounded by unit tests and later re-factored into better code.  The code that was presented as ‘horrible’ was some of the best code I’ve seen in my life!  After the presentation I came up to the speaker and showed him the project with which I was involved, which had some truly horrible code.  You should have seen the look on his face… It took him a couple of minutes to compose himself and start thinking on how to work with that nightmare.  He even thanked me and promised that we would include some examples of that crap in the future versions of his talk.

My point here is the difference in perception.  When Linus says that things can be done without any tools at all, and when that guy talked about horrible code, they both, I think, are somewhat spoiled by their surroundings.  I’m sure not everyone even would be able to make sense of a gadzillion tiny little things that Linus uses on a daily basis and doesn’t even consider them as full featured tools.  I’m sure not everyone even would be able to read some of that ‘horrible’ code the other guy spoke about, let alone write something like that (I remember it being OOP, with comments, well-tabulated, etc).  There is a certain minimum level which has to be there.  That minimum level is assumed to be a zero.  But it’s not always there.

 

Average salary for programmer in Togliatti, Russia

Yandex, also known as “Russian Google”, recently introduced a service for salary comparisons across Russia, based on the known job vacancies. This is a handy little tool that provides a lot of insight into how things are in Russia and across. For example, I immediately checked the average salary for a computer programmer in Togliatty – my hometown.

23,000 Russian Rubles approximately equal to 530 Euros. On the same graph, average salaries for Moscow and Saint Petersburg are also indicated – 1,200 EUR and 1,500 EUR accordingly. Unfortunately I don’t have an equal or reliably objective resource for Cyprus, but based on my own knowledge and experience, I’d say at least in Limassol the average salary for a programmer would be somewhere around 2,000 EUR. Moscow’s 1,500 EUR is roughly the minimum, I’d say.

First of all, this graph once again confirms that Moscow and Russia are two different things.  Prices, salaries and opportunities are very different.  Even Saint Petersburg, which is the second richest city in Russia is obviously behind here.  Togliatt’s average salary being almost 3 times less than the one for Moscow clearly indicates the huge difference.

Secondly, this makes me question (not that I haven’t before) all those bright and brilliant mass media reports of how fast the Russian economy is growing and of how well things are improving in the regions.  With 500 EUR being an average salary for a qualified professional – economy has a very long way to go.

Thirdly, it is sad to see how stale the IT industry is in my hometown. The city of almost a million in population has only 55 vacancies for a programmer (according to Yandex only, of course).  And out of those most are C++ and 1C (popular accounting software package) vacancies.  There are a few web developer positions available, but for the city that large these are too few.