5 ms·

AFAIK this is actually normal -- you learn the basics from tutorials, then the things that you need to make more complicated projects easier seem unnecessary, t

by csense 13y ago

AFAIK this is actually normal -- you learn the basics from tutorials, then the things that you need to make more complicated projects easier seem unnecessary, then you attempt a large project without them, and then you see why they're necessary.

sdrothrock 13y ago
It's normal but can be really, really scary if you don't have a mentor or someone to help you out or point out some of the pitfalls on the way. Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you through some of the more common stuff in a more accessible, interactive way than an article or a forum, which goes a long way.
- derekp7 13y ago
  Version control is one of those areas that is very difficult for a lone programmer to understand the need for (I was one). After all, I have backups, right? So why would I need it? Then I hit a snag, where something that worked before somehow didn't work now. And it was a lot harder tracking that down by going through backups, vs doing a git bisect and git revert. Eventually I ended up restoring every backup, and checking them into git.
  - saganus 13y ago
    Same here regarding version control.. until one day I after graduating from college I nostalgically searched for my old college files... and... oh the horror... my files where somewhere between "project1.final_backup_almost_final.java" and "project15.final_not_working.java.backup3" going through more strange things which I can't even think of why I named files like that, along the lines of "epsiloneridani43.final_working_working.tosubmit.java" and of course the project file I ended up sending to the teacher was something like "project16.working_again3.java" ...sigh
    - stephencanon 13y ago
      O to be young and innocent of version control.
    - grey-area 13y ago
      You see a huge amount of this sort of poor-man's version control in other industries - everyone I have worked with in other industries has worked out some personal scheme of versioning using initials, dates, numbering in order to sequence the various states of their work as it passes through multiple people and multiple versions. A lot of room for disruption there I think if someone works out how to make version control fit better with ordinary people's view of the world (i.e. not git, svn etc). Versions in word are the closest I've seen to it but it really shouldn't be in one specific program but in the OS or a helper program.
      - ygra 13y ago
        File History in Windows 8 is nice, sort of. It takes snapshots of changed files every hour. Sadly you have to enable it first and it's sort-of treated as a backup (so you have to store the copies on a different volume, etc.). So, not exactly what people have in their home unless they know about such things.
        grey-area 13y ago
        I think the missing solution here though is collaboration and versioning between people, rather than individual backups. Things like File History and Time Machine are nice, but don't really address this need.
    - runiq 13y ago
      To be fair, though, once you get the hang of it, you have to take care not to apply it to everything. Back when I grokked Mercurial (first VCS for me), I used it for packaging scripts, dotfiles, /etc files, todo lists, shopping lists for the grocery store, financial accounting, and my own poor man's dropbox clone (please don't ask). "When you have a ham^H^H^HVCS, everything looks like a programming project".
- esonderegger 13y ago
  What's worked for you all for making the leap from lone programmer to working on a team with a mentor/people who are smarter than you? I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm writing something, it's always tricky figuring out exactly what it is I should be testing. When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this. When you are good enough to make your own projects work the way you want them to work, but not good enough to contribute to the open source projects you actually use, how do you break out of your bad habits that you know you will need to break when part of a team/large project?
  - mason55 13y ago
    > When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this. If you don't have time to write tests then you've overscoped the features for the available time. Once you start treating testing as essential and budgeting a realistic amount of time to write test code (probably on the order of 1:1 feature code time:test code time) then you'll be able to get it done. Your total number of features will go down but quality will go up.
    - esonderegger 13y ago
      I'm sure I'm not the only one who got down the road to overscoped features by saying "gee, wouldn't it be cool if my users could access this info that's living in a mysql table" and threw something together with a little php mysql_query(SELECT...), and it worked! except for some edge cases with non-ascii characters and the fact that you knew you were opening yourself up to SQL injection attacks, but you weren't really concerned because you only have 100 users and they're already authenticated by a more robust system. Anyway, you decide to do it the "right way" and rewrite it using SQLAlchemy. In the mean time, your coworkers wonder why you've burned half a day rewriting a feature that worked just fine after you had only been spending 30 minutes on it. Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.

by csense 13y ago

sdrothrock 13y ago

It's normal but can be really, really scary if you don't have a mentor or someone to help you out or point out some of the pitfalls on the way. Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you through some of the more common stuff in a more accessible, interactive way than an article or a forum, which goes a long way.

derekp7 13y ago
Version control is one of those areas that is very difficult for a lone programmer to understand the need for (I was one). After all, I have backups, right? So why would I need it? Then I hit a snag, where something that worked before somehow didn't work now. And it was a lot harder tracking that down by going through backups, vs doing a git bisect and git revert. Eventually I ended up restoring every backup, and checking them into git.
- saganus 13y ago
  Same here regarding version control.. until one day I after graduating from college I nostalgically searched for my old college files... and... oh the horror... my files where somewhere between "project1.final_backup_almost_final.java" and "project15.final_not_working.java.backup3" going through more strange things which I can't even think of why I named files like that, along the lines of "epsiloneridani43.final_working_working.tosubmit.java" and of course the project file I ended up sending to the teacher was something like "project16.working_again3.java" ...sigh
  - stephencanon 13y ago
    O to be young and innocent of version control.
  - grey-area 13y ago
    You see a huge amount of this sort of poor-man's version control in other industries - everyone I have worked with in other industries has worked out some personal scheme of versioning using initials, dates, numbering in order to sequence the various states of their work as it passes through multiple people and multiple versions. A lot of room for disruption there I think if someone works out how to make version control fit better with ordinary people's view of the world (i.e. not git, svn etc). Versions in word are the closest I've seen to it but it really shouldn't be in one specific program but in the OS or a helper program.
    - ygra 13y ago
      File History in Windows 8 is nice, sort of. It takes snapshots of changed files every hour. Sadly you have to enable it first and it's sort-of treated as a backup (so you have to store the copies on a different volume, etc.). So, not exactly what people have in their home unless they know about such things.
      - grey-area 13y ago
        I think the missing solution here though is collaboration and versioning between people, rather than individual backups. Things like File History and Time Machine are nice, but don't really address this need.
  - runiq 13y ago
    To be fair, though, once you get the hang of it, you have to take care not to apply it to everything. Back when I grokked Mercurial (first VCS for me), I used it for packaging scripts, dotfiles, /etc files, todo lists, shopping lists for the grocery store, financial accounting, and my own poor man's dropbox clone (please don't ask). "When you have a ham^H^H^HVCS, everything looks like a programming project".
esonderegger 13y ago
What's worked for you all for making the leap from lone programmer to working on a team with a mentor/people who are smarter than you? I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm writing something, it's always tricky figuring out exactly what it is I should be testing. When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this. When you are good enough to make your own projects work the way you want them to work, but not good enough to contribute to the open source projects you actually use, how do you break out of your bad habits that you know you will need to break when part of a team/large project?
- mason55 13y ago
  > When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this. If you don't have time to write tests then you've overscoped the features for the available time. Once you start treating testing as essential and budgeting a realistic amount of time to write test code (probably on the order of 1:1 feature code time:test code time) then you'll be able to get it done. Your total number of features will go down but quality will go up.
  - esonderegger 13y ago
    I'm sure I'm not the only one who got down the road to overscoped features by saying "gee, wouldn't it be cool if my users could access this info that's living in a mysql table" and threw something together with a little php mysql_query(SELECT...), and it worked! except for some edge cases with non-ascii characters and the fact that you knew you were opening yourself up to SQL injection attacks, but you weren't really concerned because you only have 100 users and they're already authenticated by a more robust system. Anyway, you decide to do it the "right way" and rewrite it using SQLAlchemy. In the mean time, your coworkers wonder why you've burned half a day rewriting a feature that worked just fine after you had only been spending 30 minutes on it. Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.