Regardless of programming language(s) or operating system(s) used or the environment they develop for, what should every programmer know?
I'm interested in becoming the best programmer I can. As part of this process I'm trying to understand what I don't know and would benefit me a lot if I did. While there are loads of lists around along the lines of "n things every [insert programming language] developer should know", I have yet to find anything similar which isn't limited to a specific language.
I also expect this information to be of interest and benefit to others.
How to swallow pride and admit mistakes without taking them personally.
When to ask for help, and when NOT to ask for help.
Familiarity with version control systems. It doesn't have to be every one, but the basic concepts that can be applied to all of them should be known.
Basic data type & algorithm theory. Things like Big O notation, arrays, queues, etc.
Well... there are about a ten thousand things a programmer should know before they start getting productive, so this question is too generic and subjective. But a willingness to listen and learn new stuff, and a basic ability to Google is always a plus...
Reading other peoples' code is not going to spoil your brain, but rather figure out why you would not have done it that way (if better or not is another question).
This gives you programming gedankenexperiment, and occasionally you do find someone implementing something way better! Like in way better.
This answer naturally expands to reading your own code, thus it expands to use version control and DIFF, and thus to 42.
How to read other people's code.
How to think like a user, and not like a techie geek programmer.
That the programmer doesn't know everything and should always try to learn new languages/technologies, etc.
How to observe a big complicated object and decompose it in small simple objects that still accomplish the same task when put together again.
How to choose the right tool for the right task, and not taking part in silly flaming wars about his favourite programming tools.
While helpful at times, you should not be fully relying on your compiler or your debugger to help you make your code better.
You can't test quality into a product.
Where to find the information the programmer needs :)
The negatives of their prefered language, no better way to defend your choice of language and know how to use it to its full potential better than knowing what is down sides are
Version control. And to quote my girl friend: "I don't just want you to do the dishes, I want you to like it!"
The fact that, No one is indispensable!
Thinking out-of-the-box is usually a good thing! Most of the development is not just straightforward.
How to leverage their network of contacts both internally within their current organisation and externally, as you never know when you will need someone to mull over an issue with you or where the next interesting project might come from.
Every programmer should understand that generally the best solution for the business and the most technically elegant programming solution are not the same thing.
Here's my 10 bits:
Managing expectations of your clients, your manager, your coworkers.
What you don't know.
Never trust a user (especially if the app is public!), they will often do everything in their power to break your app one way or another.
Make it future proof & expandable â€“ you never know when you want to expand it in a few years time and realise how much effort it would take to re-code badly created code.
How to program in C.
Maybe it's too subtle, but I think of it as "knowing which problem to solve." A lot of programmers (and normal people) waste tremendous effort solving things that simply aren't very important; or they create a solution, with a great deal of extra work, that isn't quite what is needed.
Well, here's my .02$ :
Unit testing and debugging.
Every programmer should know how to learn quickly. A lot of times you come into a job and will be asked to develop in a technology you've never used. They might give you a week or so to get on your feet (if you're lucky) before you're asked to write production-quality code.
Your code will inevitably have some little thing you never thought of go wrong. Don't worry, it's ok, just fix it and learn from the experience.
Every programmer should know how to accompany code with good documentation.
I find that code that is well documented (liberal use of embedded comments) is easier to maintain and upgrade.
When a programmer embeds their rationale for an implementation (inline to the code), I can spend less time on figuring it out and more time on the task at hand whether it is adding features or debugging other related issues.
Short and sweet -- no person will be an excellent coder / programmer / developer (pick your favorite word) unless he is a continuous learner.
I no particular order...
Learn all you can about; Algorithms, Design Patterns and Data Structures
Remember programming elegance should be striven for, but not over productivity.
Remember to use Google, heck and now StackOverflow.com
How to establish good communication with management so that requirements and time frames are achievable and realistic.
How to relax. It's the secret to productivity.
Eventually, willpower and caffeine are not enough. This constant contraction we do is very damaging.
This is a big deal.
How to learn new things and adapt. I've watch us go from assembler to BASIC to FORTAN, to C, to C++ to Java to C# and so on. I've watched computers go from mainframe to desktops to embedded in just about everything.
I've seen computers go from being large calculator only a few people ever used to controlling almost everything in our daily lives. How many computers, microprocessors, and other programmable device did you interact with today? It may be hundreds!
I know a person with a CS degree they earned about 20 years ago. She has to ask her kids to help them send a e-mail or look up a web site. They could not adapt to the changes.
Your most important skill is learning.
The basics of good UI design and communication (aka graphic) design.
I see so many apps and projects ruined by bad design or poor usability. Just learning the basics can make a world of difference. Plus the visual problem solving techniques (i.e., how to communicate a concept visually) are a stimulating challenge that should open your eyes to new ways of seeing, which should in turn have an impact on your code.
A recommended book is The Non-Designer's Design Book by Robin Williams
Here's what Joel Spolsky says of it:
Wow! Everybody has to do some graphic design, and not every software team has the luxury of professional designers. This excellent, thin book will give you a grasp of the principles behind page layout, fonts, etc. The good news is, you can read it in the bath before the water gets cold, and the next day, your dialog boxes and powerpoints and web pages will start looking better.
I'm not opposed to generating a list like this, but what you get is probably going to be pretty random and unstructured in comparison to the many books that cover the same topic. I suggest the following as the best places to start: The Pragmatic Programmer and Code Complete.
More specific topics like language mastery, design patterns, refactoring, etc. are also super important.
Every programmer is a programmer. Then there are designers and analysts, too. If analysis phase has been skipped, no one should blame the programmer if he programs wrong things...
Of course small projects might have only one developer, but you get the point.
I would say the biggest thing to keep in mind is that you are programming the system for the user and not yourself. It doesn't matter how you program the actual system, but rather it meets the needs and requirements of the user because if it meets the needs and requirements of the user they will continue to return to you for business. The opposite being a programmer who programs a system very elegantly, but does not meet the needs and requirements of the users. This is one of the primary reasons people choose Windows and Mac over Linux. Linux is fantastically programmed, but does not meet the ease of use requirement most users are looking for from an operating system.
Other things I can suggest are:
Know when to ask for help.
Know where to ask questions and how to find answers?
Learn how to logically design your code, it will save you so much time and hassle when you are coding. Look into UML designs.
Learn how to properly comment and document your code. I can suggest this http://www.gamedev.net/reference/articles/article1218.asp for good tips on documenting and commenting your code.
Those are a few suggestions I can provide, but really remember that the user is who you are making the system for.
Every business application programmer needs to understand data. They need to understand not only the database structure and how to efficienty get data out of it or put data into it, but they also need to understand the meaning behind the data. How is it used for decision making? What is the impact of a mistake in a report? Why do the users want the things you think are silly? What are the legal ramifications of your coding processes? If it is a finanial system, then you need to think if the way you are accessing data creates an easy path for the person who wants to commit fraud. (Never use dynamic SQL of any kind in a financial system because you have to have the rights at the table level. This makes it very very easy for someone to commit fraud.) What data needs to be protected and how should you protect it?
People and communication skills. Seems like those who excel in the IT industry have the skills to "make friends and influence people". It seems trite, but communication and people skills are something you need to work at - just like learning programming skills...
Along the swallow your pride lines - learn how to divorce your ideas in heartbeat if a better idea is proposed.
Try to understand the complete stack of software that will turn your ascii characters into an executable program. I.e., understand how a compiler turns your code into bytecode or assembly, understand how a CPU executes your assembly code, understand what a JIT does, understand processes, operating system calls and threads, understand how polymorphism works through vtables and method dispatch.
Of course, not to a level that you could write all that code, but at least having a pretty good idea how software works on all these levels will make you a better programmer, and also give you insight into solutions you might not have thought of before.
The number one thing that you should know as a programmmer: how to take responsibility.
There are going to be bugs. Some of them are going to be yours. You are going to make mistakes and cost the company money. This is guaranteed and known.
When you find a bug, start from the premise that it's not someone else's code that screwed up; it's yours. Be willing to admit that out loud, and learn from it. Keep track of where you make mistakes, and learn how to cover from them; if you have lots of null pointer bugs, then start checking for them in every method. If you have bugs against the database, then start writing functional tests and verify that the queries you're running are correct. Do you have a tendency to go off and write something cool, even if it's not what the customer asked for or wanted? Then start writing out the user stories and use cases beforehand with the customer and hold yourself to them.
There are all sorts of things that you should know, but the most important thing is to know who you are.
Off the top of my head:
Very few programming problems require math beyond addition, subtraction, multiplication, and division. If you're thinking of using calculus to solve a problem, research the alternatives exhaustively before doing so.
Any time you find yourself guessing about how something should work, you're doing it wrong. It's not your job to be telepathic.
The person giving you the spec rarely knows everything he wants until you've hashed it out.
More than half of being a great programmer comes from dealing with human beings. Interacting with your team, managing your manager, and finessing the end user are half of the job.
Good code is written to be read by people as much as it is to be read by your compiler.
Best practice and practical reality will be in conflict more than the programmer thinks, but less than the manager does. When they appear to be in conflict, it's up to you to delineate and understand the conflict and then give in to the practical. The subtle and clever solution is only better than the ugly, brutish one if it's more cost effective in the long run.
Great tools can't make great programmers, but bad tools make us equally awful.
Never look down on a technology, but always look for the best alternative.
The more languages you know, the better you'll be in the one you're using.
Don't be disturbed by the slow creep of programming-oriented thoughts into your daily life. Even when we're not at a computer, we all suffer from bandwidth limitations, have performance penalties from task switching, and need to load things from backup storage. Computers are supposed to mimic human thought and the analogues are everywhere.
It is OK to abandon a design or solution once it becomes clear that it is not working or is very suboptimal. This is not the same as saying all your code has to be perfect. I've seen many people spin their wheels for long periods of time on something that clearly won't work in the long run. I think learning to recognize that and change tracks is an important skill.
"Learn a new language every year, and read at least 3 or 4 books a year" Steve McConnel.
More your learn, faster you'll learn.
Mathematics. Programming is just an frighteningly tiny subset of the language of mathematics.
I've found Jeff Atwood's "Recommended Reading for Developers" post to be a good list of reading material.
Suggesting Jeff's reading list isn't a shameless attempt to get brownie points. I had the same question myself and came across the list, so decided that it would be a good place to start. Whether it's the best or most comprehensive list, I don't know. I was just browsing the technical books section at Barnes and Noble, so having a thought out list of recommended reading was a huge step forward in my effort to get better educated.
Besides knowing how to do the cool, the boiler plate, the borning, and the redundant. Know and learn one thing, you are replacable. Once you get over that, you'll job will be easier. Know that even though there is "internet time", somethings which are worth doing also take time, and cannot be accomplished in five minutes, no matter what your boss thinks.
Oh, and also, don't forget to stand up for yourself, and stand your ground when you know something is not true, and someone is trying to "sell you down the river".
Don't get too emotionally vested in, attached to, or religious about any given technology, OS, or language - none are perfect - in the long run you're likely to end up wishing you could create your own ala carte from what you like about each different one.
Think of it like cars - you may not have driven a particular car before, but they all have keys, steering wheels, accelerators, and brakes - you should be able to get in one and quickly drive off once you sort out what's where. Treat OSes and languages similarly and focus on learning the essential concepts underlying them even if you're in the throes of the specifics of any given instance.
And over time try to understand and appreciate the ancestry, heritage, and commonalities of the various technologies which will help you keep perspective. Realize for example that, while the evolutionary tree is actively branching and full of dead-ends, over time technology tends to repeatedly converge around 'best practices' and 'economies of scale' (e.g. notice a Mac isn't all that different than a PC under the hood these days...).
Last, remember no matter how much fun you're having with it all, technology essentially represents an imperfect lens between what your mind can envision and what you actually produce. Do your best, learn to learn, and remain adaptable...
How to use paper and pen (or something equivalent) to write and explain code...
Use or license someone else's code when it makes financial sense to do so. In other words, be aware of the tradeoff between time and money. If it's cheaper to license a library rather than spend time rolling your own, do so.
Recommended reading list: http://www.codinghorror.com/blog/archives/000020.html
If you want to be the best possible programmer, you need to understand how the "magic" works. Others have suggested learning about compilers, and that's a good start. I would even say every serious programmer has to build their own compiler at least once. But there are other "magics" you need to understand:
I would also suggest studying "magical software techniques":
You should end up with a knowledge good enough to feel that you could look up everything you need to know to work on any part of the entire system. What this then will give you is a grounding that lets you tackle any issue, regardless of how many disciplines it traverses.
Ofcourse, this isn't all required to be a good programmer, but your question wasn't about being good, it was about being the best you can.
No-one wants to use software. They want problems solved.
Always be willing to learn from your mistakes.
A good level of Math!
I'll add my own bits:
Basic understanding of Software Development Life Cycle, generally the phases of requirements gathering, analysis and design, implementation, testing and maintenance.
Know how you learn - Do you prefer visual, oral, or some other method of learning new material? Also, what kind of reference look ups do you usually do to learn something?
Knowledge of where they want to go or at least what to try. Architect, business analyst, systems analyst, program manager, or some other next step after being a developer for a few years is something to ponder and explore, not necessarily commit to forever. Alternatively, what kind of specialization do you want to have: Web, Windows applications, web services, databases, etc.
Be able to communicate at various levels of detail depending on your audience. The exception here are the top 1% of programming geniuses that will cater to someone with such ability.
Be good at solving problems and designing solutions. In most places this may be part of your work that you didn't think as this isn't necessarily specific to what software you'll be writing.
Be humble when things go wrong, expect things to go in odd or unusual directions.
Know and understand the theory and the algorithms. Anyone could learn to code, but only few becomes those who can teach to code.
That there is a time to discuss system architecture and a time to just get things done.
One of the things that I try to recall whenever I'm writing code is that someone else will have to change it someday. Now, in certain instances, this may not be true, but I write as if it is. I try to code so that they can enjoy the process, or at least not give it a second thought.
Be language/platform agnostic. Java is not the right tool for all applications. Neither is C#, or C, or Lisp, or [insert your own language here]
Without users, there is no use for programmers
And one of my favorite quotes... Always write your code as if the next person to come along and support it is a raving lunatic who knows where you live.
Correct naming conventions for variables - There are several out there, pick one, stick to it religiously... every time.
Third normal form - If you're having to design a database, this is like, the most important thing ever.
Good commenting - Anyone with basic knowledge of the language, should be able to decipher your code.
Where to get help - No-one knows everything... knowing which forums, communities, manuals, references etc. to go to when you get stuck can literally save days of man-hours.
Boolean Logic and Basic algorithmic notions
That the day you stop learning should be the day you're no longer a programmer.
Binary search. It's useful in a lot of places: search through sorted collection, certain debugging scenarios, programming interview questions.
IMHO, a career programmer should have the passion and drive to create things. One should also be very keen on learning new stuff as well as master the language you are currently using. I also agree that good programmers should accept their mistakes and admit to have had mistakes in the past and use these mistakes to improve one's skills. And always keep in mind that someone is always better than you in something else but don't make this deter you from being the best programmer you can be.
I'm a little late to this one, but I'll go with the knowledge laid down by Edsger Dijkstra:
Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
If you can't write a good paragraph, chances are you can't write good code either.
Power of searching.
Even the tiniest issue might have answers in the net, if only one is willing to spend some time searching.
My 2Â¢ as an aspiring hardware design guy:
you should know how a computer physically works, so that you understand where the power of software bumps up against the limits of hardware, and how to prepare for them, code around them, and come out ahead.
How to learn.
This is probably already posted but I'm not about to search and read through all that. But a programmer must know when to give up on their idea if a better way of doing it comes along.
How to remain proud of your work and be able to admit mistakes at the same time.
Don't swallow pride!
Stop worrying and start doing.
I live by these mottoes:
"Success is 10 percent inspiration and 90 percent perspiration."
"How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?"
When I get to work, my ego stays in the car. Nothing matters more than the work and its quality. Never take criticism personally and listen to everyone, no matter how stupid they may sound. But don't ever compromise the quality just because it's faster or easier.
And of course, learn,learn, learn. :)
All problems are people problems
Should know what to code and how to code. if don't know, then should at least have the apt and enthusiasm to learn it !
Nature gave you two ears and one mouth, so use them in that proportion.
aka; if you have a tendency to talk to much try Listening; if you have a tendency to keep quiet then speak up.
Know that a good (the best) program is not necessarily the one that runs fast(er). A good program is one that: - Is easy to understand and change. - Is easy to use - it has a simple/clear/easy to learn interface.
I like to say that the best programmers are the one who can write programs that even the worst programmers can understand and even the most casual users can use.
Great thread! I'll add that I learned a great deal from the Programming Pearls books.
Functional programming. It'll teach you to think about how elements of your programme fit together. Terribly useful in object oriented programming.
Learn the difference between a type and a tag assigned by your compiler's type system. This will allow you to write better generic code.
I'm pretty keen on mathematics, but I think one that comes over time that programmers should know is what rabbits to chase and which to let go. When searching for an answer to a question and you can't find the answer anywhere, it's not giving up to try a different tack. We get paid to solve problems, we don't get paid on the method by which we solve the problem.
You can and will make mistakes too. This helps in two ways. First, you don't get down on yourself. Secondly, you don't look down on your coworkers. This second one will help you as you go trough your career.
Understand that (mostly) the only people who will value your code, will be another programmer. Users will only say "Hey, that's pretty, but can it be with another color?" I just had to live with that. ;)
to discipline yourself to write software that's good enough even if it's not perfect
Nobody has said this yet, but--fundamentals of computer architecture. I'm talking about things like: registers, memory access, and assembly language. Clearly you don't need to know any of this to program effectively. But if you truly want to be a professional developer, you should know the real fundamentals of the machine that you're working on. And this stuff really isn't that hard.
How to write clearly and concisely. I'm not talking about code, although that would be good too.
Every programmer should know how to solve problems. It is important to approach every task with an open mind as to what tools and methodologies to use. Sometimes frameworks or patterns will be the answer, but sometimes they will not.
To dominate through powerful, verifiable generalities. Making your code as generic as possible is a priority.
Play the game, learn that most of your daily work is going to be about work-place politics and not programming.
How to format code:
Version control, obviously. But more importantly, the mechanics of a computer.
Compiler theory: how do you transform one language to another? Without some idea for how this works and what it can do, code is bound to be full of bad decisions. Compilers tend to look magical to the non-initiated, and they tend to write horrific code.
Computer architecture: you need to understand the machine deep down below to some extent to really write good code. Even on top of multiple layers of middleware, the fundamental machine will shine through. You need to understand caches, multiprocessing, how IO works, at some level, to have a decent chance at writing decent code. Writing code obliviously to the issues of memory size, caching, etc. might work well to some point -- but when it breaks due to lacking synchronization or hits a performance wall, you need to understand what is going inside the bowels of the machine.
Surround yourself with people who are smarter than you are.
That writing code is only a small part of being a programmer.
The problem domain they're working in.
Every developer out there should read this post:
"It is harder to read code than to write it"
The one thing i can give up for advice:
Now not the form of lazy where you grab some code off some open source project, think it's good enough and cut-n-paste it in your own app, i mean preparing to be lazy in the future.
I always try to break everything down into basic, standard objects that do dedicated tasks. An SSH object that does SSH connection handling and SCP'ing, a dbconnection object that handels all the db communication, you name it.
Just drop it in, make it work and you're done. The longer you are a good programmer, the easier it gets to get something done.
Also If you're not being lazy enough (for instance, check TheDailyWTF), get yourself an other job. There should be something inside you that makes you not want to re-implement the programming language in the language itself, or do any of the other stupid stuff that you see on TheDailyWtf.
Know that there is more than one way to do it. This is Perl motto, but it is very general. You can also learn the free software song.
Humility. You're a human being, not an extension of the machine you're working on. You don't and will never know everything and you will always make mistakes.
Knowing how not to reinvent everything. The vast majority of problems a developer faces has been faced and successfully solved by smarter developers a long time ago. Not using this knowledge is the biggest mistake a developer can make. In the worst case one will not be able to solve the problem. In the best case one will waste time coming up with a solution that already exists.
I think there are two things every programmer should learn:
Seems obvious but I think developers tend forget these two simple things.
Choose the right tools/languages for the right problem
I know many programmer who learned one language (mostly C++) and stick with it. Regardless of the Problem they are trying to solve they do it in C++, because C++ is the ultimate language from their point of view. Even if it could be solved in with a fractional amount of effort and code in other languages.
You are programming to solve problems
I know many programmer (me too sometimes) who start implementing one feature after another because its cool to have them. But in the end many of these features are pretty useless because no one needs them. You are programming to solve a problems for people. So don't let that target get out of your sight.
If P == NP
And Assembly, on some platform. Probably will never want to use it but an awareness that it's not turtles (or objects) all the way down, the byte stops here.
I am of course joking about NP, but an understanding of what problems are actually difficult to solve problematically can be quite helpful.
Understand the difference between idealism and pragmatism, and why both are important when designing software.
These are things I've learned myself from trial and error over the course of my education and career. I'd say these lessons have served me well although it's sometimes a struggle to overcome my own shortfalls.
How to conceptualise a problem before trying to code it. Designing up front is important and having the ability to properly conceptualise the problem helps to get a good design.
Humility. We never stop learning and we should never assume we know it all. There's always something to learn, and we're always going to have times when we're wrong. It's important to recognise and accept that.
How to break code. Many I have worked with (including me) have coded to meet requirements and didn't spend enough time checking that the code was robust to bad data and bad control flows.
How to understand code. Borrowing from others is not a bad thing, but borrowing without understanding what is being borrowed is a bad habit to get into. Just because it looks like a duck and quacks like a duck doesn't mean that it won't eat like a lion, or BM like a flying elephant.
Every programmer should know that:
a) maintainability should not be sacrificed for insignificant performance gains.
b) maintainability is better in the long run, even if it costs a little more up front.
c) maintainability generally does not cost more up front if you know what you're doing in the first place.
To put themselves in the shoes of the developer potentially taking on the project after them - commenting well and naming sensibly.
You can't bolt 'security' onto a product.
Every programmer should at least once see his customer/user. You'll get a better view of the user and why he has sometimes such 'odd' requirements.
If you get a bug report, do not search a person to blame and rethink. Maybe it is your fault.
Figure things out on your own. Or, at least, make a real, honest attempt to do figure the problem out on your own. You'll learn more than you ever will getting the answer from someone else, and it'll be a lot more rewarding.
Recently, I've read credible blogs from technical managers complaining that almost all job applicants for programming positions can't actually code, including those with CS degrees. If this is true, then the answer to your question is clear: what every programmer needs to know is whether they can actually program. Without warning, you should be able to listen to a simple problem, then sit at a computer and code a correct solution in a few minutes.
How to talk to non-programmers about programming concepts. It's tricky to get the hang of, but it will increase your value and the ease of your life greatly.
I think that a lot of people are reluctant to help or teach others what they know, and for me, this is, simply put, wrong on many levels.
First of all, one of the best ways to really learn something is to teach it to someone else...and it that someone else doesn't understand your explaining, then it means that you don't know it enough to explain it in simple terms.
If you really are passionate about your craft, why restrict what you know to yourself? I personally think that there is a social side to programming as well. Of course, we all like our late night coding sessions with a mug and an ashtray by our sides, but believe it or not, some time or another, you will find yourself working in a team. And when you are, why not mentor the ones that are less knowledgeable than you (about the respective subject), and teach them what you know so that they become better programmers?
After all, in the final product, better developers will develop a better solution.
...and besides, wouldn't you want other fellow developers giving you a few tips here and there, or even teaching you what they know? I suppose you would...I mean, if you wouldn't, then it just means that you don't love your craft and you are just doing it because there is nothing better to do
So anyways, my point is: Do not keep what you know to yourself...
How software uses memory and the processor. How to design good software. How to comment. A bunch of programming languages / technologies, to get the best from each of them and to gain point of view on the whole. How to estimate deadlines.
I've always believed that every programmer should know as much as they can about databases. Every company worth its salt has a database ... no matter what programming language you go for ... C#, VB.NET, Perl, PHP, Python, ASP, Shell Scripts .... you're almost always going to interact with a database of some sort.
I've seen companies run on MS Access, Oracle, MySQL, MS-SQL, Pervasive ... you name it ... any big company (or company who is going to pay you to do work) is going to have a database of some sort.
Knowing how to get info out of that database in a fast and reliable manner will make you look like a hero. Being able to spot an absolutely atrocious query and re-work it can make you look pretty impressive. Just think of some of the apps you've run across with horrid response times ... if it's due to a database query and you can re-write it quickly ... you've just pleased hundreds if not thousands of people in a heartbeat.
So my advice is ... learn about databases ... queries, stored procedures, indices, tables, cardinality etc. ... because in the end it's all about the data.
Most things from there are hard to generalize. E.g., someone working on embedded controllers probably doesn't need to know SQL, likewise a DBA probably doesn't need to know the STL.
Programming is making computers
1) Get input 2) Process input data 3) Generate output
Computers are dumb but real fast..
And without electricty 'or a relevant energy source' there is no spoon..
every programmer has to be resource-hungry - has to constantly learn and adapt .
Every programmer should know the basic of the underlying hardware they work on. What is the difference between languages before choosing one. Know every inch of the language he works on. Know almost 10 different containers. Generic programming. basic Boolean logic, some basic mathematical principles. the 100 basic algorithms. And good goggling techniques.
BUT the top ability of a good programmer is the problem solving and out of the box thinking and believe me you can't learn this you are born with it.
Besides the obviuos:
Graphical, Spoken and Written.
Never Assume Anything. As in Stephen King's Cell ..Assume makes an ass out of U and Me
Beware the complicator!
a good developer must be able to;
Know when to stop.
Don't spoil a good program by overembellishment and over-refinement. Move on, and let your code stand in its own right for a while.
-- From "The Pragmatic Programmer"
Although sometimes, I just can't help it and my hands are simply itching to optimize it a "little bit more". =)
Instead of pointing fingers, point to possible solutions. It's the positive outcome that counts.
(from: "Practices of an Agile Developer")
Just few hours or few days of exploring is enough. No need to be very familiar to these things.
The main point is to broaden the view of programmer: there are many kind of programming which is so different. Don't let the language you used limit your thinking.
My .02 cents worth......
Not knowing how you are going to design/code/accomplish a task while the client is asking for it is NOT reason enough to reject the client request. Sometimes we have to agree to do something BECUASE the client needs it ...and THEN find out HOW to do it.
As Patton once said: 'We are in business to do the impossible"....any slob can accomplish what's possible. That last part I added in ;))
Lots of great answers here, but I'll toss out one more: Do NOT rely on your job to improve your skills. Many programmers figure that five years' worth of following orders and bug-fixing work at a typical IT shop, doing CRUD programming, automatically makes them a "senior programmer". Not necessarily so: I like Jared Richardson's line, "Some programmers have gotten five years' experience. And some programmers have gotten one year's experience, five times."
Accept that is ultimately YOUR responsibility (NOT your boss's) to improve your skill set, learn new languages, and produce higher quality, well-designed code. This could mean writing your own tools at work, it could mean a side project done in your spare time, it could mean a new tech book a month, or it could mean contributing to an open source project. If you can find a project related to something you're passionate about, so much the better.
Whether you're salaried, or a contractor ... ultimately, we're ALL freelancers.
97 Things Every Programmer Should know: http://programmer.97things.oreilly.com/wiki/index.php/Edited%5FContributions
User's satisfaction matters, code quality not that much
As a programmer we should take proper care of our eyes and fingers. Also should take small breaks often to keep mind fresh and avoid silly coding mistakes. Also take proper care of back and be sure to do daily routine of exercise as in programming profession they are high risks of putting some unwanted body weight which might be very hard to reduce down the line.
Do not be a complainer, solve the problem.
to understand to think to write well to optemize ..and to cheer up :D
Just be a good team player - always accept feedback as a suggestion for improvement and not destructive criticism.
How to deal with frustrating people without losing your temper.
When the manager drops a list of items on your desk and says he expects them to be done by friday; When the DBA runs a data load script twice; When the sysadmin deploys the wrong version of your code; When the user asks you to explain how it works, again -- That's when you need the be able to handle it with grace. Because you're going to have to work with all these people, and it will go much better if they don't think you're a nasty jerk, no matter how wrong they are.
How to use google
Drop your ego
Criticism is not evil
Recover from failure quickly
Practice, practice, practice ....
Be eager to learn from others
Be willing to change
You will never know as much as you think you do. Even after a few years in the business, you will continue to encounter people who know more than you do about your personal area of expertise. Don't worry about it and keep studying and learning.
You will never have learned enough languages or architectures or paradigms or buzzwords. Because once you think you know it all, someone will invent a new (insert favorite technology here) and you will be out of touch again.
You will be that old fuddy duddy soon enough. Cut him/her some slack and assume that once upon a time, he/she was in your shoes.
Think outside the box!
How to understand a program written in a programming language that you did not learn.
(for example, a Java programmer reading C# code without learning C#)
That you must eat your own dog food if you really want to make robust code.
The real world may not run the same as things did when you were in school. Accept that how a company runs its software development isn't going to match exactly what the theory was that you were taught.
Take some time to understand how things run in a new organization. This applies to everyone but grads may hopefully find it more sobering than others.
In universtiy I was one of those guys who always asked the prof. for the formulas, for tricks and mnemonics to memorize the right answer, for the fastest way to solve the question, and this is my greatest regret.
Learning things by formulas and memorization means you start every problem at step one; you can't apply any of your previous solutions to new problems. I was no better at solving problems at graduation than I was as a freshman.
The guys who did best were the ones who learned how to do things from first principles; they derived the formulas instead of memorizing them, and would solve the same question multiple times to try different approaches and check their answers.
Yeah, at first those guys took forever to solve the simplest problems, but from then on they never had to solve them again, they knew it cold. By the final year they could solve many problems at a glance, and could estimate the right answer without working it out first.
ESR nailed this one:
"languages of particular importance to hackers include Perl and LISP" ... "LISP is worth learning for a different reason â€” the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot."
I've never seen a Lisp programmer who couldn't very easily pick up any new language, though I've seen many, many programmers who specialized in every other imaginable language who had trouble learning new languages. There's something about Lisp that stretches one's brain. (I think it has to do with the circularity of defining something in itself.) Like a contortionist, nothing else seems like much of a stretch any more.
My college required all students to take courses in foreign languages and cultures, including non-western cultures. I'm amazed that we allowed people to graduate from the computer science school having only learned C++ and Java.
Yes, when hiring I rank this way above many of the other things here. Any Lisp programmer can learn "Source control, unit testing, and continuous integration" in almost no time, but a Java-only programmer who knows those 3 things may well struggle with closures, or parsers, or something that I actually need. If you know computer science and programming, we can teach you the processes, but not the other way around -- or at least, not on a timescale I'm willing to subsidize with payroll.
The skills needed to get a development job and the skills needed to be successful at a development job are often typically two very different things. In making career choices, prefer places where they are the same.
Conversely, in most jobs 95% of your data structure / algorithm needs are served by library classes. 95% of your time will be wasted by dealing with unmaintainable code written by people who are ninjas at CS but have the engineering skills of a lobotomized beaver.
Speaking as a college grad, there are soooo many things I did not learn in school, which I had to pick up on my own. I could go on about the various things I had to learn on my own, but that might take a while :) Instead, I suggest that the following trumps any specific tool or technology:
Continue learning new things. You must have the drive for continuous improvement in order to remain sharp and competitive.
How a veterinary doctor does his job!
Funny, but I find the single most important skill in my work is googling. Sometimes I google problem even before I think about it :)
Or, if generalize, I'd call it 'information processing': ability to 'scan' lots of data quickly and find the information you need.
Today I came across this book. It is a very nice book and a good recap of all the best practices.
The Mother of All Demos is a name given retrospectively to Douglas Engelbart's December 9, 1968, demonstration at the Fall Joint Computer Conference (FJCC) at the Convention Center in San Francisco, in which a number of experimental technologies that have since become commonplace were presented. The demo featured the first computer mouse the public had ever seen, as well as introducing interactive text, video conferencing, teleconferencing, email, hypertext and a collaborative real-time editor.
I would like to quote the following only,
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan