First a disclaimer:
This is a personal view and opinion and should not be taken as hard facts, not everybody would have the same experience. I’m sharing this because I think it might be interesting to others.
Some background first…
I’ve been toying with Cocoa development since around 2003 and back then it was difficult getting any information on how to use the tools and it all came down to doing a LOT of reading and a LOT of pain to figure things out. Since then there’s been a lot of great resources that showed up on the scene and a lot of books has been written on the subject matter. Given that I am a sucker for punishment (hey I have to be; I’m a developer right!?) I ended up learning about a lot of the pitfalls and quick wins in the Apple development world. I’ve since trained other developers in the art of not shooting yourself in the foot etc etc…
Now for the bit you actually want to read…
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.
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.
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.
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.
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.
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…
Log[...] things that you [...] care about[...].
I couldn’t agree more.
It’s good for software developers to experience joining projects that are at different stages of their development lifecycle. At the start, faced with an empty repository where you get to make important decisions every day, write a lot of code and functionality, and understand how everything fits together. In the middle, worrying about all those little details, dealing with testers raising defects, running into gotchas that obliterate fundamental assumptions, taking an application into production. And at the ‘end’ when a project is already running in live, fixing bugs and adding new functionality to a codebase you don’t really understand, where writing one line of code that doesn’t cause breakage is an achievement. (Ok, so I’m talking about writing server-oriented “business” applications. If you’re working on different types of software or in different environments then your mileage may vary.)
At my current job I’ve been fortunate enough to work on three projects covering each of these cases and I’ve learnt a few things along the way.
› Continue reading
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.
… 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.