Ask HN: How do fairly experienced senior engineers learn? | Hacker News Reader

Ask HN: How do fairly experienced senior engineers learn?

10 pointsyi_xuan7 comments

Due to the rapid development of the industry, there are something you need to learn almost every year. Novices usually prefer learning through videos. As they gain more experience, they begin delving into the source code of other projects and reading some office doc, which is the phase I am currently in. But I still like to watch the instructional video when learning new techs, I also read office doc though. I have heard from some more experienced individuals that they only rely on office doc, but I somewhat skeptical. Will you watch those 'beginner instructional videos' when learning new? Or office doc is just enough.

Additionally, I've noticed that some users with high reputations on stackoverflow only answer questions and never asked questions. I wonder if these high-rank players no longer need help or are capable of solving all problems on their own?

View on HN

I'll take "engineers" out of your question and answer it as I've done personally as I become more experienced, and as I've watched other experienced people learn

"Fairly senior experienced" people learn in a variety of ways ... but mostly we learn via diffs

In other words, we have a baseline of knowledge, and we're looking for what has changed / is new / is different

This can come from videos, books, papers, blog posts, one-on-one examples, seminars, conferences, etc

The best folks then take what they think they have learned, synthesize it into a teachable format, and teach others[0] the "new" thing (crystallizing it in our own minds)

In the world of programming, there are basically 3 broad types of development: object-oriented, functional, and procedural

If you know one procedural language, picking-up another (or a new framework for that language, or the new version of language) is going to be pretty trivial

Likewise, if you know one object-oriented language language, learning another is pretty straightforward

And the same for functional languages

I made the jump from procedural to object-oriented as a teen in the 90s. Encapsulation kinda broke my brain for a few weeks, but once it clicked, I had added a new way to think to my mind.

I learned PHP (...4? I think?) back in 2004 by reading the manual pages on php.net over the course of a couple weeks.

I learned [enough] Java 1.3 & 1.4 the same way the same summer to update a bunch of Java 1.1 and 1.2 applets to a newer version

I do not do a lot of "programming" any more - it's more scripting, tool-specific search language, etc ... but what I learned over the last ~30 years has enabled me to pick up the Next Big Thing™ with [relative] ease

-----------

[0] https://www.electronicdesign.com/technologies/dsps/article/2...

1. I look for a paid course where possible. If someone is taking your money, they make a commitment to teach you. As with salaries, people will charge more when they can get away with it. Think of the ROI - that $100 course will likely increase your TC by more than $100 within the same year. Many free courses do not make that commitment. About 90% of the free ones are incomplete in some way. Plenty of free courses are just a form of marketing for freelancers and job applicants.

2. Apply the knowledge. Al-Ghazali said that knowledge without practice is useless. One can have ten sharp swords and know how to wield them, but it's wasted resources unless used in battle. You can learn something abstract like functional programming, but it's only useful when you start thinking about how to apply it to your work. Maybe it lets you write better functions or easier to understand code, even if you're not adopting the whole paradigm.

3. "I wonder if these high-rank players no longer need help or are capable of solving all problems on their own?"

Get used to reading primary sources. Invest time in learning to navigate docs. ChatGPT is awesome for this. It's there to help you find the right terms, tools, or methods, but you should refer to the primary docs, not the AI response. You can even use ChatGPT to decipher the docs if you're not used to it.

4. With new tech, e.g. AI, web3, blockchain, frameworks there's usually this mental block that comes from fear/hesitance. Figure out how to get rid of that block first before trying to tackle the material. Otherwise you'll be expending lots of energy against your own mind.

5. Learn the hard things early in the day. Major things have an energy threshold. Some people will practice easy things early, like increasing typing speed or Duolingo. You shouldn't eat the frog first thing of the day, but learn to warm up as quickly as possible. Also allocate a little time to figure out your top priority to spend energy on the next day.

I recently passed the ITIL4 certification. It was totally new to me. What i did, was reading the book, then watched the provided videos of my company and finally passed the exam. My biggest help was my experience working in the IT and different companies so i understood the concepts better. I skipped some chapters, went back to them later after getting the bigger picture. Then i started from the beginning of the book and made my own conclusions about the topics, i tried to explain it to a person never have heard that before, in my mind. That helped to prove if i got it all right. Always try to explain it in your words to another person, in your mind or to a friend.

Experienced senior engineers understand that very little actually changes in the world of software. We get endless variations on the same tools and techniques.

Once you realize that Python and Ruby and Javascript (for example) have far more in common than not, and the differences are mainly cosmetic and tooling, you don’t need the long learning time a novice does.

I don't keep up on things I don't use, knowing that if I need to use it I can get to the GetThingsDone mode in a short time frame. I know I won't be an expert and nuanced things will not be apparent early on. Changing languages, frameworks, libraries or infrastructure types of things doesn't happen very often though.

Even newer cloud infrastructure things rely on HTTP verb based API's and lots of JSON with configs in YAML files. So if I was to learn a new cloud based thing, I would watch videos on how the overall process works, then install the necessary stack to begin tinkering and start doing stuff. Maybe read up on some ways people are using the thing to help understand how it fits into my set of problems it could solve.

Experienced engineers learn by doing.

No one can keep up with everything, and no one needs to. You focus on the tools that get the job done for you and master those tools. I have got a lot of mileage out of understanding Unix/Linux (dating to the late '70s) and relational databases (introduced in the early '80s). Almost all modern languages derive from C and use C libraries. All of the web sits on top of a few protocols like HTTP. Despite appearances and hype the actual pace of meaningful innovation in the software world seems glacial compared to computer hardware.

Learning the foundational skills pays off, because new and novel things will almost always have those fundamentals at their core. We don't perceive the new car models introduced every year as radical or fundamentally different from the cars we drove last year -- if you can drive a car you can easily learn to drive almost any other car in a few minutes. That holds for programming/software tech skills too, though it does take more than a few minutes to learn a new language.

Myself, for a completely new topic, review Wikipedia. If I can find a 'Hello World' example, I do that. I then find a book.

If it is something I know a little about, enough to be dangerous, but struggle applying. I look for a step-by-step guide.

Now if I know an expert on the topic, I will then go talk with them to fill in the gaps.

Following on 'gregjor's comment, I knew a person who learned C programing by reading the appendix of the classic C book. He just read the BNF grammar and was good to go.

Reply on news.ycombinator.com