General
Breaking Away from ‘The Man’
I’d like to share another entry from my GridSpy Blog about how it is harder than you think to transition to full-time.
Life got very interesting one and a half months ago. I had a meeting with my employer where he sat me down and asked me if GridSpy was ready to survive without my salary. Essentially he asked me if I was ready to leave and take GridSpy full-time. Being an VC funded entrepreneur himself he knew how hard it is to make that initial leap into full-time start-up and gave me a gentle nudge “out of the nest.”
After that meeting my mind was racing. My wife and I agreed that taking GridSpy full-time was absolutely exciting but equally frightening. We’ve been tightening our belts for some time to get ready for bootstrapping but even we don’t know how soon GridSpy will transition from a ‘sure thing’ to a trading business. I assured her that I could land on my feet with a contracting job should the money run out.
So with much trepidation I decided that it indeed was the time to leave.
Part time Entrepreneur, fulltime Employee
I’ve recently uploaded an article on the Gridspy blog that I would like to share with you about the difficulties of founding a start-up part time.
Part Time Entrepreneur, Full-time Employee
Most startups seem to embrace 60-80 hour weeks, you keep reading about them and begin to believe that this is normal. After 12 hour marathon coding sessions ‘typical entrepreneurs’ walk 10 metres from desk to bed and collapse in their shared accommodations. Living in such lean conditions makes those crucial first months of business far cheaper. This work ethic and minimial living costs maximises the runway before the seed money runs out.
In The Beginning
A: You know, I can’t deal with code that’s not correct.
B: But what is correct code? Isn’t the correctness of the code defined by the usage?
A: Yeah, that’s for sure, but you know, there’s still the ‘correctness’ in the code. I can’t leave a code behind that is not correct. Something that’s broken
Who hasn’t had this conversation? Of those who haven’t, who hasn’t heard it from other people?
There are more than two kinds of programmers in the world. Today, though, I’d like to pretend that there are the two kinds. Those who are happy with the code when it’s good enough, and those for whom enough is never enough.
And no – this is not going to be one of the fit-for-purpose arguments. The whole notion is self explanatory, and to be completely honest, I find it slightly condescending. As professionals in this field, it’s not like we don’t understand the concept of boundaries, parameters, conditions, constraints, and other things that inherently limits us and our code.
What I’m interested in, is where we derive this notion of ‘correct code’ from. There are many books written, many more guide lines set and countless hours of code reviews done, all for the search of the correct code. All this, without really ever having a satisfying explanation – not to mention the definition – of the correctness of the code.
› Continue reading
A Burnt Out Programmer
Well, here we go. I guess this is my story. If there were one thing worthwhile that was going to come out of this blogging thing, this would be it. So listen up. Also, disclaimer: chances are, if you’re reading this, you probably know at least a few people from this story. I do not mean to insult or belittle or judge anyone in the story. It is purely as I perceived them, and how I felt AT THE TIME.
About three years ago, I was working for this company ‘A’. I had been working for this company for more than 4 years by then, which was also my first full-time employer.
At first, I really enjoyed it. Colleagues were good, the boss was really good, the work was interesting, and I got recognition for the work I did. Also, the money was good. I really had very little to complain about.
Then slowly but surely, I got sick of maintaining the same software month after month. Who wouldn’t? So I asked the boss-man that I be given something new to work on. He was most accommodating, and I was given a new product to develop and a whole new team (which I quickly populated with my close friends) to build something completely new, from scratch. I was ecstatic. It was tremendous amount of fun, while it lasted.
Musings on developing across time zones
A few years ago, when I was a sheltered young programmer… I was approached by a reasonbably well known firm in Auckland to see if I wanted to be an offshore development manager. This came about through a rather long list of co-incidences. but the general upshot of which would be that I would have to got to live in a small South East Asian country and manage developers doing custom development for clients back home. I eventually declined the offer for a number of reasons and went back to my New Zealand code monkey duties.
I’m now a few years older, and a few years wiser; and I’ve found myself in a far off country trying to organise developments in a country 26 hours by plane away.
So, I thought I’d share some of the tips I’ve picked up from the experience so far. And for the sake of lazyness, I’ll write it as an “all time top 5″ list, a-la High Fidelity.
5) It helps if the two ends are culturally similar. I don’t mean culturally similar with regards to race, relgion etc… rather it helps when the two organisations are similar in ethos. Do you both have a similar level of commitment to clients? Do you both work similar hours? Have similar expectations of what constitutes an acceptable level of testing/documentation/speed of development?
4) Try and get the ability to allow both sides to access source. This gives you the ability to check progress… fix bugs and give suggestions that you wouldn’t otherwise be able to early on in the development cycle.
3) You need to clearly define the responsabilities at each end.. which country is responsible for tracking the project state? code deficiencies? documentation etc… Preferably there needs to be one designated person at either end ultimately responsible for deliverables. Without such a person, deliverables have a habit of languishing in the bowels of the development shop without progress.
2) Personal relationships are a key factor to making things work. Having met the other person at the other end of the phone can make up for a lot of process deficiencies. Put some people on a plane to meet the folks at the other end… if you haven’t met the side, your business is likely to suffer. Try and foster relationships not just with the senior members of the other side, as the developers will likely be more open to going the extra yard for you if they have a face to put the work to.
1) Communicate. Daily if possible. Emails good, IM is better, Phone calls are the best. Make sure each side is aware of what’s going on…
Random thoughts on Logging
Tim writes
Log[...] things that you [...] care about[...].
I couldn’t agree more.
DVORAK keyboard EPIC FAIL?
This is not the topic I wanted to blog about next, but I’m mad as hell and as pointed out by Justin today I’m probably on a bit of a crusade! A little background first…
Today a rather strange thing happened to me, I typed one another dev’s DAS Keyboard so my mind switched into full on touch typing mode, this lasted about 20 seconds before I started typing DVORAK instead of QWERTY (I can touch type both layouts – ironically I’m typing this on QWERTY). I’ve also been trying since around 1999 or 2000 to switch to the DVORAK layout but I almost without fail revert to QWERTY after a few weeks. I don’t revert because DVORAK is simply too hard or too slow because I’ve actually managed to build up my DVORAK touch typing speed to something that is almost useable.
On Abstraction and Encapsulation
… or ‘OO is hurting the industry because encapsulation’
The ability to abstract is a powerful one. I have seen my share of uni-freshers. There are a million different kinds of students and they all have their different ways of understanding. Obviously, some are better than others, and some are worse.
The worse kind of students are those who cannot abstract. Of course all human beings can abstract to some degree or other, otherwise no one would be able to drive a modern motor vehicle, or eat a pie. But some students insist on ‘knowing all the details’ because ‘that’s how they understand things’.
To those students, the concept of an API is difficult to explain.
‘You call this method, and fun things happen.’
‘But how does it happen?’
‘You shouldn’t care.’
‘But I need to know!’
And there are sighs. They most likely won’t pass 101, or if they do get through, they’ll be miserable for the rest of the course, unless you’re a hot chick and have a full set of 14 geeky Asian guys to help you out with the assignments.
Getting Things Done (GTD for short).
First things first, if you don’t know what GTD is read this book!
A little background first, this post has been in draft for almost a month now, I keep putting it off which is a little ironic, but the great thing about GTD is that you just need to renegotiate with yourself and it’s all good! The other strange thing about me blogging about GTD is that I’m probably the least organised person you’ll meet for a long time! Hopefully my post will inspire others like me to get a little bit more organised, it’s worth it!