Answer by Jeff Darcy on Quora
That programming is about solving problems, not writing code. Here are the four basic tasks that an individual programmer must perform.
- Define the problem (requirements and constraints).
- Define the solution (algorithms and data structures).
Express the solution in code.- Prove and/or test correctness.
A lot of people get really good at #3 because it's by far the easiest, but never master the other parts and as a result remain mediocre programmers at best. Often, a good programmer can solve a problem without writing any code at all, by using their knowledge and experience to avoid a problem or find solutions that don't require new code. In a team, an experienced programmer can often contribute most by helping people with the other non-coding tasks, including a vast array of tasks and skills that don't even come into play for an individual working alone (and were thus left off the list for the sake of brevity).
Once you're proficient in using the tools of your trade, further expertise comes from understanding a particular problem domain other than programming. It might be something serious like physics or medicine. It might be something venal like ad targeting or high-frequency training. It might be something frivolous like games. You might switch specialties several times during your career. In any case, being a great programmer means applying the technologies and techniques at hand to some goal other than programming itself.
...
Jeff Darcy has already covered about 2/3rds of what I try to drill into the folks I mentor, so I'll continue from what he wrote with possibly-provocative sound bites...
Stop avoiding the customer. Most programmers I've met have an almost pathological fear of talking to the very people who are driving the requirements that necessarily shape and constrain their output. As an intensely private introvert myself, I can sympathize to an extent ... but then I remind them: "The customers are human too, with their own worries, weaknesses and wishes. They're also the only people who can answer the Ultimate Question of Your Programming Work: What problem am I trying to solve?"
It's all about the data. Jeff already mentioned this, but I think it bears extra emphasis. Just about every algorithm you'll ever use deals in one way or another with user data, and the data structures you choose in turn are arguably the biggest non-negotiable constraint on the algorithms you implement.
This also follows from my first point, in that your problem's details inevitably shape the range of useful data structures, so not starting with a clear picture of the problem space often leads to time wasted in rethinking data structure selection down the line, when the project's late and over-budget.
You're paid to deliver, not to play. There are two types of programmers in this world: those who are expected to write code that solves real-world problems in reasonable time (both run-time and delivery-time), and those who aren't. I call the former Real World Programmers, and the latter Lucky Bastards. You are probably not a Lucky Bastard.
These days, you'll receive word at least once a week of a new programming language, concurrency programming library, NoSQL database, etc. As a Real World Programmer, your job is to be ruthlessly pragmatic. Even if the latest sexy XYZ looks like it fits the bill for some part of your project, you need to factor in the estimated time it'll take to get up to speed on it ... and to track down and resolve the bugs therein that inevitably affect your programs. (Double your initial estimate, and you're probably still nowhere near the actual time spent.)
Real life sucks ... deal with it. (Sometimes confused with the more colorful Sh*t happens.) The programming skills you were taught in school often assume ideal conditions, for the simple reason that the instructors are usually too busy/lazy/afraid-of-complete-confusion to introduce real-life complications into the course/lab material.
That's where people like me come in. Finished your client-server code? OK, go ahead and run it while I check something back here (count to a random number and yank the Ethernet cable). What happened? It crashed? It shouldn't.
The influence of the network on modern-day applications can't be overstated. If you haven't already, take a quick read of the 8 Fallacies of Distributed Computing, then meditate on each point and see how many of them your design/code falls afoul of (it's usually more than one). My personal favorite is "#3: bandwidth is infinite"; everyone falls for that, and I then lead them, via simple mental arithmetic, to the embarrassing conclusion that their intended usage exceeds the maximum theoretical capacity of their network. Nobody likes to tell management that it's mathematically and physically impossible to deliver what they promised, so that's when I get compared to an anal sphincter.
What can I say, except..."Sh*t happens, and I guess I'm the portal."
What can I learn right now in just 10 minutes that could be useful for the rest of my programming career?: originally appeared on Quora: The best answer to any question. Ask a question, get a great answer. Learn from experts and get insider knowledge. You can follow Quora on Twitter, Facebook, and Google+. More questions:
