There’s this sentiment in developers that sometimes rears it’s ugly head and sounds a bit like: “That’s not my domain, someone else can handle those problems better than I can.”
My mom would shudder at it, but I’ve been guilty of the thought. So many others I’ve worked with have thought (out loud) the same from time to time too. Sometimes people use it to be nasty to waiters or other service staff. Sometimes people use it to have a lot of downtime at work instead of branching out and trying new things. The walled domain thought can be benign, but it also can point to a hole in your skills that needs to be filled.
When’s the last time you really dove in and wrote modern CSS? Was styling your company website someone else’s problem? Could you Google how to do things, copy and paste some code and stumble through it? Sure, but would it be good?
There’s a common design trend of a sticky header/navbar, something that scrolls with you and lets you access application features and site navigation. In CSS, if you need to make a sticky header like like that, it’s just two rules:
.nav-header { position: sticky; top: 0; }
Right?
Or might there be a thousand business rules about what that header has to do at different times? Some page formats the header might need to be in the normal document flow and not stick. Sometimes it might need to stick for a little bit, and then animate away as an advertisement comes in to view. Each of those cases is more than two CSS rules. Each case can be solved, and all cases can be solved together if you’re willing to explore the magic of modern CSS.
Domain Knowledge
We had a guy at work who used to handle all the styling problems. He was a wizard with CSS and he knew enough Javascript to get by. We sorta had this unspoken agreement that I would do the hard JS stuff, he would do the hard CSS stuff and we’d review each other’s changes if we had to step into the other’s domain. That style of work was fine for us and got the job that the company wanted from us done.
But we were divided by the sort of tasks that would be asked of us. I could have used more styling tasks, I’m pretty good at fiddling around until I get it, but if I’m working on a web team, learning little ins and outs of CSS is well worth my time. Likewise, he probably could have used more javascript tasks to keep his skills sharp.
We were pulling together towards company goals, but we could have done it in a way that would have helped us both learn a lot more. We each had the skills to handle all of it. The walls arose when ticket assignments went out and there was always an attitude of “Oh, that’s a Josh problem.” or “That’s a {person’s name} problem.”
“Low Level” Magic
If you’re using Create React App, there’s this sort of magic layer between your React code and what the browser shows you.
How do all those lines of React get turned into valid Javascript? How do those lines of Javascript get turned into code that browsers-other-than-chrome-canary can understand? Why can I import CSS files directly?
Create React App runs a node server that reads some configuration files, transforms some code, opens a web socket connection to the browser, etc. This is super practical for most react development, you can build something you sort of understand very quickly.
Babel runs an Abstract Syntax Tree and takes your JS apart and then puts it back together in a format that browsers-other-than-chrome-canary can understand. Webpack bundles all the code together, Webpack Dev Server runs a socket connection to give you some sweet hot-reloading action. Add those tools together, and you get something that can feel very much like magic.
“It’s been a while since I’ve done anything that low level…”
Does everyone need to understand AST’s? Maybe not…? What about opening and parsing a configuration file? Maybe…?
That magic line is different for all developers. You ever read about a MOSFET? There are developers out there for whom the MOSFET is the magic layer, and there are developers out there for whom JSON.parse(...) is the magic layer. Your layer of magic is different from other people’s layers.
Explore the Magic
Where your magic lies is not super important, and it will be different for programmers working on different places in the stack. There’s some CSS magic for me as much as there’s some C++ magic. People who program in C++ have a lot less C++ magic than I do, and that’s great!
I don’t have to write many programs to open a file, read the bytes, parse the meaning from the file, etc. But can I? Yeah! That magic layer may exist with a few pieces still unknown, but I know the direction to go when I start a project like that. Just because I don’t have to do it a lot at work, doesn’t mean I don’t get a ton of benefit from knowing how those kinds of programs work.
If you’re using Create React App, maybe you could take a look at how they’ve set up Babel and Webpack. It’s all open-source, and you might find some really good ideas.
If you’re using CSS, maybe you want to explore the CSS specification from W3? The handy thing about this specification is that there’s even a guide for consuming it.
You will have lots of opportunities to dabble in the magic of something a little deeper in the computer than what you’re used to. I think it’s really important to be able to write little programs and tools for yourself to understand what’s going on with all the other programs and tools you’re using.
When you’re hammering out tasks at work, you might not need to know any “low level” stuff. But if you explore the “low level” stuff, you will find concepts help at the “your level” stuff.
Working on things a level deeper will help you understand the foundation upon which you’re building and help you make smarter decisions a level up. Working on things a level higher will help you understand who and what you’re building for and help you make smarter decisions a level down.
If either domain is a mystery for you, you can still write good code and do your job. Just remember that no matter where you are in the stack, there’s a lot of magic to explore up and a lot of magic to explore down. Exploring either direction can help you become a better programmer.
So I guess if there’s any take away from this long-winded blog post, it’s this:
Turning magic into knowledge fills holes in your skills and lets you make more structured and informed decisions. Don’t let magic be an excuse to not delve into something a little more “low level” than you’re used to.
Further Reading/Watching
Julia Evans is a polyglot programmer who works at Stripe. She writes articles like Batch Editing Files With Ed that are cool explorations of programming topics. She learns something, shows us why to care and why it’s cool. She constantly takes things that look like magic at the outset and then reveals why it’s knowledge. If you’ve got 20 minutes, her talk from Deconstruct Conf on building impossible programs is well worth the watch and fits with the theme of exploring hard things.
Aaron Patterson is a prolific Ruby programmer who works at GitHub. He writes articles like Ruby Variable Performance that are super cool explorations. He learns something, documents it and then if it’s bad he can fix it and if it’s weird he can tell people about it. Either way, he’s explored some Ruby performance and changed some magic into knowledge.
And here’s the kicker, because they’re blogging about it, Julia Evans and Aaron Patterson are turning magic into knowledge for more people than just themselves.