little typos tudor essay

episodes/036.md

@@ -34,19 +34,17 @@ This decision-making methodology is only half the battle. We still need the prop
 
 To be relevant, the tool must understand your specific context, for example the specifics of your build system or how you resolve dependencies. But there's no off-the-shelf tool for that. The only people who understand your context in all its little details is you and your teammates. You need to make your own tools to understand your system.
 
-But who's got time for that? If the trade-off is reading code manually vs building myself a custom code-analysis tool, I'll muscle through reading line-by-line. What if we could drastically reduce the time and cost of building your own code analysis tools?
+But who's got time for that? If the trade-off is reading code manually vs building myself a custom code-analysis tool, I'll muscle through reading line-by-line. What if we could drastically reduce the time and cost of building our own tools?
 
-Tudor's current project is the Glamours Toolkit (GT). He calls it a "moldable development environment," because it empowers developers to quickly and easily adapt their environment to specific problems and contexts. Influenced by Smalltalk, Emacs, their IDE aims to be an environment you can tailor to understand your specific system.
+Tudor's current project is the Glamours Toolkit. He calls it a "moldable development environment," because it empowers developers to quickly and easily adapt it to specific problems and contexts. Influenced by Smalltalk and Emacs, the Glamorous aims to be an environment you can customize to help you understand your specific system.
 
-They consider it a failure of their IDE any time you have to resort to drawing on the whiteboard to explain your system. The tool is designed to make it really cheap to build custom visualizers for whatever objects you want to inspect. It then saves these visualizers for you to choose from whenever it encounters another such object in the future.
-
-For that matter, they consider it a failing any time you have to "leave the IDE," because the "I" stands for "integrated" after all. Googling for documentation, libraries and example code is suboptimal. The worst offense is copying and pasting errors and hoping for an answer on Stack Overflow. That's implicitly admitting that we don't have any chance to understand our own problems. Code is only a black box today because we don't yet have the right tools to look under the hood.
+They consider it a failure of their IDE any time you have to resort to drawing on the whiteboard to explain your system. The tool is designed to make it really cheap to build custom visualizers for whatever objects you want to inspect. It then saves these visualizers whenever it encounters another such object in the future. For that matter, they consider it a failing any time you have to leave the IDE for any reason. After all, the "I" stands for "integrated". Googling for documentation, libraries and example code is suboptimal. The tool should have a built-in support for such questions. The worst offense is copying and pasting errors and hoping for an answer on Stack Overflow. That's implicitly admitting that we don't have any chance to understand our own problems. Code is only a black box today because we don't yet have the right tools to look under the hood.
 
 But the stakes are higher than 50% of your professional life. 
 
 Code lives for a long time. There are many companies that still run software on mainframes. The speed at which we can recycle old code is capped by the speed at which we can _understand_ old code. Currently this is linear because we read code line-by-line. At the same time, the body of software grows exponentially year over year, way outpacing our ability to recycle it.
 
-We mass-produce programmers to mass-produce code to eat the world with software before the next startup beats you to it. From this perspective, we behave very much like the plastic industry, focusing exclusively on production without regards to what happens when our product is no longer needed. Alongside the landfills of plastic, we setting ourselves up to bequeath our children mountains of code that nobody understands. Nobody wants their legacy to be code, because [nobody likes legacy code](http://chadfowler.com/software,/development,/career/2011/03/17/leaving-a-legacy-system.html).
+We mass-produce programmers to mass-produce code to eat the world with software before the next startup beats us to it. From this perspective, we behave very much like the plastic industry, focusing exclusively on production without regards to what happens when our product is no longer needed. Alongside the landfills of plastic, we are bequeathing our children mountains of code that nobody understands. Nobody wants their legacy to be code. [Nobody likes legacy code](http://chadfowler.com/software,/development,/career/2011/03/17/leaving-a-legacy-system.html).
 
 Clearly the answer isn't _read faster_. There's simply too much code. Just like we built tools to recycle certain kinds of plastics, we need to build tools to help us better understand and recycle our old code. We need moldable development environments.