What is the experience of being a programmer for 40 years?
A programmer who has been in the industry 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 be programmers in the long term.
As soon as the article was published, it sparked discussions on Reddit and Twitter, with many programmers agreeing and expressing their support.
Come and see what kind of valuable insights he has shared.
Insights from a programmer with nearly 40 years of experience
This programmer, Noah Gibbs, 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 language or framework to learn, but pointed out some things that he believes are more important than technology.
(The following is Noah Gibbs' narrative)
- It's never too late to start at any age
About a year ago, when I was 45, 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 great 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 the age of 50, 10 years later, when you are 60, you will definitely be much better than my level at 18.
I have met many excellent programmers who started their careers at the age of 20, 30, or even 40, 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 more software, any software, it doesn't matter what.
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 can keep your mind flexible, and the fact is that almost any rule can teach you something.
If you are too fixated on a single 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 years of my spare time on an old MUD programming language called DGD. It was not for practical value, because almost everything about it was strange and non-standard, and there were few real-world applications.
But it taught me a lot. It taught me things that later applied to Ruby on Rails, taught me how to program databases, and taught me things that I could use in the 5 or 6 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 is more practical than many "practical" languages I have learned.
As I often say to myself, "It's still early." You can learn something interesting or useful, even if it may not pay off for ten, twenty, or thirty years.
Don't always choose something that will improve in 18 months, because you can't predict what the future holds.
- Find what attracts you in your work
You started coding because something about it attracted you, and what you need to do is 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 me.
Only by finding something that attracts you enough 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 drain 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 up your mind to "become a programmer," you will make a detailed plan, which may include 8 major points, 56 minor points, and so on.
I won't tell you not to be so excited, but I will say: don't take this plan too seriously. Because you can't accomplish everything through calculation and planning.
At some point, you are not "deviating from your set tasks," you are just "living your life." This is not a failure, nor is it 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 "I'm very good at Java" in your diary.
- 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 a decent or potentially better career.
When accepting advice from others, also pay attention to whether they are talking about work or career. If you confuse the two, the advice may not be very meaningful.
- The order of learning is not important
When you are just starting out, you often 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 path, it doesn't mean that you haven't laid a solid 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 cultivate your basic abilities in every aspect.
And beginners often mistakenly think that a chief engineer needs to excel in many skills, and each skill must be at a high level, but that's not the case.
You can gain respect by writing a fairly simple piece of 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 abilities, these paths have almost nothing in common.
That's why it's foolish to ask questions like, "I'm a software engineer with 15 years of experience, what is the usual salary?"
15 years is a long time, and by then, you should have developed unique advantages compared to others. Have you written a book? Have you worked on a large profitable 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, "I'm a software engineer with 15 years of experience, does that mean I have the ability to lead this project?" The answer is probably "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 do it wrong.
For beginners, the first thing to learn is to build usable software using a practical language. Regardless of the language, you need to make real mistakes to solve problems.
Then you can cycle like this: practice, make mistakes, learn theory, correct mistakes.
Of course, it doesn't mean that if you learn theory first, you will always be worse off, but it takes time to correctly 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 not only learn 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." At the same time, learning peripheral technologies involved in programming can cultivate additional insights.
- Learn from other fields
If our industry is still young, what does that mean? It means we are still studying the basic 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 very different ways pilots, skyscraper builders, and doctors deal with problems, and these are 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 proficient. 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 all the repetitive work so that we can focus on new work.
You can try to reinvent the wheel, intentionally write code in a "bad" way, and 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 geeks, where people who have recently switched to programming have a paranoid enthusiasm.
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 be a programmer for as long as you want, no matter how many years. Anyway, if you persist, you are qualified, and that's what matters most.
After reading this, do you have a new understanding of the programming industry?