Coding in Real Life
Yesterday, two totally unrelated coding problems were solved. One was from WordPress, the other was from the Rainmaker platform. The WordPress problem was a necessity. Rainmaker was more of a stying preference. And believe it or not, both a related solution: a simple edit or addition of 2 letters or less. That was it!
It makes a world of difference adding or subtracting something in the tech world. Everything is so precise. I’m not a developer yet, but I wonder if there’s such thing as an organic or interpretive coding language. One where there is room for error and things self-correct themselves. Hm. Maybe that’s what A.I. strives to do? Either way, here’s what I learned from that synchronous experience.
I very limited control over the WordPress issue. I had to wait for forum responses, updates, etc. The Rainmaker issue actually allowed me to write some code, but I had no idea what to add. This coding problem ended up being more collaborative between me and Tech Support. In the end, however, both coding problems required me to make a specific change on my end for the solution to work. The final fix depended on how I used the little bit of control I did have.
Speaking of control, you have to know your limits. I tried figuring out the Rainmaker CSS styling issue on my own, before and after the original suggested code from tech support didn’t quite work the way I wanted it to. And the more I kept testing and experimenting, the more I understood what was going on. But I still couldn’t put my finger on the specific cause of the problem. I needed help. I had to humble myself and hand over the problem to someone else.
It takes time to solve a problem. Especially when you’re not an expert in the field. You rely on other’s expertise and wait for them to save the day. But in the meantime, you continue with your other work. After all, a watched pot never boils. I worked while I waited.
It was important that I shared exactly what I was doing with the Rainmaker and WordPress experts. While these people may be specialists, they’re not mind readers. So I succinctly took them through the different tests I did and the results I got (remember, I’m not a developer, so I didn’t have the jargon that would save me from writing 20 words for a one-word description). This helped to save them time, pointing them in the direction of what to fix. I was concise and as specific as possible in describing the problem and my tests.
The last bit of code that I received from Rainmaker finally worked, but it was messing with another part of my site. I quickly shot off another email, while trying to figure it out myself. What I should’ve done is waited before sending out another “it’s not working” message so quickly. Sure enough, I found out what the problem was on my own. I felt like I truly collaborated with fixing my own issue! But I wouldn’t have what to fix if I didn’t invest my own time into the problem.
From Coding to “Real Life”
What does all this mean for non-coders and problems in the non-developer world? Simple. When a problem arises:
- Be honest with your scope of control and knowledge.
- If you aren’t an expert and don’t have the time to invest in solving the problem, give it over to someone who can help—but still do some digging around—it’ll help you understand the problem better.
- When you give it over, be patient.
- Do your best to express not only the problem, but you did and the results of your testing.
- After your problem comes back “solved”, you may find out that it’s not totally fixed. Before sending out an immediate message, take a look at it and assess what’s going on. This way, when something arises in the future, you won’t have to heavily depend on the original problem-solver. You just might be surpised that you fixed the rest of the problem on your own.
It seems the common thread through this list is patience. When it comes to solving any problem, don’t run for help just yet. Figure out what you can actually solve first. Be patient with yourself. Forbear with others who may have the answers. Stay calm in the midst of those who made the mess.
Coding is all about creating, building and solving and improving. But it’s more of an exact art than it is an exact science. Yeah, it’s super logical, but so is understanding that mixing blue and red together makes purple. But depending on how much red, blue or any color you add, you can get magenta, lavender, fuschia, grape, French mauve, African violet, China rose, etc.
Coding is real life. If not a mere reflection of how the world works. And while it can be exacting, it’s just like any language. The more accurate the language, the less room for misinterpretation or an annoying, buggy interaction between user and software. And I suppose to make 2015 less buggy between people, we have to improve our language. Here’s a year of creating new ideas and solving fresh problems.