Internalizing Someone Else's Code: A Real Workplace Skill

I have been programming since I was very young, but would still not call myself a seasoned veteran in the world of computer programming. In fact, I wouldn't even go so far as to say I'm not still a beginner.

Out of the skills they teach you in class, I'm doing pretty well. I'm good at disciplined coding, and ensuring that methods or utilities don't do more than they ought to. I'm good at logically discerning what a class should and should not do, in order to create a more highly-organized class structure. But there are a number of real-life workplace skills that they don't teach you in class: version control, general code management, real planning, and especially coordinating with others.

I've learned many of these on my own, but many are still a constant struggle. Read more about my platitudes in this entry.

How I've Grown: Real-World Skills & Accomplishments

There are plenty of ways to measure the quality of your code, and those metrics tell me I'm proving. Without breaking any NDAs: my code is more highly cohesive, not as messily coupled, and I find myself spending more time thinking before coding, planning, and less time trying to clean up a mess I accidentally made; I notice I am more disciplined when optimizing and refactoring, waiting until test results and usage states betray a real performance bottleneck, or need for refactored code; I have become adept at using Git, and even got a white paper published through my company about why and how small companies should transition to Git from whatever legacy SCM system they use; I've become a swift debugger; I've refactored years worth of unorganized C# projects and compiled the useful things into one comprehensive library, using IDE tools to make it easy for developers to make changes or compile, or even add new pieces to the library, without much hassle. In these ways I have improved drastically.

But I still find myself consistently struggling to manage the code of others.

Wise Words From a Teacher

In a blog I did for my old job, as a writer for the Oregon University System, I wrote about one of my CS teachers at PCC who I thought was a great teacher. Dr, Trigoboff had a smart sense of humor, and loved making jokes about the world of programming. He told me something that's stuck with me:

You know you're doing a good job if you constantly feel stupid. I feel stupid every day when I go to work, trying to figure out the many problems I have to deal with. But when I look at how far I've come, I can realize I'm operating at a higher level of stupidity.

Funny words, but the lesson is apparent: get used to working with hard issues, that will test your logical abilities. If you're not feeling challenged, your job is too easy or you're not working hard enough.

I wrote a while back about when I started using Git. Now I'm accustomed to using Git, both command-line and GUI, and I feel like I've come a long way there. But there are always new issues. Every now and then I'll encounter a tough branch merge, for one reason or another, often due to some miscommunication. These issues are real, and I'm sure I'm not the only one learning how to deal with them effectively.

New Skills: Working With Different Minds

In my workplace, almost all of my coworkers are not computer scientists. They minored in CS, majoring in electrical engineering. And the EE way of computer programming is very different from what a disciplined computer scientist or software engineer will prefer.

When I get a hold of a coworker's code, to integrate it into our primary library (somehow the intern got the responsibility of managing our company library), I often see a mess of static variables and highly-coupled, un-cohesive code. This is normal for an electrical engineer, who is used to designing a static system (is a printed chip anything but?)

And that's not to say the code is bad. It works perfectly, and is very fast.

But when it comes to building it into a more traditional library, and turning it into code that can easily be expanded, I find myself struggling to do so. In order to get the job done, I absolutely can't be afraid to work closely with the coworker who wrote the code, in order to understand the nuances of their reasoning. It's an utter fallacy to assume I can understand why they chose a statement, just because I see it in front of me. I've always got to be ready for some element that I'm missing.

This kind of skill is something they definitely don't teach you in that hermetically-sealed environment known as university. I'd worked once or twice with other classmates, but for the most part real collaboration was never required. In fact, it was explicitly discouraged.

Conclusion

When you enter the workplace—even if you're a perfect student and can code in your sleep—you will have to be ready for things like this. Always hesitate to write an issue off as the flaw of someone else. Because your coworkers are contributing their minds to the same project, and you're on the same team.

You will be well served to work your hardest to develop interpersonal skills, and take responsibility for understanding someone else's code.