Rival languages are welcome.I'll crush you.-- Matz at rubykaigi 2011
Friday, July 29, 2011
Thursday, July 28, 2011
Wednesday, July 27, 2011
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
Tuesday, July 26, 2011
"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
Monday, July 25, 2011
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.
Friday, July 22, 2011
Thursday, July 21, 2011
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
Wednesday, July 20, 2011
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.
Tuesday, July 19, 2011
"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
Monday, July 18, 2011
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
Friday, July 15, 2011
[...] 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 @
Thursday, July 14, 2011
"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
Wednesday, July 13, 2011
"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
Tuesday, July 12, 2011
"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
Monday, July 11, 2011
Friday, July 8, 2011
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
Thursday, July 7, 2011
"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?"
Wednesday, July 6, 2011
"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.
-- Kent Beck
Monday, July 4, 2011
"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."
Friday, July 1, 2011
"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."