This content originally appeared on DEV Community and was authored by Paul Kaplan
I love to build things, fast. My individual creative process revolves around getting pixels on the screen right away, and iterating from there. While at the project/team level I am a good planner and coordinator, for my personal work, I like to “mess around”.
But I’ve had problems with this strategy. I often sink days into problems that could have been avoided by reading the documentation or understanding the issue more deeply. This often happens on infrastructure and build system problems, where I skip over the details to get more quickly to “the good stuff” of building and testing complex and fun user interfaces.
Worse, I haven't always left code “better than I found it”, something I almost always regret and probably makes me less effective as a team programmer.
This year I want to "level up" my engineering skills, and I think "slow down (to go faster)" is a good framing for me. I specifically want to spend time understanding things that enable myself and my team to build unobstructed. Things like:
Webpack configuration
what are the best practices for using webpack to build sub-dependencies, how do the different plugins I use actually work
Babel transpiler settings
how does "preset-env" work, where should settings go (babelrc vs package.json vs. webpack options)
Localization workflows
The projects I work on are translated in >40 languages, and I want to know how our localization works well enough to inform other choices we might need to make, like adopting a Content Management System.
Deployment process
We deploy on a rigid schedule that makes things difficult in many ways. I want to understand how other teams adopt continuous integration when thinking about QA.
NPM packaging best-practices
I often deal with an ecosystem of related JS modules published to NPM, some React, some non-React. How do others publish code that needs transpiling like JSX? What about packages with lots of image/style assets?
One common element in these types of issues is that I'm being asked to use a tool I do not fully understand that has been built up over years. I never get to the "messing around" part, where I think so much learning happens because I haven't stripped things down to their basics. So instead of trying to understand a complex system as-is, I'll harness my love of "messing about" and build lots of little dummy projects to see how each individual part works. Hopefully I'll have some follow up posts in the next few days about how this works.
Photo by Brian Matangelo on Unsplash
Are there things that you've "hand waved" (i.e. copy/pasted) your way through that came back to bite you?
This content originally appeared on DEV Community and was authored by Paul Kaplan
Paul Kaplan | Sciencx (2021-02-16T14:34:30+00:00) Slowing Down (to go faster). Retrieved from https://www.scien.cx/2021/02/16/slowing-down-to-go-faster/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.