This being my first post, I am going to dive right in to broken coding behavior. If you have ever coded in any programming language then you have been in this situation: the code works but I'm not sure why.
This is why I have usually been the slower coder in any group I work with. I may be wrong but I fuss and fuss, and fuss about my code. And then I fuss a little more. But I am usually confident with my code before I release my code to the wild. Even then, I know, there could be problems.
That whole appeal was my setup to what we all experience at work. Get it out the door. It better work and we want no problems. What I usually see, miss steps and rough coding that points to someone who did not know enough about the language that was being written or that they copied code from someone else and it worked so it must be okay. What's the harm in copying code. Everything. What I am saying is: you don't know what you don't know. In most cases, you get lucky and nothing blows up. In some cases, it's someone you know, or there is a story about that person. You know them. It was the reason for that training video you had on paying attention while at work.
All I can say is, really! What do you mean, don't be distracted. Have you ever worked in a corporate office. It is by definition a distraction.
My last full time fortune 100 job was in phoenix at a complex where I sat in the middle of a sea of cubicles. The barriers were only chest high, so if you stood up, you were looking down on someone else. It was weird to say the least. I got along with my team members, so we were only slightly weirded out from listening to each others personal calls. It was very weird, and distracting, being able to hear everyone's conversations. I swear, I could hear the heavy breathers from three isles away. That I was chatty about making sure I understood my work, made me kinda noticable. I am stubborn so even while working through a code challenge, I would get a comment from another row, sometimes with the right fix for my issue. Other times, utter chaos. Eight people at times, arguing over an issue, because we all heard the chatter. Back to my point, who can get work done in this environment? Me and my crew resortsed to headsets. This lead to missed calls and us having to bother each other to make sure we didn't miss an IM from supervision. Did I mention distractions. We had pop up texts from inside communications and phone calls and people chatting over each other near my team. And I am supposed to code right with no errors. And don't forget to make notes!
Okay, so the last part here was a bit of a rant. The main point is we are distracted while working; this is life. But how much can a coder learn about their code and improve when faced with this challenge? Well, as one of my professors used to say in college, "don't come to me with problems if you don't have a solution." I have a solution, and I am open to feedback. My solution is mentoring. A tried and true, old world program that worked for centuries. Why we don't do it much in America is a culture thing. But I think it's time for a change. Classics are classic because they are good. Like a clean haircut or a well dressed worker, people just respect others who put in effort. I think it shows you care.
Mentoring is fun too, you can do it from home, you can do it from work. You can do it in the park. It means we are not tied to our desks or corporate offices. It builds relationships and it helps others to notice your abilities.
Programming for real life comes from mentors. I have noticed that I kind of fall into these kinds of situations myself, when others ask me how to address a code or configuration issue. But I think we need to formally acknowledge this skillset. It may mean, shock, that the older crew, may still have some use in our build teams! Grey hair is something you only get as you age. There might be a reason you have to live a certain length of life, before life allows you to show your age. I think it is a badge, hey, you made it this far, you might be doing something others should learn.
This gets me to the meat of this post. The code I have built, not really used much. The code others have built, and I have modified. There is lots of that. Any true coder will look at themselves as a mechanic, more of a repair person than a true architect. If you are lucky, you get to code and deploy your own masterpiece but that also comes with major risks. I find that the environments available for deployment teams are so varied and complex, you just don't know how every system is going to react. I have missed more than a few nights sleep over my code, only to realize, there is code out there that I know is bad, but it is still working that way. OMG should I feel bad about that? I don't have time and the company is not going to pay me to go back. Well, I don't even work there now, so what is a coder to do? I think what I am getting down to here is, I think we need to rethink programming. Think of it less as a fast paced miracle drug and more like a slow and methodical art, like a painting. Everything from the canvas to the type of instruments used. Even the way in which it is viewed effects the experience. I dont know, I might be just burned on the casual ignorance of rush and pray it out the door methodologies, but I dont think I am alone.
-Rhodey
Top comments (0)