Bricklaying and Trailblazing

hi@victor42.work (Victor42) — Sun, 28 Jan 2018 21:17:08 +0000

Developers often joke about being IT coolies, just “laying bricks.” Outsiders often don’t get what they face daily, or why they make these self-deprecating jokes.

I recently teamed up with a classmate on a WeChat H5 page with data submission. I handled design and front-end; he took care of the back-end, server, and domain. This gave me a glimpse into back-end development, and I suddenly understood the “bricklaying” analogy. I gained a much deeper appreciation for the challenges developers face. It’s a different world compared to other professions. If you’re not familiar with development, I’ll explain it in plain terms.

We used a standard front-end/back-end separation. Think: front-end is close to the user, back-end is far away, connected by networks. My work involved creating the page’s look, displaying it, and handling user-side logic. For example, email fields need an “@” symbol to be valid. My classmate’s work involved receiving user info, storing it in a database, and handling statistics.

We needed to collaborate on the “interface” – how I’d format and send user input, and what feedback he’d send back, including errors.

We were interdependent. I finished the front-end first, but how could I test the interface code? I needed the back-end to know if my code was correct. Since his code wasn’t ready, I had to wait. Of course, developers don’t just wait around. There are ways to simulate each other’s work, which is what we did.

He wrote some Python to simulate the interface locally. I knew nothing about Python and was lost. After staring at it, I got a clue. Combining it with our agreed interface, I roughly understood it. My task: turn my computer into a mini-server, run his code, and submit content to it. His code would give feedback, letting me test.

But it failed miserably. The problem? Running his Python code. Prerequisites: First, Python. macOS comes with Python 2.7, so that was fine. Then, I needed common Python modules his code relied on. Installing these threw errors.

I first thought: macOS permissions. I tried getting superuser access, but no luck. Developer forums suggested upgrading/reinstalling modules – didn’t work. Then: Python version? I installed Python 3.6, replacing 2.7, and reinstalled. This time: syntax error. Python 3 changed some syntax. I fixed it, but the original error reappeared. A module he used was deprecated in Python 3, needing replacement – beyond my skills. I gave up on switching back to 2.7. Dead end.

I switched to a tool he recommended, simulating back-end data. Limited compared to raw code, but it worked, solving the problem.

This showed me how tough developers have it. Design tools are stable. Problems? Restart, reinstall. We focus on design. Developers’ tools – languages, modules, environments – are far more fragile. Incompatibility, settings, weirdness. Like a construction worker with a broken saw or drill. Fixing these isn’t development, but they spend time on it.

Front-end, which I know, is similar. Example: mobile button press feedback, like mouse hover. Hidden pitfall: code to darken a button on press might not work. You find you need a seemingly pointless line of code. Like picking up a chess knight, waving it, putting it back. No move. But it makes the effect work. Makes no sense, but you must write it. Solving this creates nothing, but it’s common. Tedious, unrewarding. Creative work brings accomplishment.

Development is amazing. Making something from nothing. Tech gurus complain about bugs, broken interfaces. Developers get stuck on unrelated technical issues. But they’re like pioneers. Venturing into the wilderness, making tools, building houses, laying railroads. Solving countless problems, creating infrastructure for later prosperity. Our stable products are thanks to their exploration.

I don’t enjoy this. I learn enough front-end to get by. I might have made inaccurate comments. With awe, I’ll stick to design!

Development on Victor42

Bricklaying and Trailblazing