31–40 of 178 posts
And the two aspects are certainly not mutually exclusive, and by that I mean: being a good programmer does not necessarily translate into being a successful programmer. The reverse is true too.
IMHO, to nurture a lasting career as a "programmer", you have to balance the two aspects. Be good and successful.
I think that a big part of it is the quality of work you get. If you work on business apps that aren't very well appreciated and most of your time is spent maintaining projects where the decisions were already made, you're never going to get to that level. A couple scut projects early in your career can teach you things about maintenance and just why code quality is so important, but eventually, you need to graduate…
An addition to your proposition that you needs make your decisions in order to improve: You also need to actively learn from your failures. Many people just go like "That sucks, it did not work out" without ever asking the Why. That's not enough to learn, and one could even learn the wrong lesson from a failure.
> I'm trying to understand what exactly they did from everybody else that set them apart. Because I'm one of the success stories, I'm in a position to answer. A successful programmer is not just a programmer, he is also a personal representative, a salesman and a contract negotiator. I originally wrote what became Apple Writer ( http://en.wikipedia.org/wiki/Apple_Writer ) because I was writing a technical magazine ar…
Break down what "success" means for you, then figure out how to achieve the really important parts of that formula. For example, my cursory read of your list of programming success stories plus "they've made a difference, they're well known and respected" suggests that you might care about your status among geeks in particular. There's nothing wrong with that, but it would counsel very different career moves than if…
Pardon me for asking, what are your programming achievements, besides writing a long-length comments and blog posts?) Where could we see your code?
Or, so I think.
That's also one of the reasons why I don't like the title 'programmer' as opposed to something like 'software engineer'.
I am not talking about Linus Torvalds, Larry Walls etc of the world. But I am going to talk about other developers who often make it big. I am talking of people who solve difficult problems, add value and make money. Great folks I've met are high on productivity, they are quick in discovering things and generally maintain an aura of self confidence around them. Many of them start off because they a 'lucky break' some…
> When we are talking of successful guys out there. We are ideally talking of guys who are >40 now. I know a relative of mine highly successful 40+ guy. I like your post and this isn't meant as criticism, but ... could we not say "guy" so much? Women are often terrific programmers, and there should be more of them. But that goal is thwarted by a certain common assumption about who programmers are.
> A successful programmer is not just a programmer, he is also a personal representative, a salesman and a contract negotiator.
(Excellent==Successful. Money & fame are more difficult to control.)
1. Choose a small subset of available technology, learn it intimately, and embrace it. Then evolve that subset.
2. Understand the pros and cons of various data structures, both in memory and on disk.
3. Understand the pros and cons of various algorithms.
4. Understand your domain. Get away from your computer and do what your users do.
5. Be ready, willing, & able to deep dive multiple levels at any time. You must know what's going on under the hood. There is a strong correlation between "number of levels of deepness understood" and "programming prowess".
6. Use your imagination. Always be asking, "Is there a better way?" Think outside the quadralateral. The best solution may be one that's never been taken.
7. Good programmer: I optimize code. Better programmer: I structure data. Best programmer: What's the difference?
8. Structure your data properly. Any shortcomings there will cause endless techincal debt in your code.
9. Name things properly. Use "Verb-Adjective-Noun" for routines and functions. Variables should be long enough, short enough, and meaningful. If another programmer cannot understand your code, you haven't made it clear enough. In most cases, coding for the next programmer is more important than coding for the environment.
10. Decouple analysis from programming. They are not the same thing, require different personal resources, and should be done at different times and places. If you do both at the same time, you do neither well. (I like to conduct analysis without technology at the end of the day and start the next morning programming.)
11. Never use early exits. Never deploy the same code twice. Never name a variable a subset of another variable. You may not understand these rules and you may even want to debate them. But once you start doing them, it will force you to properly structure your code. These things are all crutches whose use causes junior programmers to remain junior.
12. Learn how to benchmark. Amazing what else you'll learn.
13. Learn the difference between a detail (doesn't really make that much difference) and an issue (can end the world). Focus only on issues.
14. Engage your user/customer/managers. Help them identify their "what". Their "how" is not nearly as important.
15. Write a framework, whether you ever plan to use it or not. You'll learn things you'll never learn any other way.
16. Teach others what you know, either in person or in writing. You'll accidently end up teaching yourself, too.
17. Always tell your customer/user "yes", even if you're not sure. 90% of the time, you'll find a way to do it. 10% of the time, you'll go back and apologize. Small price to pay for major personal growth.
18. Find someone else's code that does amazing things but is unintelligible. Refactor it. Then throw it away and promise yourself to never make the same mistakes they made. (You'll find plenty.)
19. Data always > theory or opinions. Learn the data by building stuff.
20. At some point, run your own business (service or product). You will learn things about programming that you'll never learn as an employee.
21. If you don't love your job, find another one.
They got lucky - they picked the right career and made the right choice enough times to still enjoy what they do decades later.
This is partly true, but mostly unhelpful.
There is nothing you can do that will make you remain interested and excited and passionate about something for decades.
How to be an Excellent Programmer for Many Years (Excellent==Successful. Money & fame are more difficult to control.) 1. Choose a small subset of available technology, learn it intimately, and embrace it. Then evolve that subset. 2. Understand the pros and cons of various data structures, both in memory and on disk. 3. Understand the pros and cons of various algorithms. 4. Understand your domain. Get away from your c…
I have found that you get higher marks for saying NO in the right occasions than being known as the one that always says YES.