6 ms·

Things I Wish Someone Had Told Me When I Was Learning How to Code

159 points by iamtechaddict 13y ago

rmchugh 13y ago
Nice piece. This definitely resonates: "Braces should go on the next line. Braces should go on the same line. Use tabs to indent. But tabs are evil. You should use stored procedures, but actually you shouldn’t use them. You should always comment your code. But good code doesn’t need comments."
- danieldk 13y ago
  In contrast to what she is saying, there is a true path. The true path is: use whatever the coding standard for that particular company or project says. There is nothing more annoying than people having different formatting settings and having each commit/diff being 80% formatting changes and 20% actual changes.
- mattmanser 13y ago
  Apart from some of them are the wrong way. Work on an over-commented code base and come back and tell me commenting everything is good. Work on a large crud app where it's 'SPs only' and come back and tell me SPs are good. Worse still that particular debate is dead. The parametrized queries not only won, they blew SPs out of the park with ORMs. Hence the articles linked are 7-8 years old. And yet I still come across the occasional programmer who uses SPs (who will generally think ORMs are evil rather than massive time savers). As for commenting, new coders need to comment because they forget what they did. New programmers can't read code properly, they need help from comments. So it's good general advice to tell newbies to comment while they're learning. But not in production code. New coders also tend to get a revelation when they go back to some of the first code they wrote and can't understand it. The revelation is 'I should have commented it all!'. But the revelation is false, there are two reasons they can't understand it. Firstly, it's crap code because it's their first code. Secondly, they can't read code properly. But they can't admit it to themselves because they think that now they're good coders. I've seen this time and time again, programmers with less than 2 or 3 years experience often won't try to read the code and figure out the logic when something goes wrong. Be it their own code or a bug in someone else's they've been asked to fix. They start changing random variables or commenting out lines. And yet they honestly think they are good coders. Many time I have sat down with them to help, read the code and then pointed at a line and said 'Hmmm, that looks wrong'. And that will be the bug. 5 min fix, if you can read code. It's just part of the learning process and now I'm older I can see the Dunning–Kruger effect as stupefyingly obvious in programmers. I don't begrudge it, I don't think they're stupid or unskilled, it's just a stage every programmer seems to need to go through. The stage where they still haven't realized they can actually read the code to figure out what it does. What's funny is that I can see I suffered from it constantly in my early years and was a right arrogant idiot.
  - girvo 13y ago
    I disagree with some of your points, and I have experienced what you pointed out should be needed to bring that conclusion. This stuff isn't cut and dried, so i just go with whatever the project is already using. Seems easier that way :)
  - dsego 13y ago
    Why the down votes? These are good observations.
edw519 13y ago
Nice post. A few more of my own: 1. There is no substitute for the hours spent coding. Sure, you can waste a lot of time, but there's a high correlation between hours spent and skill attained. 2. You can do almost anything with almost any tool. The energy spent debating tools would probably be better spent building something. 3. One of the biggest differentiators between a good coder and a poser is the willingness and ability to go several levels down. Deep understanding comes from deep diving. 4. One of the best ways to deep dive is to benchmark. The milliseconds gained will be a byproduct. The real benefit is your understanding of what goes on under the hood. 5. Write a framework. You may never use it, but you'll never be the same programmer either. 6. Almost everything you do will take longer than you expect, no matter how experienced you get or how good you get at estimating. If it doesn't, then you're not taking on challenging enough work. 7. Once you regularly deliver great value to others, you will often feel like an imposter. The compliments will exceed what you think you deserve based upon how hard it was for you to build. That's OK. Accept it and enjoy it. It's payback for all those hours you slaved away and no one knew what you were doing. 8. If you maintain a sense of wonder and delight every time you get something new working, you will probably never get burnt out. Don't let anyone tell you otherwise. 9. When you look at your old code, most of it will suck. That means you're always getting better. But some of it will still amaze you. Embrace and harness that energy. Try to recreate the conditions under which you wrote it. 10. Name your variables properly. That will always be half the battle.
- lemonberry 13y ago
  Number 5 is right where I'm at right now. I'm still really new and have spent my time learning Ruby and Ruby on Rails. I've recently embarked down the Erlang path. The frameworks aren't nearly as developed as Rails and I've realized I have no idea what the hell REALLY happens on the server side. My current goal is to write a server and my own framework. I have no illusion that either will ever be used for production. But I know I'll never get to where I want to be as a programmer if I don't understand what's going on back there. By the way, nice to see a post from you. It seems like it's been awhile.
  - joshguthrie 13y ago
myopia 13y ago
I agree with all of the points of the author. I'm currently in the process of teaching myself iOS development (nathanmorgan1.wordpress.com - for anyone who's interested) and have experienced some of the issues the author addresses first hand. I'd like to say little on 'teach yourself to code' programs. I often see these type of programs criticised here but personally, I can't say enough good things about CodeAcademy and it's ilk. Even though I'm learning iOS development its learn Javascript tutorials proved invaluable for me. It's true, I wasn't building a 'real' project but the courses demonstrated to me that I had an aptitude for coding and encouraged me to keep going with their light-hearted approach and 'rewards'. When I came to start learning iOS development, I had a range of transferable skills and knowledge that I could call upon, for example I was comfortable with loops, declaring variables and manipulating/defining objects. So I think while these courses won't take you from beginner to employable or experienced, they do serve their own purpose.
- FLUX-YOU 13y ago
  >So I think while these courses won't take you from beginner to employable or experienced, they do serve their own purpose. This has been the deceptive part to me (and maybe it's only me). They're a great way to get new syntax down, but as I've learned syntax from a few languages now (Python, JavaScript, C), I really don't need these programs to serve this purpose. I learned how to learn new syntax from learning syntax. Determining when you're employable can be difficult (entry-level at Google vs. some LAMP web shop) and I'm sure that some portion of people trying these programs are looking to switch careers. I found it easy to get the notion that "If I learn through a bunch of courses and books and maybe do a few projects, I can put these languages on my resume and get hired". That, unfortunately, turned out to not be the case.
  - myopia 13y ago
    I agree with you, it is equally possible to learn syntax in other ways, whether that's from a book or tutorial etc but I think these programs reach people that may not otherwise have considered starting to code. They produce a zero barrier to entry, needing zero expense and minimum effort to get started. They also make the initial stages of learning to code 'fun' (I'm aware that's a highly subjective term however) when learning syntax, often without having grander goal in mind e.g. an app, can be a dry subject at best. On your second point, are you referring specifically to people who complete these courses or people who teach themselves to code and build a few projects? EDIT:typo
vezzy-fnord 13y ago
Any particular reason for linking to a primer on C++ pointers, instead of C pointers? It's rare that you'll need to use pointers that much in C++ (compared to C where they're definitive and essential), and type casting is stricter in C++. I also laughed a little at the Joel Spolsky bit. But overall, sound advice. It beats most of the empty fluff that the "learn to code" movement is producing.
- joshguthrie 13y ago
  Lack of pointers in C++ has been the bane of my C++ experience.
  - bloodorange 13y ago
    What do you mean by "Lack of pointers in C++"? C++ has most of the pointer stuff from C (except for some unsafe casts).
    - pantalaimon 13y ago
      You should avoid it though.
  - EpicEng 13y ago
    Why? The reason you don't really see them in most well written C++ code is because you don't need them. If/when you do, you have them. What's the problem?
Spearchucker 13y ago
Biggest lesson after my 29 years of programming is the difference between the best solution, and a successful solution. I.e. getting familiar with system patterns (architecture) that work for your chosen stack/area of interest. There are a million resources for specifics, like doing a server redirect or creating a jump list for Windows Phone, but precious little on the end-to-end implementation semantics of, say, a smartphone app that syncs content to a server that scales out and up. Also, adding security, monitoring hooks, and exception and configuration management. The realisation that open standards are far, far more important than open source. Similarly, the web is full of people telling you to use Mongo, but again hardly anything about being able to reference indexes in a document, or that partition tolerance and availability come at the expense of consistency. Get these things right and suddenly even using GOTOs, or the differences between closed and open source, become non-issues because if your solution works, and is successful, any ciritics of such semantics can go to hell.
- erichocean 13y ago
  a smartphone app that syncs content to a server that scales out and up This made me chuckle. I recently designed an entirely new way of doing just that (to me, at least), and it's probably the 20th or more end-to-end approach I've developed over the last seven years on that specific problem. I don't know why scalable sync interests me, but it does. :)
  - Spearchucker 13y ago
    I'm in exactly the same place.
xtracto 13y ago
Well, HTML is not a programming language, given that it is not turing complete. Hence, knowing how to write HTML doesn't make someone a programmer.
- spacemanaki 13y ago
  A researcher in programming languages once told me that when she encounters the "HTML isn't a programming language" meme she always thinks: Agda and Coq aren't Turing complete, are they also not programming languages? The point being, I think, that drawing this bright line at Turing completeness doesn't hold up when you give it any thought, and so it's not very useful. Aside from that, you've utterly missed the point of the OP.
  - acchow 13y ago
    How shall we define a programming language? At least as powerful/expressive as a DFA? I kind of like that. (A bit off topic, but not really - writing out a regex is sometimes harder for me than C++/Java/JavaScript. +1 for DFAs!)
  - ocfx 13y ago
    It's a markup language which is not a subset of programming languages.
- ubernostrum 13y ago
  HTML5 + CSS3 is actually Turing complete: https://github.com/elitheeli/stupid-machines https://github.com/elitheeli/stupid-machines
  - acchow 13y ago
    >"TuringMachineWithNoSyntax.java >Implements a Turing machine in Java without using control structures, variable declarations, method definitions, or anonymous classes. The main2 method shows the code before I removed variables. Control structures are too controlling for this day and age. Us youth yearn for the unstructured hippie days of our parents' generations." I like this guy's sense of humor :)
rmk2 13y ago
> Before you learn to code, think about what you want to code This is and always has been my problem. I like to look at what other people do, and I like coding in theory. But the little I need for myself isn't enough to keep pushing myself. I don't work anywhere near programming, and I don't particularly want to, either. Because of that, though, I haven't progressed very far into SICP, my finished Scheme programs can be counted on one hand, and most of my shell scripts are simple <1h (including looking things up) hack jobs. I only really script for personal use, and my personal usage patterns are either not terribly demanding or too complex for me to satisfy.
- a3n 13y ago
  Try automating some of your work. Pick one simple thing that you do a lot, and write a small script or program to automate it: getting a handful of files from somewhere; putting a handful of files somewhere; opening one or a handful of files; creating the skeleton of a file that you will later flesh out. I'm guessing you probably work in Windows because most people do at work; their shells are either too simplistic and awkward (cmd) or nuclear-capable (psh). Install cygwin and use the bash shell. Or do everything in Scheme/Racket and don't worry about a shell. Automate something today, something almost too simple to automate. Repeat.
  - rmk2 13y ago
    openSUSE & zsh all the way! ;) In all seriousness, though, my setup is a wee bit unusual for somebody who isn't a programmer, since I work exclusively in emacs via LaTeX & org-mode, stuffing all of it into git, on a openSUSE system, zsh as my standard shell, i3 as my window manager etc. The thing is, I do have a script for example to push the current git project to various remote repositories or to create a new empty remote repository on those servers, set it up locally etc. But there are few other things that need to be scripted. I'm sure some of my things violate all kinds of sensible programming standards, but they do work (e.g. looping through shell arguments and then using case "$1" instead of using getopts, because it only allows long arguments in a hackish way). The problem, essentially, is that of the plateau. If I wanted to do something that pushes things further, I'd need a real project, not the odd, occasional shell script. But for that, I lack the motivation, since, after all, it's not really what I should be doing. It's a bit of a circular problem. edit: My "job" is studying literature.
stickhandle 13y ago
A key for learning anything is being curious and exposed, in combination. A great way to get that as a beginner (in coding or in a new environment) is to take on bug fixes and CRs. While not always everyone's favourite it forces you to dig into others code, see things you like/dislike, grok new concepts, and challenge the inner-you with doing what's right vs. what is faster. Perfection vs pragmatism - knowing what to side with and when is a key to a long career.
- sopooneo 13y ago
  What are CRs?
  - ronnier 13y ago
    Code reviews
  - nabeards 13y ago
    Code Reviews
  - lgieron 13y ago
    Change Requests?
Goladus 13y ago
Good post. Though my experience with this one was slightly different: Someone will always tell you you’re doing it wrong In my case, it wasn't that people were telling me I was doing it wrong, it's that I saw all these people asserting the Right Way to do things and I was so worried about doing it wrong that I would get bogged down worrying about tiny irrelevant problems. But in the end what people cared about most was getting things done, and usually didn't care as much about the methods as one would believe reading the web. The most common traits of all the best code I've worked with is consistency and thoroughness.
tlarkworthy 13y ago
The experienced programmer knows it won't work first time, and does not wait until its finished before testing it. The time spend finding a bug is cubic in the distance you have coded since last thorough testing. You test the foundations are rock solid before building a cathedral on top of it. I find the newer blood writes way too much code in one go.
burlyscudd 13y ago
The executing process belongs to you - you should allow it no secrets in its basic running. First thing in any lang: learn the tools available for debugging and quickly opening library code to trace execution. Set breakpoints; dive into stack traces.
drblast 13y ago
I'm finally at a point where some programs I write work the first time. It's very disconcerting.
- gedrap 13y ago
  Oh familiar feeling. "There must be something wrong, it can't just WORK!"
exo_duz 13y ago
Like everything in life... Practice Practice Practice.... best advice to get good at what you do.

159 points by iamtechaddict 13y ago

Nice piece. This definitely resonates: "Braces should go on the next line. Braces should go on the same line. Use tabs to indent. But tabs are evil. You should use stored procedures, but actually you shouldn’t use them. You should always comment your code. But good code doesn’t need comments."

danieldk 13y ago
In contrast to what she is saying, there is a true path. The true path is: use whatever the coding standard for that particular company or project says. There is nothing more annoying than people having different formatting settings and having each commit/diff being 80% formatting changes and 20% actual changes.
mattmanser 13y ago
Apart from some of them are the wrong way. Work on an over-commented code base and come back and tell me commenting everything is good. Work on a large crud app where it's 'SPs only' and come back and tell me SPs are good. Worse still that particular debate is dead. The parametrized queries not only won, they blew SPs out of the park with ORMs. Hence the articles linked are 7-8 years old. And yet I still come across the occasional programmer who uses SPs (who will generally think ORMs are evil rather than massive time savers). As for commenting, new coders need to comment because they forget what they did. New programmers can't read code properly, they need help from comments. So it's good general advice to tell newbies to comment while they're learning. But not in production code. New coders also tend to get a revelation when they go back to some of the first code they wrote and can't understand it. The revelation is 'I should have commented it all!'. But the revelation is false, there are two reasons they can't understand it. Firstly, it's crap code because it's their first code. Secondly, they can't read code properly. But they can't admit it to themselves because they think that now they're good coders. I've seen this time and time again, programmers with less than 2 or 3 years experience often won't try to read the code and figure out the logic when something goes wrong. Be it their own code or a bug in someone else's they've been asked to fix. They start changing random variables or commenting out lines. And yet they honestly think they are good coders. Many time I have sat down with them to help, read the code and then pointed at a line and said 'Hmmm, that looks wrong'. And that will be the bug. 5 min fix, if you can read code. It's just part of the learning process and now I'm older I can see the Dunning–Kruger effect as stupefyingly obvious in programmers. I don't begrudge it, I don't think they're stupid or unskilled, it's just a stage every programmer seems to need to go through. The stage where they still haven't realized they can actually read the code to figure out what it does. What's funny is that I can see I suffered from it constantly in my early years and was a right arrogant idiot.
- girvo 13y ago
  I disagree with some of your points, and I have experienced what you pointed out should be needed to bring that conclusion. This stuff isn't cut and dried, so i just go with whatever the project is already using. Seems easier that way :)
- dsego 13y ago
  Why the down votes? These are good observations.

edw519 13y ago

Nice post. A few more of my own: 1. There is no substitute for the hours spent coding. Sure, you can waste a lot of time, but there's a high correlation between hours spent and skill attained. 2. You can do almost anything with almost any tool. The energy spent debating tools would probably be better spent building something. 3. One of the biggest differentiators between a good coder and a poser is the willingness and ability to go several levels down. Deep understanding comes from deep diving. 4. One of the best ways to deep dive is to benchmark. The milliseconds gained will be a byproduct. The real benefit is your understanding of what goes on under the hood. 5. Write a framework. You may never use it, but you'll never be the same programmer either. 6. Almost everything you do will take longer than you expect, no matter how experienced you get or how good you get at estimating. If it doesn't, then you're not taking on challenging enough work. 7. Once you regularly deliver great value to others, you will often feel like an imposter. The compliments will exceed what you think you deserve based upon how hard it was for you to build. That's OK. Accept it and enjoy it. It's payback for all those hours you slaved away and no one knew what you were doing. 8. If you maintain a sense of wonder and delight every time you get something new working, you will probably never get burnt out. Don't let anyone tell you otherwise. 9. When you look at your old code, most of it will suck. That means you're always getting better. But some of it will still amaze you. Embrace and harness that energy. Try to recreate the conditions under which you wrote it. 10. Name your variables properly. That will always be half the battle.

lemonberry 13y ago
Number 5 is right where I'm at right now. I'm still really new and have spent my time learning Ruby and Ruby on Rails. I've recently embarked down the Erlang path. The frameworks aren't nearly as developed as Rails and I've realized I have no idea what the hell REALLY happens on the server side. My current goal is to write a server and my own framework. I have no illusion that either will ever be used for production. But I know I'll never get to where I want to be as a programmer if I don't understand what's going on back there. By the way, nice to see a post from you. It seems like it's been awhile.
- joshguthrie 13y ago

myopia 13y ago

I agree with all of the points of the author. I'm currently in the process of teaching myself iOS development (nathanmorgan1.wordpress.com - for anyone who's interested) and have experienced some of the issues the author addresses first hand. I'd like to say little on 'teach yourself to code' programs. I often see these type of programs criticised here but personally, I can't say enough good things about CodeAcademy and it's ilk. Even though I'm learning iOS development its learn Javascript tutorials proved invaluable for me. It's true, I wasn't building a 'real' project but the courses demonstrated to me that I had an aptitude for coding and encouraged me to keep going with their light-hearted approach and 'rewards'. When I came to start learning iOS development, I had a range of transferable skills and knowledge that I could call upon, for example I was comfortable with loops, declaring variables and manipulating/defining objects. So I think while these courses won't take you from beginner to employable or experienced, they do serve their own purpose.

FLUX-YOU 13y ago
>So I think while these courses won't take you from beginner to employable or experienced, they do serve their own purpose. This has been the deceptive part to me (and maybe it's only me). They're a great way to get new syntax down, but as I've learned syntax from a few languages now (Python, JavaScript, C), I really don't need these programs to serve this purpose. I learned how to learn new syntax from learning syntax. Determining when you're employable can be difficult (entry-level at Google vs. some LAMP web shop) and I'm sure that some portion of people trying these programs are looking to switch careers. I found it easy to get the notion that "If I learn through a bunch of courses and books and maybe do a few projects, I can put these languages on my resume and get hired". That, unfortunately, turned out to not be the case.
- myopia 13y ago
  I agree with you, it is equally possible to learn syntax in other ways, whether that's from a book or tutorial etc but I think these programs reach people that may not otherwise have considered starting to code. They produce a zero barrier to entry, needing zero expense and minimum effort to get started. They also make the initial stages of learning to code 'fun' (I'm aware that's a highly subjective term however) when learning syntax, often without having grander goal in mind e.g. an app, can be a dry subject at best. On your second point, are you referring specifically to people who complete these courses or people who teach themselves to code and build a few projects? EDIT:typo

vezzy-fnord 13y ago

Any particular reason for linking to a primer on C++ pointers, instead of C pointers? It's rare that you'll need to use pointers that much in C++ (compared to C where they're definitive and essential), and type casting is stricter in C++. I also laughed a little at the Joel Spolsky bit. But overall, sound advice. It beats most of the empty fluff that the "learn to code" movement is producing.

joshguthrie 13y ago
Lack of pointers in C++ has been the bane of my C++ experience.
- bloodorange 13y ago
  What do you mean by "Lack of pointers in C++"? C++ has most of the pointer stuff from C (except for some unsafe casts).
  - pantalaimon 13y ago
    You should avoid it though.
- EpicEng 13y ago
  Why? The reason you don't really see them in most well written C++ code is because you don't need them. If/when you do, you have them. What's the problem?

Spearchucker 13y ago

Biggest lesson after my 29 years of programming is the difference between the best solution, and a successful solution. I.e. getting familiar with system patterns (architecture) that work for your chosen stack/area of interest. There are a million resources for specifics, like doing a server redirect or creating a jump list for Windows Phone, but precious little on the end-to-end implementation semantics of, say, a smartphone app that syncs content to a server that scales out and up. Also, adding security, monitoring hooks, and exception and configuration management. The realisation that open standards are far, far more important than open source. Similarly, the web is full of people telling you to use Mongo, but again hardly anything about being able to reference indexes in a document, or that partition tolerance and availability come at the expense of consistency. Get these things right and suddenly even using GOTOs, or the differences between closed and open source, become non-issues because if your solution works, and is successful, any ciritics of such semantics can go to hell.

erichocean 13y ago
a smartphone app that syncs content to a server that scales out and up This made me chuckle. I recently designed an entirely new way of doing just that (to me, at least), and it's probably the 20th or more end-to-end approach I've developed over the last seven years on that specific problem. I don't know why scalable sync interests me, but it does. :)
- Spearchucker 13y ago
  I'm in exactly the same place.

xtracto 13y ago

Well, HTML is not a programming language, given that it is not turing complete. Hence, knowing how to write HTML doesn't make someone a programmer.

spacemanaki 13y ago
A researcher in programming languages once told me that when she encounters the "HTML isn't a programming language" meme she always thinks: Agda and Coq aren't Turing complete, are they also not programming languages? The point being, I think, that drawing this bright line at Turing completeness doesn't hold up when you give it any thought, and so it's not very useful. Aside from that, you've utterly missed the point of the OP.
- acchow 13y ago
  How shall we define a programming language? At least as powerful/expressive as a DFA? I kind of like that. (A bit off topic, but not really - writing out a regex is sometimes harder for me than C++/Java/JavaScript. +1 for DFAs!)
- ocfx 13y ago
  It's a markup language which is not a subset of programming languages.
ubernostrum 13y ago
HTML5 + CSS3 is actually Turing complete: https://github.com/elitheeli/stupid-machines https://github.com/elitheeli/stupid-machines
- acchow 13y ago
  >"TuringMachineWithNoSyntax.java >Implements a Turing machine in Java without using control structures, variable declarations, method definitions, or anonymous classes. The main2 method shows the code before I removed variables. Control structures are too controlling for this day and age. Us youth yearn for the unstructured hippie days of our parents' generations." I like this guy's sense of humor :)

rmk2 13y ago

> Before you learn to code, think about what you want to code This is and always has been my problem. I like to look at what other people do, and I like coding in theory. But the little I need for myself isn't enough to keep pushing myself. I don't work anywhere near programming, and I don't particularly want to, either. Because of that, though, I haven't progressed very far into SICP, my finished Scheme programs can be counted on one hand, and most of my shell scripts are simple <1h (including looking things up) hack jobs. I only really script for personal use, and my personal usage patterns are either not terribly demanding or too complex for me to satisfy.

a3n 13y ago
Try automating some of your work. Pick one simple thing that you do a lot, and write a small script or program to automate it: getting a handful of files from somewhere; putting a handful of files somewhere; opening one or a handful of files; creating the skeleton of a file that you will later flesh out. I'm guessing you probably work in Windows because most people do at work; their shells are either too simplistic and awkward (cmd) or nuclear-capable (psh). Install cygwin and use the bash shell. Or do everything in Scheme/Racket and don't worry about a shell. Automate something today, something almost too simple to automate. Repeat.
- rmk2 13y ago
  openSUSE & zsh all the way! ;) In all seriousness, though, my setup is a wee bit unusual for somebody who isn't a programmer, since I work exclusively in emacs via LaTeX & org-mode, stuffing all of it into git, on a openSUSE system, zsh as my standard shell, i3 as my window manager etc. The thing is, I do have a script for example to push the current git project to various remote repositories or to create a new empty remote repository on those servers, set it up locally etc. But there are few other things that need to be scripted. I'm sure some of my things violate all kinds of sensible programming standards, but they do work (e.g. looping through shell arguments and then using case "$1" instead of using getopts, because it only allows long arguments in a hackish way). The problem, essentially, is that of the plateau. If I wanted to do something that pushes things further, I'd need a real project, not the odd, occasional shell script. But for that, I lack the motivation, since, after all, it's not really what I should be doing. It's a bit of a circular problem. edit: My "job" is studying literature.

stickhandle 13y ago

A key for learning anything is being curious and exposed, in combination. A great way to get that as a beginner (in coding or in a new environment) is to take on bug fixes and CRs. While not always everyone's favourite it forces you to dig into others code, see things you like/dislike, grok new concepts, and challenge the inner-you with doing what's right vs. what is faster. Perfection vs pragmatism - knowing what to side with and when is a key to a long career.

sopooneo 13y ago
What are CRs?
- ronnier 13y ago
  Code reviews
- nabeards 13y ago
  Code Reviews
- lgieron 13y ago
  Change Requests?

Goladus 13y ago

Good post. Though my experience with this one was slightly different: Someone will always tell you you’re doing it wrong In my case, it wasn't that people were telling me I was doing it wrong, it's that I saw all these people asserting the Right Way to do things and I was so worried about doing it wrong that I would get bogged down worrying about tiny irrelevant problems. But in the end what people cared about most was getting things done, and usually didn't care as much about the methods as one would believe reading the web. The most common traits of all the best code I've worked with is consistency and thoroughness.

tlarkworthy 13y ago

The experienced programmer knows it won't work first time, and does not wait until its finished before testing it. The time spend finding a bug is cubic in the distance you have coded since last thorough testing. You test the foundations are rock solid before building a cathedral on top of it. I find the newer blood writes way too much code in one go.

burlyscudd 13y ago

The executing process belongs to you - you should allow it no secrets in its basic running. First thing in any lang: learn the tools available for debugging and quickly opening library code to trace execution. Set breakpoints; dive into stack traces.

drblast 13y ago

I'm finally at a point where some programs I write work the first time. It's very disconcerting.

gedrap 13y ago
Oh familiar feeling. "There must be something wrong, it can't just WORK!"

exo_duz 13y ago

Like everything in life... Practice Practice Practice.... best advice to get good at what you do.