Advice to young programmers
chestergrant.posterous.com
chestergrant.posterous.com
In other words, keep your mind open. Don't become a domain expert, as advised, and then convince one's self that that domain is The One True Path. Conversely, don't glance at a particular domain, assume that casual knowledge to be canonical, and then write off that domain as A Path of Fools.
Young programmers are especially susceptible as the myopia of youth prevents one from grasping the miniscule nature of their own knowledge. Once one gets a bit older, he/she tends to realize that what they know is but of grain of sand in the ocean.
I first parsed this as "Don't become a domain expert, as advised. Also don't convince one's self that that domain is The One True Path".
Lest someone else confuse it the same way, this does not imply that becoming a domain expert is wrong; it means that after you become a domain expert, you should still keep an open mind.
As I've matured, my confidence in my own knowledge has only increased. People who play the "It is a truly wise man who knows he is not" card are usually trying to limit you. The main thing to keep in mind is that your intelligence doesn't preclude others from being intelligent either. Have confidence in your abilities, but don't let that stop you from having confidence in others' abilities.
I've always felt just the opposite. Acknowledging what you don't know can furnish you with the drive to learn it - thus becoming better. Understanding you're not "wise" is the first step to becoming so. The moment you get to confident in your abilities is the moment you stop learning.
I'm not saying this point of view doesn't have its place. I just think it's important to understand the dynamics involved with it. You don't tell someone they don't know as much as they think they do unless you're trying to stop them from doing something (you feel) they shouldn't be doing. Trying to paint it as enabling them is disingenuous. If you want to enable them, you have to work to help them learn good behavior in addition to limiting the bad behaviors.
Hmm, or maybe I didn't understand you or the first poster and that's what you meant. Sorry, I'm a bit confused right now.
Also I wonder how many people ever read this. Most of these things you'll realize sooner or later as it is what really makes you a good and experienced programmer. I'd just suggest to be open minded and think for yourself, but I guess that's a good suggestion for your whole life.
The way I read "become a domain expert" was not really as an expert in, say, Java or .NET, but in an area like web development or game design.
With a less technology-based focus it's easier to avoid One True Paths as you have a better perspective on (and soon a better knowledge of) the alternatives to whatever you happen to be using at the moment. It's also easier to stay knowledgeable when things change.
“There are only two hard problems in Computer Science: cache invalidation and naming things.” – Phil Karlton
The variant mentioning off-by-one errors may be pleasant, and useful for beginners, but is hardly a problem.
When we'll have solved the naming thing we'll be safe.
The rest is just buzz-words and useless noise.
Some seriously hard problems in computer science: distributed programming (consensus, consistency, handling machine failure), parallel programming models, proving correctness of nontrivial programs, P?=NP.
Cmon, P?=NP is cache invalidation? Be serious.
It's not meant to be a literal, pedantically correct statement, it's meant to be an insight, and enough people think that it is that this quote gets repeated. By all means print out your own page in 4-point text of what is and is not a hard problem and stick it on your own wall.
It's not insightful if it leads people to the wrong conclusions. It would be more insightful to impress on people that CS is a large and diverse field with more hard problems than can be reduced to a single pithy saying.
I am curious as to the reasoning here. Why are these 2 the only hard problems in computer science?
On the contrary-- I have seen many beginners struggle for a long time to fully grasp counting starting at 0, which leads to many off-by-one errors.
SAying yes is an implicit delivery promise. You will either break yourself (budget over runs, massive stress) trying to deliver, and/or you fail and your reputation suffers
If you have done it once already and know how much effort it will be - say yes and quote
If you have never done it before, say "I have never done it before" but for a small hourly fee I will implement a prototype. If you like it we can talk full project, but if not, or if I cannot make it work, then I just keep small fee as R&D.
The customer then has more choices / options which is usually appreciated
Dont lie to customers. And saying yes without saying "I've never done i before" is lying.
I've been in high level meetings with business guys before and watched them say "yah, we can do that", knowing we could not. While, in theory, saying yes might be a 'positive step in the right direction', what it usually means is all engineers will be working god-awful hours to get the work done. What is done is then usually sub-par because there wasn't enough time to think about the problems to be solved. Sometimes, code and great architecture come quick. But more often is slow and iterative. Having insane deadlines and workload because someone says yes is just a bad idea all around.
But I would even step back a bit from the computer science aspect for beginners. One thing that was very hard for me was abstraction. When I first tried learning OO programming, it was very frustrating. The problems that people modeled did not make any sense. A car has a wheel which is composed of a tire, etc... I felt like I needed real concepts. I always liked the 'User'. A user has as name, age, height, etc. It can also have multiple addresses. Once you have basic info like this, you can start doing things with or to it. Authentication is a perfect example.
Having a concept (a key) that you understand and can work with and model - like the User example - not only starts you on your way as a programmer, but also provides the bridge to learning other languages. And when I was younger, this is exactly what I did, I brought my 'key' (a User/Person) with me, started small, and built out from there. This was before understanding data structures, algorithms, patterns, etc.
So my ultimate advice (besides staying honest and being able to say no or I don't know) is have a simple 'key' concept you understand inside and out. This can open all the doors later down the road.
It's a lot easier to avoid becoming a zealot when you know what's going on underneath.
Another good platform in the same vein is the BeagleBoard, which is a great way to play with a slightly bigger platform running Linux.
Um...no it's not. And as far as understanding a problem goes, many times you do that by writing code, or don't truly understand it until you do.
Different problems call for different solutions and sometimes just jumping in and coding can be lots of fun but, on the other hand, some projects require a fair amount of problem understanding and planning. If you like to code but you don't enjoy hard problems (the kind that take real research) you eventually reach a ceiling in what you can do.
The way to learn something, is to do it.
Here's Peter Norvig's review of a Python title: http://www.amazon.com/review/R2C7L5KHUVHOR2/ref=cm_cr_rdp_pe...
I recently bought and read Wilson's recent publication, The Architecture of Open Source Applications (http://www.aosabook.org/en/index.html). It focuses more on the architecture design for some well-known programs (Eclipse, Sendmail, Mecurial et al), but does include some code samples. The best aspect of it, IMHO, is that it focuses on the decisions the programmers faced when designing their code, and the tradeoffs they made.
The NoSQL chapter, in particular, is a really good read and should be referred to by all parties before any NoSQL / SQL flamewar begins.
You already know what they're supposed to do, so they'll be a lot easier to figure out at first— and once you do, it will provide the immediate benefit of understanding your tools.
As for how you tell, a good rule of thumb is, the harder of a time you have telling how it works, the worse the code is. This is of course only a rule of thumb, but it applies doubly in the case of code where you understand well what it's supposed to be doing.
On GitHub click on Explore GitHub, Languages, your language, "most forked overall" and choose what interests you.
Or in other words look up popular programs written in the programming language of your choice. Just be sure to not look at code that's too old, as it's more likely that they contain a lot of stuff you wouldn't do anymore. Especially true in the Perl world.
Any correctly written code can probably be considered good. The rest is about how well it is designed and how it performs in different situations.
My point is that as an apprentice you should study the masters. Try and duplicate their work through practice.
Here are a few projects with good Java code: Spring Framework (check mostly around the spring-core stuff), Apache DS, Google Web Toolkit APIs, Google Guava, Google Guice (pretty much almost all Google Java open source projects have similar high-quality).
I agree that things stick better when they're harder. On the other hand, when pairing I learn ways of solving problems that would never occur to me. And it's not like when pairing nothing's hard; I think I have just as many in-the-shower ahas when on a team that pairs.
And post everything to Github (or Google Code, Sourceforge, etc). Having that kind of thing public gives you more of a reason to want to improve.
Simplicity where possible, complexity only where required.
Be a code scientist. Take your theory about the bug, test your theory, then make the fix. Then test the fix.
Don't be satisfied until you really know what's going on.
There's nothing wrong at all with being a domain expert. Most generalists - again, I say this as one - aren't as good at everything as they think.
You won't learn anything anyway, but I have been disturbed when I realized how foolish it was to stick to things, because I knew how to use them. Learning other things usually means that you gain a new perspective making you better overall, even when it comes to stuff you already knew a lot about.
The problem is also that it hinders you to even know about stuff you'd probably be very good at. IMO that's the biggest problems with this suggestion. Sometimes the thing that what looks hard and complicated to you becomes the thing you can't live without and eventually become an expert in. Maybe the 'sometimes' could even be replaced with 'often'.