Code. Build something. Figure out something you'd like to build, then figure out out to build it. You can't help but learn if you take that route.

If that's not your cup of tea, then start contributing to open source projects. Learn Git and Subversion, then start taking tickets for Firefox or Chrome. Start off with the easy things, then work your way up. There's lots out there that needs attention, and being able to show a potential employer your commits will stand you in good stead. There was a guy who was developing Chrome on here a while back offering you just that: get in touch with him, and he'll start feeding you tickets.

Ah, found it. here you go: http://www.aaronboodman.com/2010/10/wherein-i-help-you-get-g...

I think the most significant thing to learn at the OP's stage is dealing with bigger codebases. Anyone can program something in 1000 LOC. 10000 is already harder, but I think there is a guenuine difference when it goes to the next level, because at that point, you cannot do everything, and you are forced to spend more time reading than writing.

Contributing to open source projects is the obvious thing to do there. Try to pick up a project which reacts relatively quickly to patches and which of course is of some interest to you :)

I'm glad to see that I'm not the only person that uses the x10 LOC as a way of judging a programmer's skills. I generally think of it like this:

10 = Sam's Learn Java in 24 hours

100 = did some programming courses at highschool / university

1000 = baseline professional programmer. Has already understood the basics of writing reasonable code at the function level

10000 = experienced programmer - will stand out in a corporate environment, probably the minimum that you want working on a startup. Understands architectural issues and mastering the environment outside the application

100000 = star programmer. That said, I don't see a big difference between the last two categories in terms of pure programming skills. The difference is more in that the 100000 LOC programmer is capable of directing a team, explaining the system architecture to others, making the code more modularisable and accessible to others (doing the necessary makefile magic so that code will compile as C or C++ for example, or providing a plugin architecture, or adding bindings for a scripting language etc)

To go back to the original question, if you find that you are limited to 1000 LOC programs, looking at the list, you need to look a bit more at architectural issues - encapsulation, OO, functional style programming, that sort of stuff, to get you to a level where your code won't descend into an unholy mess when it starts getting bigger.

I actually use the size of codebases written entirely by the candidate as an indicator in job interviews - it gives a good feeling of where the person is at.

I don't know about saying 1000 LOC is a baseline for a junior developer. I did second year software engineering last semester and our final project was about 1000 LOC. Granted, that was C, which tends to be... verbose. Even our python implementation of something similar averaged 450. Point is, I don't think 90% of the people in that class, myself included, could start as a junior developer today and be expected to succeed.

It's not clear in my original post, but I was talking explicitly about what a programmer can achieve by themself, without any aid from peers/mentors. I don't think your example contradicts that. How many of your classmates actually did the project by themself, without getting aid from tutors/lecturers, discussing ideas with classmates, etc? And even if they did, the problem still isn't directly comparable, because you've presumably been discussing the ideas that you are using in your projects during the course. The ideas are fresh in people's heads. This is not true in the real world, where you can be assigned to working on a project that uses skills that you haven't touched for years.

Anyhow, our discussion is a little theoretical. In practice, I can say that what I described is really truly what you find when you work in a large corporation writing code. I know it's hard to believe, but have a look around at the horror recruiting stories on this site, or stories talking about how enterprises do software development. It's not a pretty picture. It's not just that your baseline programmer can only write a project of about 1000 LOC, but also that there are a significant number of "developers" that can't even do that. Hard to believe, until you've seen it for yourself, but true nonetheless.

I'd like to add a quirk to that requirement. You have to be able to build something large and ship it (and maintain it). Anybody can continue to build and build and build and you end up with a really large codebase that's bloated/duplicated/buggy and that never work in production.

Building something doesn't teach you much about quality if you don't have someone to review/assist every now and then.

I'd say, having never really thought about it, you learn quality by coding the same thing repeatedly and optimizing it each time. So you can learn in that way.

And having a friendly reviewer is excellent!

Where to find friends who can review my code? All of my friends don't know anything about programming or they don't code in there spare times like I do.

It is really hard to find someone who can explain what is bad about code design and what should I do about it or what should be "best".

That is when joining a OS project makes same. Then you will have a whole mailing list reviewing your patches, and discussing all kind of architecture decisions.

Or it teaches you more about quality because you own the product, set the schedule, and build exactly what you want.

It is possible to build an app that does exactly what you want and is completely unmaintainable in the future. If you don't know anything about code quality, it is rather hard to pick up on your own. It helps if you have someone more experienced to look at your code and go "No, you're doing it wrong. You don't need to subclass for x, just use y instead."

You can learn a lot in 6 to 12 months, but you probably shouldn't expect to become a skilled developer in that time period. There are a lot of edge cases that you just have to experience to understand, and you'll never stop experiencing them, as long as you're programming.

These days, my advice -- if I felt qualified to give any, which I don't -- would be to decide now whether you want to be "a programmer", or "a (COBOL | Python | Ruby | PHP | Java | JavaScript | .NET) programmer". That is, decide whether you want to learn the principles of programming, and apply those to multiple languages, or whether you want to learn a language, and specialize in it.

If you choose to be a generalist, then you'll be able to more easily pick up new languages and work in alien frameworks, because everything you look at will be similar to something else you already understand. You won't be as good as someone who specializes in that particular language or framework, but you'll be good enough to get a job and do reasonably well at it. The flexibility will also make it easier for you to find jobs, assuming that you're able to sell your generalism as an advantage instead of a disadvantage.

If you choose to specialize, you might not ever understand certain low-level programming concepts, but if someone needs work done in your language or framework of choice, you'll be able to knock it out without any concern about how long it'll take you to familiarize yourself with the environment.

This decision will probably mostly be the result of your own mindset -- whether you prefer puzzles or stability -- as well as whether you'd rather aim for a job as a consultant (or freelancer) or a regular job as an employed programmer for some company.

If you decide to be a generalist, I'd recommend spending a couple of months learning basic concepts in an "easy" language (PHP, VisualBasic, Pascal), and then diving into C and then C++. By then you should be able to relate most languages to one of the couple you've worked with, and you'll have a better idea of what to learn next. You'll also develop a solid understanding of types, stacks, heaps, object frameworks, and on and on.

If you decide to specialize, then honestly the best recommendation I'd have would be to hit some of the job sites, see what people are looking for (and willing to pay for), then get some real, actual books on that particular language and dive in.

Your background in math and physics will help you when it comes to thinking analytically, but programming is still a whole other level of analytical thinking.

Good luck!

PHP is not an easy language for someone just learning programming, it has tons of annoying quirks and is hard to debug. Visual Basic is better, I'd also reccommend Ruby. Not only is it a very easy language to learn, it also provides him with decent career prospects.

I selected languages based primarily on the range and depth of programming concepts that they use. So, PHP because it's relatively straightforward, but not Javascript because of its use of closures. Even though a beginner doesn't need to learn closures in Javascript, it's likely that they'll encounter them before long, and lots of experienced programmers have had to spend effort trying to get their head around them.

But, you're right, PHP does have a bad reputation in programming circles.

> hard to debug.

True, but there are ways to remedy this. My primary development environment is a PBG4; since I'm doing lots of Javascript/PHP work these days (and hating most of it), I have MAMP set up for a local development environment, with MacGDBp for debugging, and a couple of bash scripts that let me rsync between my laptop and various servers. With MacGDBp, I can step through PHP code, set breakpoints, examine variables, the usual debuggery stuff.

There are Windows equivalents for all of these tools.

Thanks for the advice. Given the choice as you define it here, I choose to be a "programmer", without specializing in only one language.

A couple of suggestions from my experience as a self-educated engineer:

1. Become a programmer and not a coder (see below)

2. Don't skimp on theory, algorithms, data structures and math

3. Learn many different languages between OOP and Functional

4. Contribute to open source

5. Have personal projects

6. Stay current (but not inundated) with the industry

7. Plan on spending at least 5 years to become "skilled"

Some elaboration:

Becoming a programmer means having vision and seeing the system - not just its parts.

Theory, math, algorithms, data structures &c... will help give you a point of view that is abstract enough that you can see the system and not just its constituent parts.

Learning different languages exposes you to radically different ways of thinking, different methodologies, different approaches, and different "programmer culture".

Contributing to open source was the best thing I ever did - I was around other programmers of varying skill levels that influenced me from the very small to the very large. Plus, there's an amount of rigor in the application of the VCS/ticketing/workflow system that you will rarely find anywhere else (you typically will have upwards of 50 or more developers that work on code at different times of the day and all of this needs to be coordinated without soaking up the project lead's time). There is also more quality control of the API's and code, in general, because it is something other people use - not just the institution.

Personal projects is self-explanatory. Anything small, to the large.

Staying current is easy, just skim HN/Reddit and read articles that catch your interest but don't get sucked into them as a time sink.

It took me five years to become "skilled" at web application programming with Python. I would venture to guess that number will be true of many industries (with varying degrees). However, do it once and your ability to adapt is pretty acute.

Programming is an investment of your mind, body, and spirit. I wouldn't have it any other way though :) Any engineering field, really, where you get to create. Programming just has the quickest feedback loop of them all.

"Any engineering field, really, where you get to create."

This is what I am missing at my current job. I don't create anything! My clients are people who innovate and build. I want to be my clients.

I'm curious - but feel free to not dive into it if uncomfortable - about your current job. What job could you possibly have that means you don't get to create anything from the ground up?

I applaud your will to pivot to something else, and your desire to learn something new at a deep level. Best of luck!

Learn python the hard way: http://learnpythonthehardway.org/index

Try to think about exiting programs that intrigue or excite you. Clone these.

Think about whether you want to write "web" applications, mobile applications, scientific applications, etc. Basically, with a background like yours, coding will be easy to "step up", you just need to commit the time and discipline to doing so. Pick something, do it, and stick with it until you're good at it.

The advice to learn a variety of programming paradigms is sound:

http://mvanier.livejournal.com/998.html

http://matt.might.net/articles/best-programming-languages/

--------------

I haven't read pyHardWay, but I think it's vaguely in the lineaage of why's:

http://www.cs.uni.edu/~wallingf/teaching/188-agile/ruby/whys...

and for FP:

http://learnyouahaskell.com/

http://learnyousomeerlang.com/content

http://www.lisperati.com/clojure-spels/casting.html

Also, SICP, little schemer. Others?

Everyone here suggesting you start coding is correct. You definitely should start coding because it's the only way to truly learn. However, if you actually want to get a good job (the bad programming jobs are likely just as unsatisfying as what you're doing now) you also have to read books. Not blog posts (those are good for staying current with trends or figuring out a specific problem but bad for truly learning) but actual books.

For the specific task of getting through a programming interview you should check out the list I made here: http://www.7bks.com/list/610009

I highly recommend you start with The Algorithm Design Manual and do all the exercises you can at the end of the chapters. They're excellent because they start off easy and get harder and harder. If you've written some small programs and scripts I think you shouldn't have too much difficulty.

Becoming a skilled developer might take 10 years (http://norvig.com/21-days.html).

You should pick a SW opening as an example and focus on developing your skills to land your first job. Your best chance is to leverage your backgrond in math and physics, for example for a programming job using python for research (http://news.ycombinator.com/item?id=1864591).

Once you are programming full time you can spend your spare time expanding your skills as a programmer in other areas.

Write a video game. I tell this to everyone who wants to learn to program. Forget web development, initially (unless you want to learn HTML5/Canvas to build the game, which is not a bad idea at all). Game development is probably the best way to learn to program because it's fun, you have some sort of goal, you can be creative, and you have to learn a great mix of skills -- graphics/sprites, sound, timing, interaction, math, physics, etc.

Around 8 years ago I did exactly this. I was (and still am, because my career shifted in another direction) a totally newbie to programming - except from some Basic I did when I was a kid.

I developed some small games and helped a friend with his architecture thesis using Visual Basic 6 + a 3D engine: http://www.truevision3d.com

It was REALLY fun and I was also able to show it to others to get their opinion.

Anyhow... I second the game dev suggestion. Good luck!

Agreed. Game programming will teach you a lot of programming skills, and staying with game programming can elevate you to great heights as a programmer, and it's great fun. The only negative is that games are relatively closed systems, whereas most of the rest of the software world includes a lot of interaction with other systems (databases, security, operating systems, payment etc etc) which you may never get to practice while programming games (unless you do multiplayer online games i guess). Oh, and do not expect to earn money programming games.

I program in C for different micro controllers and like your idea of trying a game development. Any recommendation on books or links?

The Jason Gregory "Game Engine Architecture" is a good place to start for a 10,000 foot overview. Also try "Game Coding Complete," (aka "the Dinosaur Book") which has some more details and nuances. Both books are valuable starting places regardless of what your target language or platform is.

After those two I would consider what gaming topics you want to investigate further(rendering, collision, AI, etc.), and start specializing your search.

Work with others who are better than you. You will be instantly pressured to step up your skills. Being around others of a higher skill level allows you to see how they do things and where you can improve.

I see that open source is encouraged, but you won't have the same drive as you would if you are working on your own project.

So find someone that is better than you and work on that cool idea that you always think about; we all have at least one.

The obvious is to contribute to an open-source project if you want to write a thousand lines of code. There will be plenty of suggestions on here for that.

I'll add that you should consider a site like StackOverflow to really get into "sprints" on lots of different programming topics. Plus you'll get to see what the experts do at the same time you submit your own answers, which is very helpful in the learning process.

Since you know Linux well get a job as a Linux sysadmin running servers for a tech startup. Any great sysadmin spends a good portion of his time programming. Transition over time to full-time development if you want.

Some great answers here, thanks for posting this question.

I originally come from a finance background, though I'm taking a year off now to focus on programming for some of the same reasons you mention.

Joel Spolsky listed four books which he believes makes a solid foundation for a good programmer and that's what I'm working through, along with building random apps/projects: http://stackoverflow.com/questions/414779/what-should-a-self...

that's interesting that you come from finance, I'm coming from a similar field in terms of hours and job satisfaction. These four books are exactly what I'm looking for.

I was a double major; CS and Accounting and my first IT job was building computerized accounting systems..

I understand that the current, lucrative but unsatisfying, job that you mention in the summary is being a patent lawyer [1]. I don't really know what it's like working that job but I would imagine you will indeed find coding a much more fulfilling pastime. Congratulations on deciding to become someone who creates real, rather than artificial, value.

[1] http://news.ycombinator.com/item?id=1496780

Honestly, figure out what your interested in and dive in some way. The best way to learn is to be challenged. I know not everyone learns this way, but at least for myself I like to just get way over my head and figure my way out.

When I first started programming I always wanted to build a clan league (I was 14 at the time and Counter-Striker was just the coolest). So I learned php, mysql, and html (this was in 2003, so tables were still very popular). It took a while to learn enough to understand what I was doing but eventually I figured out what I was doing.

Pick something you have passion about and just go for it. The little extra motivation will help you in times of deep frustration where you just can't find the problem.

Secondly, pick up some very general "programming" books like Paul Graham's Hackers and Painters. I also suggest reading CODE to get a fundamental understanding of how computers actually work. Once you understand those fundamentals, things will become easier.

ianl is right, you need to have a direction. Video games, desktop applications, web applications, and server side applications are all quite different. The languages will often be different, but so will all the support libraries and other technologies your code needs to interface with. You will probably find the most tools and books for doing desktop apps and web apps.

Having an itch to scratch is important, it's hard to devote hundreds of hours to a learning project if you don't care about the end result.

To get really good, you'll need to put in lots of hours developing. There is no shortcut that I'm aware of. You might as well make those hours enjoyable though.

Find where your interests with development overlap. Seeing as you already have a background in Math and Physics, put it to use. Go look for some open source projects that you're genuinely interested in and try them out. Like other people have said, contribute and engage with the community.

If you're just fixing small bugs in these projects - it's still valuable enough in that you had to have some understanding of software some other people wrote (in a potentially large codebase).

If you do eventually decide to be more ambitious with creating a project of your own - aim to do something very useful / interesting (that doesn't necessarly mean a large application). Make it open source, have people review it and don't shy to promote it. That kind of thing is great to have on a resume.

Much of the advice already here is good to help you step up from a sub-1000 LOC program to working on bigger applications; but if you've not been doing any coding since university, then you may find some of it a bit daunting. This is also true if your existing coding experience is in something like C or Java and you wish to work in something a bit more "trendy" like Python, Clojure or Ruby.

I find that writing programs for Project Euler problems (http://projecteuler.net/) is very handy for sharpening the saw, or getting familiar with a new language. Obviously, it won't help you get up to speed with a graphics library or web framework, or anything like that, but it will help get your mind back in good shape to follow everyone else's advice here.

I would suggest figuring out what you want to code as a starting point. For example, if you want to build a web start up it might be better to focus on articles in that community as opposed to say articles on how to code better in C or for windows application.

Next, there are lots of articles out there on how to be a better programmer, I imagine its a combination of working on your own things, talking to other programmers who are smart, and reading about some of the people out there who have put time into figuring out what this means -- Joel Spolsky comes to mind.

Of course with anything practice makes perfect, so that's a must. After you've decided on some philosophies, maybe you could work on a few apps every month until you accomplish your goal of 'stepping up.'

Code a lot on things just outside of your comfort zone.

Good comment! I couldn't have said it better myself. This is the way I learn new stuff. If coding wasn't "scary" every now and then, I wouldn't have learned anything!

Most of all, I'd say MOTIVATION is an important factor. I'm guessing very few programmers, experienced or not, sit all their time off from work/school programming and/or always have that "oooh-I-want-to-go-home-and-start-up-a-long-session-of-<insert programming language>" all the time. At least _I_ need some motivation and inspiration every now and then. I go to a lot of live programming forums and also watch a lot of youtube programming/presentation videos just to get inspiration and to get my motivation up. Often these events are way out of my field of programming, but I still go, because I always feel good and full of spirit when leaving. This goes for me personally, of course, but may be a good advice for you too.

Having put this from my point of view, I would love to get some advice on where to get started on open source projects or the like, where I can get smaller tasks to complete. (I think that that Chrome thing that was mentioned in the start of this thread might be out of my league, but I'll give it a try.)

4 things you can do to immediately become a better programmer if you've not focused on these areas. 0) Master recursion. 1) Learn how to write a parser in whatever language you're happiest with. 2) Learn to treat error handling like a complete and utter frothing maniac. If it can go wrong, it needs to be checked. Without rigorous error handling large programs are impossible. Furthermore, parts of the program need to be easily and quickly tested. 3) Learn git and branching so that you can easily experiment without worrying about losing everything.

Beyond that, being proficient with an editor is key to reducing repetition. learning to use flexible tools will make everything easier.

My suggestion would be to find a simple website and clone it, or come up with your own idea. Start with Django and Python as it's easy to pick up compared to most anything else in my experience, and just learn by doing, searching stack overflow, and looking at other Django projects on github. That's how I learn new languages and frameworks and it seems to work well. However it might be different since you aren't yet a programmer.

I would say not to spend too much time reading books as you won't remember any of it when it comes time to code.

Read. Buy every book you think you might be interested in and read. Then apply what you read in either (or both) side projects or open source. Then read some more. When you feel decent enough to land a job, go for a job where you can learn the tech you want to learn even if it means cutting back your paycheck. Only you know how much of a cut is acceptable to maintain a lifestyle you want to have. At that point you should be good enough (if development really is your thing) to establish a 'career'.

Look at it from point of view of employer. I'm an employer and looking to hire a coder, what am I looking for. * Someone who knows how to code; * How do I know if they can code if they don't have years of experience coding with references... a portfolio would convince me. To get started how about running your own apache server with your own blog on to describe the projects you're working on. Your first post could be how you setup an Apache Server on your Home Linux PC.

"Running your own Apache Server"

What is this the 90s? Considering how many better alternatives that are available on the cloud advising someone new to programming to set up their own server is a waste of time. That energy would be better spent learning something interesting. A better idea would be to write your own simple CMS for your blog. That would be a better exercise and a better demo of your development skills than setting up an Apache server which just shows that that you can follow a long series of tedious steps rather than actual coding.

I will doubt web development skills of anyone who has no understanding how web servers work and what's happening server-side.

Since you majored in maths and physics, you have a lot of specialized knowledge. I'd rather build on that than trying to compete with younger, better trained, more skilled people on "general purpose" development tasks. I once worked with a physicist and it was rather tiresome because on the one hand he had that "hey, I was at cern, I am the smartest guy around"-attitude while on the other hand he was ridiculously incompetent when it came to solving basic tasks.

Throw yourself into the fire! What I'm trying to say is, find a small business owner and build something for them for free. That way you'll:

- Learn the new skills - Be motivated to do a decent job as someone will actually be using your stuff - Have something to showcase on your Resume

-Sid

It really depends on what kind of software development job you are looking for. I believe writing a web server will teach you a lot. You'll learn more about the HTTP protocol and you'll learn/master socket programming.

Contribute to complete the unfinished projects in Sourceforge.

Wanna swap job with me? We can train each other.