Language Wars

Rival languages are welcome.

I'll crush you.

-- Matz at rubykaigi 2011

What killed smalltalk

"What killed smalltalk? It was just so easy to make a mess."

Ward Cunningham

Looking for the right excuse

This is the first warning sign that a project is in trouble. Quietly, our subconscious starts looking around for an excuse, deniability and someone to blame. It gives us confidence and peace of mind.

People who have a built-in all-purpose excuse (middle child syndrom, wrong astrology sign, some slight at the hands of the system long ago) often end up failing - they have an excuse ready to go, so it's easier to back off when the going is rough.

Here's an alternative to the excuse-driven life: What happens if you relentlessly avoid looking for excuses at all?

-- Seth Godin

What is TDD about?

"TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps. Would I code day-to-day with steps this small? No. But when things get the least bit weird, I'm glad I can. Try teeny-tiny steps with an example of your own choosing. If you can make steps too small, you can certainly make steps the right size. If you only take larger steps, you'll never know if smaller steps are appropriate."

-- Kent Beck

Think before commenting - Best Practices for Commenting your code

Whenever you think, “This code needs a comment” follow that thought with, “How could I modify the code so its purpose is obvious?”

Talk with your code, not your comments.

-- 5 Best Practices for Commenting Your Code

Don't wish it were easier

"Don't wish it were easier. Wish you were better."

-- Jim Rohn

Failure is progress

Failure is progress. Now we have a concrete measure of failure. That's better than just vaguely knowing we a re failing. Our programming problem has been transformed from "give me multi-currency" to "make this test work, and then make the rest of the tests work." Much simpler. Much smaller scope for fear. We can make this test work.

-- Kent Beck, about a failing test

Bored People Quit

Much has been written about employee motivation and retention. It’s written by folks who actively use words like motivation and retention and generally don’t have a clue about the daily necessity of keeping your team professionally content because they’ve either never done the work or have forgotten how it’s done.

-- rands

Work from anywhere

"Work from anywhere is a lifestyle that will become more common as time goes by. This has many implications, the most obvious one is that you can choose a great place to live at, and this is not something to ignore. But there is the other side of it: if you need to put 10k hours in something, it needs to be something you like, and chances are, that the best people doing whatever is that you like will not be seating in the next cubicle.

Working from anywhere works both ways, for you and the people you’re working with. To work with the best people, work with them no matter where they are: they will not move to your area just because. So, choose what you want to work on, you can work on anything from anywhere with anyone, at least when we’re talking about software development."

-- Java Man

Time for a workflow audit

Go find a geek. Someone who understands gmail, Outlook, Excel and other basic tools.

Pay her to sit next to you for an hour and watch you work.

Then say, "tell me five ways I can save an hour a day."

Whatever you need to pay for this service, it will pay for itself in a week.

-- Seth Godin @ goo.gl/xHQHz

The Curse of the Silicon Valley

[...] the Curse of the Silicon Valley is that great engineers are often promoted to leadership for their hard work. While many succeed in this role, an equal part fails because the skills required to lead are vastly different than the ones required to be an engineer. The Curse is that we’re often placing our most valuable engineers in a role where they’re predisposed to fail.

[...] there’s a large population of immensely talented engineers that should not be leaders. There is no amount of training that would make up for the talent we’d extinguish by teaching them how to write annual reviews.

-- rands @ goo.gl/YYFCs

Who cares if the computer takes a few more cycles to compile something?

"Someone will try to read your code in a few months' time to make some changes. We easily forget that extra user of the code, yet that user is actually the most important. Who cares if the computer takes a few more cycles to compile something? It does matter if it takes a programmer a week to make a change that would have taken only an hour if she had understood your code."

-- Martin Fowler in Refactoring

Is renaming worth the effort?

"Is renaming worth the effort? Absolutely. Good code should communicate what it is doing clearly, and variable names are a key to clear code. Never be afraid to change the names of thing to improve clarity. (...)

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Code that communicates its purpose is very important. I often refactor just when I'm reading some code. That way as I gain understanding about the program, I embed that understanding into the code for later so I don't forget what I learned."

-- Martin Fowler in Refactoring

[PT-BR] O que você prefere?

"Sempre trabalhe como se um novo membro pudesse entrar no projeto a qualquer instante.
O que você prefere?
Sentir orgulho e mostrar código de qualidade ou ter que dar desculpas para cada trecho de código em que o novato puser as mãos?
A qualidade não é negociável."

- zehzinho

People change slower than they think.

-- Rands in Response twitter.com/rands

I’ve been doing hiring for quite some time now and I’m still astonished how few candidates want to see their work space and colleagues. You will spend more time there and with them than at home. Are there windows? Is lighting nice? Two 24″ flat panels? Decent computers?

-- Stephan Schmidt @ http://goo.gl/3LvOI

The value of increased system quality can’t be diminished

"The value of increased system quality can’t be diminished. Allowing slap-happy programmers to run roughshod over a system will drag down future productivity, compounding costs every minute that it’s allowed to continue. What do you really know about the quality of product your team members produce?"

-- Jeff Langr & Tim Ottinger

Why do you code, test, listen and design?

"You code because if you don't code, you haven't done anything.
You test because if you don't test, you don't know when you are done coding
You listen because if you don't listen you don't know what to code or what to test.
And you design so you can keep coding and testing and listening indefinitely.
That's it."

-- Kent Beck

About comments - Five best practices

"Comments are codesmell

Comments are little signposts in your code explaining it to future archaeologists that desperately need to understand how 21st century man sorted lists of purchase orders."

-- 5 Best Practices for Commenting Your Code

Personal Time Management and Agile

"What if you’re waiting for that compile or CI build to complete, what do you do? Press Alt+Tab and go read a blog entry or 5 for the next few minutes? It’s easy for that few minutes to turn into 10 or 20. And yet the compile itself only took 3 minutes to complete. That’s a lot of wasted time and a definite mental context switch you have to deal with. Yet watching a compile is mind numbingly dull. So why don’t you think about some refactoring you could apply, or the next test that you could write, or the design for the next task that you’ll get started on next. There’s plenty of non-keyboard activities you can do that keep you focused on the task at hand and not chasing squirrels."

-- Richard Banks