Temporary Update
Ryan Lanciaux
@ryanlanciaux
...
For further actions, you may consider blocking this person and/or reporting abuse
Thank you my friend for identifying this concept! I have been coding for 40 years. Lately, looking for new gigs, I have tried to explain to potential employers this very concept, but I didn't have the right words. Now, I do! Why do you want an experienced developer? The mise en place from years of experience!! This will make answering interview questions so much easier! Thanks again!
A fresh perspective on good programmer habits, really enjoyed the read. It's a more difficult thing to visualise, but personally I can see this applying to backend development too. Focusing on small components that do one job, and do it well, is setting yourself for reusability.
Right on! I've been trying to bring this idea to life for a while. Looks like you beat me to it! One thing I'd add is the use of tooling to build the components in the same way. Say for instance Plop.js as a way to scaffold components.
This way all component code would have a similar look and feel. Tests would be similar, etc. To use your culinary analogy, component scaffolding is like a cookie cutter. It ensures everything starts from the same mould. You can add sprinkles and whatnot later, but the origin is the same and repeatable!
Very cool! I'd love to hear your take on this analogy too.
I really appreciate the thought of scaffolding things and will have to check out plop a bit more sometime. Similar wavelength here too on automating things and will be a topic for a future post BUT I also use scaffolding hand-in-hand with these techniques 😀 These are from a talk I'm giving on this overarching topic:
I am currently using Gluegun to make a configurable CLI I'm using on some of my projects, Blastoff. I'm hoping to write more on this a little later on.
I used this same analogy while trying to explain why functional programming concepts can improve backend code. I think the analogy goes even deeper into our day to day coding practices.
In much backend code, you are taking various data and combining it and reshaping it into other forms. Much conventional code is a real mess in creating these. Either a really long method with a bunch of for loops and mutable objects or a lot of helper functions that represent extra risk and maintenance, and we haphazardly assemble our objects.
Functional programming allows us to greatly improve and simplify this process, so that our assembly of an object looks straightforward and all of our processing gets done either in advance or with pre-built methods we assemble together (like Chipotle), such as map, filter, reduce, etc.
I’m working on a blog article describing this in more detail, but thanks for the extra insight and verbiage!
Very cool - looking forward to your article!
Go blue
Go Blue
Looking forward to hearing your talk on this later today. I listened to the audiobook of Every Tool's a Hammer and it was the first time I've encountered this concept by name.
Awesome - it should be fun.
I was reading that book around the same time I was preparing the talk that this post is a derivative of. I wasn't expecting "mise en place" to be a topic at all but was pleased to see it and how it relates to making things :)
I think you and I have similar thinking patterns on certain things. I've called my patterns "component thinking" and thinking about software as a series of isolated components.
I'd encourage you to write more about Blazor in particular.
Once again, enjoyed the talk and meeting you. I purchased 3 books while listening to you speak.