(Author's Note: I wrote this a couple of years ago after my mentor left the company. Shortly after he left, nearly every other Developer who felt the way my mentor and I did left the company. Demoralized, I abandoned this blog for about a year, but there are still some good nuggets of information here.)
The old saying “When it rains, it pours” has proven very correct rather recently. Not only have I been busy with a particularly nasty bug lately, but I also received news that one of the developers on another team at the company I work for was leaving. He's been a mentor to me since I started my career in development, so it is with great reluctance that I see him leave.
I have been giving a lot of thought to learning from the events that occur in my daily work. So, I've been reflecting on why I've felt such a kinship with my mentor (and why I keep referring to him a such), as well as why I think it's been helpful for me.
First, he and I have a lot in common. Besides a similar sense of humor, we also have a strong desire to not only write code, but write GOOD code. On several occasions when I walk by his office, he will point out the code which he is currently working on and show me questionable coding decisions his peers have chosen and what he is doing to correct them. Often we'll discuss an optimum solution, but often, with project time constraints being what they are, this is purely an academic discussion.
Second, of most of the developers I know, he is one of the few who seem to care about the craft. I'd say most developers fall into a category called “Code Monkey”. A “Code Monkey” might do designs, some coding, and be very proficient at it, but has little desire to learn beyond what the everyday tasks requires of him/her. A “Code Monkey” knows a few languages very well, but couldn't name, much less code in the latest “hip” language. The ''Code Monkeys" will never see this post though, because the very same desire to read blog posts and other writings from other developers demonstrates a desire to become better at our craft.
The developers who care to learn beyond the every day tasks, who desire to make things better, and are actively learning about new techniques and how to employ them are true Software Engineers in my book. They care about their chosen profession, and realize that the field is always evolving and requires a commitment to learning.
He's also the developer who introduced me to Code Complete. This book has proven an invaluable insight into the Development process and thanks to it, I've found and have been a daily reader to the blog Coding Horror. If you are not familiar with either the book or the blog, then I urge you to check them both out now. I'll wait.
Finally, he's been a good friend whom I've always been able to talk to. The nuances of corporate culture, development style, internal code systems and the like make it easier for us to relate to each others problems.
In the end, I know my fellow Software Engineer must move on to another company for a variety of reasons. Hopefully the two of us will be able to stay in touch. In the mean time, I will look forward.
In many classic tales, the hero of the story must lose his mentor before achieving greatness (Luke Skywalker and Obi-Wan Kenobi, Harry Potter and Albus Dumbledore, Frodo Baggins and Gandalf, just to name some more well known examples). Perhaps this is my chance to step out on my own and find my own path.
If you're staring out in development, I urge you to make friends with some of the Senior developers, either on your team or on others. The bond you make with them may provide you with knowledge and understanding that you would not have gained on your own.
Thursday, March 25, 2010
Tuesday, March 23, 2010
A Software Engineer's Development Path
A couple of years ago, my employer jumped on the Personal Career Development band wagon. They hired a consultant, setup training for everyone, and encouraged everyone to set career goals and make plans to achieve these goals.
But most of the training focused on the typical 'soft' skills of career development, such as communication, project management, organization, etc. While this may be the typical career development tasks for business people, for those in IT, and especially software development, these tasks will likely be on the periphery. The bulk of a Software Development training will center around the technical knowledge, software development processes (which are unique and ever evolving), software design, and project estimation. The consulting company Construx has a very good Professional Developer Handbook that I'd recommend checking out.
Soft skills, such as communication, are important, but present a unique challenge. While conversing with other developers, the technical terms and jargon can be used to quickly explain an issue. But, when conversing with business people, this needs to be kept to a minimum, even if it requires explaining the situation in a verbose manner.
There is another matter to discuss regarding career development: job promotion. There are two typical routes a developer will take. The first route takes a developer from a Junior Software Developer to a Senior Software Developer. Eventually, this developer learns a great deal about the processes and management of a software project and becomes a project manager.
The second route sees a developer progress further until they become a Software Architect or a DBA, or a specialist in some particular technical field. Or perhaps they continue to be a Senior Software Developer. Whatever the title, the second route arrives anywhere but management.
As for me, I can't predict the future, and its hard to say where I'd like to end up. I've always liked the idea of becoming an Architect, but my experience with them has not always been a pleasant one. My current plan is to continue coding until the pace of change is faster then the pace at which I can keep up. At that point, I think a management role will suit me better.
Do you have an overall career plan that will lead you to one of these two routes, or do you have another destination in mind?
But most of the training focused on the typical 'soft' skills of career development, such as communication, project management, organization, etc. While this may be the typical career development tasks for business people, for those in IT, and especially software development, these tasks will likely be on the periphery. The bulk of a Software Development training will center around the technical knowledge, software development processes (which are unique and ever evolving), software design, and project estimation. The consulting company Construx has a very good Professional Developer Handbook that I'd recommend checking out.
Soft skills, such as communication, are important, but present a unique challenge. While conversing with other developers, the technical terms and jargon can be used to quickly explain an issue. But, when conversing with business people, this needs to be kept to a minimum, even if it requires explaining the situation in a verbose manner.
There is another matter to discuss regarding career development: job promotion. There are two typical routes a developer will take. The first route takes a developer from a Junior Software Developer to a Senior Software Developer. Eventually, this developer learns a great deal about the processes and management of a software project and becomes a project manager.
The second route sees a developer progress further until they become a Software Architect or a DBA, or a specialist in some particular technical field. Or perhaps they continue to be a Senior Software Developer. Whatever the title, the second route arrives anywhere but management.
As for me, I can't predict the future, and its hard to say where I'd like to end up. I've always liked the idea of becoming an Architect, but my experience with them has not always been a pleasant one. My current plan is to continue coding until the pace of change is faster then the pace at which I can keep up. At that point, I think a management role will suit me better.
Do you have an overall career plan that will lead you to one of these two routes, or do you have another destination in mind?
Thursday, March 18, 2010
Reading Lists
The vast collection of Human Knowledge can be found in books. And sometimes, it feels like I have a large percentage of that knowledge in my book cases at home. Through Borders, eBay, Amazon, and Bookmooch.com, I have many places to get new books to add to my collection of Knowledge.
Yet this Knowledge goes to waste unless the volumes get to tell their story. That is why I have set up numerous reading lists for myself, and following my policy of making goals public, I have placed the current book from each list in a sidebar with a link to this page and I will keep this list updated.
As you can see on the sidebar, I currently have four reading lists: Certification, Software Development, Classical Education, and Miscellaneous.
The Certification list contains the textbook necessary for the Certification I am currently working on. Right now, I am pursuing either the MCTS Asp.Net 3.5 or 2.0 certification. The 3.5 Certification is more current, but the books for the 2.0 are a lot cheaper on Amazon. Either Certification requires 70-536, which is the test I am currently preparing for.
My Software Development reading list contains books on Software Development but aren't directly related to my Certification training. For this list, I am currently reading Mythical Man Month.
The Classical Education list contains books recommended by the book The Well-Educated Mind: A Guide to the Classical Education You Never Had. I came across this book a couple years ago thanks to the Book Lover's Page-a-Day Calendar. This Book describes the classical method of education and how to apply it to fiction novels, histories, autobiographies, plays, and poems. For each genre, it provides a reading list. Sadly, even though I've attempted 3 times to start this list, I've only completed abort half of the first book on the list, Don Quixote.
My Miscellaneous reading list includes any other book not on the other lists. Currently, I am reading Getting Results the Agile Way. Scott Hanselman tweeted about the book and I decided to look into it. The book describes itself as a system for managing outcomes that is easily incorporated into an existing System. Since starting this book, I have certainly found this to be the case. If you are like most people and need to get more at of your day, then you need to check out this book.
Yet this Knowledge goes to waste unless the volumes get to tell their story. That is why I have set up numerous reading lists for myself, and following my policy of making goals public, I have placed the current book from each list in a sidebar with a link to this page and I will keep this list updated.
As you can see on the sidebar, I currently have four reading lists: Certification, Software Development, Classical Education, and Miscellaneous.
The Certification list contains the textbook necessary for the Certification I am currently working on. Right now, I am pursuing either the MCTS Asp.Net 3.5 or 2.0 certification. The 3.5 Certification is more current, but the books for the 2.0 are a lot cheaper on Amazon. Either Certification requires 70-536, which is the test I am currently preparing for.
My Software Development reading list contains books on Software Development but aren't directly related to my Certification training. For this list, I am currently reading Mythical Man Month.
The Classical Education list contains books recommended by the book The Well-Educated Mind: A Guide to the Classical Education You Never Had. I came across this book a couple years ago thanks to the Book Lover's Page-a-Day Calendar. This Book describes the classical method of education and how to apply it to fiction novels, histories, autobiographies, plays, and poems. For each genre, it provides a reading list. Sadly, even though I've attempted 3 times to start this list, I've only completed abort half of the first book on the list, Don Quixote.
My Miscellaneous reading list includes any other book not on the other lists. Currently, I am reading Getting Results the Agile Way. Scott Hanselman tweeted about the book and I decided to look into it. The book describes itself as a system for managing outcomes that is easily incorporated into an existing System. Since starting this book, I have certainly found this to be the case. If you are like most people and need to get more at of your day, then you need to check out this book.
Tuesday, March 16, 2010
Technical Writing
Writing skills are a necessity in many different jobs, including Software Development. While it is one thing to be able to write code for a system, it is another to describe that change in writing. This can include the comments in the code, the check-in comments in the source control, a write-up of the fix in a bug tracking system, or a technical design. Each piece of documentation has a different use and target audience, and the first key for success is to understanding this and to write for your audience.
Inline code comments
Only developers will see your code comments. So feel free to use terms and language other developers world understand. The style, effectiveness and the format of code comments has been discussed and argued extensively. A Google search for "Comments in Code" returns a staggering 472 million results, so I will not attempt to discuss that here. But do remember that your audience can see the code themselves. Your comments will add nothing it they are simply repeating the code. What cannot always be conveyed through the code is why a particular coding method was used and the intent of the code.This is what your comments should explain when necessary.
Check-in Comments
Check-in comments are ained at other developers just like code comments. These comments should be short but informative. It should briefly describe what changed at a high level and for what defect or requirement so if another developer needs to know why a change was made they can reference the defect or requirement.
Defect Report
Defect reports will be read by other developers as well as testers, business analysts, and possibly support people. Writing for this large audience can be difficult at first, but I find the best approach is to write your response geared towards the non-technical folks first, and add more technical information in each subsequent paragraph as necessary. In this way, those who need just the basic information can get the information quickly, while other developers researching your issue at a later date will have all the logical and technical information that you have provided.
Technical Design
While college pretends to prepare yor for the real world, they never tell you quite how much of the time you will spend writing designs. I probably spend between 20 and 30 percent of my time reading or writing designs. The audience of your technical design may differ, but where I work, Developers, Business Analysts, and sometimes Testers will review designs, so the document must be accessible to all of them. Since Defect Reports and Technical Designs share the same audience, the guidelines for Defect Reports apply well to Technical Designs.
General Tips for Technical Writing
Remember that you're not writing the next great novel. Keep the language simple and use the same language or phrase to explain a task multiple times. There is no need to use a thesaurus to make each
10 Outline Document
20 Write Document
30 Revise Document
40 Goto 20
Software Development is unique in that in order to properly design it, you must first determine how to solve the problem. Once you have solved the problem in your head, you can begin to design it, but the process of designing it will reveal edge cases you didn't previously consider, and perhaps you will find places for improvement. Thus, you may find that you need to re-design your solution. The best way to write a technical design document is to follow the above process for a couple of iterations until you are comfortable with the document.
When writing for other developers, it is very useful to know the right terms. Every developer should know the name of common Design Patterns, technologies, and techniques, and using these terms in technical writing can allow the focus to remain on what is important, and not on the details of the Model/View/Controller design pattern.
Technical writing skills are a must for software developers. Unless you are working on a project by yourself, eventually you will need to tell someone else what the code does or what the code will do. However, even if you are the only developer on a project, code comments and documentation may save you if you ever forget why you wrote that dirty little hack in a method buried halfway down in the code base.
Inline code comments
Only developers will see your code comments. So feel free to use terms and language other developers world understand. The style, effectiveness and the format of code comments has been discussed and argued extensively. A Google search for "Comments in Code" returns a staggering 472 million results, so I will not attempt to discuss that here. But do remember that your audience can see the code themselves. Your comments will add nothing it they are simply repeating the code. What cannot always be conveyed through the code is why a particular coding method was used and the intent of the code.This is what your comments should explain when necessary.
Check-in Comments
Check-in comments are ained at other developers just like code comments. These comments should be short but informative. It should briefly describe what changed at a high level and for what defect or requirement so if another developer needs to know why a change was made they can reference the defect or requirement.
Defect Report
Defect reports will be read by other developers as well as testers, business analysts, and possibly support people. Writing for this large audience can be difficult at first, but I find the best approach is to write your response geared towards the non-technical folks first, and add more technical information in each subsequent paragraph as necessary. In this way, those who need just the basic information can get the information quickly, while other developers researching your issue at a later date will have all the logical and technical information that you have provided.
Technical Design
While college pretends to prepare yor for the real world, they never tell you quite how much of the time you will spend writing designs. I probably spend between 20 and 30 percent of my time reading or writing designs. The audience of your technical design may differ, but where I work, Developers, Business Analysts, and sometimes Testers will review designs, so the document must be accessible to all of them. Since Defect Reports and Technical Designs share the same audience, the guidelines for Defect Reports apply well to Technical Designs.
General Tips for Technical Writing
Remember that you're not writing the next great novel. Keep the language simple and use the same language or phrase to explain a task multiple times. There is no need to use a thesaurus to make each
10 Outline Document
20 Write Document
30 Revise Document
40 Goto 20
Software Development is unique in that in order to properly design it, you must first determine how to solve the problem. Once you have solved the problem in your head, you can begin to design it, but the process of designing it will reveal edge cases you didn't previously consider, and perhaps you will find places for improvement. Thus, you may find that you need to re-design your solution. The best way to write a technical design document is to follow the above process for a couple of iterations until you are comfortable with the document.
When writing for other developers, it is very useful to know the right terms. Every developer should know the name of common Design Patterns, technologies, and techniques, and using these terms in technical writing can allow the focus to remain on what is important, and not on the details of the Model/View/Controller design pattern.
Technical writing skills are a must for software developers. Unless you are working on a project by yourself, eventually you will need to tell someone else what the code does or what the code will do. However, even if you are the only developer on a project, code comments and documentation may save you if you ever forget why you wrote that dirty little hack in a method buried halfway down in the code base.
Thursday, March 11, 2010
Idle Hands
I'm currently reading through Getting Results, a productivity book based on desired outcomes. One of its guiding principles is to eliminate Analysis Paralysis, a condition that occurs when a person, Department, or institution becomes paralyzed while analyzing a set of alternatives. So much analysis occurs that nothing gets accomplished, whereas a great deal could have been accomplished if action was taken, even if it proved to be the wrong decision.
The new book Rework by Jason Fried and David Heinemeir Hansson of 37 Signals also espouses this idea that action is preferable to inaction. With the phrase 'Planning is Guessing' in the book, it is clear that the authors put little stock in up front planning.
From my limited experience, I have to agree that the state of doing is preferable to analyzing. About 2 years ago the development project I was on came to a screeching halt while many requirements were discussed for inclusion into the next release. For reasons I'll never fully understand management spent several months planning and debating the direction of our product, when we could have designed, developed, and tested a major release to the product.
During this time, the development team had little to do. About once a week I would ask for more work to do, but my manages rarely had anything for me. We had a few support issues to work on, and a few internal projects to work on, but I found myself with alot at free time.
As a developer on this project, my hands were tied. Due to a bad release cycle a couple years earlier, developers were not allowed to touch the code unless they had a specific requirement. We could have re-written piles of the code and done away with the behemoth 1000 and 2000 line functions, but that was not a decision the developers were allowed to make.
Anyway, it was during this fine that it formed a couple bad habits that l still have today. I began subscribing to numerous blogs, reading online technical articles, and even a couple of books during the day while waiting for work. During this time, I was exposed to Why's (Poignant) Guide to Ruby and Getting Real, both very good books from the Ruby community.
Today, I still find myself habitual Checking for new blog posts throughout the day, even though I have plenty of work to do. It is even worse now then before, because I'm following many more blogs today then ever.
In addition to the wasted time by having a development team do nothing for a long period of time, one also risks them becoming lethargic and the possibility that they develop bad habits that do not easily disappear when work returns.
The new book Rework by Jason Fried and David Heinemeir Hansson of 37 Signals also espouses this idea that action is preferable to inaction. With the phrase 'Planning is Guessing' in the book, it is clear that the authors put little stock in up front planning.
From my limited experience, I have to agree that the state of doing is preferable to analyzing. About 2 years ago the development project I was on came to a screeching halt while many requirements were discussed for inclusion into the next release. For reasons I'll never fully understand management spent several months planning and debating the direction of our product, when we could have designed, developed, and tested a major release to the product.
During this time, the development team had little to do. About once a week I would ask for more work to do, but my manages rarely had anything for me. We had a few support issues to work on, and a few internal projects to work on, but I found myself with alot at free time.
As a developer on this project, my hands were tied. Due to a bad release cycle a couple years earlier, developers were not allowed to touch the code unless they had a specific requirement. We could have re-written piles of the code and done away with the behemoth 1000 and 2000 line functions, but that was not a decision the developers were allowed to make.
Anyway, it was during this fine that it formed a couple bad habits that l still have today. I began subscribing to numerous blogs, reading online technical articles, and even a couple of books during the day while waiting for work. During this time, I was exposed to Why's (Poignant) Guide to Ruby and Getting Real, both very good books from the Ruby community.
Today, I still find myself habitual Checking for new blog posts throughout the day, even though I have plenty of work to do. It is even worse now then before, because I'm following many more blogs today then ever.
In addition to the wasted time by having a development team do nothing for a long period of time, one also risks them becoming lethargic and the possibility that they develop bad habits that do not easily disappear when work returns.
Tuesday, March 9, 2010
The Wisdom of Elders
I'm always surprises me whenever I'm told I've done a good job on something. Part of this is because I am my own toughest critic. I have not found an application where this trait has served me well, but it's who I am.
The other day, I was asked to take on a new responsibility at work. The task would require learning a new code library, but I jumped at the opportunity. My enthusiasm and willingness to take on new roles has really impressed the management at my company, but from my point of view, I've done nothing special.
Learning to me is second nature. I've been gifted with an insatiable appetite for knowledge in many fields. My many interests include computers, electrical engineering, history, writing, politics, astronomy, model railroading, geology, geography, photography, and gardening. There are so many sub-topics of computers that I'm fascinated with that I won't even try to list them all.
Part of my thirst for knowledge comes from two sayings my father told me while growing up. The first, which came from his grandparents, was that the day you did not learn anything new is the day you die. While morbid, it makes a good point. With this in mind, my family would go around the table at dinner and discuss one thing that we learned during the day.
The other saying my father shared with me when I was a teenager is that the one thing no one can take away from you is what you know. It is this saying in particular that really drives me to learn new things, and in a field that is constantly changing, like Software Development, if you are not moving forward, you are falling behind.
My father-in-law has also shared a couple tidbits of wisdom with me that are a bit more practical in nature. The first is to always have an updated resume. Unfortunately, we don't live in the 50s, when it would be possible for someone to work for one company their entire adult life. Nowadays, most workers will switch careers a couple times in their lives. Having a resume that is up-to-date will eliminate one necessary step for finding that next job.
I would even go so far as to suggest having a supplemental document to your resume that lists EVERYTHING under the sun that you can thing of that you know. I try to tailor my resume to the job I am applying for. While I'm not adding skills I don't have, I do emphasize skills highlighted in the job posting and removing skills that do not seem important.
An alternative to a supplemental document would be a CV. The Stack Overflow Careers site has a CV that you can fill out for free. So long as you remember to keep this document updated as well, I see no harm in using this instead of a supplemental document.
The final piece of wisdom comes from my father-in-law, who told me to dress as if I had been promoted to the next level up in the management chain. Thus, if you are not a manager, you should dress like one. If you are a manager, you should dress like an executive.
My work is very relaxed on dress code. In the summer, it is common to see people in khaki shorts, T-Shirts, and sandals. In the winter, Jeans, T-Shirt, and tennis shoes is the norm. So, when I started wearing Khaki pants, dress shoes, a button up shirt, and a sports coat, I certainly got a few remarks. I've dressed down a bit since the first day, opting for a T-Shirt under the sports coat. Since switching to this level of dress, I have felt a bit more confident and professional and that can never be a bad thing.
The other day, I was asked to take on a new responsibility at work. The task would require learning a new code library, but I jumped at the opportunity. My enthusiasm and willingness to take on new roles has really impressed the management at my company, but from my point of view, I've done nothing special.
Learning to me is second nature. I've been gifted with an insatiable appetite for knowledge in many fields. My many interests include computers, electrical engineering, history, writing, politics, astronomy, model railroading, geology, geography, photography, and gardening. There are so many sub-topics of computers that I'm fascinated with that I won't even try to list them all.
Part of my thirst for knowledge comes from two sayings my father told me while growing up. The first, which came from his grandparents, was that the day you did not learn anything new is the day you die. While morbid, it makes a good point. With this in mind, my family would go around the table at dinner and discuss one thing that we learned during the day.
The other saying my father shared with me when I was a teenager is that the one thing no one can take away from you is what you know. It is this saying in particular that really drives me to learn new things, and in a field that is constantly changing, like Software Development, if you are not moving forward, you are falling behind.
My father-in-law has also shared a couple tidbits of wisdom with me that are a bit more practical in nature. The first is to always have an updated resume. Unfortunately, we don't live in the 50s, when it would be possible for someone to work for one company their entire adult life. Nowadays, most workers will switch careers a couple times in their lives. Having a resume that is up-to-date will eliminate one necessary step for finding that next job.
I would even go so far as to suggest having a supplemental document to your resume that lists EVERYTHING under the sun that you can thing of that you know. I try to tailor my resume to the job I am applying for. While I'm not adding skills I don't have, I do emphasize skills highlighted in the job posting and removing skills that do not seem important.
An alternative to a supplemental document would be a CV. The Stack Overflow Careers site has a CV that you can fill out for free. So long as you remember to keep this document updated as well, I see no harm in using this instead of a supplemental document.
The final piece of wisdom comes from my father-in-law, who told me to dress as if I had been promoted to the next level up in the management chain. Thus, if you are not a manager, you should dress like one. If you are a manager, you should dress like an executive.
My work is very relaxed on dress code. In the summer, it is common to see people in khaki shorts, T-Shirts, and sandals. In the winter, Jeans, T-Shirt, and tennis shoes is the norm. So, when I started wearing Khaki pants, dress shoes, a button up shirt, and a sports coat, I certainly got a few remarks. I've dressed down a bit since the first day, opting for a T-Shirt under the sports coat. Since switching to this level of dress, I have felt a bit more confident and professional and that can never be a bad thing.
Thursday, March 4, 2010
Build failed on an ILog Project without an error
I was recently working on an ILog project. ILog is one of many Business Rule Engines out there. Business Rule Engines are becoming more popular. How do I know? Because one Developer wrote Space Invaders using a Business Rule Engine and Business Rules.
(As an aside, I'm not a big fan of Business Rule Engines because one of their touted benefits is that if will free Developer's time for other things. I have yet to see this benefit materialize on our project. However, they do have many other benefits, but that is another post for another time.)
While taking over the responsibility to maintain the business rules from another developer, I tried to build our rules project. Unfortunately the build failed without a message explaining why.
I exited the solution and reloaded. The reason for the build failure was displayed in the error list this time. In my case, the Model needed to be rebuilt. So I switched to the Business Object Model view and selected Refresh. When I went to Build the Solution, this time it succeed.
Each tool has its own quirks, and ILog is certainly no exception.
(As an aside, I'm not a big fan of Business Rule Engines because one of their touted benefits is that if will free Developer's time for other things. I have yet to see this benefit materialize on our project. However, they do have many other benefits, but that is another post for another time.)
While taking over the responsibility to maintain the business rules from another developer, I tried to build our rules project. Unfortunately the build failed without a message explaining why.
I exited the solution and reloaded. The reason for the build failure was displayed in the error list this time. In my case, the Model needed to be rebuilt. So I switched to the Business Object Model view and selected Refresh. When I went to Build the Solution, this time it succeed.
Each tool has its own quirks, and ILog is certainly no exception.
Tuesday, March 2, 2010
My goals for the next 3 months
What is not started today is never finished tomorrow
~Johann Wolfgang von Goethe
I like to set goals for myself and if I make them public. In doing so, I feel I'll put more effort to complete them. When I restarted this blog three months ago, I set several goals for myself. My first goal of the was to write 1 blog post a week on average. That worked out to 17 blog posts in all. I actually posted 21 blog posts in the last 3 months, so I did even better then I had planned.I also planned to redesign my Blog. While it still isn't professional looking, it is an improvement over the old design. I still have a few revisions I'd like to add but these are small changes that I will make over time.
Next, I planned to finish Strunk and White's Elements of Style and to reach the halfway point in the Self-Paced training kit for the MS Certification Test 70-536. I Finished both of these goals with ease and I've even started on the second half of self paced training kit.
Finally, I wanted to get my Stackoverflow rating op to 300. As of March 1st, it is 369.
As for the next 3 months, I'm going to build on the momentum I already have. I plan to write 20 blog posts in this quarter, starting with this one. Second, I'm going to finish the Self-Paced Training Kit for 70-536. Third, I'm going to finally read Mythical Man Month. Next, I'm going to get my Stackoverflow reputation up to 500. Finally, I'm going to make a contribution of some sort to the Open Source project (or create my own).
This time, I've chosen a more aggressive set of goals. But with all of the previous goals accomplished, I'm ready to tackle a new set of goals.
Subscribe to:
Posts (Atom)