« « JavaScript Patterns – Chapters 1 and 2

JavaScript Patterns — Chapter 3 » »

Learning…how to think ahead about big-picture coding problems

Posted by on Jul 30, 2014 in Blog | 2 Comments

In past posts on this blog, and conversations with mentors, colleagues and friends — we have lamented the difficulty of the learning path for the intermediate coder. The posts I’ve been writing about recommended book readings are part of a step forward. But if one is not careful, they become an academic exercise. It’s in the application of new coding concepts that one truly starts to see their worth, I’m starting to understand.

I’m learning that another thing, in my estimation, that sets apart experienced coders from the, well, less-experienced ones, is the perspective that comes with experience. Perhaps I will be that good as the years go by, but since I’ve never really been one to patiently wait until I get older to understand things, I focus on precepts I can apply now that I feel can help give me that perspective.

I’ve now written and deployed my first object-oriented Ruby project. It’s certainly different than front-end, but is teaching better practices. I also now am writing Ruby in my JavaScript, and getting syntax errors while I do it, but that’s okay.

Anyway, as I’ve been learning my way through this with the help of my teammates and my editor, I’ve been thinking a lot about two concepts: thinking through what a system should do, and how to go about it, before diving into code, as well as the importance of documentation. Both of these ideas come from teammate Serdar, who I’m incredibly lucky to get to benefit from, and who’s been a marvelous teacher this week in particular. As I wrestle with these concepts, I thought I’d capture some of my thoughts here. So if you, like me, wonder what it means to be attempting the “next” level of programming, and how you get there, here’s one type of approach.

I recognize some of these concepts are controversial, and it’s intriguing following the debate. I don’t mean to say this way is the one true way, but that these are just where my thoughts happen to be now. And they may be in a different place next week. Just sharing as I go. If you have alternate perspectives, please drop them in the comments.

To me, a “beginner” programmer can follow tutorials and examples to hack until it works — bringing their vision to life. And that’s great and noble. But as the systems get bigger and more complicated, we crave order. I feel myself floundering, leaving out key steps. It’s not about not knowing “how” to make the program do a thing, but how to figure out what that program should do. Taking a step back and looking at the forest instead of the trees.

I didn’t do it this time — but I will in the future. Just as with data analysis, it is recommended to write down your questions first, what you want to ask the data, before looking at a spreadsheet, figure out what you want your program to do. Talk through and describe those steps and their different components. Discuss that logical flow with a friend or colleague to see what you may have overlooked. Don’t start implementing until there is a thoughtful plan as to what you are coding.

The next step beyond that is to figure out what the components of your program are. This lends itself quite well to the work I’ve been doing looking at object-oriented programming and design patterns. What classes, or types of information is there? What methods are there, and what do we want the code to do? Again, discuss the architecture of the system with a colleague. Recognize that code design is extremely important, and much deeper and more thoughtful than just going at it.

I hadn’t ever really thought that this type of process could bring more sanity to my workflow. I love attending hackathons, and doing quick weekend projects, but in some ways, that’s just cementing the “get-it-done” workflow. I think it may take longer to start projects this way, but there should be less last-minute total-course corrections. I actually think it will speed things up in the long run, and just as importantly, improve my mood on deadline when it gets crazy. It’s like helping your future deadline-crazed self.

There’s another important aspect to helping your future self, and that’s documentation. It’s funny — I’ve often eschewed documentation as an optional thing, especially on smaller projects. But some of Serdar’s comments really changed my tune. When you come back to the code later, remembering even simple caveats, how to kick the program off, things you meant to optimize but didn’t get to, and special cases that might mess up the program’s accuracy when re-deploying it, all are essential. If you want to be selfish about it, documentation will make your life easier later. Of course, we also do it for our colleagues coming to a project sooner or later. And it feeds into my overall goals about sharing with the community, too. I also thought of documentation as a bigger deal, and a formality, but a readme is important even on a smaller scale, and can be even 10 lines. But something is better than nothing.

I also like the readme idea, because the documentation is closely related to the project itself. Sometimes documentation ends up in a central place rather far afield from the project, which is less than ideal. It is up to you to update the readme as the code changes, but perhaps it would be easier to remember that when it’s closely related to the project.

I’m also now seeing the role of documentation via comments within the code. I feel like I hear different advice from all over — you should comment a lot, the names of your variables and functions should make your intent clear and you shouldn’t need comments, etc. But perhaps one really meaningful perspective is that generally, the names should speak for themselves, but comments explain what you meant to do, or why to do something. In fact, I’ve been advised that on commit messages, too. Not “changed some CSS”, because that’s obvious information that’s already findable. More interesting is “adjusted headline size because it was unexpectedly wrapping at certain widths” or some such.

Anyway, when you see me at a conference and ask me why I’m posting more sporadically, it’s because this is deeply difficult work, but it’s a whole new level of doing work. It requires some deep concentration. So, when I tell you I’m learning, this is the kind of thing I mean. Who knows what knowledge the next day will bring? All we can do is vigorously run toward it, embrace it and seek to do the best work we can.

Someone asked me the other day if this type of knowledge acceleration is something I want. Let’s not sugar coat it — this is deeply difficult work: a new way of thinking, a whole new vocabulary and learning in several parallel directions at once. But do I want it? Gosh, yes, it brings some sort of elation and euphoria that’s difficult to describe, because learning and getting better is one of the best ways I believe we can spend our days.

« « JavaScript Patterns – Chapters 1 and 2

JavaScript Patterns — Chapter 3 » »
  • Christopher Krug

    Thanks, Michelle. I would like to hear more about the documentation process, i.e., examples, etc.


    Michelle Minkoff Reply:

    Thanks for the comment. I’ll work on that, hopefully for next week!