Ask HN: How do you keep improving?

I focus each morning on working on the number one thing I have to do that day, in the afternoon I can attend to other less important tasks.

Josh Kaufman has some good tips (https://first20hours.com/).

Also as John Sonmez (https://simpleprogrammer.com/) would say - trust the process. Don't focus on immediate results, focus on the process of reaching your end goal

Personally, I used to find it tough to learn things I couldn't immediately apply. That's because I would try and commit them to memory in a way I could immediately retrieve them if required. So spawned a path of memory learning techniques... flash cards... ugh...

Then I was watching a Derren Brown show (a British 'mentalist') who taught a guy to memorise hundreds of books so that on command he could read out the content of any given book, any given page and any given number.

The individual would read the books in a particular way (picture dragging your fingers down in a v shape across the page). When asked to reiterate the content, it was very important that he just trusted his gut. And he got it right every time.

The key takeaway for me was that it's equally important to learn how to retrieve knowledge.

Slight tangent here, I also remember reading about how Steve Jobs was able to 'think outside the box' and come up with seemingly new ideas. And the suggestion was he was just good at retrieving knowledge through a confidence of confidence in himself and a non-pressured environment.

Hope that gives you something to think about!

2. Find a mentor. Lacking that, find e.g. talk of someone explaining some hard techniques and then try to follow the advice. Even and especially if it feels clumsy at first.

(More on those two here: https://codewithoutrules.com/2017/04/17/learning-without-a-m...).

3. Switch to a new job where you'll be exposed to new things. try to find a job where people do code review, feedback is how we learn faster.

4. Learn how to learn: https://www.youtube.com/watch?v=FKTxC9pl-WM

5. Reflect on your mistakes, try to find what cues you missed and what you should look for next time. I've been doing this on weekly basis (you can read the results at https://softwareclown.com) and I've learned a huge amount from figuring out underlying cause of what I did wrong.

Either you're doing the wrong tutorials, or give them more credence.

2) What I do:

i) Keep myself exposed to what is out there (Hacker News, Blogs, Twitter)

ii) Make sure I am always reading a book (audio books, usually)

iii) Be aware of the next wave of tech -- what is bleeding edge? (current answer: Machine Learning, VR/AR, Self-Driving Cars, Blockchain)

iv) Find resources to learn them: Coursera, Udacity, local colleges courses, meetup groups.

Next, distinguish between depth and breadth. Are you a generalist by nature, or a specialist? I'm a total generalist. I've achieved basic competence in a truly shocking variety of different subjects, but the main thing I'm an expert at is being a generalist. I've gotten very good at picking up new skills whenever I'm interested in them.

Other people are specialists. They find something they're passionate about, and they get good at it. Really good. They go deep. They may not know a whole lot of things, but that one thing they know, they know so well it's hard to even comprehend from the outside.

So are you a generalist by nature, or a specialist? Do you want to be one or the other? Pick a direction and start walking.

My most difficult projects have been done with C++ and took years. That experience still gives me an advantage even with JavaScript because I have developed pretty good instinct about what probably will work or not.

[0] - http://www.daedtech.com/how-developers-stop-learning-rise-of...

Once in a while I go back and review some of the work I did that day and look for ways to improve.

In practical terms that means that you need to change the way you write code. And that means practice. Katas are good, but you have to force yourself to do it differently than you would normally.

Here's an example of something I did recently: https://github.com/ygt-mikekchar/es6-monad-challenge/blob/ma...

This code is clearly insane. You would never do it this way in production. Or would you? In reality, how do you know what the advantages and disadvantages are if you never try it?

But small toys and katas are not enough. Architecture and design requires practicing on a big scale. That means side projects that you have complete control over. It's unfortunate, but this stuff takes time. If you like programming it's not bad, though :-)

Always get ideas from other people. Read books and blogs to get more ideas. Then go nuts. The hardest part is to have to courage to absolutely suck. Picking insane things to do will help with that because you don't have the feeling that it must turn out good in the end. It's insane.

Hope that helps!

I am rebuilding myself with this process and taking inspiration from Bhagwad Gita for that.

Few people are actual experts in a domain. It takes years to do.

To grow, one can either scale vertically or horizontally (paraphrased).

Now if we apply this to your situation , scaling horizontally would be learning new languages, ie. Objective-C, Javascript etc. I'm assuming you're not really about this but you want to scale vertically.

If scaling vertically is the case, then what you really want to focus on is doing something either 1) other people have not done before yet and/or 2) do something that is 10x better than what is already out there. I don't do too much C/C++ dev but maybe think about embedded, OS, GPU, etc.

If you accomplish 1) and/or 2), then you can truly master C/C++ dev. My 2 cents.

There will always be someone who knows more than you or is more skilled. Don't let that bother you. Instead, use those people as role models.

Simply awesome.

There are couple ways I keep up on things (keeping in mind that there are no absolutes and everyone is different).

First, I identify subjects that are both interesting to me and have traction with the developer community. Forums like this one are generally a good sniff test. I then subscribe to mailing lists that deal with that tech. I clip a lot of articles and code snippets to a datastore (Evernote in my case) where I can peruse my notes later. I install said tech and build little micro apps and generally futz around and have a good time. The key here is to be interested in the tech you are trying to learn. Maybe you are bored with C/C++? Whats the harm in looking at something totally different like Ruby or NodeJS? They might give you ideas or a different way of looking at things. Whatever it is, try to have fun. Learning doesn't have to be all drudgery.

When I want to take a deep dive (usually after a good bit of research mentioned above) I find a job working with the tech in question. Nothing will force me into gaining a deep deep understanding of a technology or concept like getting thrown into the deep end. After a year or two at that job, I emerge a ninja level dev in that area. Not a bad deal if you ask me. If that approach is too extreme maybe you can just set up a side project or contribute to open source? Anything that forces you to sit in a chair and produce functional code in the manner with which you want to learn is going to accelerate your learning in ways you never thought possible. Good luck!!

By familiarizing yourself with a large codebase, you'll start to pick up the patterns in use. Having your code reviewed by project owners is a great way to get others to help you improve.

Some projects and communities are better than others. Some can be hostile or quiet, others can be welcoming and active.

Don't just start by throwing PRs at random projects and hoping someone bites. Managing an open source project is work and initially you want to be causing as little extra work for the maintainers as possible.

I also think that having high standards is important if you want to keep improving.

So they're two general areas I'd suggest working on.

Learning new languages and different paradigms can also play a huge role in how you approach future problems. Go to glot.io and play around with a handful of languages you've never touched.

Read up on various best practices and style guides. Read blogs on architecture, design patterns, etc. I read probably 5-10 hacker news articles daily, but I also watch many videos on youtube such as pretty much anything by Martin Fowler, Rob Pike or any of the other greats.

Code stuff outside of your comfort zone. If you're a web developer, try writing some games. If you're a game developer, write a web server or a blazing fast load balancer that handles TCP/UDP sockets and HTTP. I code random shit all of the time just to gain some exposure even if I'm never likely to do related work in the future. I probably have a few dozen Go programs I've developed just because I was curious how something worked.

I've been programming for over 17 years starting with C++ when I was 13. Over the years, I've developed stuff in C/C++, Python, Ruby, Lua, C#, Java, JS, TypeScript, SQL, Dart and Go for the past 3 years. Each language has given me new insights in how to tackle problems that knowing say just C++ alone would not have lead me to.

TLDR: Exposure!!, Books, Blogs and LOTS of bouncing ideas off of other developers.

Deeply analyse those reads without ever touching a computer. If I feel the need to write code I usually write it in a paper sheet and analyse it.

I started by making a reasonably conplex TODO app, which took a few months. This taught me about the importance of declarative (popularized by React) style programming, and MVC separation.

Then I moved on to building a Vim extension for visual studio code. This took about 6 months, and taught me a bunch about programming larger apps and keeping them bug free. I also learned a lot about open source maintenance. I learned why Redux-style architectures are important.

Then I moved on to working on a fully featured pixel editor. This has been my toughest app of all. I've been working on it for about 4 months full time at this point, and I've learned so much about canvas perf, js perf, the importance of end to end testing, ... I could go on for a very long time. :)

And this is all a warmup for an even larger app I haven't started on...

This approach seems to have worked well for me, and I'd recommend a similar style approach of working your way up from smaller programs to larger apps. You learn lessons from smaller apps that will save you a lot of time when coding larger apps.