Thoughts on Github Copilot
A couple of weeks ago, Github announced an immediately polarising new tool, Github Copilot. Some though it looked excellent, others presented concerns that it would prevent people from truly understanding what they’re doing, yet more declared significant concerns over licensing, and what the copyright impacts of using code that was effectively derived from repositories that might be licensed under GPL would be (rel: Twitter).
Leaving aside the nightmareish warren of legal ramifications, these are my thoughts on why and how it could be used.
In a Nutshell
Provided it does what it says it does, Copilot has the potential to be the tool that our industry desperately needed: a way to help entry-level devs be productive and effective while learning about what makes good code. That said, like all training wheels they do have to be taken off at some point if you really want to become an adept software engineer(/developer/artisan/programming title of choice. We’re not yet at the point where an automated tool is a replacement for proper Mentoring, but it sure can help lighten the load on the mentors.
Beyond that, it may well turn out to be a novel way to expose yourself to different ways of doing things that you already know how to do, that may turn out to be better in the context.
Lessening the Learning Curve
One of the major problems software roles have is how much there is to learn at the start in order to be effective. You have the standard stuff on joining a new team:
- Getting to know the people
- Getting to know their (invariably unique) process
- The review process
- The release process
- The team dynamic
- The codebase
- etc. etc. etc.
Lots! But on top of that, as a Junior/entry-level dev you also have:
- How to write working code
- (Hopefully) How to test that code
- Where do I even start making this thing that I’ve been given
- Where should I put it
- Who knows how this stuff works and can help me figure it out
It’s a Huge amount to take in, and it normally results in either:
- If you’re lucky, pairing with someone more senior who takes you through all these steps with them
- If you’re not, struggling on your own with limited help and taking forever to do an “easy” task
There’s a critical point that every new hire is trying to get to - the point at which they know enough that they are providing more value than they are consuming. Depending on the environment, that can currently take months to a year to hit. It looks to me like Copilot could help postpone some of the more technical learning a new dev has to do by assisting them in writing productive code. They still have to learn why it’s good code at some stage (I’ll get to that), but anything that reduces the time to net productivity helps not just the team they’re joining commit to taking on entry-level devs, but also the confidence and happiness of the new starter.
It’s not the first Code Assistance Tool
Copilot is by no means the first tool of its ilk, however much it pushes the scope of how much it’s doing to help. We’ve got linters, static analysis tools, SEO optimisation tools, we’ve got language specific tools like ReSharper, which is so monumentally useful that you get withdrawal symptoms without it! As an industry we’ve already wholeheartedly accepted a wide range of automated assistance to help standardise and clean up our output; is Copilot that different?
The answer for me is no… and yes. Sort of. I’m really nailing my colours to the mast with this one.
It’s not different because the aim is ultimately the same - use knowledge instilled into an automated process to help people write better and tidier code.
It is different because of the scope; it’s not just helping you write better code, it intends to give you the code that should be written. In the same way that sometimes ReSharper is wrong/misleading (more succinct code != more readable code), Copilot will invariably have cases where In Theory it’s given you something that works, but it is absolutely not the correct solution in the context.
Taking off the Training Wheels
As such, I agree that it’s still necessary to learn the Why, and get to the point where you can write the code without Copilot, in the same way that a senior C# dev needs to be able to write readable C# without ReSharper, even if you continue to use it as a productivity aid, so that you can spot the mistakes, and understand the consequences of what it’s suggesting.
“When” is going to depend on the context. As long as someone else is reviewing your code, you’re probably fine. You should be ensuring that you try and understand everything it gives you though, and use it as a learning tool. Do I know why it chose to do it that way? What are the impacts of that keyword I haven’t seen before? Can I think of a way that I’d write it myself?
As soon as you’re meant to be the one doing the reviewing, you should know how to do it without a tool’s help. If you’re using a tool that’s adding code with abandon to your solution, someone has to be checking that the code being added is correct, and that it isn’t building up a raft of problems that need to be dealt with, even if it appears to provide the required outcome.
Does that mean you have to stop using it at some point? Absolutely not - it still sounds immensely useful as a code discovery tool (how else might I do this thing?) and as a productivity tool (I know what I need to write, but it’s a lot quicker to auto-complete this and then check it’s correct/tweak it) - but you will need to be confident that you really understand the code that it’s spitting out, and all the consequences of its choices.
Would I Use It?
Were I still in an active development role, yes. Depending on how the legal ramification discussion pan out, I will certainly be looking at whether it’s something we should be introducing, so I’m looking forward to hearing more about it, and having a go in the near future!