Académique Documents
Professionnel Documents
Culture Documents
should not live without, and then they work tirelessly to make it happen. What they achieve
does more good to the world then themselves and that makes them remarkable. So the
recipe is - do something that the society needs and work really hard to achieve it even if
you do not have to go that far for your personal benefit. If Linus Torvolds had stopped
adding device drivers for hardware he does not own, I doubt Linux would have been this
much successful. Passionate Programmer briefly touches the subject of helping Open
Source projects and writing books. But most of it is about helping yourself. After all,
Passionate Programmer is a self-help book. But my idea is that remarkable people become
remarkable not only by helping themselves but also helping everyone else (although not
always by intention :). So a better subtitle for Passionate Programmer would have been
"Creating a HIGHLY SUCCESSFUL career in software development." And as a book on
achieving a highly successful software development career, it is only full of good advice.
What follows is my summary of these good advices.
[Note: All quotations from Passionate Programmer are wrapped in quotation marks below.
Everything else is my own comment.]
A good way to learn things is to teach it to others. This is an advantage that comes
with mentoring.
Musicians, artists, etc. practice a lot. Programmers need to practice outside their
jobs too. We have to stop treating our jobs as a practice session.
Learn a software development process, e.g. Extreme programming.
Study existing code. Styding the work of masters is an essential part of becoming a
master. This tip is my personal favourite. Maybe we should have a museum of
source code :-)
Automate as much of your work as possible.
You might be the coolest Z# programmer around, but if you are not good at solving
your employer's problems with Z#, you are not really that cool :-(
Parkinson's law states that "work expands so as to fill the time available for its
completion." especially when there are tasks you don't really want to do.
Have an accomplishment to report everyday.
Solve your manager's problem, and you've solved a problem for the team.
If you are not good at your current role, you won't be good at the next upper level
role either. So if you are a bad junior developer, you will also be a bad senior
developer. Do not wait to improve yourself until you get the next promotion.
One way to get over with boring tasks is to make them interesting! For example, if
you have a boring pointy-clicky task to do, why not write a programme to do it?
Sure it will take longer, but it will be less boring.
Every staff usually costs their employer twice their salary. Ask yourself if you are
helping your employer earn a lot more than that.
All employees are replaceable. Some are more replaceable than others, but
eventually all are replaceable. Some programmers has the tendency to create cryptic
systems and then feel that they are irreplaceable. Nothing comes out of it except
bitterness.
Even in my own experience, people tend to avoid maintenance programming. As
long as you're keeping it running and responding to user requests in a timely
fashion, maintenance mode is a place of freedom and creativity. Maintenance
programmers tend to get more exposure to customers. So if you like interacting with
lots of people, maintenance is the way to go. It also puts you in a prime spot for
truly learning the inner workings of your business.
Do not work more than 8 hours a day. But you should work so relentlessly that there
is no way that you could continue longer than eight hours.
Fail gracefully. we don't judge each other on the mistakes we make. We judge each
other on how we deal with those inevitable mistakes. Remember the following four
points after making a mistake:
o Don't hide the issue, please raise it.
o Accept the blame.
o offer a solution. If you don't have one, offer a plan of attack for finding a
solution.
o Do not hesitate to ask for help in clearing the mess.
The difference between how a company treats us when they make a mistake can be
the ultimate in loyalty building (or destroying).
Do not promise what you cannot deliver. If you are from the Indian subcontinent
like me, then remember that The inability to say "no" happens to be a common part
of the Indian culture.
Heroes never panic. Have you even seen MacGyver panicking? Be like the heroes
when you have landed in a mess.
Deadlines actually help us get things done on time. So do not hate deadlines.
Prepare a daily plan in the morning. Plans help avoid ambiguity.
Sometimes send unsolicited emails to your manager telling them about your plan or
what you are working on. People who are managing tend to like this type of inputs.
I have tried this on my manager and I can tell that this actually works.
If you have a complain, do report it to your manager. But even better, if the
complain is accompanied by proposed solutions.
Among other things that you learn from a commercial failure, you learn the
importance of conserving cash.
We all know it, There's a lot more to success in the marketplace than having a great
product. So the best programmer is not always the winner.
Beauty is in the eye of the beholder :-) Being a good programmer is not enough.
You need other qualities too. If I'm a project manager, the quality of your source
code is a lot less important to me than the quality of your communication. If I'm a
fellow programmer, your raw ability and creativity drives my perception of you
more than, for example, your follow-through. Understanding what's important in
each of your relationship is an important part of building credible perceptions with
those you interact with.
Nonprogrammers are, on the average, as intelligent as programmers. There is no
reason for them not to be. After all, programmers do not eat any special magic diet
that enhances intelligence. So please respect nonprogrammers. They also represents
the needs of the business, and you are paid to provided for those needs.
Improve your writing skills as written communication is getting more common. You
may be a great coder, but if you can't express yourself in words, you won't be very
effective on a distributed team.
Here might be a gem for hiring managers - If you can't organize your thoughts in
your mother tongue so that others can clearly understand them, how can we expect
that you can do it in a programming language? The ability to shape an idea and lead
a reader through a thought process to a logical conclusion is not much different
from the ability to create a clear design and system implementation that future
maintainers will be able to understand.
Have as much face-to-face communication with others involved in the development
of your software project. If that is not possible, talk to them over the phone.
Try to be known outside of your company for your excellence. Write blogs, give
presentations at local technical meetings and even better in large conferences.
Having Open Source code under your belt is an excellent way to move up the social
chain of the programmer community.
The subtitle of the book is "Creating a remarkable career in software development."
So what is remarkability? Remarkability means that people talk about you before
they are asked. Think of Dries Buytaert. Releasing successful Open source software,
writing books and articles, and speaking at conferences may all increase your
That's all. So ask what impact you are having on the world? A remarkable career should
provide a happy answer.