What's the one thing you would go back and tell yourself when first learning to develop software?

Question

I'm interested in the craft of software development, not just programming, although answers like writing unit tests, understanding patterns, et cetera are perfectly valid.

Answer 1

Learn more than one language. C and/or C++ should be one of them.

Answer 2

I would tell myself to learn C# instead of VB.Net. Coming from VB6 it was an easy transition, but I think C# has a larger sample base. Because of that, I ended up going and learning C# just to translate code to VB. Jeff Atwood mentioned something similar on a recent podcast.

Answer 3

Writing your own code, solving your own problems, debugging your own programs is far more valuable than working through example projects.

Don't get me wrong - going through a tutorial to learn something is okay, but you really need to saddle up and work on your own small projects using what you've learned to really know what you're doing.

Answer 4

Don't be afraid. Tinker and try. Nothing is impossible given a good amount of time and perseverance.

Oh, and don't pretend do build the software from zero to none in a single shot. Use evolutive programming, start from a simple thing, and add new things. Sooner or later you will have a complex system and you will wonder who coded it, since what you did was just small changes and additions here and there.

Answer 5

Read lots of code. No matter how good you are, you'll always learn something by reading other people's code. You'll see the solutions they've found, and you'll also see the pitfalls they've fallen into.

Being able to read code helps when you need to work with other team members, work with new codebases, and do code reviews.

Also, learn more than one language. I've found that every time I learn a new language it makes me a better programmer in the other languages I already know. A good programmer shouldn't think of learning a language as a big deal, and no matter what language you decide to learn now, you will have to learn others later in your career as technology changes.

My suggestion? One of the languages should be C, the other should be Lisp :) C is as low level as you can get without writing assembler, and Lisp is as high level as you can get. Master them both, and you'll be in awesome shape.

Answer 6

Get exposed to as many real, working codebases as possible and pursue the simplest solution first. Don't put too much stock in books and don't try to shoehorn in clever design patterns after you've just learned them from your neat new design patterns book.

Answer 7

Learn Haskell!

Then C.

Then C++.

Definitely don't learn QBASIC!

Answer 8

Find quickly a study group, and fellow programmers who know the subject better than I do, ask often, and experiment more often, learning alone can be very cumbersome.

Answer 9

Learn more about process and Software Development Lifecycle concepts. Teams in well established or progressive shops will often have a Lifecycle in place, which takes the software being developed or modified from project inception to rollout (and beyond!).

Pick one or some that seem right for you, and pick from a good list of places to start: iterative/waterfall development, Agile development (and scrum), CMM, and specific implementations of process like Rational Unified Process (RUP).

Having process exposure and experience will not only make you more marketable (and do better in resume screening and interviews), it will also make you a more well rounded developer as a whole.

Answer 10

Complain less and refactor more.

Answer 11

When you hear hoofbeats think horses, not zebras.

I could have avoided or minimized so many of the mistakes I've made in the past by keeping things simple. Part of knowing what's simple means you need to do and know the pain of maintenance, not just greenfield development.

Answer 12

Learn Unix earlier, learn vi and the command line.

Use an IDE instead of Notepad, or at least use vi like mentioned above.

Answer 13

To be a successful developer you need good people/communication skills as well as programming skills. These other skills require study and practice just like programming, so the sooner you start the better. I've gone through a good number of books on these subjects, I highly recommend these two:

Making Things Happen (by Scott Berkin) - This is a guide to the software development lifecycle. Its not specific to any particular methodology, it does a good job of generalizing the essentials. It also has a great bibliography for further reading.

Getting to Yes: Negotiating Agreement Without Giving In - This is a book on negotiating, which is useful for when you're landing a job and want to discuss things like benefits. Its useful well beyond that, and has given me tools to resolve all sorts of issues that come up during development.

Answer 14

What I would really tell past me is "Stop! Do the MBA instead. You'll get way more professional respect and won't be considered past your Use By Date at 35. Also: buy Amazon.com stock."

But to answer this question specifically: "Learn a functional programming language early and pay more attention to algorithm fundamentals. It's much more important than you think."

Answer 15

Don't be intimidated by all the masters out there who knock off elegant syntax; write simple and understandable code even if you think it might be mickey mouse.

Don't think there's a shortcut.

Learn how to do the basics like: reading and writing to a filesystem / database / URL in several languages.

Figure out something small and useful to code and code it.

It's better to finish a small project than to get bogged down in several big ones.

If you get software WRITTEN then you are magical to people who can't do it. If you can ALMOST get software written then you're not quite magical.

Keep an open mind to new technologies but be able to do whatever you need in C.

Answer 16

Im basically in a state of shock by most of the answers here:

Learn vi, learn c, learn lisp (!), learn visual basic, learn haskell

This is definately not what I would advice someone learning to program: to get bogged down for days trying to understand how to change line in vi.

This is the year 2009 and today only a handfull of new programmers will ever reach a point in their career where things have fucked up to the point that the only alternative for writing sourcecode is vi. We are talking seriously weird situation where this is the only option, like being caught in a spaceship, all the real computers blown out of the hole, and only left with a cracked nintendo to do the in-flight navigation.

What a new programmer should focus on early on is off course Understanding of Patterns, Patterns for making algoritms, Patterns for integrating socially with other programmers, Patterns for automation of their work routines, Patterns for making components, patterns for writing patterns.

The tools they use should be of the 3 main flavours: Functional, Procedural and Set-based.

3 modern and useful languages that would fit this is: F#, C# and T-SQL

The tools used for this is in the learning period Visual Studio Express (the free development studio option from Microsoft).

If you do the C# and T-SQL combination you would be able to target the Microsoft community, you could also do other variations, targeting other industry segments.

This wouold create a programmer with insight into the working aspects of programming, who would be able to work on a lot of different real teams in the world of software engineering.

You could also go into making your own compiler, making your own simulated CPU, making your own operating system, net stack, web server etc, and it will be fun for a while and teach you alot, but wont put food on your table.

ML, Java and MySql could be another solution which would require other IDE's, but still on the same productivity scale as Visual Studio (or about).

Same time as you learn to program - learn to use a versioning system - i would prefer Subversion, but many others exists.

Learn to communicate and work together with non-programmers.

Before you reach the state where you will use Vi the next worst scenario would be to use a drillingmachine and a lawnmover in combination to construct a syntax parser.

All the best,

Answer 17

Find a mentor.

Whether it is through work, user groups, friends, or professors, surround yourself with programmers that are smarter and more experienced than you. They can educate you and help you avoid the pitfalls that they've stumbled through.

Answer 18

I would love to explain to myself the concept of Objects. The typical "Car" example just never clicked with me. I think I could have explained it to myself much better, and it would have saved a lot of headache.

Answer 19

This is what I'd like to go back and tell myself back when I first starting developing software:

"You are going to screw up and that's OK. The tools and techniques you use now will evolve and change and you should be prepared to accept that."

Answer 20

The following:

• when the coder at my first employer said the best way to learn is do, I should have listened to him.
• one year coding courses are a great way to waste a lot of money, and a poor way to get employed
• when I told myself I should learn java better, I should have listened to myself. I would have had eight years of experience by now.
• php is easy to learn, that's why everyone knows it and pays accordingly.
• it would have been a good idea to study up the fortran and cobol books that my uncle had from his coding days. It would have probably made learning java easier, c++ possible, and my employment prospects a lot better then they were when I started looking into the coding industry.
• that I should have started to look at becoming a coder in 1995, not 2001.