What is the experience of being a programmer for 40 years?
A senior programmer who has been in the field since 1984 has come forward to share his experience.
He has summarized his nearly 40 years of experience into 13 pieces of advice, hoping to provide some help to newcomers who want to pursue a long-term career as programmers.
As soon as the article was published, it sparked discussions on Reddit and Twitter, with many programmers agreeing and expressing their support.
Hurry up and take a look at what valuable insights he has shared.
Insights from a programmer with nearly 40 years of experience
This senior programmer is named Noah Gibbs and has worked for companies such as NVIDIA, AppFolio Inc, DAQRI, and is currently employed at Shopify.
As a seasoned software developer, he has always been active in the field of development.
However, contrary to expectations, this time he did not introduce what languages or frameworks to learn, but pointed out some things that he believes are more important than technical skills.
(The following is Noah Gibbs' narrative)
- It's never too late to start at any age
About a year ago, when I was 45 years old, I started learning to play the piano. In this year, I feel that I have been making progress, and I believe that if I continue, I will be excellent by the time I'm 60.
Learning programming is the same. When you already have a background in other fields, learning programming becomes faster.
Believe me, if you start programming at 50, in 10 years, when you're 60, you will definitely be much better than my level at 18.
I have met many excellent programmers who started in their 20s, 30s, or even 40s, so I don't know why you can't start at 50 or 60. This field requires time and work, but you don't have to be young.
- Try different types of programming
If you are just starting out and want to pursue a long-term career in programming, my advice is to write different types of software, anything will do.
In my 40 years as a programmer, many trends have come and gone. It is important to expose yourself to different types of programming.
This will prevent your thinking from becoming rigid, and in fact, almost any type of programming can teach you something.
If you are too fixated on a specific task, you are likely to fail.
- Don't be afraid of slow returns
Don't think that what you are learning is useless because usefulness is relative.
I once spent many years of my spare time learning an old MUD programming language called DGD. It was not for practical value because almost everything about it was strange and non-standard, with very few practical applications.
But it taught me a lot. It taught me things that I later applied to Ruby on Rails, how to use database programming, and things that I could use in the 5 or 6 other languages I learned later.
Interestingly, many years later, I found a consulting job related to DGD. There aren't many DGD jobs in the world, but I got one! It turned out to be more practical than many "practical" languages I learned.
As I often say to myself, "It's still early." You can learn interesting or useful things, even if the returns may not come until ten, twenty, or thirty years later.
Don't always choose something that will improve in 18 months because you cannot predict what the future holds.
- Find what attracts you in your work
You started coding because something about it attracted you. Your task is to figure out what that is.
The answer is different for everyone. For me, I enjoy the sense of achievement and the feeling of being smart that coding brings.
Only by finding enough attraction in your work can you persist in the long run.
If you don't feel any attraction, you may need to take a break or find something you love because a job like this will only exhaust you.
- It's not a sprint or a marathon, it's like writing a diary
If you are a beginner, it is likely that after making the decision "I want to become a programmer," you will create a detailed plan with 8 major points and 56 minor points, and so on.
I won't tell you not to be excited, but I will say: don't take this plan too seriously. Because you cannot accomplish everything through calculation and planning.
At certain times, you are not "deviating from your set tasks," you are simply "living your life." This is not a failure or giving up.
You cannot predict what is valuable, so you should learn everything. My experience is that the longer you live and work, the more you realize that everything (and everyone) can teach you something useful.
You are not running a sprint or a marathon. Instead, it's like writing a diary.
Ten years later, you will look back at this diary and say, "Wow, I did some cool things" or "Hmm, I'm an interesting person." But I don't think you will write in your diary, "I am very good at Java."
- Don't confuse work and career
Don't confuse work and career, they are not the same thing.
For me, writing software is a great job, but it's just an okay or potentially better career.
When accepting advice from others, pay attention to whether they are talking about work or career. If you mix the two, the advice won't be very meaningful.
- The order of learning is not important
When you are just starting out, you may receive different advice on what language or technology to learn first, but it doesn't really matter.
If you don't follow the conventional path and create your own, it doesn't mean you haven't laid a good foundation or that you are terrible.
Because if something is really important, you will eventually discover it and learn it again.
- The better you are, the more different you are from others
Early career training for programmers (such as blog articles, university courses, books) is like an assembly line, trying to develop your basic skills in every aspect.
And beginners often mistakenly believe that a senior engineer needs to excel in many skills, with high proficiency in each skill, but that's not true.
You can gain respect by writing a relatively simple code and describing it in detail, just like what Patrick McKenzie did in "Bingo Card Creator," or by creating something truly profitable.
Apart from basic skills, these paths have almost nothing in common.
That's why it's foolish to ask questions like, "I have 15 years of experience as a software engineer, what is the usual salary?" 15 years is a long time, and by then, you should have developed unique advantages. Have you written a book? Have you worked on a profitable large-scale project? Have you integrated an interesting open-source project? What have you done in these 15 years?
Of course, it's not just about salary. You can ask, "As a software engineer with 15 years of experience, does that mean I have the ability to lead this project?" The answer is likely "maybe." The next question is, "What have you done in these 15 years?"
- Learn from practice
I wouldn't advise people to start by learning the deep principles of software design because if you try to learn them purely as theory, you will almost certainly make mistakes.
For beginners, the first step is to learn how to build usable software using a practical language. It doesn't matter which language, but you need to make real mistakes to solve problems.
Then you can cycle through this process: practice, make mistakes, learn theory, correct mistakes.
Of course, this doesn't mean that if you learn theory first, you will always be worse off. It just takes time to properly apply the knowledge you have learned.
- What technology you use is important
If you want to be in the programming field for decades, you need to learn not only various technologies but also various non-technical skills.
For example, "learning at least one functional programming language" is as necessary as a pianist "learning to play Mozart's piano pieces." However, at the same time, learning peripheral technologies involved in programming will cultivate additional insights.
- Learn from other fields
If our industry is still young, what does that mean? It means we are still studying the fundamental principles.
You can learn a lot from other fields. I once wrote a book about how to steal the practice methods of artists because art and music are ancient disciplines that have been ahead of computer development for thousands of years.
So, if you encounter a problem, you can consider how people in other fields would handle it.
For example, Atul Gawande's "The Checklist Manifesto" talks about the different ways pilots, skyscraper builders, and doctors approach problems, which are all good methods to learn from.
- Don't reinvent the wheel
It is well known that if an artist repeatedly draws a still life or a musician practices a piece of music, they will become more skilled. But it's different for programmers.
There is a saying among programmers, "Don't reinvent the wheel." Our job is to find ways to make computers do repetitive work so that we can focus on new work.
You can try reinventing the wheel or intentionally write code in a "bad" way to see what happens. In short, you need to be really good at something unusual.
- Just do it
I have been recommending advice from non-technical fields rather than forums filled with tech enthusiasts, where there is an obsessive passion from people who recently switched to programming.
If you write code, you are a programmer, or a software engineer, or whatever you want to call it.
As long as you keep writing, you can continue to be a programmer for as many years as you want. Regardless, if you persist, you are qualified, and that is the most important thing.
So, after reading this, do you have a new understanding of the programming industry?