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.
> Don't become a domain expert, as advised, and then convince one's self that that domain is The One True Path
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.
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.
Naming things is a hard part of programming, but that doesn't make it a computer science problem. Computers can't name things for us. To solve the naming thing would be to solve the thinking thing.
> My only advice, to all programmers, is to print the following and stick it in a place where you can see it everyday: “There are only two hard problems in Computer Science: cache invalidation and naming things.” – Phil Karlton
I am curious as to the reasoning here. Why are these 2 the only hard problems in computer science?
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 totally agree - saying NO is one of the best things you can do. And also "I don't know" is ok as well.
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.
I would also recommend learning at least the basics of lower levels of computing technology, e.g. some CPU architecture and some assembly or low level C.
It's a lot easier to avoid becoming a zealot when you know what's going on underneath.
Do you know any good resources to study this sort of thing from? (any summer programs?) I am a young developer and have been meaning to learn this sort of thing for a while.
Some good advice in this article. The most valuable thing I've picked up as a young programmer is the importance of finding your own learning style. Some people read books, some watch podcasts, some can just read the documentation and go. I've found that browsing example source code in the language/framework I'm using (with some light documentation reading) does well for me. It may take you too long to learn the skills, languages, or frameworks required by your post-graduation employer if you never took the time to find the best way to teach yourself.
This advice is mostly not harmful, but the most important thing a newbie programmer can do is actually just code. Just sit down and write some code. That's it.
I kinda hate this mindset. Programming is not about how much code you write, it's about understanding a problem and then coming up with a solution; writing code is but a small part of this process. If there is anything I have learned over the years it is that one should think first then code.
The 'path' seems to be of a solid programmer/consultant. If you are going to work in a team then I would add 'improving teamwork skills'. This mainly involves respecting others in the team and focusing on team's success. These things go a long way and you will get a chance to work with developers in different areas of the company and contribute towards interesting projects.
I like this article, probably because I do as outlined in it - but I also wonder how this (or the first advice particulary) is applied to pair programming? Seing someone else solve an interesting problem over his/her shoulder while discussing it endlessly will never quite stick as when you think about a problem for days and then come up with a solution for yourself.
Pair programming should not involve watching somebody else solve a problem. A good pair programmer knows how to involve even junior colleagues in the hunt for a solution.
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.
I think the main piece of advice is number 2. Make lots of small throw-away programs. Whether these little junk programs are good or bad doesn't matter - you will be learning something either way.
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.
I think his Point #5 should say "knock something OUT", not "knock something UP". If someone asks you to knock something up, you should probably ask your wife for permission first.
The author actually mentions "Bare[sic] in mind that there are multiple paths to becoming a programmer, and this is just my way of being a programmer."
I don't think seven "Become a domain expert" is a good idea and especially not something you should recommend. If yo really find the right thing you'll know, but it is very good to know a lot about everything.
The problem with that - and I say this as a generalist myself - is that usually you don't know a lot about everything. You think you do, but it turns out you don't. For instance, I've known "a lot" about web development. Now I have a new job that exposes me to domain experts in web development - and it turns out I didn't know jack.
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.
[+] [-] crikli|14 years ago|reply
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.
[+] [-] LiveTheDream|14 years ago|reply
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.
[+] [-] j_baker|14 years ago|reply
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.
[+] [-] Rusky|14 years ago|reply
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.
[+] [-] keiferski|14 years ago|reply
[+] [-] nakkiel|14 years ago|reply
“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.
[+] [-] haberman|14 years ago|reply
Some seriously hard problems in computer science: distributed programming (consensus, consistency, handling machine failure), parallel programming models, proving correctness of nontrivial programs, P?=NP.
[+] [-] gruseom|14 years ago|reply
[+] [-] shadowfox|14 years ago|reply
I am curious as to the reasoning here. Why are these 2 the only hard problems in computer science?
[+] [-] carols10cents|14 years ago|reply
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.
[+] [-] lifeisstillgood|14 years ago|reply
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.
[+] [-] equalarrow|14 years ago|reply
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.
[+] [-] zwieback|14 years ago|reply
It's a lot easier to avoid becoming a zealot when you know what's going on underneath.
[+] [-] conradev|14 years ago|reply
[+] [-] RegEx|14 years ago|reply
[+] [-] mtogo|14 years ago|reply
[+] [-] jimmyjazz14|14 years ago|reply
[+] [-] console|14 years ago|reply
[+] [-] sayrer|14 years ago|reply
Here's Peter Norvig's review of a Python title: http://www.amazon.com/review/R2C7L5KHUVHOR2/ref=cm_cr_rdp_pe...
[+] [-] sshah|14 years ago|reply
[+] [-] peterb|14 years ago|reply
[+] [-] ThePawnBreak|14 years ago|reply
[+] [-] defdac|14 years ago|reply
[+] [-] wpietri|14 years ago|reply
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.
[+] [-] thesmartace|14 years ago|reply
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.
[+] [-] xsmasher|14 years ago|reply
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.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] apetresc|14 years ago|reply
[+] [-] robgough|14 years ago|reply
[+] [-] known|14 years ago|reply
[+] [-] LiveTheDream|14 years ago|reply
[+] [-] tete|14 years ago|reply
[+] [-] grammaton|14 years ago|reply
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.
[+] [-] unknown|14 years ago|reply
[deleted]