TURNKEYGNU / LINUX

From the project

Programming insight that helped unblock me

By Liraz Siri8 min read
developmentinsight

I'm finding a big part of the context switch involved in getting back to a high level of productivity on my programming is relearning old lessons.

In particular one of the most important lessons is to figure out how to systematically break down different goals into separate steps in a way that allows you to concentrate your full brain power on each of those steps in succession rather than trying to get it all done at once.

For instance, being a perfectionist is a bitch. I don't want to write ugly code! But writing code that works is hard enough. Writing code that is both beautiful (read: elegant and easy to understand) and that works is a bit overwhelming. Trying to engage my mind on two different goals at the same time either locks me into paralysis or reduces my productivity dramatically as my brain constantly switches back and forth between these two goals without getting that much of anything done.

So the trick is to do it in two steps:

  1. Write ugly code the works: Give yourself permission to write a chunk of code that is sloppy, ugly, in the wrong place, etc. Your full brain power is concentrated on just getting it to work (I.e., pass the next test).
  2. Make it pretty: Refactor it so it's pretty (e.g., easy to understand, small and elegant, small) while making sure you don't break your test.

Presto: good code that works.

You still have to be careful how much ugly code you write. If you go too far you may tie a knot of tangled complexity too difficult to break without a full re-implementation.

Note, I don't think I'm breaking new ground here. Just deepening the existing paths.

Comments (5)

Bah, web development is my kryptonite

Reply 2
I'd really like to see some screenshots when you have something to show for your efforts! It sounds like you have a good approach. We can generalize the principle of focusing on the minimum complexity required to move to the next milestones: "If you don't have to think about multiple things together, then don't!"

Also, I can sympathize with your web development struggles. My web development skills are still stuck back in the 90s. I've had refreshing them with all this AJAX goodness on my todo list for a while but I've managed to distract myself with work on the back-end/systems side so far.

Truth be told, I was hoping secretly hoping that by the time I got back to web development the tools would have improved sufficiently so I didn't have to concern myself with more arcane, low-level black magic. That has happened to a degree. Browsers are much more compliant these days. It used to be that you had to spend most of your time tracking down bugs specific to one browser or another.

When I get back to this, my plan is to start by researching in depth the low-level fundamentals, so I can go down that rabbit hole if I need to, but mostly I'd like to spend most of my time leveraging high-level Javascript compilers such as GWT and Pyjamas.

Thanks for the link to unobtrusive Javascript. Looks like a pretty sweet approach!

Good advice

Reply 3

I've been a victim of paralysis by analysis. And it's worst when you are learning new technologies. My code for the web tkldevenv interface started very VERY ugly. I didn't know in python indentation was so important! The code was totally messy, as I'm also in my crash course for learning vim. And of course there's django. But after about a month of work, I'm getting better. Just today I finally put some steroids on vim to work like a real programming tool. So now I'm fixing indentation with the 4 space standard. And rearranging files from one directory to another. And moving functions from files to common libs. It's a very agile way of working. and I'm really enjoying the process. I had a previous failure with other app in ruby which I was also learning and trying to do everything following all standards and also trying to make it pretty on the outside (the gui). I had a deadline so the project didn't end well. * sight *

In this app (tkldevenv), I'm programming the gui with 0 javascript, which also has been a bit of a challenge. For me, writing guis is something that I'm not very good at. So trying to do an ajax interface with jquery at the same time as I'm learing python/django/git/vim/jquery would have locked me completely. So my plans are 0 (and I really mean zero!) javascript. And once the app is working, I'll use the Unobstrusive Javascript technique to focus on enhancing the user experience.

I hope this helps me to advance on the project more easily. I think that was my error with the previous ruby project. And there's the whole testing world which is in my learning path too, in my way to becoming an agile pragmatic zen programmer :D

Ah, another fan of Zen and the art of motorcycle maintenance...

Reply 4
Thanks for joining what is quickly becoming a discussion of slightly grumpy perfectionists!

It's interesting you ask about optimization because I've been meaning to write a little bit about that on the blog. Premature optimization is definitely the root of all evil. My philosophy is that you never even think about performance until the program is functioning, and the code is well written and easy to understand. Then if your program needs a performance boost, you profile to identify the hotspots and only optimize those as necessary. There's no point in optimizing the CPU performance of a program that is IO bound anyway. Or optimizing the performance of a piece of code that only takes up 1% of the program's time, because even if you optimize it down to 0 ms, you'll still only make your program 1% faster! The exception to this rule is special cases when your program needs to be designed for performance up front. In that case you have to think about it before you write the first line of code, because there are limits to how much you can optimize a bad design later on. But that's rare. When in doubt, save optimizations for last.

Unfortunately, these days I get to do less and less hard core programming where all of this interesting stuff is even a consideration. Programming has changed a lot since I started. It used to be that you would start from a well defined toolset (e.g., the compiler toolkit, libc), and then spend most of your time building up your program from those basics. These days I find myself spending ever larger amounts of time finding the right off the shelf components and figuring out how to glue them together. When it works, this realized ideal of code reuse can be highly productive. But it's a shift from "real" engineering into more of an integration role, and it's a shift I often find unsatisfying.

You've just deepened my existing paths

Reply 5

Thank you for the insight, well written, simple and pragmatic thoughts those you have shared with us.

And Adrian comment was the cherry on top of the cake. Thank you also for your shares.

After 15 years of sysadmin, I've fall in love again with my academic passion - programming (back then it was mainly C and LISP). 

15y later got back to the books... a bit of everything - Software Engineering, DB engineering, UML, RUP, Agile, CVS, php MVC frameworks, etc and found myself fascinated with this new world of WebAPP development. Finally I felt good at my job and found happiness as a professional :)

But being also a perfectionist bitch (btw good to know I'm not the only "bitch" around) all the avalanche of info and knowledge soon became a block element, just like you posted. Your two steps make perfect sense to me.

Until now, my apps GUI are also zero JS pretty much the same way and with the same intuit as Adrian, waiting for the jquery  d-day to take better care of UI.

One other thing I do is break up my CSS in 2-3 or 4 parts that match the agile development phases, it helps me to understand my layouts and debug them also. Until their ready to become just 1 css file.

To finish my first turnkey user comment, I would like to ear your thoughts regarding code optimization development (sql instructions included). Should I consider it a third block element?

I never know when it's time to stop everything and focus on those lines that cost me 100 cpu cycles and refurbish them to achieve same results in 20 cycles. No one will notice those 50ms gain but seems like those lines can't get away my perfectionist-bitch-sourcecode-sight.

Again, thank you for the enjoyable reading

Nuno