Left-liberal totalitarism.

This is the text that got a software engineer fired: Google's ideological echo chamber

Google's Ideological Echo Chamber (pdf)

Is there any different between Communist Russia circa 1970 and today's Silicon Valley? I can't think of any.

Real "Pair Programming"

Looks like North Korea is leading in introducing Pair Programming to the Agile software development teams:

Code reviews

Some thoughts I have on how to organise code reviews when you are a team leader (at least this is what I try to follow):      

• Code changes need to be reviewed before merging it to Master branch and before testing.

• As a leader, code review all changes done by other people, but ensure that everybody else is involved in code reviews (others don't have to code review everything, but ensure that everybody does some code reviews).

• Ensure that your code is always code reviewed by your team members and always react positively when a problem is found with your code, make changes to the code you written based on advise of the junior team members. This will ensure that the team members don’t see a problem someone found in their code undermines their position.

• Don’t nitpick, accept that different people write code differently. Insist on modifications to the work you reviewing only in a case of a bug or if the change that does not fit with overall design. Be polite and try to explain the reason.

• Have coding standards and ensure that tools for automatic code formatting are used (in case of Java IDEs both Eclipse and IntelliJ allow this and you can copy formatting rules between computers — when someone joins the company, just send them the formatting setup file). This will prevent “formatting wars” and comments about formatting.

• Have static code analysis tools run as part of CI (e.g. Sonar), this will reduce disagreements — psychologically it is easier to accept criticism from a machine then from a fellow developer.

Joys of legacy code

I have recent stumbled across this text: http://typicalprogrammer.com/the-joys-of-maintenance-programming/

Somehow it resonated with me. I started working as a developer in early 1990s and I have done it all – “green field”, maintenance, you name it, I had my share of creating software from scratch, I had experience of re-architecting existing software and I experienced fixing bugs in code that was written before I learnt how to program in a language nobody wanted to learn anymore.

What I have noticed that as time goes I enjoy maintenance development more and more.

Often I find developing software from scratch to be too easy and boring. I find there is more challenge in making legacy code “great again”.

I can understand why those, who have never had a chance to do it, are dreaming of “green field development” and writing systems from scratch using latest and coolest technologies and methodologies. Many developers believe that if only they were given a chance, the software they will design will be much better then whatever they work with. Unfortunately, it is not the case…

I would say that the majority of developers are able to write a new application that will more or less do what is required. But in most cases, couple years down the line, their code will probably be found by “the next guy” to be even worse then the one they love to criticise. I think only a minority of programmers can actually make an old code with layers and layers of changes to be nice again.