4 ms·

It's not so much that I disagree with OP, it's just that I've never done much of what he recommends. Initially, screw the algorithms and data structures. That

by edw519 15y ago

It's not so much that I disagree with OP, it's just that I've never done much of what he recommends. Initially, screw the algorithms and data structures. That's like saying, "Initially, screw the basement and build the attic." The number one problem I've ever seen with shitty code, over and over and over again, is lack of understanding of fundamentals. Do yourself a favor and learn how to build things properly first. Poorly structured data cannot be overcome by the greatest of processes. Poorly structured processes will give you technical debt forever. Choose a good language. One that you think you can produce something useful in short time. This is a chicken and egg problem. How would anyone know which language to choose without using it first? Choose anything, just get to work. (When in doubt, choose something popular. Things will be tough enough without running into problems no one has ever seen before.) Choose a good editor. No. The more features and functions an editor or EDI has, the more crutches you'll routinely use when you don't need them. Which means you won't learn and grow as quickly. Choose something simple like Textpad, disable the syntax color highlighting, and make mistakes. Sure, it'll be a pain in the ass, but that's the best way to learn the quickest. Use an operating system that’ll teach you something. If you are paying enough attention to the operating system to know what it is, then you aren't paying enough attention to what you're building. Focus on what you're building. Get it to work properly on any operating system. Let someone else worry about porting or emulating on other operating systems later. Don’t copy-paste files to backup stuff. I've been doing this for 30 years and have never lost anything. I save every old version. Relying on special software to do this for you makes you dependent on that software so much so that you may lose track in your head of what you have. Other programmers may disagree with me; it just shows that there is more than one way to do things. Know where to get help. The more popular your choices are, the easier it is to do this. (Don't make the same mistake as me: using specialty and proprietary technologies. When Technology A and Technology B don't play nicely together, it's really hard to find someone else who has experienced the same problem.) Develop your netiquette. "netiquette" shouldn't be any different from any other etiquette. Just treat others the way you'd like to be treated. Meet people, because books only teach you routine stuff (oh and the "book" is dead they say). People aren't much better than books. The best teacher is building stuff. Write opensource code. I've never done this and have never understood why people think it's so important. I prefer to build stuff for paying customers. They're never bashful and are a great way to get really good really quickly.

NickPollard 15y ago
I have to say that I agree with the article on 'screwing the algorithms and data structures'. Sure, if you want to be a good, successful programmer, you need to know your algorithms and data structures, inside out, back to front, whilst underwater being surrounded by sharks. This is far more important than being up-to-date with language X or framework Y. However (and this is a big however), the letter is targeted at people who are thinking about learning to program, in which case it's important for them to actually achieve something quickly, so that they will be encouraged to continue. When I started to program (at the grand age of 3), I wrote absolutely terrible programs in BBC-Basic. For years I wrote lines and lines of code without a single function, procedure or subroutine. Even Arrays, lists and such were beyond me. I didn't care though. I had written stuff that worked. I had created text based adventure games that the computer would play with me. To a young kid, that feeling of power, creativity and success was like a drug, and I was addicted. If instead, I'd spent ages reading books to work out whether I should be using quicksort or radixsort, or whether my Hashmap would scale well enough, I'd have gotten bored and never written anything, and probably become an accountant.
mironathetin 15y ago
"I prefer to build stuff for paying customers." Thanks for this brave sentence. I already started to think it was only me.
SingAlong 15y ago
Thanks everyone for the comments on the blog post. I don't know how whoever submitted this found this one. This started as a letter to my junior in college who asked me for advice on where to start. The number one problem I've ever seen with shitty code, over and over and over again, is lack of understanding of fundamentals. I humbly beg to differ and would stick to my words - "Initially, screwing the algorithms and data structures". I guess I should have written the word "initially" in all-caps. I feel that to be creative as a programmer, it's very essential that you can fuel your creative self by motivation. And that can happen not by reading too much about how to do it, but instead just jumping into the pool and checking it out (which a you, me and a lot others agree on). Later on, when interested to improve, the theory part can be learnt. The intention was not to scare away those who want to begin by telling them there's a learning curve to be followed and instead just say "here's what you can do, check these out, install these stuff and get started". How would anyone know which language to choose without using it first? Which is why I mentioned trying out some languages for a few hours and choosing something of personal taste + something with good docs (getting started, tutorials, etc). About backing up files by copy-paste, IMO, it's just personal choice. Whatever works for you. Since the post was targeted at someone who wanted to begin, I thought I should clearly mention to the reader that better tools existed. I prefer to build stuff for paying customers. Atleast to get to that point where you 'can' build stuff for paying customers, you have to start somewhere. First, finding paying customers isn't that easy for everyone. Second, when you don't know programming at all, and are trying to deliver something technical to a paying customer, IMO, it's just building castles in the air.

by edw519 15y ago

NickPollard 15y ago

I have to say that I agree with the article on 'screwing the algorithms and data structures'. Sure, if you want to be a good, successful programmer, you need to know your algorithms and data structures, inside out, back to front, whilst underwater being surrounded by sharks. This is far more important than being up-to-date with language X or framework Y. However (and this is a big however), the letter is targeted at people who are thinking about learning to program, in which case it's important for them to actually achieve something quickly, so that they will be encouraged to continue. When I started to program (at the grand age of 3), I wrote absolutely terrible programs in BBC-Basic. For years I wrote lines and lines of code without a single function, procedure or subroutine. Even Arrays, lists and such were beyond me. I didn't care though. I had written stuff that worked. I had created text based adventure games that the computer would play with me. To a young kid, that feeling of power, creativity and success was like a drug, and I was addicted. If instead, I'd spent ages reading books to work out whether I should be using quicksort or radixsort, or whether my Hashmap would scale well enough, I'd have gotten bored and never written anything, and probably become an accountant.

mironathetin 15y ago

"I prefer to build stuff for paying customers." Thanks for this brave sentence. I already started to think it was only me.

SingAlong 15y ago

Thanks everyone for the comments on the blog post. I don't know how whoever submitted this found this one. This started as a letter to my junior in college who asked me for advice on where to start. The number one problem I've ever seen with shitty code, over and over and over again, is lack of understanding of fundamentals. I humbly beg to differ and would stick to my words - "Initially, screwing the algorithms and data structures". I guess I should have written the word "initially" in all-caps. I feel that to be creative as a programmer, it's very essential that you can fuel your creative self by motivation. And that can happen not by reading too much about how to do it, but instead just jumping into the pool and checking it out (which a you, me and a lot others agree on). Later on, when interested to improve, the theory part can be learnt. The intention was not to scare away those who want to begin by telling them there's a learning curve to be followed and instead just say "here's what you can do, check these out, install these stuff and get started". How would anyone know which language to choose without using it first? Which is why I mentioned trying out some languages for a few hours and choosing something of personal taste + something with good docs (getting started, tutorials, etc). About backing up files by copy-paste, IMO, it's just personal choice. Whatever works for you. Since the post was targeted at someone who wanted to begin, I thought I should clearly mention to the reader that better tools existed. I prefer to build stuff for paying customers. Atleast to get to that point where you 'can' build stuff for paying customers, you have to start somewhere. First, finding paying customers isn't that easy for everyone. Second, when you don't know programming at all, and are trying to deliver something technical to a paying customer, IMO, it's just building castles in the air.