Creating a Remarkable career in Software Development

by Chad Fowler

My own journey as a software developer has been fairly traditional. I’ve spent almost 100% of my career working in j2ee/java, mostly on web applications. One of my own personal goals is to be a java expert/ninja, and so, even outside of work, I do a lot of java related development. A book like The Passionate Programmer is great find for someone like me who is risking putting all of their eggs in one basket by working in a single area. The book is full of suggestions for getting out of your comfort zone, researching alternative career growth areas and growing a career outside of your 9-to-5 job. You may be familiar with a previous edition of the book, unfortunately named My Job Went to India: 52 Ways to Save Your Job.

My favorite part of the book was the “Act on It!” sections that give you suggestions for things you can do now to act on the concepts introduced in the chapter. If you are looking for a springboard of ideas on how to enliven and improve your career as a software developer, this book gives you over 50 concrete actions to move in that direction.

I am so excited about using these suggestions in my life; I have already started with some of them. Of the 50 or so suggestions shared in the book, the following are the ones that really stood out to me.

• Figure out how the internals of the vm you program for work. Determine how external libraries are loaded or imported. Take time to learn the mechanics of how source code is compiled.
• Be the worst musician in your band. This means that you should surround yourself with developers who challenge you, who are better than you are…. so that you are continually challenged and feel the impetus to keep up and perform at your best.
• Practice
• I love this one… Questions you should ask yourself and your boss
  • Was I worth it today?
  • How could you make your development team more efficient?
  • How could you creatively save your company money?
• Keep a development diary—what did you work on, why did you write it that way. I have started trying to do this and initally my ‘diary’ was more like a hit list of what i accomplished that day. What I have started doing differently is picking out some snippet that i wrote that day and pasting it into my diary post and then commenting on different lines.
• Try to do the boring stuff perfectly. I’ve tried this as well; it will add life back into your most tedious tasks.
• How to Fail
  • raise the issue as soon as you know about it
  • take the blame
  • offer a solution
  • ask for help
• One of my new goals after reading this book is to talk to all of the developers I work with face to face more often.
• Always have your “elevator speech” ready. What are you working on? Could you explain what you are working on to the CEO of your company?

I definitely recommend the book; it is inspiring and will silence even the whiniest of developers. While reading, you will want to take notes while you are reading or keep a to do list handy.

The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life)

Image: FreeDigitalPhotos.net

I wrote this a few months ago when I was doing a lot of code reviewing. There are a number of criticisms of the Code Review, and certainly, a number of review mechanisms that can and should be used in conjunction with some type of human review, such as static code analysis and performance analysis. In this post, I won’t be comparing or contrasting the Code Review to any of these.

Strategies, Questions to Ask and Things to look for

Some code review questions…

• Is it relatively clear what the code does from reading it?
• Is the code in a reasonable location and named appropriately?
• Is this same functionality duplicated elsewhere?
• Are there any unnecessary calls, methods, variables?
• Do any of the url params have the potential to conflict?
• Has all text been pulled out into properties files?
• Would it be useful if this code could be disabled or enabled? If so, has the author provided a means for turning it off?

Tools

My experience with code reviewing tools is limited. The Jupiter eclipse plugin seemed to require too much work on the developers part—generating the request for review, checking in the .jupiter file and review files slowed development down. Monitoring svn check-ins seemed to work moderately well, although it required more work on the reviewer end.

• jupiter
• Review Board
• trac
• Crucible

When to do the code review

Ideally, code reviews shouldn’t uncover any larger architectural issues that need addressing. They should expose overlooking coding mistakes. So, ideally there should be no timing problem, that is, you shouldn’t find some large refactor that needs to be done before the code is released. Code should be reviewed after development is finished, but before the functionality is ready for qa.

Double Time

There are several different ways that code reviews can go: the code reviewer(s) can monitor check-ins, developers can request that code reviews be done on their code or the dev team can get together as a group and go over the code line by line etc etc. One thing that has worked for me is employing more than one of these methods. So, developers submit requests for review and I also monitor check-ins.

Why read Ubuntu Hacks?

1. If Ubuntu is the entry-level Linux distro, then Ubuntu Hacks is the book that helps the entry-level user take advantage of the great software and tools Linux has to offer.
2. I would have saved myself a lot of effort if I owned this book on the day that I install Ubuntu on my machine.
3. In many ways, Ubuntu Hacks is an introduction to the software available to all Linux users. So, if you are looking for some “real Ubuntu hacks”, you may be disappointed, _{but that is ok; that just means that the title of the book is a bit of a misnomer, but it doesn’t necessarily mean that the books isn’t valuable.}
4. Some subjects (like kernel building) aren’t really examined with much detail and refer users to seek help elsewhere.
5. The command-line based instructions are great for those new to using the terminal. There are quite a few hacks that provide visual instructions only, but Ubuntu Hacks had far less GUI-based instructions than the other Ubuntu books I perused at the bookstore.
6. If you aren’t a techie, but you want to explore Linux and its myriad of software options, Ubuntu Hacks is for you.
7. A lot of the hacks in Ubuntu Hacks you can figure out on your own or find on the internet.
8. Things that I would like to know about Linux/Ubuntu that weren’t addressed in Ubuntu Hacks:
   • File system organization… whys and best practices (i.e. Hack #101 – Get a good visual picture of the linux file system in your head)
   • A brief history of Linux, Debian and Ubuntu (i.e. Hack #102 – How to tell friends & family about Ubuntu in a non-freakish way)