Devon Estes on how Architecture Is a Myth and One-file Design

There is no difference between architecture and design. It's all engineering and creating a distinction between the two is a way for someone to get paid more and have a different title. That hot take comes from Devon Estes, today’s guest, who provides a novel way of seeing design and architecture. We open the episode by diving straight into the topic of design, with Devon exploring how good design might be less important than developing the right toolset. We then talk about how language servers can help you effortlessly define functions, meaning that in some cases, it doesn’t matter where you put your code — even if it’s all in one file. After touching on game-changing innovations in the world of design, such as GTP-3, Devon shares how our design options are limited by our editors. Considering the impact of human error on software, we discuss the value of convention and rulesets. As Elixir apps or apps that use Phoenix are open-ended, Devon talks about his middle-ground solution to help teams overcome this challenge. Near the end of the episode, Devon chats about why design and architecture, as elements of engineering, are different levels of abstraction and not separate entities. Following this, he highlights how domain-driven design can be used to avoid confusion and bugs by ensuring that people across departments all use the same language. Tune in to hear more of Devon’s unique and well-pondered insights. Key Points From This Episode: Devon’s take on design; “Where things go doesn’t matter if you have a language server.” Defining what a language server is and its incredible usefulness. How ‘go to definition’ functions could render much of design as unnecessary. Game-changing innovations that will change the world of design. Functional versus object-orientated languages and the challenge of finding files. Why Devon uses Vim and what makes it attractive to other programmers. How Elixir apps can be a challenge due to their open-ended nature. Creating primary and secondary contexts to give Phoenix more structure. The human factor; why people are often the cause of many coding issues. Hear how Devon has been structuring his Absinthe projects. Devon shares details about his Absinthe testing library, Assertions. Devon’s hot take that there is no difference between architecture and design. The importance of domain-driven design in avoiding confusion and bugs. Why engineers need to push to ensure the same language is used across departments. Links Mentioned in Today’s Episode: SmartLogic — https://smartlogic.io/ Devon Estes — http://www.devonestes.com/ Devon Estes on GitHub — https://github.com/devonestes Devon Estes on Twitter — https://twitter.com/devoncestes Jake Becker on GitHub — https://github.com/JakeBecker GPT-3 — https://www.independent.co.uk/life-style/gadgets-and-tech/news/gpt3-ai-tool-designs-websites-medicine-a9627966 Elixir Is — https://github.com/elixir-lsp/elixir-ls Ale — https://github.com/dense-analysis/ale MOO — https://lisdude.com/moo/ Erlang code — https://erlang.org/doc/man/code.html ‘A Proposal for Some New Rules for Phoenix Contexts’ — http://www.devonestes.com/a-proposal-for-context-rules ‘A proposal for an Absinthe application structure’ — http://www.devonestes.com/a-proposal-for-absinthe-project-structure Elixir Radar — https://elixir-radar.com/ Assertions.Absinthe — https://hexdocs.pm/assertions/Assertions.Absinthe.html#document_for/4 ElixirConf EU — https://www.elixirconf.eu/ ‘Elixir testing from beginner to expert’ — https://www.elixirconf.eu/trainings/elixir-testing-from-beginner-to-expert/Special Guest: Devon Estes.