Linus, Alan, DaveM, Rusty, Tridge, <insert guru name here>, everyone had to start somewhere. Where did everyone start, and has anyone got useful tips?
Linus, Alan, DaveM, Rusty, Tridge, <insert guru name here>, everyone had to start somewhere. Where did everyone start, and has anyone got useful tips?
I'm a small-time Netfilter hacker, I do what I can in between work, school, Debian, and a life. Right now, I'm just learning everything, I know my way around C and Netfilter quite well, I'm just not that proficient (and my machine's bloody slow on compilations, so not getting it right sucks ;). Where did all of you guys start off, and have you got any useful pointers? (note: I'm only a 15-year old student, so I haven't got any really substantial income to speak of).
Well, when I've seen the title of your question on my stinky portal, I thought "Nice, somebody I could give some advices to, let's see what he's looking for". But you're looking for Gurus. You name people, very talented people, and you ask how they started. Well, only them could answer your questions. And I feel, certainly like most people reading your question. I'm not a guru, and the way you asked your questions makes me feel like my contribution would be useless to the state of guruness you wanna reach... Think twice before hitting the post button.
I'm not a guru, but from my point of view it looks simple.
The way to become expert is lots and lots of practise and study of everything you can get your hands on...
I started off using Linux at Uni (as a student) in 1997, on the urging of a friend who was fed up listening to me swear when Windows crashed, again.
I started coding specifically for Linux (no, I haven't done anything interesting or significant and probably never will, my code isn't that good) when I realised that it didn't keep crashing when I was working, which I liked so much that I formatted my disk and reinstalled without the former taint of Microsoft software.
I now work for a University developing an application which is supposed to run on Linux and Windows, but I am fortunate enough to develop and test it under Linux and let someone else worry about the cross-platform issues.
I started advocating Linux when I first started using it professionally, working at a different Uni to the one I now work for, doing web development. I was very impressed with the way people in the Linux community would help me with some of the problems I encountered trying to use Linux for something I had never done before. I was so impressed that I started up my local Linux User Group (Milton Keynes LUG) which I still run.
On the whole, I think the person who said "Do stuff. Repeat." has probably captured the essence of it, and from the sound of it, you're already well on your way along that path - I wish I'd discovered Linux when I was 15! Of course it didn't exist then but you know what I mean :) (I'm 27 now by the way)
Good luck with the things you choose to do...
The fact that he mentioned names in his article doesn't mean they are the people he was addressing the question to, they are just examples of the fact that (as he says) we all have to start somewhere.
The actual question he asked is "Where did everyone start?" which means you, me, the newest person to join advogato and the person who started writing Linux... and anyone else who wants to answer :)
Personally I'd say you need to think before you post, or at least read more carefully... but that doesn't matter, I'm not trying to start an argument. What I would like to say is that I think your answer to the question "Where did you start?" would probably be valued by the article's poster - so why not answer the question, and help him get a feel for the community he is already making contributions to...
1.Do stuff 2.Repeat
mstevens is dead on with his analysis (so much so, that I thought it bore repeating). The only thing I would add is that when you do stuff, make sure you do it well. Always. Never be satisfied until you've done the best possible job.
OK, misread a (little) bit. Still, I don't think that it's formulated very well, but who am I to judge somebody's english.
Just have goals, maybe easy ones, work on different projects, try not to get bored with what you do. Personally I started programming in C nearly 4 years ago. And I really started using it this summer. I have a rio500 and there were no nice Gnome GUIs for it. So I started walk500, and I'm learning an awful lot of gtk/gnome. My TODO list is just huge for all the different projects I know I can contribute to, like powerpc related utilities, gnome, window maker and the rest. My next project is an emulator, actually the GUI for one that's already written... So I know I'm gonna have some fun at that point. But I _must_ finish the programs I've started writing, like duff said, code until I've achieved perfection.
I wrote stuff first on a ZX-Spectrum in basic for my dad's Life Insurance Business then when on to do a degree in IT. Since then I have work for 4 companies, being a programmer and system admin. So far I have contributed nothing but testing and pointing out errors to freeware projects, but I am planning to do more (ie Hg, Tng-Samba).
I have written a brief article on History of Computers and Myself that was more of a basic time line of when I did various work.
I'd say that one of the best ways is to read the documentation. This sounds crazy, but most of my Unix knowlege came from first reading the man pages, and then if I didn't understand part of it, I went to the source. It also helped that I hung out on freebsd-hackers which would discuss some very low level stuff which if you file away for a while, in the future you'll finally have the pieces for parts of it to make sense.
The real core of becoming good, is not just do it well, but do it the best you possibly can, and then improve upon it. I'd say most people who work on code are perfectionists. You have to be if you want good code.
Garlic and sapphires in the mud
How did I get started? I think seeing my father always reading books.
It's a lot easier to get involved these days; although I firstused a computer in 1976 (maybe earlier), it was in BASICusing coding sheets that were sent off to be typed onto punched paper tape and then fed to a computer. If there was a mistake, whether ours or the typist's, the program failed. So the maximum length of program you could do was maybe between ten and twenty lines.
Later, the school got a teletype and a modem, and, later still, a personal computer. No, not an IBM copatible, this was 1978, but I was able to write a screen-based game.
When I got to University (Warwick, in 1981) they had Unix on PDO 11 and VAX systems, and in 1982 we joined (thanks, Kay!) this thing called Usenet, and I discovered a community of people sharing public domain code and diffs (later, pateches for Larry Wall's excellent patch program), and helping one another.
I think that's the key really: find a community to join.You need people to nurture you and encourage you, and a community to learn from. Or if they are not essential, they help a lot.
It does help to have a mentor, or mentors, but ultimately you have to find your own path. It's easy to confuse people with a lot of experience and knowledge for people with a lot of useful insights; some of us just got here sooner because we started earlier. Don't be over-awed. Yes, a solid background in computer science, mathematics and physics will probably help you to program well - especially a physics that teaches estimations and how to explain your analyses, and a "modern" integrated mathematics course that doesn't pretend algebra and trig aer unrelated, and does groups and sets and modular arithmetic.
But I think the single most useful thing is being interested. If I am in a boring job, I do interesting things on the side. Never give up, there's always so much more to learn and do.
God I sound trite today.
I've gained a lot of Unix experience points by porting stuff to various obscure systems. At the time Configure (aka "show of Larry Wall") was the only semi-AI to assist you and autoconf didn't exist yet, so you would grep for ifdefs, read man pages and write relevant defines in configuration header by hands. I ported almost all the GNU apps (1991 tape, I belive) to the very peculiar SysV 3.x variant we were using and learned quite a lot in the process, from m68k assembler and COFF to signal handling and terminal driver interface. (The only program I didn't port was the gcc. My friend did it, converting it to the m68k asm syntax the system used). I also had a dubious pleasure of working with Xenix-286, and porting anything to *that* beast was a nightmare. It had that 64K limit and it's on that platform that I learned the hard way that testing for NULL pointer by comparing to (integer) zero was a deadly wrong idea.
These days when autoconf is ubiquitous it's harder to gain exp points this way, but I see this being promptly compensated by piles of "linux-only" software. Try to port it to, say, *BSD or Solaris and I think you'll learn quite a lot.
Overall my advice would be to *read* a lot of code, preferrably good code. Write some of your own drawing from techniques and ideas you learned while reading others code. The best way to combine both seems to participate in some established project where you have a big code base to familarize yourself with and where you can write some code on your own and don't have to start from scratch and where you can learn how to work in a team. Not only this will help you to get started, it will also give you all the relevant skills that you'll need when you'll seek employment, as chances are your first job will be maintenance and learning a big code base quickly will be essential.
Just my $0.02.
I would advise you to be very random in what you do. Find a lot of tasks to tackle. Little programs here and there, and even further over there. Write new stuff, look at existing stuff, tweak software you find. Use as many languages as you can.
Good programming is about recognizing patterns in the code. If you can quickly see and understand those patterns, then you can quickly tell if they are correct or broken. You can also reference your own knowledge of different patterns and determine whether something better could be applied.
I'm not talking about "Patterns" in the formal sense. I'm talking about simply seeing different ways that code and data flows through software. This is where breadth comes in. The more programs you play with, the more patterns you'll see and learn. The more languages you use, the more you'll understand different ways to tackle problems.
The "write code. repeat." mantra suggested early is good. But I'd highly recommend to do that loop with *different* things. "write foo. write bar. write baz. ..." If you spend the next two years writing a GUI to control your fancy DTS Receiver through an S-Link cable, then all you're going to know at the end of that time is controlling a receiver thru S-Link. That is such a small scratch against the bazillion problems out there, that you won't really be that further along.
If you use C for one project, Python for the next, Perl for the third, and Lisp for the fourth, then you're going to have experience with a lot of ways to tackle a problem. Each of those languages solves problems in different ways, with different considerations, and different organizations.
Some of the best programmers that I've seen can look at a page of code and tell you right away what it does. That is because they take 60 lines of code and reduce it to a half-dozen semantic patterns in their head. Deriving code and data flow and purpose/intent from six items is quite possible. You can't do it with sixty lines of text.
So: spend your time on lots of little things, with lots of languages.
'Do stuff, repeat' is an excellent motto (or maybe a mantra).
Everything I've read leads me to believe that a lot of the current group of hacker gurus owe their status to hacking about on their home computers in the 1970s/1980s. Doing lots of stuff. And repeating/refining it.
The best reason to start 'doing stuff' is because you like doing it, or because it's a challenge, or because you want to get something working better than it does already. And open-source allows you to modify as you please, feed back, and feel a nice warm glow inside at the thought of having Done Something Good For The Community.
Practical suggestions: join a local user group, be it the ACM, BCS, an LUG or even your uni's computer society. See what they do, get involved if you want, and learn from those more advanced than you.
Additionally (or alternatively, if you're isolated from those activities) read lots of code. Find a project that genuinely interests you and join the mailing list for it, be it linux-kernel or something more mundane.
And if you decide you'll never make it as a hacker, don't worry. You can always go elsewhere and discuss plans for world domination instead :)
As someone who found himself in the same position 2 or 3 years ago (17 now), I can only advise, once again, do stuff, repeat :) However, after 2 or 3 cycles of that, consider "seek advice" as well. Show your code to other people, get advice, etc.
The other question is what kind of stuff to do. I like to think that there's a lot of (relatively) trivial to implement ideas out there that haven't been done yet - I also like to think that I fill those gaps with some of the stuff I write. Think of something small you want but don't have, then make it. Slowly work up to large things you don't have.
I can really agree with gstein's recommendation. Lots of experience is good, but lots of experience with only one thing leaves you without enough context to really know what code boils down to.
I'd also recommend doing some sysadmin -- it really gives you an idea of what a user/administrator needs in the way of interfaces, configuration mechanisms, etc. A lot of developers just don't seem to have this knowledge ;)
Sysadmin also gives you a good idea of how code should interact with its environment, which no amount of books on Design Patterns or Extreme Programming will give you -- I've seen Patterns-waving designers writing some incredibly inefficient code, because they never stopped to think how much I/O, or network traffic, or thread synchronisation, their nice design would require.
Also, it gives you a bit of an idea of how to write scalable services and fault resilience -- 'cos you have to clean up after some daemon or another barfs when it runs out of disk space. ;)
To get back to the top of the thread: I got started on a Commodore VIC-20 in BASIC, followed by the C-64 and 6502 assembly, followed by UNIX and C in college. But I'm no uberhacker like the guys you mentioned, so I'll leave it there.
As someone wiser than me once said:
Premature optimization is the root of all evil.
First make your program work. If it is too slow and wastes resources start to track down those issues. Use available tools to see where the application wastes most of its time or what it wastes resourcewise. Always monitor that your optimizations don't break the functionality that you had from the beginning.
But sure, you are right in that you can't just take any pattern and expect it to be the ultimate end-all solution. Patterns are just just that, namely patterns for programming. They have to be modified and adapted to suit your need.
Anybody know of any existing programs to analyse which statements in a
program are taking the most time? I'm thinking of something like gdb
=~ s /step/step+time/
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!