It’s been about 2 months now since I switched back to doing mostly software development – in an attempt to get a new home monitoring software going. That does not mean that electronics and hardware design are off the table – far from it, in fact – but the switch has turned out to be essential for me to break out of the box, and find the headroom needed to make things happen.
This is not just a post about HouseMon, however. What I’d like to describe, is the process I went through, and some first experiences and notes.
Picking a new programming language is no big deal, really, but in this case I intend to go in very deep. I don’t just want to program in CoffeeScript, I want to become productive in it. If this will take several months – as I expect – then so be it. As the saying goes:
“If it’s a job’s worth doing, it’s a job worth doing well.”
Note that I didn’t set out to use CoffeeScript, or Node.js, or AngularJS. Half a year ago, I wanted to use ZeroMQ and Lua, in fact. But there were tiny gaps and little doubts in my mind, and I thought it best to let the whole issue rest. Turns out that this strategy works really well (in cases where one can afford the extra delay, of course) – if a decision doesn’t solidify once taken… wait, don’t rush: it may be trying to tell you something!
Of course every switch will be painful, to some degree. The habitual is, by definition, more convenient. A switch to something new and unfamiliar is a step back, sometimes even a huge step back. And at the end of this post I’ll tell you about one more switch which is also excruciatingly painful for me this very moment…
Not all changes turn out well over time. There are several forum choices to prove it, as all long-time readers and participants at JeeLabs know, and which I still feel bad about.
So how does one pick new technology, apart from choosing based on requirements?
My answer to this is now: follow your passion, but don’t let it blind you…
Go for what interests you, go read and surf like crazy, and try the things which you like. Because unconsciously, your mind will make lots of choices for you, leaving you free to apply your reasoning for making trade-offs which need to be made anyway.
The second guideline IMO, is to never go down a rabbit’s hole – if all the decisions you have to make end up becoming inter-dependent, to the point that you have to accept a single package deal, then… stop. Choices are compromises. There is no silver bullet. If something looks too good to be true – then it probably is (hmmm… where have I heard that before?).
I’ve taken quite a few very far-reaching decisions, lately, w.r.t. HouseMon. But watch this:
- CoffeeScript is not essential – it interoperates 100% with standard JavaScript
- Node.js is not essential – it could be replaced by Ruby On Rails, or Django
- SocketStream is not essential – it merely streamlines the use of WebSockets
- Redis is not essential – it could have been ZeroMQ, or Mosquitto, or some DB
- AngularJS is not essential – it could be replaced by Knockout, or Backbone.js
- Safari is not essential – everything will work fine with Chrome or FireFox
- the Arduino IDE is not essential – underneath it’s all done with avr-gcc
- the JeeNodes are not essential – there are several µC alternatives out there
- the RFM12B is not essential – again, there are alternatives one could use
- the Mac I use is not essential – it’s merely my personal platform choice
- Vim is not essential – it just happens to be the editor I’ve chosen to work with
The key phrase is “is not essential”, and the key concept is orthogonality – the choices made above are to a large degree (but not 100%) independent of each other!
If any of the above turns out to be a disappointment, I can still get rid of it, without the whole plan unraveling and blowing up in my face (I hope…).
Which brings me to the main point of this post: by having a certain amount of de-coupling in there, something else also becomes quite an important benefit… the task of learning new stuff has a reduced risk! – if any of the above hits a dead end, I will lose my investment in time and energy in part of what I had to go through. But not all.
It’s really the same as in the real world: don’t put all your eggs in the same basket, as the saying goes. If one of ’em crashes and breaks, it won’t be the end of the world that way.
With so many eggs, eh, I mean technology choices, forcing me to re-learn, there is one more which I’ve decided to go for. Long ago, as a kid I took a course in touch typing, but never found the courage to carry it through for programming – all those nasty characters and punctuation marks were (and are) scaring the heck out of me! Well, no more excuses and no more hunt-and-peck: this post was written in touch-typing mode. Let me just say that my hands are hurting like crazy right now, and that it took – a g e s – to write!
Tomorrow, I’ll post an annotated list of pointers, for many of the items listed above, about the information I found which is really helping me forward right now. You may not make all the same choices, but with a bit of luck there will be something in there for everybody.
I do a fair amount of typing for work, not code, just text. Four, five years ago I had a touch typing course, 8 hours, in two days, since then, the typing speed really increased, and I really enjoy typing while looking at the screen. One of the main advantages, I find, is the reduced amount of correcting – text comes out at least well typed first time around! So I’m sure you will benefit for it!
Another choice: I’m waiting for my alpha grip keyboard to speed up my typing and help against rsi
You will not regret your decision to learn touchtyping for good. In my case, I had a very simple touchtyping class when I was in high school. I think it lasted only a quarter, so it wasn’t very long, and we were young back then and computers were not as prevalent as today (this was like 30 years ago; I’m in my 40s), so nobody really took it seriously. But about 10 years ago I thought “if I use computers so much then every second I can save by using a computer more efficiently will make a big difference” and decided to learn to touchtype. I can say it’s been on of the best decisions I’ve taken; it allows me to focus on what I am doing with the computer instead of diverting my attention to how to enter information into it. I learned using gtypist (open source). Ugly text-based program, but highly recommended (in fact, that it’s text-based probably helps to learn faster since there are no graphics to be distracted by, and since there is no mouse you have to get used to using the keyboard ;-) ).
Good luck with your touchtyping!
I’m another typing ‘improver’. My favourite tutor is the free KTouch – http://en.wikipedia.org/wiki/KTouch It’s possible to add your own training lectures so could set up ruby, javascript based flavours etc.
If I don’t practice some ‘scales’ on a fairly regular basis, I’m inclined to revert to old ‘looking at the keyboard’ habits.
I agree with @amvv’s comment – it feels great to type while looking at the output after (many!) years of doing it the wrong way.
Good luck JCW. Thanks for all the inspiration.
JCW, I agree that touch typing is the way to go. It’ll take time to re-program your brain (from the old hunt & peck method), but you’ll find that initial slow progress will accelerate. You’ll also become more aware of the learning/unlearning process, which is quite enlightening in general.
An pertinent quote: ‘What we learn to do, we learn by doing’- Aristotle.
Hi, I fully agree with your method and it is an interesting combination of logic and gut feeling (very illogical) but I think all good programmers or problem solvers seem to pull on it regularly whether they are aware of it or not. Sometimes, things just don’t feel right and very often you I end up getting frustrated at the end of several hours of head bashing, only to come back the next morning and solve the problem within five minutes! Our subconscious computer is running behind the scenes and definitely attempts to solve any task we throw at it, with whatever limited information it has. That’s why I like the approach (and share it) to gathering loads of info on the web before and during the creation of any project or device although sometimes it also is discouraging because everything is already out there in some form or another, maybe not exactly what you are doing but similar! As for housemon, I wish you all the best and happy coding.