As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Its always said that more you program, the better you become. Sounds good and true.
But I was wondering if there is a proven route to becoming a better programmer.
Something like:
Learn a
Learn b
Learn c > 'Now you are good to burn the engines'
Try stuff around based on your learning.
The answer might be similar to a CS course roadmap, but I want to hear from successful programmers who might want to pitch in with something notable.
Thanks
It's not true that practice makes perfect.
It's perfect practice that makes perfect.
If all you do is keep repeating the same bad practices again and again, you'll only make it possible to create bad code faster.
By all means keep coding. But at the same time be critical of everything you do. Always have a jaundiced eye that looks for ways to do things better. Read widely to get new ideas. Talk to others about how they do things. Look at other people's code, good and bad.
There's no "sure" way to learn anything that I know of. If there was, anyone could master this.
All questions are rhetorical and meant to stimulate thought.
Technical parts:
Design Patterns - There are probably some specific to a domain but generally these are useful ways of starting parts of an application. Do you know MVC or MVP?
Basic algorithm starting points - Divide and conquer, dynamic programming, recursion, creating special data types like a heap, being greedy, etc.
Problem solving skills - How easily can you jump in and find where a bug is? Can you think of multiple solutions to the problem?
Abstract modelling - How well can you picture things in your head in terms of code or classes when someone is describing a problem?
High level versus low level - How well do you understand when one wants something high or low? This is just something I'd toss out there as these terms get through around a lot, like a high level view of something or a low level language.
Process parts:
Agile - Do you know Scrum, XP, and other new approaches to managing software projects? How about principles like YAGNI, DRY and KISS? Or principles like SOLID? Ideas like Broken Windows?
Developer Environment - How well do you know the IDE you use? Source Control? Continuous Integration? Do you know the bottle necks on your machine in terms of being productive?
xDD - Do you know of TDD, BDD, and other developments driven from a paradigm?
Refactoring - Do you go back over your old code and make it better or do you tend to write once and then abandon your code?
Soft skills:
Emotional Intelligence - Can be useful for presentations and working with others mostly.
Passions/Motivation - Do you know what gets your juices flowing and just kick butt in terms of being productive? Do you know what you would like to do for many many years?
My main piece of advice would be: don't be afraid to rewrite your own code. Look at stuff you wrote even a month ago and you will see flaws and want to rewrite stuff.
Make sure that you understand some fundamentals: collections, equality, hashcodes etc. These are useful across pretty much all modern languages.
Depending on the language you use - use lint and metric tools and run them over your code. Not all their suggestions will be applicable but learning which are important and which are not is important. E.g FindBugs, PMD etc for Java.
Above all refine and keep refining your work. Don't treat your work as abandonware!
Learn your 1st programming language a new programming paradigm or a
find a mentor you can learn from
Apply what you've learnt in a real world project
Learn from your mistakes and successes and goto step one
The trick is knowing what to learn first:
Programming languages - this is the place to start bcause you cannot write software without knowing at least one of these. After you've mastered one language try learning another.
Programming paradigm - i.e. object oriented, dynamic/functional programming etc. Try to learn a new one with each new language.
Design concepts - S.O.L.I.D, design patterns as well as architectural concepts.
People skills - learn to communicate your ideas.
Team leadership - learn how to sweep others and how to become a team or technological lead.
After that the sky is the limit.
I would look at improving roughly in this order, in iterations with each building on the previous one:
Programming concepts. Understand things like memory management, pointers, stacks, variable scope, etc.
Languages. Work on mastering several modern languages.
Design concepts. Learn about design patterns. Practice using them.
Communication. Often-overlooked. You can only become a highly valued Software Engineer if you can communicate effectively with non-tech people. Learn to listen and understand the needs that people are expressing, translate that into a set of requirements and a technical design, but then explain what you understood (and designed) back to them, in terms they can understand, for validation before you code. This is not an easy one to master, but it is essential.
Architectural concepts. Learn to understand the big picture of large, complex systems.
Learning a programming language is in many ways similar to learning a spoken language. The only way to get good at it is to do it as often as possible. In other works
Practice, practice, read and then practice more
Take time to learn about all sorts of coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget.
Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.
For example, learn about:
•Development Practices, Software Design, Estimation, Methodologies Business Analysis Database Design (there are a lot of great books out there and online resources)
•Read Code - Open Source Projects are a good place for this. Read
Programming blogs
•Try to participate on Open Source
Projects.
•Look for programming user groups in
your town and/or someone who can mentor you.
And yes, as mentioned practice. Don't just read, do and watch how you will improve. :)
Practice, practice, practice.
Once you're over the basic hump of being able to program, you can also read useful books (i.e. Code Complete, Effective Java or equivalents, etc.) for ideas on how to improve your code.
First and foremost write code. Write as much as you can. Tackle hard problems. If you want to be a really good programmer you need to get into the guts of what you are doing. Spend a lot of time in debuggers looking at how things work. If you want to be a good programmer who really understands what is going on you need to get down to the metal and write highly async code, learn about how processors work and why SSE is so awesome. Understand threading primitives and be able to write them as well as describe what is actually happening in the processor. I could keep going here but you get the idea.
Second find someone who knows a lot more than you and learn. This relationship will work better if you are already deeply immersed in writing lots of code.
Third, spend some time in a large high quality open source code base. I learned a ton from the Quake I and Quake II code. Helped me be a better programmer.
Fourth take on hard problems. Push your limits. Build things that you thought were impossible. Right now I am writing a specialized compiler. I have learned so much just working on this for the last couple of months.
Sure, strictly speaking, the more you practice programming, the better you become at solving those sorts of problems. But is that what you really want?
Programming is a human activity more than a technological one, at its heart. It's easy to improve your computer skills, not so hard to improve your interpersonal skills.
Read "Journey of the Software Professional" by Hohmann. One of the concepts the concepts Hohmann describes is the "cognitive library," which includes both programming skills and non-programming skills. Expand your cognitive library, and your programming skill will improve too.
Read a lot of non-programming books too, and observe the world around you. Creating useful metaphors is an essential skill for the successful programmer. Why do restaurants do things how they do? What trade-offs is the garbage department making when they pick up the garbage every few days instead of every day? How does scaling affect how a grocery store does business? Be an inquisitive human to be a better programmer.
For me, there has to be a reason to learn something new... that is, unless I have a project in mind or some problem I need to solve, there's no hope. If that prerequisite is met, then I usually try to get "Hello, world" working, and after that the sky's the limit. So much of development these days is just learning new APIs. Occasionally there's some kind of paradigm shift that blows your mind, but that's not as common as people like to think, IMHO.
Find a program that intrigues you, one that solves a problem, or one that would simplify many of your tasks. Try to write something similar. You'll get up to speed very quickly and have fun doing it at the same time.
You can try learning one thing really well and then expanding out to programming areas that are associated with the things that you have learnt, so that you can offer complete solutions to customers.
At the same time, devote part of your time to explore things outside your comfort zone.
One you have learned something, try to learn something a little harder. Read and practice a lot about things that seem confusing at first time (lambda functins, threading, array manipulation, etc). It will take its time, but once you have practiced enough, what seemed confusing at first, will be familiar and easy.
In addition to the rest of the great advice already given here, don't be afraid to read about coding and good practice, but also take everything with a grain of salt and see what works best for you. A lot of advice is opinion.
Good sites to read:
-thedailywtf.com
-joelonsoftware.com
-codinghorror.com
-blogs.msdn.com/oldnewthing
A great place to get practice is programming competition websites. Those will help you learn how to write good algorithms, not necessarily maintainable code, but they're still a good place to start for learning.
The one I used to use (back when I had time) was:
http://uva.onlinejudge.org/
Learn more than one language. One at a time, definitely, but ultimately you should be fluent in a couple. This will give you a better perspective I think, and help you to become an expert at programming, rather than being an expert at a certain language.
Learn the ins and outs of computers at all levels, hardware, os, etc. Ideally you should be able to build your own system, install multiple operating systems on it, and diagnose just about every problem that can arise. I know many programmers who are not "computer tech people" and their failure to understand what is happening at every level becomes a major hindrance in diagnosing and fixing unusual bugs or performance issues.
As well as looking at 'last weeks code', talk to users of your work after delivery - be one yourself if possible.
Its not my bag, but some of the best coders I know have spent time supporting applications. The experience improved their product I'm sure.
eat breath dream the programming language your using (no seriously, it helps)
There are two kinds of learning -
1. Informal (like how you learned how to function in society- through interaction with peers and family)
2. Formal (like your high school training- through planned instruction)
If you want an entry-level programming job, formal training via an undergrad Computer Science/Engineering degree is the way to go. However, if you want to become a rock-star developer, it is best done by informal training- make unintentional mistakes and have senior developers curse at you, learn a design pattern because an app you are updating uses it, almost cry because a bad developer wrote a huge messy program lacking documentation and best practices and now you have to do several updates to it ASAP; thing of these nature.
It is hard for anyone to give you a list of all you need to know. It varies per area (e.g. a web developer vs. to a desktop developer) and it varies per company (e.g. Microsoft that sells software vs. General Motors that mainly just use it in their cars.) Informal traiing and being engaged in trying to learn to do your job better and get promoted is your best bet in my opinion.
To prove my point, everyone here has great answers but they all differ. Ask a rock-star developer how he learned something or when, why; they may not know- things just happen.
Practice, individually and collectively
Keep an open mind, always learn new things, don't limit yourself to what's familiar. Not solely from a tech perspective, ui design, people skills, ... Don't be afraid of what's new
Peer review, talk to people about your code, let people talk to you about their code, everyone has a unique way of looking at a problem and you will learn a great deal from peers
Love coding. If you love what you're doing, putting in alot of time seems effortless. Every coder needs the drive!
One small addition to these good answers. When I work on someone else's code, usually I pick up something new. If you have the opportunity to work with someone else that is of equal or greater skill, noticing their programming style can teach you tons.
For example, in C++ & Javascript I no longer use if() statements without braces. The reason is that it's just too easy to mistakenly put:
while (true) {
if (a > b)
print a
print b
}
This is an obvious typo, but very easy to introduce, especially if you're editing existing code. I just call it defensive programming in my mind, but little tricks like this are valuable at making you better.
So, find a peer or mentor, and work on their code.
I am not sure if the OP was looking for general advice on how to be a good programmer, but rather something more specific.
I know I am reviving this thread, but I found it because I was trying to see if anyone asked this question already.
What I had in mind was, can we come up with a "knowledge-map" of programming concepts similar to the map that Khan Academy uses.
As a programmer, I want to be able to visualize the dependencies and relationships between different ideas, so that I can understand what skill level I am currently at; what I need to know before tackling a challenging subject; and be able to visualize my progress.
The very belief in the roadmap's existence blocks the road to perfection.
I need do write an expert systems that should aid user in picking up best mobile phone operator. It should be very simple and not based on languages/libaries such as CLISP or JESS. So I need to write it all from the ground up.
Do you know some books or online tutorials that explains how this can be done?
What I really need to get to know is how to represent knowledge and facts.
Any help would be much appreciated.
If you get any of the good texts on AI, there will be a section on expert systems; you can, if forced, work it out from there and implement your own.
The basic idea is really fairly simple: you have a collection of rules in "if-then" form that represent inferences, or4 implications. Like, for example:
IF blood temperature > 41°C
THEN patient.has-fever := TRUE
IF patient has wet-sounding breathing
THEN patient.has-pneumonia
IF patient.has-fever AND patient.has-pneumonia
THEN CONCLUDE bacterial pneumonia. ACTION prescribe Augmentin
In other words, you have a bunch of rules, and you evaluate the rules until you get to a conclusion. There's a lot more to is (forward or backward chaing and that kind of thing) which you can read about in thed pretty decent Wikipedia article.
I'm puzzled why you can't use an existing rule engine though -- there are a number of them, for most languages, usually under pretty liberal licenses. That's really an easier route unless this is a homework problem or something.
Prolog is well suited to writing rule-based systems (a pretty standard approach to expert systems development). P# compiles to C#, which may meet your needs - and it's free.
More information on P#.
The basis rationale, and mathematical proof, for the PROLOG language, should help you understand most of the concepts you will need to address, if not provide the final language you need to use to implement it.
I couldn't find a link to the original implementation, but it would not help you much anyway. Alain Colmerauer's early work on logic programming should be helpfull.
[EDIT] Sorry, duplicate...
I would vote for some implementation of Prolog or CLIPS, depending if backward or forward chaining logic best suits the problem. Instead of re-implementing either of these, spend the time working out how to integrate them with your environment.
Jess is a good choice but you should read the book "Jess in action" as a first step.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm supposed to learn how to use LabVIEW for my new job, and I'm wondering if anybody can recommend some good books or reference/tutorial web sites.
I'm a senior developer with lots of Java/C#/C++ experience.
I realize that this question is perhaps more vague than is intended on stack overflow, so how about this? Please answer with one book or web site and a brief description. Then people can vote up their favourites.
It will take some training and some time to learn the style needed to develop maintainable code.
Coming from Java/C#/C++, you probably have a good idea of good software architecture. Now you just need to learn the peculiarities of LabView and the common pitfalls.
For the basics, National Instruments offers training courses. See if your new employer can send you to a Basics I/II class to get your feet wet. They offer some online classes as well. Following classes, you can sign up to take tests for certification.
Get an evaluation copy of Labview from National Instruments; they have a well maintained help file that you can dive right into, with example code included. Look at "Getting Started" and "LabVIEW Environment". You should be able to jump right in and become familiar with the dev environment pretty quickly.
LabVIEW, being graphical is nice, but don't throw out your best practices from an application design point of view. It is common to end up with code looking like rainbow sphaghetti, or code that stretches several screens wide. Use subvi's and keep each vi with a specific purpose and function.
The official NI support forums and knowledgebase are probably the best resources out there at the moment.
Unofficial sites like Tutorials in G have a subset of the information found on the official site and documentation, but still may be useful for cross reference if you get stuck.
Edit: Basics I/II are designed to be accessible to users without prior software development experience. Depending on how you feel after using the evaluation version, you may be able to move directly into Intermediate I/II. NI has the course outlines available on their website as well, so you know what you're going to cover in each.
LabVIEW for Everyone is recently revised and quite comprehensive. Other than the free stuff available on the Web, this is probably the best place to start learning the language.
The LabVIEW Style Guide is a great book on how to organize and arrange your code and files for maximum benefit.
Object oriented programming is a recent addition to LabVIEW. The LVOOP white paper explains much about how it works and why the way it is the way it is.
It's a bit out of date, but LabVIEW Advanced Programming Techniques by Bitter, Mohiuddin and Nawrocki is still full of useful stuff.
The National Instruments forums are a great place to go for basic help. The LabVIEW Advanced Virtual Architects (LAVA) is the community forum for advanced topics.
Tutorials in G, also check out the webring.
-Adam
The official NI support page and support forums are hard to beat.
It really helps having a guru around for LabVIEW.
'Arc the daft' pretty much nailed exactly what one should try to do to learn LabVIEW. However, I would not skip Basic's I and II. The classes do teach basic programming concepts and are geared to non-programmers, however they do cover the IDE extensively. The LabVIEW IDE is strange coming from a text based language and spending the time in the class learning it with an instructor can really accelerate your learning.
I would skip Intermediate 1 if you are a seasoned developer. Intermediate 1 tries to teach software engineering practices in the span of a three day course. If you are studying to get your CLD you need to know the course and the terminology for the exam, otherwise I wouldn't spend my time or capital in the course.
Subscribe to the Info-LabVIEW mailing list. It's got a lot quieter in recent times as the NI and LAVA forums have grown in popularity, but it's still read by some very experienced and helpful people, including people at NI, and if you can't find what you need elsewhere then a good question will usually get a good answer.
The NI style guide, as already mentioned, is a good reference - re-read it as you learn about more of the things it covers, it contains some densely packed good advice.
Personal top tips: look at the supplied example code (although it's not necessarily perfect); learn to use queues and notifiers as soon as possible; don't dive in to using event structures and control references until you've figured out what you can and can't do without them; and start small and simple - you should find it easy to reuse this code later on by repackaging it into subVI's as the scope of your ambitions increases. And have fun!
For me the best way to learn LabVIEW was by analyzing the in-build examples. The best forums are NI Developer Zone Community and LAVA Forums
LabVIEW is really easy to work with but the tricky bit is to know how to design your application so that it will not becaome a spaghetti. Once you get the basics (e.g. LabVIEW Introduction Course) learn how to use design patterns, events, queues, typedefs and references. Use modular architecture, avoid big structures, try 'writing' your code in small window.
It is also important to know the differences between LabVIEW versions (full/pro, and ver 7.1.1, 8.2, 8.5, 8.6, 2009), how to use version control system with the vi's (binary files), and how to keep your files in project so that you can easily reuse any code and be "DRY" (don't repeat yourself), how to build executable and what LabVIEW RunTime Engine it needs (for customers), what is DAQmx and how to use it, what are VISA drivers and which version is correct for you settings, how to use Measurements & Automation program..
When I started with LabVIEW a few years ago I was given a link to the LabVIEW Graphical Programming Course. It covers the basics and having a sound knowledge of other programming languages I think helped me pick things up quickly.
I would start with the LabVIEW wiki.
Specifically, LabVIEW Tutorial. There are lots of online references and links to LabVIEW reference books. Welcome to the world of LabVIEW!
I would suggest you start with LabVIEW for Everyone. Its a good book which covers the basics of LabVIEW well.