This book is highly recommended if you want to advance your career as a software engineer. The authors shares his personal experience as a software engineer and provides actionable items that I found very useful.
Below is a list of actionable items I found particularly useful:
Be the worst – learn from people around you
Be a Generalist Be a Specialist .
Dive into directory services, get comfortable with a UNIX variant, and master a scripting language.
Learn From Projects
Pick a project, and read it like a book. Make notes. Outline the good and the bad. Write a critique, and publish it. Find at least one trick or pattern that you can use from it. Find at least one bad thing that you observed that you will add to your “What not to do” checklist when you’re developing software. 2. Find a group of like-minded people, and meet once a month. Each session have someone nominate some code to study—2 lines to 200 lines. Break it down. Discuss what’s behind it. Think of the decisions that went into it. Ponder the code that isn’t there.
If you treat your projects like a race, you’ll get to the end a lot faster than if you treat them like a prison cell. Create movement. Be the one who pushes. Don’t get comfortable. Always be the one to ask, “But what can we do right now?”
Setting Current Job Goals
Schedule a meeting with your manager. The agenda is for you to understand your manager’s goals for the team over the coming month, quarter, and year. Ask how you can make a difference. After the meeting, examine how your daily work aligns to the goals of your team. Let them be a filter for everything you do. Prioritize your work based on these goals.
Put your career goals away for a week. Write down your goals for your current job. Instead of thinking about where you want to go next, think about what you want to have accomplished when you finish the job you’re in. What can you have produced in this job that will be great? Create a plan that is both strategic and tactical. Spend the week implementing these tactics in support of the long-term goal of “finishing” this job. During lunches and breaks with your co-workers, focus the conversation on these goals. Steer yourself and those around you away from any conversation about career advancement or office politics and gossip. At the end of the week, take stock of your progress toward meeting these job goals. How long will it be before you’ve accomplished everything you feel you need to in your current role? How will you know you’re done?
Keeping A Work Log
Inventory the code you have written or you maintain and all the tasks you perform. Make a note of anything for which the team is completely dependent on you. Maybe you’re the only one who fully understands your application’s deployment process. Or there is a section of code you’ve written that is especially difficult for the rest of the team to understand. Each of these items goes on your to-do list. Document, automate, or refactor each piece of code or task so that it could be easily understood by anyone on your team. Do this until you’ve depleted your original list. Proactively share these documents with your team and your leader. Make sure the documents are stored somewhere so that they will remain easily accessible to the team. Repeat this exercise periodically
Measure, improve, measure—For the most critical application or code that you maintain, make a list of measurable factors that represent the quality of the application. This might be response time for the application, number of unhandled exceptions that get thrown during processing, or application uptime. Or, if you handle support directly, don’t directly assess quality for the application. Support request turnaround time (how fast you respond to and solve problems) is an important part of your users’ experience with the application. Pick the most important of these measurable attributes, and start measuring it. After you have a good baseline measurement, set a realistic goal, and improve the application’s (or your own) performance to meet that goal. After you’ve made an improvement, measure again to verify that you really made the improvement you wanted. If you have, share it with your team and your customers.
Dealing with Mistakes
Take the blame. Don’t try to look for a scapegoat even if you can find a good one. Even if you’re not wholly to blame, take responsibility and move on. The goal is to move past this point as quickly as possible. A problem needs a resolution. Lingering on whose fault it is only prolongs the issue. • Offer a solution. If you don’t have one, offer a plan of attack for finding a solution. Speak in terms of concrete, predictable time frames. If you’ve designed your team into a corner, give time frames on when you will get back with an assessment of the effort required to reverse the issue. Concrete, attainable goals, even if small and immaterial, are important at this stage. Not only do they keep things moving from bad to good, but they help to rebuild credibility in the process.
Start keeping a development diary. Write a little in it each day, explaining what you’ve been working on, justifying your design decisions, and vetting tough technical or professional decisions. Even though you are the primary (or only—it’s up to you) audience, pay attention to the quality of your writing and to your ability to clearly express yourself. Occasionally reread old entries, and critique them. Adjust your new entries based on what you liked and disliked about the old ones. Not only will your writing improve, but you can also use this diary as a way to strengthen your understanding of the decisions you make and as a place to refer to when you need to understand how or why you did something previously.’
Catalog the crusades you’ve personally witnessed in the workplace. Think of the people you’ve worked with who have behaved as if on a mission. Think of the most driven and effective people in the places where you’ve worked. What were their missions? Can you think of any such missions that were inappropriate? Where is the line between drive and zealotry? Have you seen people cross it?
Companies want to hire experts. While a résumé with a solid list of projects is a good way to demonstrate experience, nothing is better at a job interview than for the interviewer to have already heard of you. It’s especially great if they’ve heard of you because they’ve read your articles or books or they’ve seen you speak at a conference. Wouldn’t you want to hire the person who “wrote the book” on the technology or methodology you’re attempting to deploy?
First, read weblogs. Learn about weblog syndication, and get yourself set up with an aggregator. If you don’t know what to read, think of a few of your favorite technical book authors and search the Web. You will probably find that they have a weblog. Subscribe to their feed and to the feeds of the people they link to. Over time, your list of feeds will grow as you read and find links to the weblogs other people have been writing. Now open your own weblog. Many free services are available for hosting and driving a weblog. It’s dead simple to do. Start by writing about (and linking to) the stories in your aggregator that you find interesting. As you write and link, you’ll discover that the weblog universe is itself a social network—a microcosm of the career network you are starting to build. Your thoughts will eventually show up in the feed aggregators of others like you, who will write about and spread the ideas you’ve created.
Your writings on the Web will also provide work examples that you can use in the next step. Now that you’re writing in your own forum, you might as well take your writing to community websites, magazines, or even books. With a portfolio of your writing ability available on the Web, you’ll have plenty of example material to include in an article or book proposal. Get yourself in print, and your network grows. More writing leads to more writing opportunities. And all of these lead to the opportunity to speak at conferences
Save the file but leave it open. If you reboot, reopen the file. You have three weeks. Each day, choose an item from the list and write an article. Don’t think too hard about it. Just write it and publish it. In the articles, link to other weblogs with related articles. As you read the list to pick each day’s topic, feel free to add ideas to it. After the three weeks are over, pick your two favorite articles and submit them to user-moderated news sites such as Digg and Reddit. If you still have ideas on your list, keep writing.
Although many of these developers are just having fun and expressing themselves, some real incentives exist there. They are moving their way up the social chain of a community. They are building a name for themselves. They are building a reputation in the industry. They may not be doing it on purpose, but they are marketing themselves in the process.
Contribute to Open Source Projects
Stuart Halloway15 does a workshop at conferences he calls “Refactotum.” If you get a chance to participate, I highly recommend it, but the gist is as follows: Take a piece of open source software with unit tests. Run the unit tests through a code coverage analyzer. Find the least-tested part of the system and write tests to improve the coverage of that code. Untested code is often untestable code. Refactor to make the code more testable. Submit your change as a patch. The beautiful thing about this is it’s measurable and can be done quickly. There’s no excuse not to try it.
Releasing successful open source software, writing books and articles, and speaking at conferences may all increase your remarkability
One way to experiment is to shoot for remarkable productivity. Project schedules often have a lot of padding. Find something that everyone thinks is going to take a week and do it in a day. Work extra hours for it if you need to do so. You don’t have to make a habit of working extra hours, but this is an experiment. Do the work in a remarkably short time. See whether people “remark.” If not, why not? If so, in what ways? Fine-tune the variables, and try again.
The most serious barrier between us mortals and the people we admire is our own fear. Associating with smart, well-connected people who can teach you things or help find you work is possibly the best way to improve yourself, but a lot of us are afraid to try.
Of course, you don’t want to just randomly start babbling at these people. You’ll obviously want to seek out the ones with which you have something in common. Perhaps you read an article that someone wrote that was influential. You could show them work you’ve done as a result and get their input. Or, maybe you’ve created a software interface to a system that someone created. That’s a great and legitimate way to make the connection with someone.
The same thing can happen to you in your career. The process in this book is a loop that repeats until you retire. Research, invest, execute, market, repeat. Spending too much time inside any iteration of the loop puts you at risk of becoming suddenly obsolete.
Computing power doubles. With technology progressing so quickly, there is too much happening for any given person to keep up. Even if your skills are completely current, if you’re not almost through the process of learning the Next Big Thing, it’s almost too late. You can be ahead of the curve on the current wave and behind on the next. Timing becomes very important in an environment like this. You have to start by realizing that even if you’re on the bleeding edge of today’s wave, you’re already probably behind on the next one. Timing being everything, start thinking ahead with your study. What will be possible in two years that isn’t possible now? What if disk space were so cheap it was practically free? What if processors were two times faster? What would we not have to worry about optimizing for? How might these advances change what’s going to hit?
If you’re a programmer, try a day or two of doing your job as if you were a tester or a project manager. What are the many roles that you might play from day to day that you have never explicitly considered? Make a list, and try them on for size. Spend a day on each.
Before mapping out where you want to go, it can be encouraging and informative to map out where you’ve been. Take some time to explicitly lay out the timeline of your career. Show where you started and what your skills and jobs were at each step. Notice where you made incremental improvements and where you seemed to make big leaps. Notice the average length of time it took to make a major advancement. Use this map as input as you look forward in your career. You can set more realistic goals for yourself if you have a clear image of your historical progress. Once you’ve created this historical map, keep it updated. It’s a great way to reflect on your progress as you move toward your newly defined goals.
Set big goals, but make constant corrections along the way. Learn from the experience, and change the goals as you go. Ultimately, a happy customer is what we all want (especially when, as we plan our careers, we are our own customers)—not a completed requirement.