So, to be a prolific programmer, what does it take? In the past, we would have to sit beside the programmer or have them describe their workflow to us. With streaming platforms, we can observe how software engineers approach problem-solving and learn from their approaches, which can help improve our own.
Live Stream Programming
I was watching a few videos from the George Hotz streaming archives on YouTube. George Hotz, more popularly known as geohot, is a prolific programmer who has jailbroken the iPhone and PlayStation 3, built open source semi-autonomous car software, and, more recently, founded a machine learning startup. What's interesting is his approach to tackling challenges, such as building a neural net chess engine.
Coding Questions
Another interesting selection to watch is from Neetcode, videos that walk through solutions to LeetCode problems.
For example, in one video, it begins with a review of the question, followed by a diagram to map out the inputs and steps to achieve the expected output, and then the coding is presented.
No matter the question, this is the overall process for coding interviews. Where it gets interesting is the code implementation. As it's walked through, take note of where there's a pause and where the solution is checked and stepped through. The debugger can help step through code.
AI Pair Programming
Gene Kim paired with Steve Yegge, an incredible engineer and writer, on chat-oriented programming, basically AI pair programming. You can find Yegge's writings from 2005 to the present, and they're all good stuff. Within many essays, there are a few lines that can have a significant impact on how you write code and approach problem-solving. In Yegge's essay "Innovation 101," for example, there's a section on why he writes essays.
The video walkthrough effectively demonstrates the process Yegge uses to work with an AI copilot and how knowledge transfer and training occur.
Open Source History Class
There is a wealth of open source code out there to learn from. There are even two great books that discuss the architecture, system design, and code for various open-source projects. However, this focuses on the code at a certain point in time.
An interesting way to learn is to attend history class. By going through the past commits in a project, you can see how the code got into its current shape.
The llm command line tool provides an instructive example. The code for llm is written in Python and began with prototyping, with the first commits made on April 1st, 2023. The first commit sets up a GitHub Action workflow to test and publish the Python package; it also has one command. From the start, it's possible to use the tool, test it and publish a package to distribute it more widely.
The initial design of llm is documented through the open GitHub issues. One of the issues opened was "command for browsing captured logs", and it contains a few ideas on implementation. The expectation is revised and then closed out with a pull request. What's interesting is that this is still the initial part of the journey to building a new command-line tool. The issues are used as documentation and then quickly closed out with an implementation.
Let's think about the alternatives to this. If we start a project and create a comprehensive list of tasks using issues, we may reconsider our approach and close many of the issues. What about beginning with no issues listed and only documenting through pull requests? This approach can work; however, the design will already be in place, and we may not see the complete set of techniques that have been tried. By opening issues that are going to be worked on soon (within a day or within a week) and commenting on them, a trail of code and design breadcrumbs is created, along with a place to document the various approaches tried. Commenting on the design and leaving notes for yourself (and your team) about considerations that changed the design helps you in the future when looking back at how and why the implementation is the way it is.
From Your Software Engineer Coworkers
In the above, I've covered the ways you can learn from great developers who develop in open source or stream their coding sessions. You can apply some of that to learning from your coworkers. Read through their code and code commits, read through what they comment on code reviews, and ask them about their workflow. They may utilize many keyboard shortcuts or use specific extensions and plugins for their IDE. When they plan their work out, they may use a TODO comment in the code or a simple list in a notepad or another method. Whatever their strategies, processes and systems thinking they use, you can ask and learn from them.
Top comments (0)