Review: The Passionate Programmer

Chad Fowler's book is all about building a successful career in software development.  When I read that sentence, 2 questions immediately come to mind: what's in it for me (as a developer)? and what's in it for me (as a business owner/manager/project manager/etc)?  Well the answer to the first question is pretty obvious: what I get out of a successful career is happiness, money, purpose, etc.  What does my employeer get out of it?  Well, a happy, motivated, driven developer.  Why does that matter?  Happy, motivated people produce more and better work.  So now we have covered the most rudimentary of why, let's look at how this book helps.

There are 5 sections in the book:
  • Choosing your market
  • Investing in your product
  • Executing
  • Marketing... not just for suits
  • Maintaining your edge

Choosing your market talks to the importance of being aware of what you do and how it related to the larger picture.  Are you .NET developer?  Why?  Why aren't you a Ruby developer?  Or a Java developer?  Or a COBOL developer?  Or a DBA?  Did you make a conscious decision to go into this area or did it just happen?  Are you in control of the direction of your career?  Are you specialized?  Will that help you or hurt you in the short term?  Medium term? Long term?  Make sure that you know what path you are on, why you are on it and how you will change if that path disappears.

Investing in your product is about improving in the areas you have chosen.  Learn continuously from those around you.  Help those you can.  Read, study, practice.

Executing is make yourself indispensable (not because no one can do what you do, but because you are constantly bringing so much new value to the team/project.)  Executing is also being honest: working hard and saying "No" when the answer really is "no."

Marketing is about managing perceptions because they really do matter.  Make sure people around you know who you are, what you do and why that matters.  Become a brand.  Get your name known on not just in your company, but in the industry.

Maintaining your edge is a pretty obvious need.  You have to always be improving because the industry is always moving and if you stand still, you will be left behind.

The 53 short essays in this book will help you focus on what you need to do to have an exceptional career that takes you where YOU want to go.  I was pleasantly surprised at how many of the recommendations I am already following.  I was also amazed at how much work I still have ahead of me.  This book can be very useful in providing you with a direction and a starting point.  Each essay has an Act On It section that gives you specific advice on how to improve your career right now.

Comments

  1. UnknownJanuary 7, 2013 at 2:16 AM

    Just finished the book yesterday.
    I really like the examples he uses to validate some of his views. I'm so glad I read it at a time when my career was going nowhere and I was struggling with finding joy in the art of developing solutions to problems.

    very good investment.

    ReplyDelete

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more