Lessons From 2012

2012 was a great year for learning for me. I had the opportunity to make many mistakes and learn from them and for that I am grateful. So without further ado:

Lesson 1: Automate everything

I could have written this as “test everything” but “automate everything” encompasses that and so much more. As an example, if you find yourself performing the same editor actions over and over, STOP. Learn how to write a macro and store it for easy reuse.

If you find yourself manually executing a series of steps to check a result, STOP. Write an integration test now and learn how to run your integration tests in isolation for faster development. I would say that the moment something manually needs to be done in this regard once or twice, a test should be written.

If your deploy process is “nearly automated” by whatever tools you are doing, STOP. Author your own tool that fills in whatever gaps your existing tools have.

If your compilation requires some sort of dependency checking or other manual steps that do something other than make all, edit your Makefile and make it better.

On that note, if you are forgetting to build the documentation and commit it, add that to the Makefile too as make docs.

On that note again, you might as well add make docs as a pre-commit hook so you never have to think about it again.

Why do all this? Because it is worth it to invest in your own time. By taking some time upfront to learn something new and automate it, you are investing in yourself, and surely that is worth it right?

Things you should probably learn if you haven’t already (and you program):

  • Bash/Zsh scripting
  • Makefiles
  • emacs/vim (Actually learn them)
  • The profiler of whatever language you use
  • Debugging tools of whatever language you use

Lesson 2: Take actual breaks

I need to get better at this myself. Personally, I hate leaving any problems outstanding, but inspiration rarely strikes when you are in the thick of things. My most productive moments come after I’ve been itching to get back to work.

But, but, but, I’m a workaholic.

Yes, you are (speaking to myself here). But even in moments when you aren’t working on your direct tasks, you can at least take time to read or work on something entirely different. To me, this still constitutes a “break” and I have enjoyed exposure to many topics this year as a result including:

  1. A new programming language
  2. A reread of K&R
  3. Electronics
  4. Hadoop (which, for reasons I’ll discuss in a later post maybe, I don’t plan on using for a while)
  5. Contributing to various open source libraries

Also, breaks should encompass exercising (mandatory!) and eating. I missed more meals than I care to admit in 2012, and I hope this will improve moving forward.

Lesson 3: Don’t do what everybody else is doing just because

This comes with a caveat. Usually, lots of people are doing something because that thing fits a lot of use cases. Or, the general use case of the time is essentially the same from person to person. How many people, when told to write a webapp, turn straight to Ruby on Rails without even thinking?

Use the right tool for the right job. Make your life harder for a short while, but much easier later. It can be scary to venture off the beaten track (beaten either by others or by yourself), but at the very least, keep an open mind to all options available and analyze them objectively.

Some people have the opposite problem where they go out of their way to do something novel just for the sake of novelty. This is dangerous as well. Again, strive for objectivity, determine the best course of action, and do it.

Lesson 4: Your morale matters

If you don’t like what you’re doing, if you find yourself bored, do something about it. Tell your manager (and be grateful that you have a manager that will listen). Before doing so, however, make sure that there is, in fact, another option that you can demonstrate capability for.

Be appreciative of the people that improve your morale. Humor and positive attitudes are probably better indicators of long term productivity at a professional workplace than raw “smarts.” Note that I said “long term” productivity. Having smarts but zero morale or an extremely negative attitude may work for a while, but burning out is a real danger.

When you choose work late, be thankful that you have a job that actually provides you with tasks that you would be interested in working late on. Don’t impose a hard schedule on yourself and hate it too! If you don’t like what you’re doing that much, than don’t work evenings. This goes for students too. If you are miserable studying condensed matter physics or Riemannian manifolds for an entire weekend, maybe you should be a Physics or Math major (or politics or English or …).

Lesson 5: Your editor matters

Don’t “settle.” Examine other editors and ruthlessly assimilate everything that could be useful to you. I won’t speak too much about this, but be brave! If you don’t use emacs or vim (or one in the other) yet, I encourage you to give it a shot in 2013. If you already use them, take time to continually invest in your knowledge of them. Learn a new package or write your own.

Conclusion

It is very possible that you the reader disagree with some of my assessments, and that’s ok. I should stress that (this being a personal blog), all of the above is directed primarily at myself. Hopefully, however, some of it is useful to you as well; I am sharing this because that possibility exists.

Comments