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?
Top comments (12)
This is a supply side issue. The demand for product delivery is massive now, and the end users are super smart. They want new features to run as smoothly as Facebook, Google, or Amazon which means we in the trenches need to learn how to keep pace.
In the developer market there are plenty of suppliers that make things worse. They introduce new things which are purchased and of which we may eventually have to learn. The world is highly complex and requires a lot of knowledge, so much that it's impossible to keep pace.
So we have to narrow our focus by watching trends. For example today there are only three trends for tomorrow.
Cloud
The Cloud is a disrupter. It changes everything we knew. Just look at microservices, they require no server configuration we have to worry about. They are instantly scalable upward and outward. Say good bye to the traditional back-end Rest Service.
React
Is super fast lightweight, easy to understand and works perfectly everyday on FaceBook. Yes there are others, but React is the winner.
GraphQL
The SQL peak years have been met. GraphQL is the new kid on the block. It's best suited for web sites, ecommerce, etc. JSON is king today.
Guard your Time
We must be laser focused on what we are learning. If the job environment doesn't allow that, then we have to do it ourselves. We have to be relentless to kind-of-sort-of get there.
By choosing one of the three techs listed above, we are pretty much ensured anything we add to that knowledge space is going to live on for a few years. By staying focused we don't wind up losing years of work in something that's dead today.
Environment
Most Agile teams today recognize the knowledge deficits but I have yet to see any time built into any sprint for that reason alone. Instead the expected part delivery is whittled down. What helps us the most is to deliver only what we see on a user story and not to create tasks as we discover new things not asked for or implemented.
Keeping things simple for a senior software engineer is hard, because their minds are wired into super complex solutions of the past. They are predisposed to always offer up elegant in-depth solutions when in fact they weren't a requirement.
Over Expectations
Today the Senior Software Engineer doesn't only need to know three or four languages, they also need to know the entire pipeline from start to finish, which includes the Cloud. Obviously we can't get there overnight but we can do our best to continuously improve. Our laser focus gets us there more quick as we steer things to what we know is the best of class for today.
Being continually persistent does get us there and there's no substitute for that. Experts don't get that way by being a unicorn. They know just a few things extremely well.
We can control our environments to a good degree by choosing work of interest within the confines our our jobs. If your jobs are sailing in a different direction, then we can find new work.
Hey, why don't you write a post and describe these points in detail? Honestly, I'd love to read more of what you have to say, especially the things you said here.
My boss asked me to create a presentation and a lecture to educate my colleagues on how to keep up with technology. I've spent less time on the material telling them how to keep updated and more of my presentation is focused towards knowing what to learn that best suit their goals and make them employable.
Literally each day, there is a new framework or library coming out. NPM competitor, snowpack and other such b*st. I'm honestly frustrated and I'm taking break from learning anything new.
First post for you
Damn! Thanks man!
Ok there are now two post in the series, that's enough for 6 months to 1 year of direction. Good Luck to you and stay in touch.
Sounds good I'll post something soon.
Slowing down can be such a great idea in our industry. We tend to want to get things done as fast as possible, keep up with or surpass other devs, and many other reasons to work quicker than we maybe should.
I love the idea of "slow down (to go faster)" like you mentioned and have actually recommended this to some devs in the past. Besides helping learn more about the tools and things we use every day it can also help make sure the code we write is bug free and using the best design.
Localization was also one of the things that had me start to understand the frameworks, libraries and tools I use to the deepest level. There was this point where I totally messed up on an architectural level and could not localize packages/dependencies in a flexible way without sacrifices of bloating things Up. I started to read much more and more carefully and I never regretted that decision.
Oh yeah especially the part about bloat, any good references you’d recommend?
Hard to narrow down to specific literature. I mostly read Domain-driven Design from Evans and the C4 model for Architecture plus design pattern and anti pattern and worked my way through the code. Especially dependency injection is in JavsScript so good to implement, because of functions being first-class citizen.
My current l10n setup uses an internal module with an adapter pattern, that is an empty class that provides a common interface to all my components, no matter which i18n framework or package I actually use and this class gets injected the actual l10n handler. I use the common interface even in my packages, make it package devs easy to implement l10n in the way they like, because I don't restrict anyone to use a specific l10n framework but let them use theirs.
This is in the beginning a huge effort but in the long run a total dream to maintain. You would also think that this is more code (regarding the bloat) but it is not. The bloat started when I had to fiddle with multiple times the same l10n implementation in my host app AND in packages AND services. Now I can narrow this down to every part using a minimal part of the interface (that's the good thing when you split code in Functions; use Object-destructuring for parameter definitions) instead of full implementations.
Describing in exact detail where we want our application design to go. It is easy to keep plowing through and at times I think taking the time to create some design would save effort and waste around misunderstandings.
To answer your question: absolutely.
The "move fast and break things" approach has never sat well with me because it means you miss out on exactly the kind of stuff you're thinking about now.
The pace thing is a genuine issue. What I'm learning, though, is that there's a ton of garbage code out in the wild that was part of "eh... Good enough." That's going to come back to bite people later. I was under the hood of a managed WordPress setup that contained managed WordPress themes and plugins the other day, and the quality of the code was stunningly overcomplex. It didn't look very scalable, let alone readable. And this was on top of the controversial Gutenberg editor!
I see that @jankapunkt wrote up some information about i18n practices for you. I think another thing you should look into if you haven't already, is automated translation memory that works in tangent with a CMS to keep everything up-to-date in your content (I think this may differ a bit when we're talking UI). I haven't looked at translation memory in several years myself, but I do recall working with this specification at one point: docs.oasis-open.org/xliff/v1.2/os/...
Nice writeup!