Learning Programming during the job? [closed]

Question

Introduction:

I have read and heard advice, about learning programming by accepting programming projects. I need real assistance to understand this, because:

Problem:

Although, it would seem to me that one would gain much more technical knowledge by doing, real world projects, if one doesn't know much about a technology, it would add much more risk to the actual delivery of the final product! Even the smallest of real world projects could be too much for a newbie.

There is a contradiction here:

• You need to know the job to do it!

and

• It's recommended to do the job, in order to learn it!

Question:

Any personal experiences in this case would be very pleasant to know while describing:

• How new was the subject to you? didn't have a clue at all? Or, did you have experience with similar technologies?
• Was it a solo project or were you in a team? If team, then did others help you with learning it?
• Did it work as expected? Did you deliver on time?
• Do you recommend this approach to others as well?

Answer 1

As far as I can tell, everything you observed is correct, but I think you may have overlooked one thing: you do not need to learn on a "real world" project that you started, instead learn on a project that was started by someone else.

In professional world, a lot of us started by joining a team of experienced developers. A lot of times new person that is coming in is not simply given a project and told, "go do it". Instead they are given simpler tasks, such as fixing bugs in existing work. As you get more familiar with the product, the team, the coding conventions, the existing code base, you might be given more complicated tasks but none of them will be "a new project".

To give you an example, when I started my first co-op job, my very first assignment to find a cause and a fix for production data log unexpectedly failing in the middle of a long job. It took me 5 days of tracing through the code and when I found a problem, which turned out to be a malformed SQL statement, it took 1 line of code to fix it. It was 2+ years from that point before I was given a chance to actually start my own project and design from ground up an OPC HDA server. Before that, I was working with a ton of code written by other people.

If you are not working as a software engineer but want to learn on your own, I would limit how much time you work by yourself on "real world" projects. You should still do it, but keep in mind that while you learn the language and some technology, you will inadvertently developer not so good habits. By yourself, it might take you years to learn that these habits are bad and even longer to finally learn a better way.

Another alternative you should explore though, is to take a look at some open source software that you might happen to be using. Is there anything about that software that is glitchy or buggy? Start with something small and easy. Find a fix for it and submit it. Most likely, it will get code reviewed by the project owners/leaders and they will give you feedback on whether or not your fix is acceptable or if it should be tweaked some more. That feedback to you is invaluable. For example, I have a coworker who is relatively new to C++. He has been using this open source music library manager written in C++/Qt. He ended up submitting several fixes, which were low priority when compared to everything else, but those specific bugs were annoying him, and so he got to learn more about C++ and Qt and at the same time improve his own user experience with that software.

Answer 2

This is definitely a very grey area however it is easy to under estimate the complexity of some requirements and then under deliver on the project. I would be more inclined to learn the basics (from a book or however you will) and then go in search of a low end project that you will be challenged with, but won't fail with it.

The only experience I had with this was working in a team when we were picking up a new language. It worked out ok but that was due to the knowledge of the other developers and their willingness to teach others - without that trait, the project probably would have went belly up.

Answer 3

As always, this may depend on some things; most importantly, what the project/product is and who else is working on the project.

If it's an internal app or script(s), then go to town, have fun, ask questions, learn. I'm all for that.

If you have a mentor/lead that is reviewing the code and ensuring that significant tests are being done to verify the code, then again, go to town.

Programmers/developers often have a saying similar to "The language is an implementation detail." Basically, what it means is that learning a new language/framework is relatively trivial (timely sometimes, for sure, but trivially easy).

The assumption, however, is that you're already a proficient programmer; which you are not. You're not just learning a language, or a framework, or an API, or a technology. You're learning to be a programmer, which is more than syntax. Much more than I could describe right here.

I wouldn't buy a car from an un-trained, un-supervised would-be-mechanic and I wouldn't buy (critical) software from an un-trained, un-supervised would-be-programmer.

In summary: learn it, try it, love it; but know your limits.

Answer 4

All fields have a similar problem, but you are framing the problem in an unsolvable way.

When hiring someone, they really want someone experienced or someone they want to train to do it "their way". You need to find who hires the inexperienced. Often you'll get a job that's not exactly what you wanted, but consider it a stepping stone in your career.

What appeals to the people who will hire you? Motivation and security. You must be motivated, and you must have people vouch for you. The motivation can be shown by your actions, and the proof that you're not lying will be shown by your references. If in school, get to know a professor, they have office hours that few take advantage of, and they know a lot of people that need work. You just might not get paid for it.

Working without pay has a tendency to turn into working for pay. Do a good job, and you'll have the vetted references you seek (along with the experience). Just don't languish in volunteer work for too long (unless it serves your purposes).