Friday, December 9, 2011

There are only two hard things in Computer Science: cache invalidation and naming things.

Wednesday, December 7, 2011

Always design a thing by considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan
~ Eliel Saarinen

Saturday, December 3, 2011


Learning to program teaches you how to think. Computer science is a liberal art.
~ Steve Jobs

Thursday, December 1, 2011

Since tests are the first reuse of your code, if setting up a test is hard.... Yup, that code can't be reused.
~ Sandi Metz

Tuesday, November 29, 2011

Código a gente joga fora, conhecimento não.
Marco Sbrolini


Friday, November 25, 2011

The shortest path to exceeding expectations doesn't necessarily go through meeting expectations
~ Ward Cunningham

Wednesday, November 23, 2011

Fear leads to risk, risk leads to process, process leads to hate… and suffering and Gantt charts.

~ Dan North

Monday, November 21, 2011

Architects are taught to look at buildings, and composers study one another's scores, but programmers - they look at each other's work only when there's a bug to fix; even then, they try to look at as little as possible. We tell students to use sensible variable names, introduce them to some basic design patterns, and then wonder why so much of what they write is so ugly.

~ Greg Wilson



Thursday, November 17, 2011

We are terrified of uncertainty – we would rather be wrong than uncertain

~ Dan North

Wednesday, November 16, 2011

Ward Cunningham being asked about XP:

- Well, your own work. Do you use it?
- Of course not, not always. Well, keep in mind that if you don't try different ways to do things how would I ever come up with XP? The computer is so powerful that you have to keep trying ways that can work.


Tuesday, November 15, 2011

A complex system that works is invariably found to have evolved from a simple system that works
~ John Gall

Monday, November 14, 2011

If we want good, there has to be time to do good.

~ Ward Cunningham




Friday, November 11, 2011

Coders are special

"Coders are special. We are expected to know how to do things we've never done before and estimate how long they will take."

~ Unknown

Thursday, November 10, 2011

What if?

What if software wasn't "made", like we make a paper airplane - finish folding it and fly it away? What if, instead, we treated software more like a valuable, productive plant, to be nurtured, pruned, harvested, fertilized, and watered? Traditional farmers know how to keep plants productive for decades or even centuries. How would software development be different if we treated our programs the same way?

~ Kent Beck

Wednesday, November 9, 2011

Good Judgement by Fred Brooks

Good judgement is the result of experience ... Experience is the result of bad judgement. 
~ Fred Brooks

Tuesday, November 8, 2011

About modern education and programming

It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail and learning to be self-critical?

~ Alan Perlis, Epigrams in Programming

Sunday, November 6, 2011

OO is about Messaging

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is
all about (and it's something that was never quite completed in our Xerox PARC phase).
The Japanese have a small word -- ma -- for "that which is in between" -- perhaps
the nearest English equivalent is "interstitial".

The key in making great and growable systems is much more to design
how its modules communicate rather than what their internal properties
and behaviors should be.
Think of the internet -- to live, it (a) has to allow many different
kinds of ideas and realizations that are beyond any single standard
and (b) to allow varying degrees of safe interoperability between these ideas.



Thursday, November 3, 2011

Tuesday, November 1, 2011

The constant battle

"Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary."

~ Eric Evans

Thursday, October 27, 2011

I will not write crap


I've gone from Dan North's post, to Gil Zilberfeld's to Michael Feather's to Jason Gorman's. It would appear that we, in the software craftsmanship movement have not been clear. I hope this blog clears a few things up.

Why is there a software craftsmanship movement? What motivated it? What drives it now? One thing; and one thing only.

We are tired of writing crap.

That's it. The fat lady sang. Good nite Gracy. Over and out.

We're tired of writing crap. We are tired of embarrassing ourselves and our employers by delivering lousy software. We have had enough of telling our customers to reboot at midnight. We don't want bug lists that are a thousand pages long. We don't want code that grows more tangled and corrupt with every passing day. We're tired of doing a bad job. We want to start doing a good job.

That's ... what ... this ... is ... about. Nothing else.

What we are not doing:

  • We are not putting code at the center of everything.
  • We are not turning inward and ignoring the business and the customer.
  • We are not inspecting our navels.
  • We are not offering cheap certifications.
  • We are not forgetting that our job is to delight our customers.

What we will not do anymore:

  • We will not make messes in order to meet a schedule.
  • We will not accept the stupid old lie about cleaning things up later.
  • We will not believe the claim that quick means dirty.
  • We will not accept the option to do it wrong.
  • We will not allow anyone to force us to behave unprofessionally.

What we will do from now on:

  • We will meet our schedules by knowing that the only way to go fast is to go well.
  • We will delight our customers by writing the best code we can.
  • We will honor our employers by creating the best designs we can.
  • We will honor our team by testing everything that can be tested.
  • We will be humble enough to write those tests first.
  • We will practice so that we become better at our craft.

We will remember what our grandmothers and grandfathers told us:

  • Anything worth doing is worth doing well.
  • Slow and steady wins the race.
  • Measure twice cut once.
  • Practice, Practice, Practice.

I suppose that some people might look askance at our code katas and our code retreats, and our practice sessions. They might think that we're turning inwards and abandoning our customers. They might think that we've given up on the real world and have yielded to the temptation to entertain ourselves. I can see how someone might come to that conclusion.

But they are as wrong as the day is long. We are doing this because we care about the customer. We are dedicating time and effort to being the best that we can be so that our employers will get the best possible value out of us.

Do you think the only time musicians play their instruments is when they are on stage? Do you think the only time that batters hit balls is during games? Do you think the only time lawyers give a closing is at trial? Of course not. These people are professionals; and professionals practice! Professionals study the minutia of their disciplines. Professionals know all the little tricks and quirks. They know the history, the theories, the anecdotes. They know techniques and methods. They know good options and bad options and how to tell them apart. And they know all this stuff because they practice, practice practice.

So when you see someone wearing a green wrist-band that says "Clean Code" or "Test First" or "Test Obsessed", it's not because they've joined a movement, or signed a manifesto, or that they somehow feel superior to everyone else. They aren't participants in a holy war. They aren't trying to join a tribe and huddle around a campfire. The green band is a personal thing. It's a promise made to one's self: "I will do a good job. I will not rush. I will write tests. I will go fast by going well. I will not write crap. And I will practice, practice practice so that I can be a professional."



http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmen

Wednesday, October 26, 2011

Bad Code

"Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down"

~ Uncle Bob

Tuesday, October 25, 2011

Reuse in the small

"Understanding how to achieve reuse in the small is essential to achieving reuse in the large"


~ Uncle Bob

Thursday, October 20, 2011

Adaptation to the world

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
George Bernard Shaw
Man and Superman (1903) "Maxims for Revolutionists"
Irish dramatist & socialist (1856 - 1950)

Sunday, October 16, 2011

What the system wants from you


Emerging is when you use a platform to come into your own. Merging is when you sacrifice who you are to become part of something else.
Merging is what the system wants from you. To give up your dreams and your identity to further the goals of the system. Managers push for employees to merge into the organization.
Emerging is what a platform and support and leadership allow you to do. Emerging is what we need from you.
 -- Seth Godin

Thursday, October 13, 2011

Be undeniably good


When people ask me how do you make it in show business or whatever, what I always tell them — And nobody ever takes note of it ‘cuz it’s not the answer they wanted to hear. What they want to hear is here’s how you get an agent, here’s how you write a script, here’s how you do this — But I always say, “Be so good they can’t ignore you.” If somebody’s thinking, “How can I be really good?”, people are going to come to you. It’s much easier doing it that way than going to cocktail parties.
-- Steve Martin on Charlie Rose

Thursday, October 6, 2011

Eye, sir!

“It’s more fun to be a pirate than to join the navy.”

-- Jobs quoted in Odyssey: Pepsi to Apple, 1987

Wednesday, October 5, 2011

The fear of making the wrong choices


We think we want a lot of choices, but really we want freedom. There’s a difference, and the overwhelming number of choices in our lives these days leads to confusion, paralysis, and unhappiness. 
Scarcity choices can be seen as a bad thing, but I see it as liberating. I’m not saying we should have no choices, but fewer is better. 
Try narrowing down your choices, in as many ways as you dare. Watch fewer TV shows by picking just three you watch every week. Pick just one book and read that until you’re done. Have a to-do list that’s only three items long each day. Make a weekly menu that only has two or three meals you cook in big batches, and eat those all week. You might worry that you’re making the wrong choices — you’re not.
There are no wrong choices, there’s only the fear of making the wrong choices. 
I find limiting my choices to be an opportunity to let go of the worries about making the wrong choices, and to focus on enjoying the choices I do make. 
Leo Babauta @ http://zenhabits.net/scarce/#more-8603

Sunday, October 2, 2011

Some of them are really smart

“I’m an optimist in the sense that I believe humans are noble and honorable, and some of them are really smart. I have a very optimistic view of individuals. As individuals, people are inherently good. I have a somewhat more pessimistic view of people in groups.”

-- Jobs @ Wired, February 1996

Thursday, September 29, 2011

Don't settle

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.”

-- Jobs @ Stanford commencement speech, June 2005

Saturday, September 24, 2011

What people want

“When you’re young, you look at television and think, There’s a conspiracy. The networks have conspired to dumb us down. But when you get a little older, you realize that’s not true. The networks are in business to give people exactly what they want. That’s a far more depressing thought. Conspiracy is optimistic! You can shoot the bastards! We can have a revolution! But the networks are really in business to give people what they want. It’s the truth.”

-- Jobs @ Wired, February 1996

Tuesday, September 20, 2011

Your time

“No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.
“Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”
-- Jobs @ Stanford commencement speech, June 2005

Sunday, September 18, 2011

On-site costumer

Managers will have to decide which is more valuable - having the software working sooner and better or having the output of one or two people. If having the system doesn't bring more value to the business than having one more person working, perhaps the system shouldn't be built.

-- Kent Beck

Thursday, September 15, 2011

Millions of human tapeworms

Since the modern, scientifically conceived corporation was invented in the early half of the twentieth century, creativity has been sacrificed in favor of forwarding the interests of the “team player.”

Fair enough. There was more money in doing it that way; that’s why they did it.
There’s only one problem. Team players are not very good at creating value on their own. They are not autonomous; they need a team in order to exist.
So now corporations are awash with nonautonomous thinkers.
Creating an economically viable entity where lack of original thought is handsomely rewarded creates a rich, fertile environment for parasites to breed.
And that’s exactly what’s been happening. So now we have millions upon millions of human tapeworms thriving in the Western world, making love to their PowerPoint presentations, feasting on the creativity of others.
-- Hugh MacLeod @ Ignore Everybody

Monday, September 12, 2011

All the great code

So you can write Java code that's object-oriented but C-like using arrays, vectors, linked lists, hashtables, and a minimal sprinkling of classes. Or you can spend years creating mountains of class hierarchies and volumes of UML in a heroic effort to tell people stories about all the great code you're going to write someday.

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done. It's not very easy to drag your heels and dicker with class modeling in dynamic languages, although I suppose some people still manage. By and large these languages force you to face the computation head-on.


-- Steve Yegge

Friday, September 9, 2011

Importance of data modeling

It's obviously important to do some amount of data modeling. What's not so obvious is when to stop. It's like commenting your code: newer programmers just don't know when to quit. When you're a little insecure, adding comments and metadata are a great security-blanket that make you feel busy when you've in fact stopped making forward progress and are just reiterating (or perhaps teaching yourself) what's already been accomplished.

-- Steve Yegge


Tuesday, September 6, 2011

Bible salesman

"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''

-- Alan J. Perlis

Friday, September 2, 2011

The most horrible invention in the last 20 years

"Here is what I think: The web was probably the most horrible invention in the last 20 years. Just exactly the wrong thing to do.

Now, it happened by accident, and it evolved, and I think that's very interesting. But if you take about 5 steps back and look at this thing we call web and you realize "we're jumping through 85 hoops a day just to get anything done".

How many languages do you have to know to get a freaking a website up?"

-- Bob Martin @ Pragmatic Podcast 29

Wednesday, August 31, 2011

If you do get a bug report...

"If you do get a bug report, it's a sign you need refactoring, because the code was not clear enough for you to see there was a bug"

-- Martin Fowler in Refactoring

Tuesday, August 30, 2011

Teenager programmer

...programmers eventually have to go through a stupid-teenager phase. [...] I've been hearing sad but unsurprising news stories about teenagers getting stuck on big rocks, being killed falling off cliffs, or dying of exposure. [...] It's just a bad time for us. Even though teenagers are old enough to understand the warnings, they have this feeling of invincibility that gets them into trouble and often mortal peril.

The programming equivalent happens around us all the time too. Junior programmers with five to ten years of experience under their belts attempt to build giant systems and eventually find themselves stuck on the cliff waiting for a helicopter bailout, telling themselves "my next system rewrite will be better!" Or they fall off the cliff – i.e., the project gets canceled, people get laid off, maybe the company goes under.

That being said [...] you should keep in mind that "5 to 10 years of experience" on a resume does not translate to "experienced"; it means "crazy invincible-feeling teenager with a 50/50 shot at writing a pile of crap that he or she and his or her team can't handle, and they'll eventually, possibly repeatedly, try to rewrite it all." It's just how things are: programmers can't escape being teenagers at some point.

-- Steve Yegge

Saturday, August 27, 2011

Watching television

Our parents and grand­pa­rents spent their “Cognitive Surplus” watching tele­vi­sion. That’s a thing of the past… a his­to­ri­cal acci­dent of the old factory-worker age mee­ting the modern mass-media age. Of course it wouldn’t last fore­ver. We humans as a spe­cies were desig­ned to com­pete, not to sit around on our asses.

-- Hugh Macleod @ http://gapingvoid.com/ep/

Tuesday, August 23, 2011

The over-extended class

Plus the five little kids, the two star­tup com­pa­nies on the side, etc. Obviously, balance is a dis­tant goal. In the mean­time, I dele­gate, work all the time, hardly sleep, totally ignore poli­tics, sports and pop cul­ture, neglect my family too much and pro­bably don’t do any ofmy jobs as well as I could. But these are exci­ting days, and if ever there was a time to be ove­rex­ten­ded, this is it.

-- Chris Anderson

Friday, August 19, 2011

Life Meaning

"Frankly, it beats the hell out of com­mu­ting every mor­ning to the cor­po­rate glass box in the big city, [...] just so I could make enough money to help me for­get that I have to com­mute every mor­ning to the cor­po­rate glass box in the big city."

-- Hugh Macleod @ http://gapingvoid.com/ep/

Tuesday, August 16, 2011

We are authors

We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

Uncle Bob

Friday, August 12, 2011

Teaching people

Better to teach people and risk they leave, than not and risk they stay.
-- anonymous

Wednesday, August 10, 2011

Looking for a map

If you're looking for 'how', if you're looking for a map, for a way to industrialize the new era, you've totally missed the point and you will end up disappointed. The nature of the last era was that repetition and management of results increased profits. The nature of this one is the opposite: if someone can tell you precisely what to do, it's too late. Art and novelty and innovation cannot be reliably and successfully industrialized.

-- Seth Godin @ Linchpin (best book ever)

Monday, August 8, 2011

Sucesso na carreira

[...] então "estou fazendo alguma coisa que me motiva a levantar da cama todo dia pra fazer" ou "estou fazendo alguma coisa que todo dia eu não quero sair da cama pra fazer" define sucesso ou insucesso na carreira.

- Sob essa óptica, você é bem sucedido?

Eu nem durmo.
-- Fábio Akita, Grok Podcast n° 26

Friday, August 5, 2011

Unemployed?

If you’re a programmer today and you’re not employed, you’re not looking or you’re not doing the right things:
(A) get involved in open source development
(B) learn a development environment that’s hot right now.

-- @dhh in Episode #26 of the 37signals Podcast

Thursday, August 4, 2011

The best line of code, ever

"The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write.

The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write."

-- Steve Jobs

Tuesday, August 2, 2011

Embrace the constraints

Every project worth doing comes with constraints. Our natural inclination is to fight them.
...
There's a useful alternative: embrace the constraints you've been given. Use them as assets, as an opportunity to be the one who solved the problem. Once you can thrive in a world filled with constraints, it's ever easier to do well when those constraints are loosened.

-- Seth Godin

Monday, August 1, 2011

Choose the simpler design

If a programmer sees a one-minute ugly way to get a test working and a ten-minute way to get it working with a simpler design, the correct choice is to spend the ten minutes. Fortunately, you can make even radical changes to the design of a system in small, low risk steps.

-- Kent Beck

Friday, July 29, 2011

Thursday, July 28, 2011

What killed smalltalk

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

Wednesday, July 27, 2011

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

Tuesday, July 26, 2011

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

Monday, July 25, 2011

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.

Friday, July 22, 2011

Thursday, July 21, 2011

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

Wednesday, July 20, 2011

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

Tuesday, July 19, 2011

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."


Monday, July 18, 2011

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

Friday, July 15, 2011

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

Thursday, July 14, 2011

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

Wednesday, July 13, 2011

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

Tuesday, July 12, 2011

[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

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

"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

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

Monday, July 4, 2011

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."

Friday, July 1, 2011

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."

Thursday, June 30, 2011

Details

To understand why details matter, you first need to notice them.

-- Rands in Response twitter.com/rands

Wednesday, June 29, 2011

Measure performance

Even if you know exactly what is going on in your system, measure performance, don’t speculate. You’ll learn something, and nine times out of ten, it won’t be that you were right!

Skilled people & doomed companies

It’s a fact that a lot of skilled people are working at doomed companies, and that’s bad, because the most precious resource (in business) is the time, energy, talent, and creativity of these people.
-- Eric Reis @ http://goo.gl/F9QsU

Monday, June 27, 2011

Great Habits

“I’m not a great programmer; I’m just a good programmer with great habits.”

-- Kent Beck

Friday, June 24, 2011

About design and refactoring

"The harder it is to see the design in the code, the harder it is to preserve it, and the more rapidly it decays. Regular refactoring helps code retain its shape."