I have a very tech-savvy brother who, although he is not a coder, I am absolutely certain he could pick up how to use most of the tools we software developers use. That is, with one exception- version control systems. Why do I believe I can teach my brother about complex IDE's but not version control? Because modern version control stinks!
I often think about what a version control system designed by Steve Jobs would look like. I don't know the answer but I am 100% certain it would not look like git, mercurial, or subversion. Linus is undoubtedly a genius but he was the wrong person to design the most used version control system in the world. Here are some thoughts on why git is hard to use.
Git, mercurial, and subversion were all developed within the last ten years or so. Even though they were developed in the 21st century, they seem to be designed with 1980's constraints. They are all optimized to be very disk efficient. They trade minimizing the disk impact of recording raw differences in files for recording more useful data about the programming process. Hard disks are tremendously inexpensive these days and are moving toward obsolescence. So, why don't we fill our cheap hard disks with more information about the programming process?
What information should we be recording about how a developer works with a set of files? Well, how about all of it? Because modern version control systems don't record this information one cannot:
- Write good commit messages
When writing a commit message one cannot review all the changes that were made since the last commit. Without being able to see all the changes one often can't recall all the interesting twists and turns that have happened in the coding session. More importantly, one cannot write down the reasons why some decisions were made. We remember some of these reasons for a certain amount of time but it would be nice to have a record of low level decisions for anyone who has to maintain the code later.
How often have you found yourself paralyzed by trying to come up with a short description of all the changes that took place since your last commit? It can be as hard to describe the changes as it was to write the code itself. I believe this is the cause of most of the extremely short commit messages that provide little or no value. If one could review their work I think we would have better commit messages.
- Visualize changes easily
The tool 'diff' shows the raw differences between two files. However, it does not show the order that the changes were made and does not show any context about the changes. The 'context' that I am talking about are the reasons why the changes were made. If one were able to see what order the changes were made and have a narrative to go along with those changes one might have a better sense of how the pieces fit together.
- Tell stories about the system
Commit messages could help us understand the changes in our systems if we wrote good ones. Unfortunately most of us do not. So, if we don't have meaningful commit messages and we can't visualize how the changes were made, it is unlikely that someone will easily understand the evolution of a piece of software.
Imagine that one could visualize the changes as they were made, and during this visualization a developer could pause the playback of the code and write a message about why they made a decision. Now imagine if a series of these messages could be tied together and linked to the code being played back. One could then review one's work at a natural stopping point and tell a story about the latest changes. If these stories could be searched directly from the code, for example by highlighting some code and seeing what stories include that code, then someone responsible for maintaining code could get inside the mind of the original developer and understand their thought processes. This is valuable information that doesn't get written down anywhere else.
- Teach your colleagues
With the ability to record the reasons why we do things that is linked to the code but not in code comments, developers can more easily become teachers. Working on a computer is such a solitary activity that it is hard developers to learn from each other. You might be sitting three feet away from a great programmer and never learn anything from them. We need a way to open up the programming process so that we can learn from each other.
Each one of these deficiencies limits the amount of knowledge one can acquire by working with legacy code. Each can be remedied if we rethink how version control systems can help us understand how our code has evolved. The version control system I am developing records every single keystroke, delete, copy and paste, and file operation. This information can be used to replay development sessions. A developer can replay certain parts of how their system has evolved and tell stories about it.
Monday, April 15, 2013
Monday, April 8, 2013
Learning computer science should also be about learning entrepreneurship
It costs virtually nothing to start a business that manipulates data as its main business model. The obvious reason computer science students should learn about entrepreneurship is because they have the best chance of learning how to build a business early in their careers simply by attempting to do it. They do not have to raise significant capital to get the business off the ground. The barrier to entry is high for biology, chemistry, or physics students who would like to start a science-based business.
There is a less obvious link between learning computer science and entrepreneurship, however. Developing a program and developing a company have a lot in common. When I sit down to write a complex program I know, before I even begin, that there are some things that I will need to accomplish that I have no idea how to do. I won't even know exactly what needs to be done until I have made some progress in earlier steps and get some feedback from the running program. That sounds like an accurate description of starting a business to me.
When I introduce a complex programming project to my students I tell them that there are many paths that they can go down. To be a good programmer, one has to be able to venture down one of these paths and, if they decide they have made a poor choice, back up and start again. The best programmers do not fear throwing out work that they have spent a great deal of time and effort on. The best programmers look at the journey down the wrong path as a learning experience. Inexperienced programmers bend over backwards to keep the code they have been working on even when they know it is not the best solution to a problem. They cannot bring themselves to throw out hours, days, or weeks worth of work. The worst thing that a programmer can do is to become paralyzed with the fear of failure. When there are an overwhelming number of options or paths to go down, one must choose one and start walking. They might not have chosen correctly but they can't know that until they start.
One of the great things about computer programming is the tight feedback loop that a programmer has. A developer can write some code and be able to test whether the decision they made with that code moved the program forward or not. Once a developer sees some running code that verifies their understanding of the system they look at the problem in a new way. They understand how the small piece of the solution that they just tackled will influence the rest of their work. They can now see a couple steps ahead that they couldn't see before. All progress is made by having confidence in an initial idea and then moving down the path a little farther than before (or, realizing that the initial idea was not the best, starting over with a different idea). All progress is made in baby steps.
I am going through Steve Blank's 'How to Build a Startup' course right now. When starting a business one is also faced with many choices and paths. Startups should create a minimal viable product (MVP) that does not have all the bells and whistles of a production piece of software but has enough to get feedback from customers. Then, founders must 'get out of the building' and go talk to customers. This is equivalent to running one's program and taking a few more steps down the right path. I tell my students not to write code for eight hours before compiling it for the first time. They should write a few lines of code and then run them to see what effect they had on the system. This is similar to the MVP. Building a startup on an untested theory about what your customers want is like going too long in between compiles and runs.
Founders must not fear backing up and trying something new. This is called a pivot and the founders have to repeat the process until they know they are building the right business. It is common, even expected, that startup founders fail more often than most people. Most people have an adverse relationship with failure but entrepreneurs and computer programmers are used to it. Computer science students should learn about entrepreneurship because they are conditioned to try, fail, learn, and repeat. They are unwittingly trained in the skills that most entrepreneurs find to be the hardest to learn!
There is a less obvious link between learning computer science and entrepreneurship, however. Developing a program and developing a company have a lot in common. When I sit down to write a complex program I know, before I even begin, that there are some things that I will need to accomplish that I have no idea how to do. I won't even know exactly what needs to be done until I have made some progress in earlier steps and get some feedback from the running program. That sounds like an accurate description of starting a business to me.
When I introduce a complex programming project to my students I tell them that there are many paths that they can go down. To be a good programmer, one has to be able to venture down one of these paths and, if they decide they have made a poor choice, back up and start again. The best programmers do not fear throwing out work that they have spent a great deal of time and effort on. The best programmers look at the journey down the wrong path as a learning experience. Inexperienced programmers bend over backwards to keep the code they have been working on even when they know it is not the best solution to a problem. They cannot bring themselves to throw out hours, days, or weeks worth of work. The worst thing that a programmer can do is to become paralyzed with the fear of failure. When there are an overwhelming number of options or paths to go down, one must choose one and start walking. They might not have chosen correctly but they can't know that until they start.
One of the great things about computer programming is the tight feedback loop that a programmer has. A developer can write some code and be able to test whether the decision they made with that code moved the program forward or not. Once a developer sees some running code that verifies their understanding of the system they look at the problem in a new way. They understand how the small piece of the solution that they just tackled will influence the rest of their work. They can now see a couple steps ahead that they couldn't see before. All progress is made by having confidence in an initial idea and then moving down the path a little farther than before (or, realizing that the initial idea was not the best, starting over with a different idea). All progress is made in baby steps.
I am going through Steve Blank's 'How to Build a Startup' course right now. When starting a business one is also faced with many choices and paths. Startups should create a minimal viable product (MVP) that does not have all the bells and whistles of a production piece of software but has enough to get feedback from customers. Then, founders must 'get out of the building' and go talk to customers. This is equivalent to running one's program and taking a few more steps down the right path. I tell my students not to write code for eight hours before compiling it for the first time. They should write a few lines of code and then run them to see what effect they had on the system. This is similar to the MVP. Building a startup on an untested theory about what your customers want is like going too long in between compiles and runs.
Founders must not fear backing up and trying something new. This is called a pivot and the founders have to repeat the process until they know they are building the right business. It is common, even expected, that startup founders fail more often than most people. Most people have an adverse relationship with failure but entrepreneurs and computer programmers are used to it. Computer science students should learn about entrepreneurship because they are conditioned to try, fail, learn, and repeat. They are unwittingly trained in the skills that most entrepreneurs find to be the hardest to learn!
Wednesday, March 27, 2013
Knowledge work is a lonely activity
Performing work on a computer is a mostly solitary activity. One can generally only reflect on one’s own experiences. It is difficult to get inspiration and learn from others. Because of the nature of our work and the tools we use it is as if we software developers go out of our way to hide how we do our work.
Imagine if you were learning to play chess but you could never play against anyone but yourself. One cannot expect to become a great chess player without being able to watch masters play the game. After they leave school many software developers are left in this situation. It is not so easy for others to watch and learn from knowledge workers doing work on a computer because working in front of a monitor in a cube is not an inviting learning environment.
The software development community is in need of tools that open up the development process to encourage learning by team members. It is critically important to:
Software developers need to be continuous learners to keep up with changes in the field. Young developers fresh out of college have decade’s worth of learning in front of them. The questions that I am interested in are:
Try, then fail, then fix
Failing at something followed by remedial work can lead to excellent gains in knowledge. However, this knowledge can be painful to acquire. Perhaps the most insidious characteristic of this type of learning is how difficult it is to impart the hard earned knowledge on others. Only the developer who makes the mistake and fixes it learns.
Read books and blogs
Books and blog posts on the subject of software development are great tools for professional developers to learn. However, not every topic has a high quality book or blog post written about it. Invariably, each developer encounters some level of specialization where finding reading material is impossible.
Read code
One might think that reading good code is a natural way to learn to become a better programmer. This can be tricky, however, because most developers read code left to right, top to bottom, jumping occasionally to other functions and files. But, how often is code actually written this way?
When writing code it is common to touch many different parts of many different files. The order of the additions and the deletions has an impact on how a problem was solved. Existing version control systems do not record enough of this information.
Code comments could be useful for telling a story about a system but they are not always the best place to record historical information. For example, if a developer is changing the name of a variable from ‘age’ to ‘yearsExperience’, they could write a comment about why that change was needed. That comment is really only relevant to the people who knew the old name and are interested in why the old name changed. Developers who never knew the old name are not interested in that comment. So, most developers would not write down that information anywhere.
Commit logs
On check in, developers write a commit message to the version control log. These logs could help animate the changes in a group of files if developers wrote good messages. Unfortunately, they do not. It is very difficult to write a complete description of all the changes that take place from one commit to another. Remembering and describing why we make a set of changes in a commit message is almost as hard as writing the code itself.
Code reviews
Code reviews are an excellent way to learn from one's peers. Some of the best discussions I have ever had about software engineering have taken place in code reviews. There is a significant drawback to code reviews, however, the team only gets one chance to perform the review. If one is not lucky enough to be in that review they miss out on all the learning that takes place there. Ideally, a narrative about a code review would exist that all developers could consume.
Q&A sites
Question and answer websites that target developers and programming problems provide good opportunities for learning. One criticism of these opportunities is that they only happen when a developer is stuck. In other words, the sites provide only reactive opportunities to learn, not proactive ones.
There are clearly many people who are willing to help provide these reactive learning experiences. The people who answer questions have different motivations. Some genuinely want to help others learn something about software development. Some are building reputations that they hope to leverage professionally and some are supporting specific products. Regardless of why people choose to answer questions, they should have a chance to be more proactive.
Why don't we record more?
I have had discussions with professional software developers about how our tool records every single keystroke and makes it available to be played back. Some are afraid of others being able to see all the mistakes that they make. Some have even asked if there was an option to 'turn off' the recording of data.
I try to explain that all developers make mistakes and that there is value in a lot of those mistakes. One can teach their colleagues by walking them through the misunderstandings and misconceptions they had of their system. Most of the mistakes I make are due to an incomplete understanding of the requirements, the existing system, or the algorithms being used. If I am having trouble understanding these then surely someone else might be too. Why should we all have to suffer through the same painful discovery process?
If we recorded more data about the programming process and provided stories about the reasons why things were done a certain way it would be easier for us to teach and learn from each other. Knowledge work would become a less lonely activity.
Imagine if you were learning to play chess but you could never play against anyone but yourself. One cannot expect to become a great chess player without being able to watch masters play the game. After they leave school many software developers are left in this situation. It is not so easy for others to watch and learn from knowledge workers doing work on a computer because working in front of a monitor in a cube is not an inviting learning environment.
The software development community is in need of tools that open up the development process to encourage learning by team members. It is critically important to:
- get feedback from ‘masters’ about our work
- see how developers leverage good decisions and extend their position from them
- see how developers recover from bad decisions
Software developers need to be continuous learners to keep up with changes in the field. Young developers fresh out of college have decade’s worth of learning in front of them. The questions that I am interested in are:
- How do software developers learn about the systems they are hired to work on so they can be effective members of a team?
- How do software developers learn to be better programmers after they have left school?
Try, then fail, then fix
Failing at something followed by remedial work can lead to excellent gains in knowledge. However, this knowledge can be painful to acquire. Perhaps the most insidious characteristic of this type of learning is how difficult it is to impart the hard earned knowledge on others. Only the developer who makes the mistake and fixes it learns.
Read books and blogs
Books and blog posts on the subject of software development are great tools for professional developers to learn. However, not every topic has a high quality book or blog post written about it. Invariably, each developer encounters some level of specialization where finding reading material is impossible.
Read code
One might think that reading good code is a natural way to learn to become a better programmer. This can be tricky, however, because most developers read code left to right, top to bottom, jumping occasionally to other functions and files. But, how often is code actually written this way?
When writing code it is common to touch many different parts of many different files. The order of the additions and the deletions has an impact on how a problem was solved. Existing version control systems do not record enough of this information.
Code comments could be useful for telling a story about a system but they are not always the best place to record historical information. For example, if a developer is changing the name of a variable from ‘age’ to ‘yearsExperience’, they could write a comment about why that change was needed. That comment is really only relevant to the people who knew the old name and are interested in why the old name changed. Developers who never knew the old name are not interested in that comment. So, most developers would not write down that information anywhere.
Commit logs
On check in, developers write a commit message to the version control log. These logs could help animate the changes in a group of files if developers wrote good messages. Unfortunately, they do not. It is very difficult to write a complete description of all the changes that take place from one commit to another. Remembering and describing why we make a set of changes in a commit message is almost as hard as writing the code itself.
Code reviews
Code reviews are an excellent way to learn from one's peers. Some of the best discussions I have ever had about software engineering have taken place in code reviews. There is a significant drawback to code reviews, however, the team only gets one chance to perform the review. If one is not lucky enough to be in that review they miss out on all the learning that takes place there. Ideally, a narrative about a code review would exist that all developers could consume.
Q&A sites
Question and answer websites that target developers and programming problems provide good opportunities for learning. One criticism of these opportunities is that they only happen when a developer is stuck. In other words, the sites provide only reactive opportunities to learn, not proactive ones.
There are clearly many people who are willing to help provide these reactive learning experiences. The people who answer questions have different motivations. Some genuinely want to help others learn something about software development. Some are building reputations that they hope to leverage professionally and some are supporting specific products. Regardless of why people choose to answer questions, they should have a chance to be more proactive.
Why don't we record more?
I have been working with my students on a new version control system that captures very fine-grained, textual information about coding sessions. It allows the sessions to be played back so a developer can tell a story about their code. These stories form a new type of program documentation that can be viewed by team members to learn about the systems they are working on and to learn how to become better developers.
I have had discussions with professional software developers about how our tool records every single keystroke and makes it available to be played back. Some are afraid of others being able to see all the mistakes that they make. Some have even asked if there was an option to 'turn off' the recording of data.
I try to explain that all developers make mistakes and that there is value in a lot of those mistakes. One can teach their colleagues by walking them through the misunderstandings and misconceptions they had of their system. Most of the mistakes I make are due to an incomplete understanding of the requirements, the existing system, or the algorithms being used. If I am having trouble understanding these then surely someone else might be too. Why should we all have to suffer through the same painful discovery process?
If we recorded more data about the programming process and provided stories about the reasons why things were done a certain way it would be easier for us to teach and learn from each other. Knowledge work would become a less lonely activity.
Monday, March 25, 2013
The right way and the wrong way for learning a thinking person's craft
I have been teaching computer science to undergraduates for more than ten years. Lately, I have had a sneaking suspicion that I (and the rest of the world) am doing it wrong. One learns to write good software by first writing a lot of bad software. Then, one day, after having written a lot of code, one becomes good enough to write software professionally. For me, I first felt qualified to write software professionally at least one year after graduation. During that year or so I was paid very well to learn how to do it right. I am very grateful to the company that subsidized this learning experience for me but I have a feeling they would have preferred hiring someone ready to make a lasting contribution on or around day one.
Why aren't most freshly minted computer science graduates qualified to write code professionally?
I believe a fundamental problem with the typical undergraduate computer science curriculum is that it breaks its learning units into discrete, relatively non-overlapping units that don't emphasize an integrated, hands-on approach to learning the craft. It drives me crazy when a student asks me about the syntax for creating an interface in some programming language because they have not actually done it since their OOP class. Similarly, I feel like I haven't done my job well when they ask me how to spawn a thread because they haven't done so since their operating systems class.
Writing software is a craft. One definition of craftsman is "one that learns by doing". Cabinet makers do not take separate courses on framing, drawer construction, and finishing and then wait until they leave cabinet making school to build their first cabinet. They learn those skills by spending several hours each day practicing them. With all their other responsibilities, I would guess that the typical undergraduate computer science student does not spend several hours a day, every day, writing code. They don't, but they should. We should expect them to do that. We should set up an environment where they can do that.
Should software development be taught like a trade like cabinet making or plumbing?
An argument can be made that there should be trade schools that teach software development. Perhaps it should not be taught in the same higher education environment that students learn mathematics or biology. There is a growing movement to train software developers through mentoring and on the job training. 8th Light in Chicago is an example of doing this well.
However, writing software is a thinking person's craft. Having been around software developers for more than 15 years I believe that those who receive a liberal arts education are more interesting people. They work better with others. They are better readers, writers, and communicators. They have a distinct advantage in all of the 'soft' people skills that are as important as the 'hard' technical skills. We should not deny computer science students the opportunity to grow in these environments. This is the dilemma- software developers need a mix of a craftsman's education and a traditional college education.
The right way
If I had no restrictions in setting up a new curriculum for computer science students these are some of the things that I would do to mix learning styles:
Students who are interested in computer science will start with the traditional sequence of introductory courses in their first two years. They will take other courses to meet full time status. In other words, there will not be any difference for freshmen and sophomores studying computer science in this new environment than in a traditional environment.
Then, after a student has committed to studying computer science, they would transition to a mix of a traditional and a craftsman's learning environment during their final two years. Students will spend at least four hours a day, five days a week, for at least the last two years of a four year education working:
Projects
A college would have to set up an entity to take on projects for the community, local schools, for departments and programs within the college, for churches, for local government bodies. This would be the epitome of technology-based service learning. One side effect is that it might attract more women to CS. Women are generally attracted to solving real world problems whereas the men are interested in technology for technology's sake. Everyone would start out working on someone else's open source project. Eventually, everyone would create several of their own open source projects.
Occasionally, I have excellent students who don't have a lot of interesting work to show potential employers. With this model, upon graduation, every student will have a real portfolio of work to show potential employees and real experience working in a group.
Why aren't most freshly minted computer science graduates qualified to write code professionally?
I believe a fundamental problem with the typical undergraduate computer science curriculum is that it breaks its learning units into discrete, relatively non-overlapping units that don't emphasize an integrated, hands-on approach to learning the craft. It drives me crazy when a student asks me about the syntax for creating an interface in some programming language because they have not actually done it since their OOP class. Similarly, I feel like I haven't done my job well when they ask me how to spawn a thread because they haven't done so since their operating systems class.
Writing software is a craft. One definition of craftsman is "one that learns by doing". Cabinet makers do not take separate courses on framing, drawer construction, and finishing and then wait until they leave cabinet making school to build their first cabinet. They learn those skills by spending several hours each day practicing them. With all their other responsibilities, I would guess that the typical undergraduate computer science student does not spend several hours a day, every day, writing code. They don't, but they should. We should expect them to do that. We should set up an environment where they can do that.
Should software development be taught like a trade like cabinet making or plumbing?
An argument can be made that there should be trade schools that teach software development. Perhaps it should not be taught in the same higher education environment that students learn mathematics or biology. There is a growing movement to train software developers through mentoring and on the job training. 8th Light in Chicago is an example of doing this well.
However, writing software is a thinking person's craft. Having been around software developers for more than 15 years I believe that those who receive a liberal arts education are more interesting people. They work better with others. They are better readers, writers, and communicators. They have a distinct advantage in all of the 'soft' people skills that are as important as the 'hard' technical skills. We should not deny computer science students the opportunity to grow in these environments. This is the dilemma- software developers need a mix of a craftsman's education and a traditional college education.
The right way
If I had no restrictions in setting up a new curriculum for computer science students these are some of the things that I would do to mix learning styles:
Students who are interested in computer science will start with the traditional sequence of introductory courses in their first two years. They will take other courses to meet full time status. In other words, there will not be any difference for freshmen and sophomores studying computer science in this new environment than in a traditional environment.
Then, after a student has committed to studying computer science, they would transition to a mix of a traditional and a craftsman's learning environment during their final two years. Students will spend at least four hours a day, five days a week, for at least the last two years of a four year education working:
- with a mentor
- in a lab on campus dedicated to the craft
- with changing team members
- on different projects both large and small
- during the summer (if not interning for a company)
Projects
A college would have to set up an entity to take on projects for the community, local schools, for departments and programs within the college, for churches, for local government bodies. This would be the epitome of technology-based service learning. One side effect is that it might attract more women to CS. Women are generally attracted to solving real world problems whereas the men are interested in technology for technology's sake. Everyone would start out working on someone else's open source project. Eventually, everyone would create several of their own open source projects.
Occasionally, I have excellent students who don't have a lot of interesting work to show potential employers. With this model, upon graduation, every student will have a real portfolio of work to show potential employees and real experience working in a group.
Monday, January 14, 2013
The invisibility of software and the coding warroom
Software is one of the few things built by humans that is incredibly hard for us to fully see. This is true during the construction process and after it is 'complete' (one problem is that good software is never really complete- new features are constantly added, it is made easier to use, and it gets fixed when bugs are found). It is very difficult to get a sense of how all the pieces fit together.
When asked by a layman to describe how modern software (i.e. large software) is built I like to use an analogy. Building a large piece of software is like building a skyscraper where the construction workers can only work at night and each worker has only a small flashlight to guide them. One can only see about ten feet in front of them at any one time.
We write code on small screens and can only see a tiny fraction of it at any one time. We use certain models to help get different perspectives of our systems but we cannot pick up and examine the pieces and see how they fit together like we can with almost every other thing that is engineered.
It is even harder to visualize how software changes over time. With time lapse photography one can see how a skyscraper evolves but the same is not possible with software. How does one see how some exceptional work has evolved from the early beginnings to a mature and extensible solution? Most of the code I am proud of was grown over many iterations. There is usually a good story about how the code changed over time but these stories rarely get told to anyone and almost never get written down anywhere. They stay in our heads for a little while but they inevitably escape into the ether.
In order for developers to grow and learn we must open up for examination how we do our work. One would think that knowledge workers, because of their ability to gather and manipulate data, would excel at capturing and presenting this information to their peers. However, if you look at some of our tools (our version control systems in particular) we are pretty bad at it. For example, some of the most valuable thought work that we do happens at the whiteboard. Inevitably, it gets erased shortly after we create it. We rely on our memories to store much of this valuable information and the stories about how the work has evolved. I think a more reliable storage mechanism should be used.
I have often wondered what it would be like for software developers to project their work in 'warroom' like environments. Imagine groups of developers working together where everyone could see what is happening by members of the team. This would certainly help (at least partially) solve the 'invisibility' problem by expanding our view of the system beyond the 10 foot limit.
When asked by a layman to describe how modern software (i.e. large software) is built I like to use an analogy. Building a large piece of software is like building a skyscraper where the construction workers can only work at night and each worker has only a small flashlight to guide them. One can only see about ten feet in front of them at any one time.
We write code on small screens and can only see a tiny fraction of it at any one time. We use certain models to help get different perspectives of our systems but we cannot pick up and examine the pieces and see how they fit together like we can with almost every other thing that is engineered.
It is even harder to visualize how software changes over time. With time lapse photography one can see how a skyscraper evolves but the same is not possible with software. How does one see how some exceptional work has evolved from the early beginnings to a mature and extensible solution? Most of the code I am proud of was grown over many iterations. There is usually a good story about how the code changed over time but these stories rarely get told to anyone and almost never get written down anywhere. They stay in our heads for a little while but they inevitably escape into the ether.
In order for developers to grow and learn we must open up for examination how we do our work. One would think that knowledge workers, because of their ability to gather and manipulate data, would excel at capturing and presenting this information to their peers. However, if you look at some of our tools (our version control systems in particular) we are pretty bad at it. For example, some of the most valuable thought work that we do happens at the whiteboard. Inevitably, it gets erased shortly after we create it. We rely on our memories to store much of this valuable information and the stories about how the work has evolved. I think a more reliable storage mechanism should be used.
I have often wondered what it would be like for software developers to project their work in 'warroom' like environments. Imagine groups of developers working together where everyone could see what is happening by members of the team. This would certainly help (at least partially) solve the 'invisibility' problem by expanding our view of the system beyond the 10 foot limit.
Monday, January 7, 2013
So, you think you're a good software developer? Who have you taught lately?
The Learning Dilemma
The day one graduates from college with a degree in computer science is usually a joyous day. It is on this day, however, that most realize that their educations have really just begun (I know I felt rather unqualified at this point). All software developers have decades worth of learning in front of them. In no other field is this more true than in computer science. Our field is so new and so important that one cannot expect to make a real contribution without a serious commitment to learning over an entire career.This knowledge will be hard to acquire, however, because there will be no more lectures, formal assignments, tutors, or professors to guide them along the right path. For a professional developer, most learning takes place while building a real system. To make matters worse, knowledge workers have an additional burden- it is extremely hard to see how others do their work.
Working on a computer is a mostly solitary activity. We sit in front of our machines and do our work. Rarely, do we invite others to see what we do or how we do it. There may be a great developer sitting three feet away from you but it is unlikely that you will ever learn anything from watching them work. Or, you may be that great developer, and you may be surrounded by lesser developers who want desperately to learn what you know. Because of the nature of work done on a computer it is not entirely clear that your knowledge will spread to the people geographically close to you. Compare this with sculptors sharing an art studio and you will see that knowledge workers are at a disadvantage.
Good Developers Teach
We have excellent teaching resources available to us, these are our best developers. There is a dangerous misconception that our 'rock star' developers are too valuable to slow down to help teach the rest of the team. I would argue that if you want to call yourself a good developer you must:- actively teach the people around you to become better
- actively seek out learning experiences from others with different experiences
Our best developers should be given a venue to teach what they know. Management should survey the team to find the most obvious and high value deficiencies of the majority that can be remedied by the minority. The lesser developers on the team may not be able to teach the rock stars many things about software development but they can teach about other experiences that might be of value. For example, I learned a lot about the culture of China from a chinese co-worker of mine who was an electrical engineer. This knowledge has colored my view of offshore manufacturing and engineering ever since.
My advice for computer science students who are still in school is to try and land a job as a department tutor. You will learn how to teach others by listening to how your clients perceive their problems and coming up with suggestions that match their needs. You will take this skill with you into the 'real world' where it will be put to good use. Interestingly, since people perceive things differently and have different backgrounds you will most likely learn things from the people you are trying to teach! This is something that always amazed me while I was a tutor and still amazes me today as a college professor.
Subscribe to:
Posts (Atom)