A new year is rising…. ah, actually it is already here, and I’m late! Anyway, when a year is ending and a new one is starting, it’s time to think about what went wrong and what was successful, what should never happen again, and what should be taken as lesson. So lets talk about those things that should be taken in consideration for this new year. The things you might have being doing but definitely shouldn’t: in this 2009 will you continue to the same old mistakes? Like…
start coding without planning
Sharpening the saw time enough to clarify the steps needed to accomplish a task, sowing your thoughts deep enough to define details and caring about design principles are certainly required steps for every project startup. There are lots of ways to setup and to accomplish a task, and ten times more for a project. Defining a start point, a north, guide lines, and the expected end makes it easier to know how far you should go, and how long it shall take.
So, before sitting in your chair and launching your dev set, take your time, open the white board, take two color pens, and draw about “What is it that I’m going to do?”, “How, when and where is it going to be useful?”, and finally, “How can I do it?”.
If programming was a religion, planning would be praying.
using no SCM
Version management is free and easy. Now with git, it got a lot easier to have your own setup to manage the source code of your projects, there’s no need for remote hosts, repos can be created everywhere – even in your pen-drive, easy branching and ease work flow, and, if you ever feel the need, github.com private accounts worth every cent, providing more than just a remote host with all it’s functionalities and reports.
But if you still don’t feel like using git, you can create an account on code.google.com and store your projects there, playing a little with admin settings and making it a “private” project.
Ok, but what is it all about? Managing source code allows you to revert changes without messing with your project, tag releases for easy access of production ready versions, make changes to the project without hurting what’s already there, work with other developers without collision of code changes.
If programming was a religion, scm would be the confessional, commit would be the confession and revert would be the forgiveness.
reinventing the wheel
Creating your own solutions for already solved problems is tempting: your way, your rules. When solving problems on your own, there’s almost no need for reading and learning, and getting used to someone else’s ideas, implementations and styles.
But let the truth be told, everything is already done when talking about programming – well it may not be open source, but it was done.
In the long run, using supported, tested and maintained code is always the better choice. The time spent reading documentation, api, examples, digging someone else’s work and investigating adds to you in experience, knowledge and ideas.
When common problems end up solved with almost no expense on time, you are free to think about the project’s domain problem, that peculiar part that makes the whole project value/price.
If programming was a religion, reinventing the wheel would be a sacrilege.
defining no code standards
Code standards are the guidelines that rule implementation’s styles. Having fixed code standards will help any project to remain consistent all over it’s implementation, with defined ways to write, name and format snippets, classify and solve problems, create and iterate through arrays, and so on.
Standards are the key for integration and maintenance of a project when it’s run by a team, but it’s also a time saver on small and personal projects, assuring you won’t need to bash your head every time you want to implement a new feature or read the code two months after having written it.
If programming was a religion, Code Standards would be the “Ten Commandments”.
commenting the source code
There are no worse code than the unreadable one. It can be tricky, magical, voodoo based, or anything else… but it must be readable and maintainable by anyone whose skill level is the same as the one that coded it. The code should talk by itself – with the api, variable names, iteration purposes and architectural principles.
Commented code is insulting for both the coder , and the reader. The first is showing how unreadable it’s code is – and turning it even more unreadable, and how illogical its structures might be. The second gets annoying lines in the middle of the code, making it really hard and lengthy to read, and is somewhat humiliated by obvious statements.
When feeling the need to guide the code reader through your work, think that, just as the one who coded something should care about its code readability, the one who is reading the code should care about its own knowledge.
If programming was a religion, comments in the source code would be heresy.
leaving code with no documentation
Documentation is the key to unlock any issue in a project, be it a personal project that no one else will ever read, be it a small project with only one person assigned, be it a large project with many contributors.
During the development, documentation will help tracking what is done, show how it was done, and will be a reminder on how to use implemented features. After the development process, documentation will help to track bugs, maintainability of the code and ease the investigation when reopening the project.
Documentation must be used as the code manual, it must be as explicitly as possible, and regard every aspect of the documented process.
If programming was a religion, documentation would be the Bible.
asking and not trying to learn
Well, probably the most dangerous and committed mistake I’ll forever and ever see: people don’t like to fish and cook, they like to eat sushi. I won’t talk too much about this, because I know people won’t change.
Think about the time you spend asking for solutions and you’ll see that there’s something really wrong down there. The current workflow used by new developers to solve problems is scary, they tend to never get conclusions by themselves, never getting their hands dirty by digging on the source of a problem and start asking for help at the first error message.
Every problem solved by an unlearned solution, leads to another n problems that you will never be able to solve.
When learning you can be assured you’ll only have headaches once, and then, every time you get in touch with the problem, you’ll know how to solve it. Learning processes are usually seen as painful and boring, but they can be really fun if used properly: make a dynamic process, where you’ll need to read, write and act, always having in mind short steps with visible improvements, and always put the learned lessons in practice as soon as possible.
When thinking about learning, think wide and abstract, think about concepts as much as possible. When you know a concept, you master the implementation, in any language, tool and rule set. The more abstract is the lesson, the more concrete is the knowledge.
When facing a problem, dig it, look for its reasons and sources, that’s for what we developers are paid for.
If programming was a religion, the askers would be atheists. And all the radicals would burn them for this.
not following this blog
Well, 2009 is a promising year preceded by a successful period of personal and professional achievements. I’ve gained a bunch of experience in everything I’ve done, I pushed myself to the edge of productivity and learning, I’ve never felt better about my thoughts, feelings and wishes. Everything is on it’s way.
One remarkable thing about 2008, that will leave a rich legacy for this new year, is this blog and what I’ve learned with it. Things shown here allow me to say that I’ve earned an interesting amount of recognition, even from people I follow and have as “guru”. It’s good and fun for a narcissist like me – after all I wasn’t that wrong about my value.
Said that, you can bet I’ll be a more active blogger, with more respect for my personal projects – the ones that I should be launching by now, and far more dedicated to knowledge and concepts on programming and leading. What are you waiting for subscribe?
If programming was a religion, I would be a priest.
… as it isn’t, I’m an atheist. Thanks and a happy, wealthy and productive 2009 for everyone.
ps.: I’ll leave a note as soon as I move to the new domain.