Coding Reflections – Week 3

81 days ago

Week 3 of attempting to speed up my learning process through reflection. On the reflection process: After 15 days of practice, this is really starting to feel like a habit. I’m...

Week 3 of attempting to speed up my learning process through reflection.

On the reflection process:

After 15 days of practice, this is really starting to feel like a habit. I’m starting to see the circles get smaller (the Art of Learning is a great book) in my work and when previously I could only think about things in their macro forms, I am discovering even more subtleties.

One way that I am starting  to make the circles smaller in the reflection process is by forming the habit of reflecting immediately when something happens. I think it has to do with what this article suggests, that  the habit of reflecting on mistakes as they happen can greatly increase the speed at which one learns. So instead of spending a long time at the end of the day thinking back on what I did, I am instead reflecting at the point of the mistake (which for me usually means taking too long to find a bug) and trying to find ways to avoid it in the future.

 

Programming:

Sometimes doing the smallest thing doesn’t mean starting small. Instead of building up to something big piece by piece, it can often be more effective to take a large block of code that currently works (from somewhere else in the code base or the internet) and whittling that down to only the essentials. There is skill required in making sure you got rid of all the non-essentials, but if you’re diligent, it can be really successful.

 
concentrate on differences. When faced with a complex system that works and a simpler one that doesn’t, you can either increase the complexity of the broken system until it works, or decrease the complexity of the working one in order to see what parts are truly necessary for what you need done. An example is that this week I had a component that when given a hash with 10 entries would work, but that wouldn’t work when I fed it my own hash with 3 entries. I then methodically added things to my hash until it was exactly the same as the complex one and the function still didn’t accept it. Finally I went the other way and stripped the 10 item hash down to 3.. and the function still accepted that hash. Now with much less complexity I could look deeper and see that the difference wasn’t in the entries, but in the hash type (the one that worked was a “HashWithIndifferentAccess” instead of a normal Hash)

 

Look for more than one example. When you are working with a large code base and have to do something that is done somewhere else in the application, look hard for other places where things are used. Remember to check more than one place instead of assuming that the code is DRY and it’s all done the same way throughout the application. If you do find that there is more than one way to do something, be sure to use the best way possible and then go back and update the bad example.

Kitteh used Scratch!! Its super effective

 

Write things down. The tactic of writing out all the possible causes has been proving really effective. Like super effective! I’m constantly amazed at how well it helps me spot the areas where I should be focusing on. Tracing out the actual flow of a piece of code across functions and source files is way better out in the open than in your head, your mind makes false leaps and assumptions that the cold hard light of a whiteboard marker uncovers easily.

 

Code in flow state more often. I’ve spent a lot of time building my trigger… now I just need use it more often.

 

 

 

 

Coding Reflections – Part 2

88 days ago

Continuing with my attempt to increase the speed at which I master the craft of programming, here is my second week of reflection. One part of the reflection process that I...

Continuing with my attempt to increase the speed at which I master the craft of programming, here is my second week of reflection.

One part of the reflection process that I noted was that reminding yourself of the previous reflections is crucial. Toward the end of the week I found that rereading me reflections from earlier really helped me to not repeat those previous mistakes.

Week 2:

Always make the minimal amount of changes to go from working to not working. Yes, I know i started with this one last week, but it bears repeating. This week I did a lot of building new things and again found myself being slowed down by making too many changes and then having to figure out which one of those changes didn’t work as they were supposed to. Starting with the simplest thing takes discipline. I’m not sure why that is, but our brains seem to want to see big effects and use those to trip us up. In order to practice the simplest thing we need to be continually vigilant.

Pay careful attention to any error trace. Often the answer is buried deeply and even though after making changes it may look like the trace is the same as before, there could be changes in where the error came from a few lines down from the top of the trace.

Write bad code. One problem that I’ve been having (probably magnified by the fact that I’m working  in Ruby on Rails) is that everything I read really concentrates on writing and architecting really good code. The problem with that is that it is really hard to know what the best code is as you go along. As you code you get paralyzed by the different design choices. You then spend hours trying to make what you think may be good design work, only to throw it away because the direction of the code means that another design pattern actually makes more sense. Instead, if you write crappy code that just gets the feature complete as quickly as possible, you end up with a complete feature and time left over to refactor (of course this only works if you’ve written tests to ensure that everything stays working after the refactoring is finished). I think it’s a lot easier to see where to fix bad code than it is to ponder over what the best code is to write. Of course, a big part of this strategy is the commitment to go back and actually do the refactoring. Code review helps a lot as sheer embarrassment can be a great motivator for going back and making sure your code looks good!

Danbo conoce a Domo - Danbo meets Domo

 Follow the Law of Demeter. There are many complex aspects to this law, but the heuristic that I’ve been using is thinking about it as “don’t take your toys apart”. If your context has a class, then you can call any of it’s methods or attributes, but you cannot “break the toy apart” and call methods of that toy’s attributes. This article does a good job of explaining why breaking the Law would seem silly in a real world context. When you buy something, when the cashier asks you to pay, they don’t “break you apart” by grabbing your wallet (your attribute) and taking the money straight out. Instead, they ask you for the money and you give it to them. They don’t even have to know about your wallet, maybe you don’t have one and just shove your money into your pockets, that would make a waiter trained to take money from wallets very confused and would be a very awkward end to the evening. Throughout the week I found that code following the law was super easy to debug and refactor, code that didn’t wasn’t, with fun little errors popping up like “you called x on nil”.

 

Coding Reflections – Week 1

96 days ago

Working full time as a developer again, I’m trying to apply my years of thinking about learning to my programming. Learning in school is one thing, it’s supposed to be the...

Working full time as a developer again, I’m trying to apply my years of thinking about learning to my programming. Learning in school is one thing, it’s supposed to be the point of school after all. Learning at school became even easier for me once I reached the all important “learning matters far more than grades” conclusion. Learning while working full time is very different though. You have to explicitly decide to learn, to take extra steps to learn, otherwise learning stagnates and you find yourself stuck at the same skill level for years. I’m determined to not let that happen, so will be making every effort to keep up the pace of my learning.

Of course, there are many ways to practice “continuous learning”, but the one that I’m going to be attempting is just reflection. Sure, learning “the hard way” and other techniques may be more effective in the short run, but using them while at the same time producing as much good work as possible is hard. Using reflection as a tool for learning has the benefit of not taking time away from other important tasks and is arguably a more sustainable learning habit to create.

So the learning plan is as follows:

Every day after work, I reflect on what happened. Where did I make mistakes, where was I brilliant? what did I learn?

At the end of every week I can review the learning and summarize it. I will try and post these summaries here every week. Some of it will be new learning, some of it will be things I’ve forgotten some will be things I didn’t do because of lack of sleep and some will be pure guesses as to what will help make things better. I will break things into sections, general programming  and language specific learning.

Week 1

General Programming:

Much of this week was spent refactoring old code, in order to make a new set of features easier to implement. The process took me much longer than it should have. Here are some ways that I think can make the process of refactoring less painful.

Always make the minimal amount of changes to go from working to not working. My method was to first change the main attributes to be named correctly, then to watch for where things broke when they called for those attributes. Terrible idea.

The last thing that one should do is rename badly named variables and attributes. The first thing to do should be to DRY up the code as much as possible, only after everything is working and the code is as elegant as possible, should you worry about renaming old bad names. a “rename_column” migration is a hell of a lot cheaper than hunting through bad code for all references to a badly named variable/attribute.

On the subject of renaming attributes never use “find and replace all”. Check each instance of something that gets replaced. If there are too many of them, then it means that you haven’t done the DRY work that you should have first. If you do use “find and replace all” then every bug that you encounter for the next hour should have you thinking… “could this have been because of that find and replace all that I shouldn’t have done?”

Basic debugging:

Resist the temptation to just mindlessly trace variables when there is a problem. After the first or second tweak to try and make things work, stop and take a breath. Start enumerating the things that could be wrong. Don’t trust your brain to hold all of these elements, write the various causes for the error down (yesterday I stuck a large strip of dry-erase roll on my des to help with this). Doing it without looking at the code too much helps as well, it gets you thinking more abstractly and actually allows you to put those years of listening to Computer Science lectures to use. Think of all the different ways that you can actually test to see which one of these causes it is. Once you have a list, rank them by probability and work from there. As Steve Wolfman told me on my very first CS lecture at UBC, “Computer Science is the science of clear thought”. Writing things down is the easiest way to make your thoughts clear.

 Ruby on Rails:

use validates_presence_of to ensure that variables that you need are there. Make sure you actually need those variables.

The before_validation callback can be really useful to consolidate and double-check that everything your model needs is there.

Spend every effort as a team to make the specs fast. Every extra second that a test takes, gets multiplied by the number of developers running tests by the number of times it’s run over it’s lifetime. Those extra seconds can easily add up to hours on a big complex project. Slow specs lead to less testing which leads to broken code.

Single table inheritance in Rails is easy. It can be done simply by making a class a subclass or another ActiveRecord::Base class. The caveat is that that superclass’s table needs to have the “type” attribute, in which Rails will automatically store the type of the subclasses.

When converting a non-ActiveRecord model to an ActiveRecord model pay careful attention to methods that may be overriding ActiveRecord methods. Deal with those first.

Rails AntiPatterns is a really good book. I’ve been trying to force myself to read and watch as much as possible on programming in Rails and this book has been by far the most engaging!

New York

103 days ago

New York Panorama