[vinay_ys]

Couple of important lessons that will keep you in good stead for a long time:

1. Learn how to learn well, continuously, and sustainably. Tech changes rapidly. And you will want to hop from one domain to another, just for keeping things interesting and to move with markets. This is both a blessing and a curse. It is a blessing because you can start late and still be in the top percentile if you have the brains and work hard for it. It is a curse because you will be doing this no matter how many years of experience you have.

2. Hone your non-technical skills– caution: these are compounding over time (both good and bad habits) – being disciplined, thinking clearly, articulating clearly, being professional, being trustworthy, managing your physical and mental health, being dependable/reliable, having a growth mindset, thriving in ambiguity and uncertainty etc. then, honing your communication skills – effectively collaborating with people, give/receive effective feedback, do/get mentoring/coaching, working with cross-functional people, working with very seniors, very juniors, peers etc. read a lot, develop mental models, deeply craft your personal approach to first principles problem solving, to making tradeoffs/bets etc.

You can do the above all by yourself, through reading, and observing people from afar, and engaging with people (even strangers on forum like this one) in dialog.

[McScrooge]

I've been in a similar position of having to learn solo for 10+ years and lesson #2 above has been FAR more important than #1 in my experience. Clients and bosses care much more about communication, dependability, etc. than whether a product has been coded elegantly via best practices.

[Gokevin]

Agree;

[underdeserver]

I would argue that articulating clearly is not a non-technical skill, it's the essence of what software engineers do.

[shafyy]

There is a big difference between articulating "code" clearly and articulating clearly when you speak / write to other humans.

[otikik]

I can see some differences, but none of them seem "big".

In code you don't have all the extra communication avenues that we have when speaking, like body language, intonation, sarcasm and so on.

On the other hand, when writing code we are not speaking in real time. We can think about a problem for a while, consider the best possible way to solve a problem and how to explain it.

What do you see as a big difference?

[Kabootit]

1) Coding clearing in the moment vs (2) coding clearly for future selves is two different mindsets/contexts right there.

(3) Communicating clearly is an orthogonal skill to coding clearly. I think this skill is barely acknowledged in engineering cultures in comparison to the above.

I feel you have to have an engineering culture that values institutional knowledge retention, team education and growth — and not treating engineers as fungible — to get to level (2). Level (3) would be a great place to work.

[Kinrany]

Code is written for other humans

[shafyy]

Ideally, yes. And I agree that there's some correlation of how well clearly people can write prose and write code. But, articulating yourself with your teammates is not only about writing well. It's also about saying the right things. I have seen many engineers that write code well, can write a paragraph in English well, but just don't communicate enough and don't communicate the right things at the right time etc.

[heeton]

I agree. Writing well is _highly_ technical.

[jerjerjer]

For 2, I'll single out the skill of tailoring technical explanations to your counterparty's level of understanding and technical knowledge. The ability to explain to less technical people what your new project/feature does without going into too many unnecessary details and without being too high-level is invaluable. It builds confidence in your work for them (I know what this thing is doing - maybe not all nuts and bolts, but enough to operate with confidence) and in you as a professional (this guy clearly understands what he's working on and does not try to bury me in jargon or oversimplify things).

[_kb]

This exact scenario is one of the best interview questions I’ve been asked and have repeatedly re-used when on panels myself.

Taking a complex domain and effectively communicating it (correctly) at different levels requires having not just rote knowledge but an actual understanding.

[newfocogi]

How do you learn how to learn well?

[wruza]

I tell myself to not adhd it and instead take time and read through a whole manual, experiment in a local sandbox, grasp the limits of knowledge and features and also where it gets deep.

Then in a regular work I explicitly detect where it pays off and feel “see I told you”. This creates a motivational loop to continue not-adhd-ing through tech.

Sometimes I still fly over the knowledge, but then may note that what I’ve been doing in a complex way could be solved with one parameter, if only I knew about it. This creates negative feedback against flying over.

This is ofc only one facet of learning, but I find this “see I told you” method very effective, cause my main issue with learning is unwillingness to learn for no clear reason.

[Insanity]

My issue with this method of learning is… deadlines. During work time, I often feel that I need to solve something “quick”, which then leads me to usually learn and really deep dive outside of regular work hours instead.

Now, I mostly actually enjoy doing this and thus it has not really limited me. But I wish I could just spend some actual work time on more ‘non adhd-ing’ what I learn.

[mathgeek]

Have you chatted with your manager about expectations and your personal growth goals?

[wruza]

Yeah, deadlines suck. Historically I managed to "manage the management" into a reasonable rush/cook balance most of the time, which allows for healthy exploration, but that is absolutely "ymmw" thing.

[markus_zhang]

I love the manual method and occasionally used it. Basically assuming there is no Internet, just a book and a repo of source code and try to figure out how to do something.

Sadly I'm now so easily burnout that even setting a dev env up can burn me out.

[christoff12]

The key is to figure out what your learning process looks like.

For example, I discovered early on that I learn in three phases: 1. I get exposed to something (a concept, a process, etc); basically discover that something exists. 2. I then see how that thing is used whether through mentorship or tutorials or, increasingly, through trial and error. 3. I apply that thing to some novel problem.

Through this cycle of Discovery-Tutelage-Application, I can assess my level of comfort with new material and understand when my struggles are due to trying to short circuit the process.

It's likely that you have some form of learning process that is equally cyclical, yet undefined -- once you identify and codify those steps, you can evaluate your progress when it comes to acquiring new skills.

[theonething]

Dr. Barbara Oakly is pretty renowned in this area of study and has a free online class.

https://www.coursera.org/learn/learning-how-to-learn

[emusan]

This is a difficult question to prescribe an answer for that works for everyone, but the best I personally can think of is "practice".

To make that more actionable... My approach in life has generally been to find a project (even something seemingly incredibly dumb, as long as it is fun), then work through it, learning what I need to know as I go along. To learn "well", you must then also constantly question what you have done as you complete various stages of the project to see if you have done them as effectively as possible, and try to incorporate any lessons learned into future projects.

I have found that how individuals do the learning required for this differs significantly from person to person, so it is hard to recommend any particular approach.

[zer0x4d]

You learn to learn with time and imo it's different slightly from field to field. In tech field you just learn by doing, asking questions, making mistakes and gaining experience. Take a sample code in a new language, make it do something slightly different. Then add one more thing on top. Then something slightly more complex, then finally try to make it do what you want. Once ready, deploy, test, and iterate.

[tourmalinetaco]

At its simplest, rewrite and interface regularly with knowledge. There’s an entire hobby around personal knowledge management, and it‘s all up to you to find what works best, but taking meaningful notes and rewriting those notes, processing them further and further, will help form deeper mental connections regardless of method.

[disambiguation]

You're doing it right now, i.e ask questions and seek answers.

[j45]

There is a pretty good course called learning how to learn that seems to pop up every so often.

https://www.coursera.org/learn/learning-how-to-learn

[chii]

i learnt that at university - by essentially not being taught, but being given curiosity on the subject and told to research it.

I am not sure there's any hand holding that can be given to someone to learn how to learn.

[obrit]

Any recommendations on learning to "think clearly"? I feel like this is something I struggle quite a bit with and haven't found any good resources on improving it other than "sleep" and "exercise", which I'm not lacking in.

[beezlebroxxxxxx]

Unironically, that's what school is supposed to be for.

There's keeping the engine well maintained (the sleep and exercise part, for example) and there's driving the engine down new paths and honing you driving technique. You work on the latter by exposing yourself to novel and interesting arguments (interesting philosophy or argumentative non-fiction, for example) and then working through the argument again with counter-arguments in mind. I would not recommend pop-sci books for this, because their arguments and writing tends to be quite flabby.

I'd actually recommend something like RG Collingwood's "The Principles of Art" which is a relatively plain English example of well written philosophy:

https://archive.org/details/in.ernet.dli.2015.188470/page/n1...

You will disagree with him. The point is to understand how and why you disagree with him and to explain that clearly, not only to yourself but others as well. Thinking clearly is about responding and communicating clearly while displaying a sure and succinct understanding of the problem at hand.

You can apply that to everything you read or are confronted with, but the key thing to realize is that "thinking clearly" is something you practice. There is no one trick --- it's an approach.