Strangely enough, I received the most profound piece of advice I have ever heard in a pub out in the wilds of Wales, while on a stag do. We'd spent the day quad biking, shooting, and engaged in other equally testosterone-fuelled activities. We'd had our curries, and were sinking a few beers before the stripper-that-the-groom-didn't-know-about-but-fully-expected was due to arrive.
I got talking to one of the guys, and the talk turned to babies. My wife was pregnant, and I expressed some concerns about my ability to deal with the immense responsibility of caring for and raising a whole new human being.
"Don't worry about it." came the booze-fuelled reply from the father of three. "You already know everything you need to know. If they're hungry, feed them. If they're cold, warm them up. If they're too hot, cool them down. You'll be fine."
At that point an approving roar announced the arrival of a comely lass clad in a nurse's uniform, and we all lost interest in the conversation.
But the guy was absolutely right - common sense will take you a very long way as a new parent. And that it why I have no hesitation in awarding this particular piece of advice the most profound I have ever received.
---
Last year I was chatting to a new father-to-be, and he asked me for advice on dealing with a new baby, as he was freaking out about the responsibility etc etc as mentioned above. I furrowed my brow, drew myself up to my full height, pretended to be thinking thoughts of the utmost profundity, and passed on verbatim the advice given to me.
He didn't believe me, of course, but I hope that in the fullness of time he'll appreciate my astuteness.
This got me thinking about what advice I would give a newbie engineer, in the hypothetical situation where such a person were to ask me for advice on programming. I say 'hypothetical' because (a) nobody's ever asked me for advice, and (b) as a newbie, I was so self-confident and arrogant that I rarely asked for advice. I fully expect the new generation(s) of engineers to be exactly the same. Indeed, I found that the people who tried to give me advice were almost without exception fine instances of a combination of arrogance and incompetence. My favourite piece of expert advice is still that function prototypes are a waste of time, so don't bother with them. Absolutely priceless, you can't make this sort of thing up.
Instead I just wrote a whole bunch of dreadful code, slowly and painfully worked out what worked and what didn't, and over the years developed an approach that now serves me well.
So, if asked for advice, here is what I would say. These will form the basis of a series of blog articles over the next few weeks/months, depending on how often I find the time to sit down with my netbook and a few glasses of wine.
1. Use version control.
2. Use unit testing.
3. Do it right the third time.
4. A quick wrong decision is often better than a slow right decision.
5. When in doubt, use brute force.
6. Fail fast and hard.
7. Learn a scripting language.
8. Use static analysis.
Subscribe to:
Post Comments (Atom)
4 comments:
You've certainly opened a can of worms with this one! For me the advice I give out the most often is 'If you can't describe the problem you are trying to solve in English (or whatever your native language is), then don't even think about sitting in front of a keyboard.' That's not to say that I disagree with your list (well may be one or two).
Hi there, came to your blog from Stack Overflow. I write code for embedded systems and on a team of mostly electrical engineers. There is no version control. I came to this company from one that used the 300 pound gorilla Clearcase, so I had do something. I installed the 3 pound tortoise that is SVN on my desktop. I sleep a little easier at night.
So I agree with your points, especially 7. To that I'd add, get a good editor and learn how to use its regular expression and code navigation functions... The same task you can complete by hand in 40 mins, in perl in 20 mins, can sometimes be completed in 5 with search/replace and regular expressions.
But can you expound on 3 and 6?
Thanks,
Shimona
Hi guys, thanks for the comments. Please note that I've sneakily edited the post to add a number 8 (one that I'm sure Nigel felt was missing!). In the interests of brevity I skipped over a few ideas that could have been on the list, but they're earmarked for future blogs.
Hi Shimona, thanks for your comments, you make a great point about getting to know the capabilities of your tools. And I'm glad to hear that you've snuck in some version control, I regard coding without this as nothing short of madness.
I'll expand on all of the items in later posts, but basically (3) says 'don't try to design the ultimate solution for a given problem upfront; instead, get a simple solution up and running fast, and only revisit it if needed'. And (6) says that, at least during development, the tiniest error should bring the code crashing to an obvious halt; fix the problem, don't try to silently cover up system errors.
Post a Comment