Thoughts on Passionate Programmer (part 3 of 3)

This is the final instalment of my learnings from Passionate Programmer. It covers the part on 'Marketing'. The first part of this series can be found here.

In the book, Fowler stresses the importance of marketing in building a successful career. He said "the best saxophonist does not always get the job", and that "who you played with is at least as important as how well you play". Hence the first part of marketing chapter is about building relationships.

Kinds of relationships

Chad talks about the importance of several kinds of relationships: relationship with management, clients, mentors and peers. He suggests to list the parties in your current project, and or your current employer, list expectations that each party may have of you, and make sure that you are meeting (or exceeding if you like) the expectations of the key stakeholders. Its significant because, as Zig Ziglar, says, and I believe in this: "To get what you want, you just have to help enough people get what they want". Chad also highlights the importance of having regular face time with the key parties.

Outside of relationships, Chad describes another side to marketing, which is making yourself remarkable: by writing books, or contributing to open source, giving talks at user groups or conferences. In this post however, I would like to focus on two types of relationships mentioned in the book.

Relationships with management

Key areas are: make suggestions, don't just execute; don't make unreasonable commitments, it doesn't help credibility; remember, your managers success is your success.

Another area that I like is having a mission, and an elevator pitch, so that during occasional encounters with management you have a good answer to their question on what your contribution is to their business. It's important because you are to them what you can explain.

Cool by association

Speaking about "cool by association" phenomena, Chad encourages developers to make effort and approach those tech luminaries giving talks at conferences, or user groups, and have a conversation with them. Overcoming personal fears and making efforts to know them personally increases the potential to work with them in the future.

These are my key highlights of Passionate Programmer, which I enjoyed greatly. If you found the areas covered interesting, the full book can be purchased here.

Thoughts on Passionate Programmer (part 2 of 3)

Welcome to the second instalment talking about learnings from reading Passionate Programmer. This post focuses on 'Executing'. The first installment can be found here.

Fun

In this section the author encourages developers to be proactive about making our work more fun. He asks us to reflect on what the difference is between the work we enjoy and the work we loathe. The author prompts us to do our best at changing the work we do, or the way we see work, to make it fun.

Learning to love maintenance

Another interesting suggestion is about maintenance work, it seemed to be counter-intuitive initially, but it makes sense. Here is a metaphor used by Fowler:

"If I give you $1,000 and ask you to go get me a cup of coffee, I’m going to be very unhappy if you return with 1,000 less dollars and no cup of coffee. I’m even going to be unhappy if you bring me plenty of really nice coffee but it takes you two hours. If I give you $0 and ask you to go get me a cup of coffee, I’ll be extremely appreciative if you actually return with the coffee, and I’ll be understanding if you don’t. Project work is like the first scenario. Maintenance is like the second."

The author says that project work usually costs big bucks and attracts high expectations and a lot of attention from the business, however, when doing maintenance the costs to the business and their expectations are less. Hence with maintenance, there is less pressure to deliver and more opportunities to clean up the design problems in the system, and improve the UI amongst other things.

Learning how to fail

Failure happens to everyone. Fowler highlights that the stressful times is when an opportunity arises to build loyalty. Here is the authors recipe for a graceful handling of a failure:

• do not panic, always know how your actions fit into the larger context - your current failure may be small in the scale of things. What would you think about it 5 years?
• raise the issue as early as possible
• take the blame
• offer a solution
• ask for help

The next and final post on this book talks about 'Marketing'.

Thoughts on Passionate Programmer (part 1 of 3)

I read Chad Fowler's book Passionate Programmer over a weekend. I liked the book because it puts structure around what it takes to have a successful career in software. That is something I have been looking for as a developer at the beginning of my path (developers at early stages of their careers are the target audience for this post). I wouldn't take it as gospel, as there are many ways to a great career, but I think its full of useful ideas. In the book, Chad describes the career as a composite of four key processes:

• Choosing your market
• Investing in your learning
• Executing and
• Marketing yourself

Given there is quite a bit of content to cover, I've broken this post up into three parts: The first installment covers the 'Choosing your market' and 'Investing in learning'.

Choosing your market

Reading the first part I reflected on my plan of things I would like to learn. It needed the right mix of upcoming vs mainstream technologies, generalist and specialised knowledge, and people & process skills.

To tell apart which technology is which, we have developers' blogs & TIOBE index. Knowing the role of these sources helps allocate time to reading them in a productive manner, and avoid sinking in the sea of press releases and news stories wasting valuable time.

Investing in your learning

The author suggests four key ways of investing in learning, these are:

• Reading literature,
• Practicing,
• Reading code and,
• Finding & working with a mentor

Reading literature
At my current employer, we run a book club which is a fantastic forum for reading texts that move us towards being better developers and consultants. However, I feel I would benefit from doing more practice. I have a couple of pet projects that I work on periodically, but according to Fowler that would barely qualify as practice.

Practicing
To explain practice, the author brings out an analogy with music. It's not about delivering a finished product, but about working on its elements, learning about the moving parts and stretching the limits. To quote the author:

"When you practice music, it shouldn’t sound good. If you always sound good during practice sessions, it means you’re not stretching your limits. That’s what practice is for. The same is true in sports. Athletes push themselves to the limit during workouts so they can expand those limits for the real performances. They let the ugliness happen behind closed doors—not when they’re actually working."

Reading code
Reading code is another area I've been neglecting (outside of working hours), but I see some great value in doing it. When talking about reading code, Fowler compares it to the same practice as done by various types of artists: musicians, painters, composers.

"Studying the work of masters is an essential part of becoming a master."

Mentors
Fowler really emphasised the role of mentors, comparing it with the Jazz scene. He said that when a jazz musician is asked who his mentor is, its a normal thing, like asking a player "how are you". The suggestion is to look for people who you can see as a mentor and approach them. The benefits of having a mentor are many: they can help shape a longer term career vision, give a bit of structure to your learning process, help guide and judge your progress.

The Mentor - Mentee relationship is not one way, it is the mentee's role to support and promote the mentor.

As a takeaway from this chapter, I'm going to mix up my ways of learning to include more practice and reading code.