I’ve been having a discussion with anther developer, Brad. He’s a good dev and he is trying to add some technologies to make his workflow better, and that’s a laudable effort. I’ve tried to do similar things with some successes and some failures.
He’s got a good queue of udemy videos lined up and does a lot of diagramming of his environments to make sure that he’s got a good handle on how to set things up. he also seems like he’s got a pretty firm idea of which technologies he thinks are useful to him. Those two things are a great start for improving skills.
Here’s some general advice for Brad.
Just take the “killer feature”, forget the rest
Learn things based on the ability to add a single, killer feature and then worry about something else. Like, when I learned Sass, the fact that I could split the files up and nest rules was enough of a reason to used sass, and I didn’t worry about doing complex stuff with mixins or even global variables for a while after I got it working.
I just took whatever base theme I was using, ran “npm install” and “npm run watch” just like it said on the label, and when I went to author my sass, I just enjoyed nesting stuff and splitting files and was happy.
Then, at some point, I encountered a problem where I found myself repeating a lot of code, and I realized that I could write a general function to generate the “blue version” and the “red version”. At some point I realized that I anytime I wanted to override something in Foundation or Bootstraps base classes it was way easier to just modify their “settings.scss” files and let them recalculate how wide the page is or what the primary button color is.
The same goes for gulp/grunt/webpack: the fact it could build sass based on watching files was enough for me. I think the first time I used webpack I just ripped the parts that did that sass compile and was good to go, and then when I wanted JS compiling (babel, etc) I added that, and then when I needed X, Y, and Z I added that.
Learn to count the costs
A really uncharitable way to think about what I am saying above is to read it like this “it’s great that I can just keep stacking crappy technologies on top of each other and hope that future me will just deal with it”. That sounds terrible. Brad wrote that he’d like to learn “how to set up a solid dev workflow environment rather than cowboy coding it.” I get that, and he’s right to worry about that issue. If you’re just adding new-shiny technologies because it’s neato, then that’s indeed a problem.
There is a tradeoff here, though.
I’ve worked with shops where version control was seen as some kind of hipster system that was unimportant. The shop was hesitant to take up using git because it was costing time to learn the system and it changed their workflow. Which (I kid you not) was to dev locally, check that the system worked, copy the changes to files by hand on the server by using BBedit. However, that flies in the face of so much advice. For most projects source control brings so many of those killer, I-don’t-want-to-work-without-it features that it’s an obvious win to get it working even if there is a bit of a learning curve for some team members.
The tradeoff, here, is between how much utility the single “killer feature” brings versus how stable the new tech is versus how much pain there is in learning or swapping out that technology.
So, let’s look at Zurb Foundation.
What you’re buying:
In general, it has an obvious payoff:
- consistency across projects and a lot of useful UI parts
- well documented
- tested across browsers
And even if you had to leave that specific set of tools, it is very similar to Bootstrap and other tooling where you have a ready made UI set. Plus if you read the code behind it then it will teach you a whole lot.
What you pay in learning
The “cost of learning” question is less straight forward. I personally found it super easy to use. But I’d also used bootstrap for quite a while and already knew Sass/less. That set of existing skills is important: that’s why there is no one answer that everyone can use about the appropriate-ness of a solution. If I know Python then adding Django to my toolkit isn’t a big deal… if I’ve never programmed before then it might be a life-altering decision.
What you pay in tech debt
Alongside the cost of adopting tech, there is a cost in swapping out tech. If I had to swap out Foundation for, say, Bootstrap on an existing product, then that would be a lot of work. And no fun, either. If I had to get rid of Foundation for custom code, the same is true. Thankfully, that’s not usually how development works in my business. Usually I am starting fresh on a new theme or making modifications. So it doesn’t matter that Zurb is no longer supporting Foundation… if Foundation lives or dies, it still works well in the themes where it lives. That’s why I don’t bother with child themes: the css/js framework is not designed to be replaced.
If that’s a cost I can pay, that’s great. If we’re talking about choosing Joomla, then I’m a lot iffier on the value of that tradeoff.
Unfortunately, that nexus of having to trade things off versus how much control you have over the overall world ecosystem of software is minimal. And, once agin, that’s a skill you need to learn and thing about.
So that brings me to my ultimate point. How do we learn about the costs of learning technologies:
Don’t worry about the ad-hoc nature of this stuff
To be blunt, a great deal of infrastructure is ad hoc. That can sure as hell bite you in the ass. For instance, I used to have a lot of problems with various Sass compilers working with various versions of node. This was quite frightening because when I’d come back to a project that had been sitting for 9 months, who knows if npm run watch was going to work or not.
On one level, troubleshooting that stuff is a “fun” learning exercise. We want to avoid that kind of fun.
But you do in fact learn from it, so for as big a pain in the ass as it is, it’s valuable. On a second level, the skills to troubleshoot things are learned: “read your log file” isn’t obvious to a lot of newer users. But you’re never going to figure out what you’ve done wrong to mess up your dovecot install if you don’t. You just aren’t going to have that kind of insight. So reading logs, running the debugger, picking through people’s code… these things all come from fixing this stuff. That’s just what we do.
On a third level, then, comes my final point: learning to deal with systems breaking is how we learn so my final advice is just this:
build the stuff you need to build to get that one killer feature and move on to building the next thing that you need to build. Fix your systems when they break, and learn from your mistakes when you inevitably pick technology that bites you in the ass.
