CodingPrime

I am a software engineer. Not a front-end developer. Not a back-end developer. Not a full-stack developer (whatever the fuck that means today). I am an engineer. I understand how to devipher technology, figure out how it works, and build things up using said technology.

If you spend more than 15 minutes lurking around the various tech hangouts these days, you will undoubtedly come across some bit of tech that smells. It may work as advertised, it may not crash your system, but its just...wrong. When you go digging into its guts, you find that it's a well polished pile of shit, put together by some well-intentioned flunkie who wanted to "be somebody" on the web.

By itself, this isn't really a problem. Bad software has been around since software was first invented. The issue today is that these really bad parts are being cobbled together into really, really bad apps by developers less skilled than the original author of the shitty bits.

If this sounds elitist, good. Chances are, if you're in the software world, I'm better at whatever you do than you are. And this isn't because of some innate gift I possess, or a trip I made to a mountaintop to visit the oracle of teh codez. I got this good by making damn sure I understood what I was doing before I did it. When I've moved into a new arena (Node.js development, for instance), I've taken the time to get the lay of the land, determine the right and wrong ways to implement features, and how best to interact with the community at large.

More than anything, I make sure I develop my own best-practices, usually heavily influenced by the opinions of others, and follow them religiously. I'm constantly re-evaluating my positions, based on my own experiences as well as those presented by others. The key here is evaluating, which requires an understanding. I never take anyone's opinion or suggestions at face value. I prove them out on my own, making sure there aren't fallacies, or even room for improvement. In short, I'm always trying to hone my craft.

I was doing some of the aforementioned research when I came across this gem, which is apparently a transcript of a conversation between a self-labeled "front-end" dev and some of the maintainers of the webpack packaging tool. I'm posting this not to poke fun at "Steven" (if that is in fact your real name?!?), but to hopefully highlight some of the issues Steven's side of this conversation highlights in the development community at large.

His issue comes down to a lack of understanding around what he's trying to accomplish. He's been getting by with just copying/pasting "solutions" he's found on SO/Github/HN, and he's finally come up against a problem that doesn't make any sense to him. We already have a problem, but it's about to get a lot better. When confronted with his ignorance, instead of acknowledging it and resigning himself to do the requisite research, he lashes out at the webpack devs for not spoonfeeding him said requisite knowledge in their docs. Actually, its worse than that. He doesn't want the knowledge, he just wants to short-circuit the learning altogether. Just give him the what, not the why. And this is one of the fundamental issues I see in software development today.

I've been dabbling in React lately (doing some universal stuff, how sexy!), and have been dumbfounded by the amount of misinformation present. I must have reviewed a dozen or so "boilerplate" repos, and each one seemed to be more over-engineered than the last. Rather than stop and try and understand what they were trying to accomplish, these authors were just trying to throw as many external resources at a problem until it went away. If your "boilerplate" has more than 10 dependencies, it's not boilerplate, sir.

Not taking the time to understand what you're doing is basically your way of pushing that responsibility off onto somebody else (be it a library author, a coworker, or some guy on SO). I've been around long enough to know that there are times where this is required due to time constraints, budget, etc. But if you want to graduate from being just a front-end guy to being a real engineer, those instances need to be thorns in your side, itches you aren't comfortable until you can really scratch them.

This has been a bit ranty, but I'm getting old, and I can't help it. While the vast array of tooling available today does make the task of carrying out your day to day duties much less taxing than in years past, at the core of it all, somebody still has to know how shit works. If you look around your team and can't point to anybody who fits that description, take it upon yourself to step up and be an engineer.