Note: This is a reposting from my previous blog. I'm just "migrating" the posts that I feel a need to keep track of.

As a student at Rose-Hulman Institute of Technology, I am lucky to work with some of the most engaging and brilliant professors in the world. These professors are a great resource for nearly any question and I am hard pressed to find a question that someone in the relatively small department doesn't know. Many of their lectures are littered with information that references colleagues and leaders in the computer science and software engineering world.

In particular, software engineering courses tend to rely on very recent research. Heuristics, models and standards that professors mention are starting to be developed later and later. For example, in my Software Maintenance and Evolution course, Dr. Bohner (Shawn) frequently mentions men and women in industry that have just been recently published on that particular topic. The body of knowledge for software engineering is evolving itself at a very rapid pace. For example, 8 years ago Agile and xPM were non-existent; but, now they are fundamental in Software Project Management.

And, it seems, the information that I am learning today will be obsolete by the end of this year. And, in 1.5 years, I will no longer be a student; I will be working in industry. This concerns me because I believe that I will no longer have the exposure to the breadth of knowledge that I have in academia. Through personal experience, I have found that members of industry are a bit lagged in adoption or creation of cutting edge methods, models and technologies. I have a great appetite for knowledge and I want to keep on the leading edge of the field. After discussing the issue with several professors, I came to the conclusion that there is no "silver bullet."

[caption id="" align="alignright" width="346" caption="An example of how a simple knowledge web might work."][/caption]

I was looking for a blog or a blog roll that would keep me up to date in a relatively short amount of time. However, I found that such blogs are very difficult to find and their value is limited. On average, the blogs that deal with software engineering in detail on a regular basis have post about once every month. In order to deal with this issue, I have come up with the "knowledge web." A knowledge web is a method and model for maintaining and evolving a software engineer's skills and knowledge. As the body of knowledge changes, software engineers should change with it. The model has a set of entities and a set of connections. Entities are people that work in the area of software engineering. Connections are methods of communication between those people. An example of a diagram representing a knowledge web is below: There are several benefits to a knowledge web. In the limited example above, one benefit can be easily seen. I (the figure at the bottom) only know two people and possibly through indirect means (email and blog).

However, I have access to the body of knowledge of 4 other people through indirect means. An example is that I could email a professor proficient in databases and ask him "What would be the best type of database to stored irregular data?" The professor may know and I would get an answer back. However, that professor may not know but knows a researcher that was answering this exact question. The professor either contacts the researcher or gives me contact information.

Another benefit of the knowledge web is that it is self serving. In the example above, if the professor gave me the contact information I would have one more direct member of my knowledge web. This is important because a knowledge web can only go so deep. It would be difficult to imagine a "chaining" of more than 2 or 3 would ever occur. However, by conversing with that researcher and making a direct contact, I have eliminated one link in that chain and giving me more access to different people.

There are some foreseen complications with the knowledge web model. For example, as a member of industry a person may know several direct contacts. However, if those direct contacts within the company only know others within the company, there are no "secondary" contacts outside of the system. This can lead to a separation of this isolated group from the rest of the body of knowledge. So, to mitigate this risk, a web should be made of several people from several different areas (academia, research, industry, etc.) for several different locations (Europe, West Coast, East Coast, etc.).

As mentioned before, chaining will only go so far. So, expectations that knowing "the right guy" that has all of the connections can get you that full body of knowledge is likely not true. Instead, software engineers should build their own knowledge webs that make them "the right guy." I am personally developing my own knowledge web. It is currently very limited but I hope to expand it quickly and thoughtfully. I want to get to know more people in European countries, big companies, west coast companies and bleeding edge researchers. I want to get to know more academics and read my industry leader blogs and attend more conferences. Hopefully, by the time that I graduate, I will be equipped to be better informed that my colleagues in industry.

Also, as an aspiring Project Lead and, eventually, Project Manager, I think that I will employ this as a simple exercise that my engineers perform every so often. The quickest method of doing this is to ask "Whom, outside of the company, do you know in the fields of Computer Science and Software Engineering? Please list name, position, company and company location for each person." With some practice, I am sure that it would be easy to estimate the effectiveness of each engineer's web.

As I have reread this post, I still believe that a "Knowledge Web" is of great importance and I feel that I have really started to build a solid foundation for that. Blogs and books are a key part of that but still are of limited use. Software engineers still need to branch out and be able to pick the mind of the entire industry--not just Scott Hanselman or Martin Fowler or Robert Martin (as good as those guys are).