There are many different ways to learn how to become a software developer. One can go to college and learn about computer science for four years. Or, one can learn on their own with books or one of the many great and free online course aggregators and interactive tutorial sites. One can even get intense training in a very specific niche in the field. I would guess there are people working on even more distinctive and new ways to deliver the content a programmer needs to know in order to be effective. This is all great for those of us who love to code and want others to love it too.
However, even though there are new content delivery technologies we have to remember that learning to be a software developer has not gotten easier because of them. Acquiring the content is important, of course, but I don't believe it matters much whether you learned the content from a college professor, read it in a book, or learned it in an online course. What matters is how you grow from an inexperienced developer to an experienced one.
Imagine if you were interested in learning how to paint. You could take some courses at a college, watch online videos about painting, and even use some interactive web apps to hone a technique or two. But none of these will make you a great painter. The only way to become a great painter is to do a lot of painting (and even that doesn't guarantee that you will ever be great).
This is as true with painting as it is with developing software. The only way to become a great software developer is to write a lot of software. You will not be very good at first but then you will get better. It will be hard and frustrating. If you put enough effort into it, however, you will grow as a developer. You will not grow simply by acquiring all the content from these new teaching technologies.
Different people have different preferences for acquiring content. Having different avenues for acquiring knowledge is great but lets not make the mistake of thinking that it is any easier to learn how to become a software developer today than it was ten years ago. I believe programming is one of the purest forms of thoughtful design and creativity. It has always been hard and I believe it will always be hard.
Monday, April 22, 2013
Monday, April 15, 2013
Why modern version control stinks
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.
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 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!
Subscribe to:
Posts (Atom)