What is it like to be a programmer for 40 years? A senior who has been a programmer since 1984 came out and said something.
He summed up his nearly 40 years of experience in the industry and compiled 13 suggestions, hoping to provide some help for newbies who want to be programmers for a long time.
As soon as the article was published, it sparked discussions on reddit and Twitter, and many programmers also posted their opinions. Some netizens said: I couldn’t agree more!
Experience sharing from nearly 40 years of code farmers
The programmer is Noah Gibbs, who has worked for NVIDIA, AppFolio Inc, DAQRI and many other companies, and is currently working at Shopify.
As a senior software developer, he has been active in the front line of development. But unlike what he imagined, this time he didn’t introduce what language or framework to learn, but pointed out something he thought was more important than technology. Below is what Noah Gibbs dictated.
1. It is never too late to start
I only started learning to play the piano about a year ago, at the age of 45. I feel like I’ve been improving this year, and I’m sure if I keep at it, I’ll be great by the time I’m 60.
The same goes for learning programming, when you already have some background in some other field, you learn programming very quickly.
Trust me, if you start out as a programmer at 50, 10 years from now, when you’re 60, you’ll be much better than I was at 18.
I’ve met a lot of great programmers who started in their 20’s, 30’s and 40’s, so I don’t know why you can’t start in your 50’s or 60’s. This line of work takes time and work, but you don’t have to be young.
2. Try different types of programming
If you are new to the industry and want to be in the programming industry for a long time, my suggestion is: write more software, any software or anything.
In my 40 years as a programmer, many trends have come and gone. It can be said that it is important to allow yourself to experiment with different types of programming.
This keeps your mind from becoming rigid, and it turns out that almost any rule can teach you something.
If you get too caught up in a single task, you’re likely to fail.
3. Don’t be afraid of slow returns
Don’t feel like what you’re learning is useless, because uselessness is relative.
I used to devote years of my spare time to an old MUD programming language called DGD. It’s certainly not for practical value, as almost everything about it is weird and non-standard, and very few actually apply.
But it taught me a lot, it taught me things that Ruby on Rails would later use, it taught me how to use database programs, and it taught me something that I could use in the 5 or 6 languages I learned later. thing.
Interestingly, I got a consulting job at DGD years later. There aren’t many DGD jobs in the world yet, but I have one! This is more practical than many “practical” languages I’ve learned.
As I often say to myself, “It’s still early.” You can learn more about something interesting or useful, even if it might pay off in ten, twenty, or thirty years.
Don’t always choose something that will be good in 18 months because you can’t foresee what will happen in the future.
4. Find a job that appeals to you
You must have started programming because something about it appealed to you, and what you have to do is try to figure out what that is.
This answer is different for everyone, for me, I like the sense of accomplishment and intelligence that programming brings me.
Only when you find enough points in your work to attract you can you stick to it for a long time.
If you don’t feel any attraction, then you may need to take a vacation or rediscover what you love, as work like this will only drain you.
5. It’s not a sprint or a marathon, it’s journaling
If you are a novice, it is likely that after making up your mind “I want to become a programmer”, you have listed a detailed plan, which may include 8 big points, 56 small points, and so on.
I won’t tell you not to get so excited, but I will say: don’t take this plan too seriously. Because you can’t do everything by calculation and planning.
At some point, you’re not “off your mission”, you’re just “living your life.” It’s not failure, it’s not giving up.
You can’t predict what’s valuable, so you should learn everything. My experience is: the longer you live and the better you work, the more you realize that everything (everyone) can teach you something useful.
You are not running a sprint or a marathon. Instead, it’s like writing a diary.
Ten years from now, you’re going to look at this diary and say, “Wow, I did some cool stuff” or “Well, I’m a funny guy,” but I don’t think you’d write in it “I’m very good at Java”.
6. Don’t confuse work and career
Don’t confuse job and career, they are not the same thing.
Writing software is a great job for me, but it’s just an okay or better career.
When accepting advice from others, also pay attention to whether the other person mentions advice about the job or about the career. If you confuse the two, the advice won’t make much sense.
7. The order of study doesn’t matter
When you’re just getting started, you tend to get different advice on what language or technology to learn first, but it doesn’t really matter.
If you forge your own path instead of following the old rules, that doesn’t mean you haven’t done the groundwork, and it doesn’t mean you’re bad.
Because if something is really important, sooner or later you will find out and relearn it.
8. The better you are, the more different you are from others
Early career training for programmers (e.g. blog posts, college courses, books) is like an assembly line, trying to develop your basic skills in every area.
And it’s easy for a novice to mistakenly think that a lead engineer needs a lot of skills, and each skill must be high, but that’s not the case.
You can get respect by writing a fairly simple piece of code and describing it in detail, like Patrick McKenzie did in Bingo Card Creator, or by writing something really profitable.
Aside from basic abilities, these paths have almost nothing in common.
That’s why it’s stupid to ask questions like, “I’m a software engineer with 15 years of experience, what’s the typical salary?”
Fifteen years is such a long time that you should have developed an edge over everyone else. Have you ever written a book? Have you worked on a large, profitable project? Have you put together an interesting open source project? What have you done in these 15 years?
Of course, it’s not just about wages. You can ask, “I’m a software engineer with 15 years of experience, which means I’m qualified to lead this project, right?” The answer, of course, is “maybe.” The next question is “So what have you done in 15 years?”
9. Learn by doing
I wouldn’t advise people to learn the deep principles of software design in the first place, because if you try to learn them as pure theory, you will almost certainly do it wrong.
For beginners, first learn to build a usable software in some actual language. No matter the language, you can only solve problems in mistakes if you make some real mistakes.
Then you can loop back like this: practice, make mistakes, learn theory, and fix mistakes.
Of course, that doesn’t mean that if you learn the theory first, you’ll be worse forever, it just takes a while to properly use what you’ve learned.
10. What technology is used is important
If you want to be a programmer for decades, then you have to learn not only a variety of technical but also a variety of non-technical skills.
For example, “learning at least one functional design language” is as necessary as “learning to play Mozart” as a pianist, but at the same time, learning some of the fringe techniques involved in programming will develop for you Extra insight.
11. Learn from other fields
What does that mean if our industry is still young? It means we’re still working on the fundamentals.
You can learn a lot from other fields. I once wrote a book on how to steal the way artists practice, precisely because art and music are ancient disciplines that have been ahead of computers for thousands of years.
So, if you have a problem, you can think about how people in other fields would handle it.
For example, Atul Gawande’s Checklist Manifesto describes the very different ways in which pilots, skyscraper builders, and doctors approach problems, and these are all good approaches.
12. Don’t reinvent the wheel
As we all know, if an artist repeatedly draws a still life and a musician repeats a piece of music, they will become more and more proficient, but programmers are different.
There’s a saying among programmers that “don’t reinvent the wheel”, our job is to figure out how to get the computer to do all the rework so we can just do new stuff.
You can try to reinvent the wheel, you can write code in a “bad” way on purpose and see what happens. All in all, you need to be really good at something unusual.
13. Just do it
I’ve been recommending non-technical advice to everyone, rather than forums full of tech nerds with the paranoid enthusiasm of recent programmers.
If you write programs, you are a programmer, or a software engineer, or whatever you want to call it.
As long as you keep writing, you can keep being a programmer, no matter how many years. Anyway, if you stick with it, you’re eligible and that’s all that matters.
source: