The Ultimate Code Kata

On June 14th your don’t go dark entry implored developers to share their code at the first opportunity
Don’t go dark. Don’t be that guy in the room. Hiding your code until it’s done may feel safer, but it isn’t.

In a response to a comment in this entry you reply
I’m probably going to follow the reddit.com model and open source the code once the site is firmly established.

isn’t there something of a contradiction there?

Effortful study means constantly tackling problems at the very edge of your ability. Stuff you may have a high probability of falling at. Unless you’re failing some of the time, you’re probably not growing professionally. You have to seek out those chanllenges and push yourself beyond your confort limit.

This is genial !!! …I could say historicly :slight_smile:

Respect,
Bogdan

I have 5 rules for programming kata:

1.LEARN THE PROJECT’S BUSINESS DOMAIN
2.LEARN THE PROJECT’S BUSINESS DOMAIN
3.LEARN THE PROJECT’S BUSINESS DOMAIN
4.LEARN THE PROJECT’S BUSINESS DOMAIN
5.LEARN THE PROJECT’S BUSINESS DOMAIN

And by saying ‘LEARN the PROJECT’S BUSINESS DOMAIN’ I mean take the path which would make you from a programmer to an expert of that business domain.
Dont reach its end, it is impossible, but take that path.

Then, you may humbly, try to start designing…

I’m probably going to follow the reddit.com model and open source the code once the site is firmly established.

Dont’ go dark, Jeff!

Jeff,

You are dead correct in your view of building your own software or business. When I am working towards my own deadline, and using my own time/money, my view of the software I write is much different. I become much more pragmatic when writing for myself. I wouldn’t say I write sloppy code for myself, but I definitely write code that I expect to re-factor at some point down the road. When I am writing code for my employer, and tend to “pre-factor”, which is to say that I try to re-factor before I need to do so. I think that at least 50% of this pre-factoring goes to waste (prolly much higher). This is a lesson I have tried to apply when writing code for my employer as well.

This shouldn’t discount the point of trying your best to write it correctly the first time. I just try to make sure I am not coding myself into a corner the first time with really bad code. In my personal and work projects this approach usually pays off well.