Add the piece you wrote about parsers.

[panoply]

Hey Austin.

Hope you are well. You wrote a beautiful piece about writing parsers some time ago now. It's utterly brilliant and I constantly share it with developers. I have it saved and read it from time to time. I think it's a fantastic addition for wisdom. To refresh your memory, here is the excerpt.

Writing parsers isn't fun and exciting like writing the next hot video game. It probably won't unlock the keys to the next major computer science breakthrough. Writing parsers will, however, make you a better programmer. Writing parsers will infuse in you a disciplined, conservative, and humble approach to programming. It is often a thankless effort hidden beneath layers of rules and utilities not visible to the end user. When you do well few people will notice. When you break a user's code many will notice and few will forgive you. Writing parsers is not the path to heroism.

I believe writing parsers has made me a better programmer in ways many other programming disciplines could not. I believe I have learned qualities and decisions that differ from many of my software developer peers because the goals are different.

Application predictability is important. Unpredictable outputs often results in harm. Helpful tooling and exciting or clever new conventions and features won't make the code more predictable. The only things that make code more predictable are fewer instructions, clearer flow control paths, separation of concerns, and increased testing. The end result is boring stuff and code put on a diet. Dieting in code is often, for many developers, an unacceptable inconvenience much like dieting in real life.

You are on your own. There might be a team you can turn to help answer questions, or an adviser to guide you through tough decisions, or there might even be a helpful toolkit to assist with testing. None of those things will solve hard problems for you. You will be forced to make decisions. Many of these decisions could mean catastrophic failure that breaks a user's code. Many times you won't have any idea. There isn't going to be a magical framwork out there to make decisions for you. There is no solution in a box to write APIs for you or manage expectations. You are on your own. You have to make hard decisions and when you break a user's code, because it will happen, you have to own those consequences and seek resolution.

Simplicity is different than easiness. Easy means lower developer effort for the developer writing the code, but simplicity means less effort for everybody else to include your users and the processing computer. These terms could not be more different. The job of a competent developer is to make that distinction and solve for it as directly as possible. Nobody will forgive you when you fail. Your users will, however, recognize the additional effort to compensate for the external failures around you if that means increased application dependability or user fulfillment.

Superior programmers are simply people who iterate faster. There is no way to know if you have solved a given problem until you have tested the solution. Once the problem is solved you won't know if you have created additional problems or regression issues without running additional tests. The pattern here is to attempt a solution and then attempt to verify the solution against various validations. The key to success is not some brilliant vision or the magic ability to avoid failure. The key to success is simply speed. There is clearly more to it than that, like a diversity of reliable test cases, but in the end it always comes down to speed. The best way to think about this is that a developer who works 10 times faster than the next developer is allowed to fail 10 times more frequently before releasing code into production. The way to achieve superior speed is to access the problems as directly as possible. Each barrier between you and the problem will slow you down. Common barriers are too many tools, abstractions, build processes, compile steps, frameworks, missing documentation, unclear flow control, and so forth. Increased speed pays unforeseeable compounded dividends over time as you learn to further increase your speed with more precise forms of automation, organization, and planning.

Writing parsers is actually enjoyable and fulfilling. Over time you notice that your discipline and development capabilities increase. Your speed dramatically increases over time as each edge case can quickly consume large portions of your life and mental health. Your ability to perceive large complex problems before they occur and address them with simple elegant solutions is something only you can appreciate, but it applies to many areas of life even outside of software. Given enough practice your ability to write software architectures seems to spontaneously arise from nothing when really it is the result of solving many tiny edge cases paired with a modest amount of planning.

[prettydiff]

Looks like it comes from here and last updated in 2018: https://prettydiff.com/2/guide/unrelated_parser.xhtml

I will convert this to markdown and put it up. I had completely forgotten about it.

[prettydiff]

Task complete - https://github.com/prettydiff/wisdom/blob/master/Writing_Parsers.md

[panoply]

Thanks Austin.

It was wonderful to read the complete version again.

The strategic concept of Sparser together with PrettyDiff continues to teach me so much. Though you've retired those projects and focusing on Shared File Systems the evolution of open source has allowed the algorithm/s to find purpose again and remain at the core of the Æsthetic project I've been working on.

I know that talented SWE tend to be critical and prefer critique over compliment but it continues to be a privilege to learn through your work. Thanks again.