Well I have read that article. I do understand that true mastery can take a lifetime.
The posted article gives specific chess exercises which when practiced for 3 - 5 months can produce a marked improvement. I was asking whether there any such exercises for programming.
I enjoy ProjectEuler.net and I would put it in that category. Within the first few months I was motivated to learn a number of excellent Python performance tips. I can't guess whether you find math puzzles as compelling as I do, but [the popular article about Project Euler in The Atlantic](http://www.theatlantic.com/technology/print/2011/06/how-i-fa...) suggests that you don't have to have a history of enjoying math.
You could try code kata (http://codekata.pragprog.com/) or koans, (just search Google for your language + 'koans') but those are really only a fun way to work on a specific, easily-tested skill, that also happens to be the very first a novice learns, that's implementation. By all means, if they help, knock yourself out.
The thing about programming is that to get better at it, you need to expand the way you think about abstraction. You have to think not just in terms of how you will maintain what you wrote, but how the end user will use it and how the domain might change.
Any novice can hack together something that will work for one specific purpose, it takes someone skilled to pull useful abstractions out from that single-use code and turn it into something flexible enough that even years from now another novice will be able to pick it back up and understand it enough to be able to reuse it.
All that is to say is, any purported exercise isn't going to get your brain thinking the way it needs to. They're only going to take you to the end of the very first step of mastery, that's in "getting the computer to do what you want it to".
Exactly. IMO its not just the exercises that help you write great code (though they MIGHT help in competitive coding like for ACM). Truly beautiful code comes from experience and working with those who have spent years getting that experience. In my current company there is a huge focus on the re-usability and extensibility of the code. We are forced to think of future changes and make sure the code allows changing things in the most easy way possible.
One simplest example: All queries to a single DB table have to be done through a single "Data Class". The class will have functions that will allow other classes to use that table. this ensures that if tmrw, we make changes to that table, there is only one place in the code we have to make the changes. Instead of running around in the massive code base, looking for the queries to that table.
That's an application of the Dependency Inversion Principle, part of the SOLID methodology. You always want your code to depend on abstract forms rather than concrete ones. By abstracting database calls into a class, you avoid having to constantly write brittle methods digging deep into concrete implementations.
One way your company's method might evolve is into the Active Record pattern. You define a class around a particular table, implementing domain logic inside that class. You see this pattern used in Rails. If you're using one class per table, I think that's the way it will eventually go.
I like Active Record ORMs for many applications, but only as a persistence layer. Implementing domain logic in a data class is asking for pain, it violates the Single Responsibility Principle. Each class should do only one thing. The thing handling your data persistence should only read/write to the database, it should not also perform calculations or perform actions on anything other than the database.
I refactor domain logic out of models when I see it into Plain Objects with no dependencies, and let the domain have its own abstract world of classes minus ugly database wrappers to play in. I can then write an adapter to the data classes. If it's an existing application in production, then at this point I would start to re-design the database, inevitably it will need work.
I do this by creating another database schema, generating the data classes, simple as pie now without domain logic getting in the way, then create the adapter from examining the existing one. I can then import all the data from the database, represent it as abstract plain objects, then shoot those objects through the other adapter into the new database.
But it only really works if everything does one thing. Your domain objects talk to each other. Your adapter classes go between the domain and the data. The data talks to the database. Achieving this requires hard-won experience with programs that break the principles. You have to feel the pain and recognize where it's coming from. No kata will give you this experience.
Well yes, that's what we do too. The logic implementation is in the Business classes. The data classes just read/write from the tables, and return that data to the business class that performs more meaningful functions on it. This way the data can be used in multiple ways by multiple classes without them depending on each other. A change in domain logic would mean a change in the business class, leaving the data class unaffected
They are as good as you could hope for a guided tour.
They get your feet wet and let you get your bearings.
But there is still a large gap between having knowledge of a language and performing synthesis with one.
It would be interesting to have a tutorial series for those that get past the syntax stage.
I could imagine being given a small problem and asked to craft a solution. Your entry could be graded, perhaps by humans, perhaps by machine analysis -- it shows how you could improve and some of the top level solutions and what make them better. If you don't meet a certain threshold, you are given another problem of the same level, rinse and repeat, until you are truly solving problems with the language of choice at a level and style that is comparable to your top rated peers.
Yeah that would truly be great. As stated in Norvig's essay, each new language should open up your perspective. it should teach you a new a way to think. But all i ever achieve is learning a new syntax. Because not only does it take a considering programming effort effort in that language but also feedback from seniors to actually know what you did wrong and who to improve it. That's why i love having code reviews! Sure, they can be embarrassing, but at least it improves my programming.
